Developer Productivity Metrics | DORA Guide
Measure developer productivity with DORA metrics, cycle time, and throughput. GitScrum provides meaningful team metrics without creating perverse incentives.
6 min read
Measuring developer productivity is essential but fraught with danger. Bad metrics create gaming, destroy morale, and miss what matters. Good metrics provide insight, drive improvement, and respect the complexity of software development.
Metrics Philosophy
| Avoid | Embrace |
|---|---|
| Lines of code | Value delivered |
| Commits per day | Cycle time |
| Hours worked | Throughput |
| Individual ranking | Team performance |
| Activity metrics | Outcome metrics |
Useful Metrics
DORA Metrics
DORA METRICS FRAMEWORK
══════════════════════
DEPLOYMENT FREQUENCY
├── How often code is deployed to production
├── Elite: Multiple times per day
├── High: Weekly to monthly
├── Medium: Monthly to yearly
├── Low: Less than yearly
LEAD TIME FOR CHANGES
├── Time from commit to production
├── Elite: Less than one hour
├── High: One day to one week
├── Medium: One week to one month
├── Low: More than one month
CHANGE FAILURE RATE
├── Percentage of deployments causing issues
├── Elite: 0-15%
├── High: 16-30%
├── Medium: 31-45%
├── Low: 46-100%
MEAN TIME TO RECOVER (MTTR)
├── Time to restore service after incident
├── Elite: Less than one hour
├── High: Less than one day
├── Medium: One day to one week
├── Low: More than one week
Flow Metrics
FLOW METRICS
════════════
CYCLE TIME
├── Time from work started to work completed
├── Measures: Development efficiency
├── Good for: Identifying bottlenecks
├── Target: Consistent, trending down
Typical Breakdown:
├── Development: 40%
├── Code review: 30%
├── QA/Testing: 20%
└── Deploy: 10%
LEAD TIME
├── Time from request to delivery
├── Measures: Total responsiveness
├── Good for: Customer perspective
├── Includes: Queue time before starting
THROUGHPUT
├── Items completed per time period
├── Measures: Delivery capacity
├── Good for: Planning, predictability
├── Compare: Week over week
WORK IN PROGRESS (WIP)
├── Items currently in progress
├── Measures: Focus vs. context switching
├── Good for: Overload detection
├── Target: Low and stable
Quality Metrics
QUALITY METRICS
═══════════════
BUG DENSITY
├── Bugs per feature or per release
├── Trend: Should decrease over time
├── Action: Invest in testing if high
└── Context: Some features naturally riskier
TEST COVERAGE
├── Percentage of code covered by tests
├── Target: 70-80% (not 100%)
├── Action: Cover critical paths
└── Warning: Coverage ≠ quality
CODE REVIEW METRICS
├── Time to first review
├── Review cycles per PR
├── Trend: Should be stable
└── Action: Improve if increasing
TECHNICAL DEBT
├── Known debt items tracked
├── Debt addressed per sprint
├── Trend: Should not grow unchecked
└── Action: Allocate capacity
Measuring the Right Way
Team Not Individual
WHY TEAM METRICS
════════════════
INDIVIDUAL METRICS PROBLEMS:
├── Encourages gaming
├── Ignores collaboration value
├── Punishes helping others
├── Creates competition
├── Misses pair/mob programming
└── Demotivating
TEAM METRICS BENEFITS:
├── Encourages collaboration
├── Shared ownership
├── Focuses on outcomes
├── Reduces gaming incentive
├── Celebrates team success
└── More accurate
EXAMPLE:
Instead of:
"Sarah committed 47 times this week"
Use:
"Team delivered 5 features this sprint
with 0 production incidents"
Avoid Vanity Metrics
VANITY VS ACTIONABLE METRICS
════════════════════════════
VANITY METRICS:
✗ Lines of code written
✗ Commits per day
✗ Hours logged
✗ Stories completed count
✗ Velocity points (easily inflated)
WHY THEY'RE BAD:
├── Easily gamed
├── Reward wrong behavior
├── Miss quality
├── Create perverse incentives
└── Don't correlate with value
ACTIONABLE METRICS:
✓ Cycle time (can improve process)
✓ Deployment frequency (measures flow)
✓ Change failure rate (measures quality)
✓ Customer issues (measures impact)
✓ Developer experience (measures sustainability)
WHY THEY'RE GOOD:
├── Hard to game
├── Tied to outcomes
├── Drive improvement
├── Balanced view
└── Actionable
Dashboards and Visibility
Productivity Dashboard
TEAM PRODUCTIVITY DASHBOARD
═══════════════════════════
┌─────────────────────────────────────────────────────────┐
│ Engineering Productivity - March 2024 │
├─────────────────────────────────────────────────────────┤
│ │
│ DORA METRICS │
│ ┌─────────────┬─────────────┬─────────────┐ │
│ │ Deploy Freq │ Lead Time │ Fail Rate │ │
│ │ 3.2/day │ 2.1 days │ 4.2% │ │
│ │ ↑ from 2.8 │ ↓ from 2.8 │ ↓ from 6% │ │
│ │ 🟢 Elite │ 🟢 High │ 🟢 Elite │ │
│ └─────────────┴─────────────┴─────────────┘ │
│ │
│ FLOW METRICS │
│ Cycle Time: 4.2 days avg (↓ 0.5 from last month) │
│ Throughput: 23 items/week (stable) │
│ WIP Average: 2.1 per developer (healthy) │
│ │
│ QUALITY │
│ Bug Density: 0.3 bugs/feature (↓ good) │
│ Test Coverage: 78% (stable) │
│ Review Time: 4.2 hours avg (acceptable) │
│ │
│ TRENDS (6 months) │
│ Cycle Time: ↘↘↘↘↘ Improving │
│ Throughput: →→→↗↗ Stable/growing │
│ Quality: →→→→↗ Stable/improving │
│ │
└─────────────────────────────────────────────────────────┘
Developer Experience
DEVELOPER EXPERIENCE SURVEY
═══════════════════════════
QUARTERLY SURVEY QUESTIONS:
(Scale 1-5, with comments)
FLOW & FOCUS:
├── I can focus on coding without interruptions
├── I have the tools I need to be productive
├── Our processes help rather than hinder
QUALITY & SUSTAINABILITY:
├── I'm proud of the code we ship
├── Technical debt is manageable
├── Our workload is sustainable
COLLABORATION:
├── Code reviews are helpful and timely
├── I can get help when I need it
├── Team communication works well
GROWTH:
├── I'm learning and growing
├── I understand our architecture
├── I can influence technical decisions
AGGREGATE SCORE:
├── Team DX Score: 4.1/5 (↑ from 3.8)
├── Track over time
└── Act on feedback
Best Practices
For Productivity Metrics
Anti-Patterns
METRICS MISTAKES:
✗ Individual productivity rankings
✗ Lines of code as measure
✗ Punishing based on metrics
✗ Single metric focus
✗ Metrics without action
✗ Gaming-prone measures
✗ Ignoring developer experience
✗ Comparing teams directly