Developer Productivity Metrics | DORA & Cycle Time
Track developer productivity with DORA metrics and cycle time analysis. GitScrum analytics identify bottlenecks and process improvements for teams.
7 min read
Productivity measurement should identify systemic improvements, not rank individual developers. GitScrum's analytics provide team-level insights into velocity, cycle time, and throughput that help managers identify bottlenecks and process improvements. The key is measuring the system, not the people—and using data to remove obstacles rather than apply pressure.
Productivity Metric Categories
| Category | Good Metrics | Bad Metrics |
|---|---|---|
| Output | Features shipped, PRs merged | Lines of code, commits |
| Quality | Bug rate, incidents | Code coverage % alone |
| Speed | Cycle time, lead time | Hours logged |
| Flow | WIP, blocker time | Tasks started |
| Impact | Customer value, revenue | Story points as absolute |
DORA Metrics Framework
DORA METRICS OVERVIEW
DEPLOYMENT FREQUENCY (Speed):
┌─────────────────────────────────────────────────┐
│ How often do you deploy to production? │
│ │
│ Elite: Multiple times per day │
│ High: Between once per day and once per week│
│ Medium: Between once per week and once per mo │
│ Low: Less than once per month │
│ │
│ Your team: Weekly deployments │
│ Status: High performer │
└─────────────────────────────────────────────────┘
LEAD TIME FOR CHANGES (Speed):
┌─────────────────────────────────────────────────┐
│ Time from commit to production │
│ │
│ Elite: Less than one hour │
│ High: Between one day and one week │
│ Medium: Between one week and one month │
│ Low: More than one month │
│ │
│ Your team: 2-3 days average │
│ Status: High performer │
└─────────────────────────────────────────────────┘
CHANGE FAILURE RATE (Stability):
┌─────────────────────────────────────────────────┐
│ % of deployments causing production failure │
│ │
│ Elite: 0-15% │
│ High: 16-30% │
│ Medium: 31-45% │
│ Low: 46-60% │
│ │
│ Your team: 12% │
│ Status: Elite performer │
└─────────────────────────────────────────────────┘
TIME TO RESTORE (Stability):
┌─────────────────────────────────────────────────┐
│ Time to recover from production failure │
│ │
│ Elite: Less than one hour │
│ High: Less than one day │
│ Medium: Between one day and one week │
│ Low: More than one week │
│ │
│ Your team: 2-4 hours │
│ Status: High performer │
└─────────────────────────────────────────────────┘
Developer Experience Metrics
DEVELOPER EXPERIENCE (DX) METRICS
SPACE FRAMEWORK:
┌─────────────────────────────────────────────────┐
│ S - Satisfaction and Well-being │
│ ├── Developer satisfaction surveys │
│ ├── Burnout indicators │
│ └── Team morale scores │
│ │
│ P - Performance │
│ ├── Code review turnaround time │
│ ├── Quality of reviews │
│ └── Outcomes delivered │
│ │
│ A - Activity (use carefully) │
│ ├── PRs merged (team level) │
│ ├── Build/deploy frequency │
│ └── NOT: commits, lines of code │
│ │
│ C - Communication and Collaboration │
│ ├── Knowledge sharing │
│ ├── Documentation quality │
│ └── Onboarding time │
│ │
│ E - Efficiency and Flow │
│ ├── Time in meetings │
│ ├── Wait/blocked time │
│ └── Context switches per day │
└─────────────────────────────────────────────────┘
QUARTERLY DX SURVEY:
┌─────────────────────────────────────────────────┐
│ Scale 1-5: │
│ │
│ Q1: I can do my best work here │
│ Q2: I rarely have to wait on blockers │
│ Q3: I understand what I should be working on │
│ Q4: Our tools help rather than hinder me │
│ Q5: I have enough focus time │
│ Q6: I'm proud of the quality of our code │
│ Q7: I'm learning and growing │
│ │
│ Track trends quarter over quarter │
└─────────────────────────────────────────────────┘
Cycle Time Analysis
CYCLE TIME BREAKDOWN
END-TO-END CYCLE TIME:
┌─────────────────────────────────────────────────┐
│ Task Created → Done │
│ │
│ Total: 8.5 days average │
│ │
│ Breakdown: │
│ ┌────────────────────────────────────────────┐ │
│ │ Queue (To Do) │████████ 3.2 days (38%)│ │
│ │ Development │█████ 2.1 days (25%)│ │
│ │ Code Review │████ 1.8 days (21%)│ │
│ │ Testing/QA │███ 1.1 days (13%)│ │
│ │ Deployment Queue │█ 0.3 days (3%) │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Observation: 38% time waiting in queue │
│ Action: Reduce WIP to improve flow │
└─────────────────────────────────────────────────┘
FLOW EFFICIENCY:
┌─────────────────────────────────────────────────┐
│ Active work time: 2.1 days (development) │
│ Total time: 8.5 days │
│ Flow efficiency: 25% │
│ │
│ Industry targets: │
│ ├── Poor: < 15% │
│ ├── Average: 15-30% │
│ ├── Good: 30-50% │
│ └── Elite: > 50% │
│ │
│ Your status: Average - room to improve │
└─────────────────────────────────────────────────┘
Metrics Dashboard
PRODUCTIVITY DASHBOARD
TEAM HEALTH OVERVIEW:
┌─────────────────────────────────────────────────┐
│ │
│ Velocity Trend (Story Points): │
│ 40 ┤ ●────● │
│ 35 ┤ ●──●───● │
│ 30 ┤ ●──●───● │
│ 25 ┤ ●───● │
│ └──────────────────────────── │
│ S1 S2 S3 S4 S5 S6 S7 S8 │
│ │
│ Trend: Steady improvement (+50% over 8 sprints)│
│ │
└─────────────────────────────────────────────────┘
KEY METRICS THIS SPRINT:
┌─────────────────────────────────────────────────┐
│ Metric Value Trend │
│ ────────────────────────────────────────── │
│ Cycle Time 7.2 days ↓ Improving │
│ Deployment Frequency 3/week → Stable │
│ PR Review Time 4.5 hours ↓ Improving │
│ Bug Escape Rate 5% → Stable │
│ Blocked Time 8% ↑ Concern │
│ │
│ Action: Investigate blocked time increase │
└─────────────────────────────────────────────────┘
BLOCKERS ANALYSIS:
┌─────────────────────────────────────────────────┐
│ Top blockers this sprint: │
│ ├── Waiting for code review: 35% │
│ ├── Unclear requirements: 28% │
│ ├── Dependencies: 22% │
│ └── Environment issues: 15% │
│ │
│ Actions: │
│ 1. Add code review SLA (< 4 hours) │
│ 2. Improve backlog refinement │
└─────────────────────────────────────────────────┘
What Not to Measure
ANTI-PRODUCTIVITY METRICS
VANITY METRICS (Don't track):
┌─────────────────────────────────────────────────┐
│ ✗ Lines of code │
│ Why: Encourages bloat, punishes refactoring │
│ │
│ ✗ Commits per day │
│ Why: Encourages small meaningless commits │
│ │
│ ✗ Hours logged │
│ Why: Measures presence, not output │
│ │
│ ✗ Story points per developer │
│ Why: Points aren't comparable across people │
│ │
│ ✗ PRs per developer │
│ Why: Encourages splitting unnecessarily │
│ │
│ ✗ Issues closed per person │
│ Why: Encourages cherry-picking easy ones │
└─────────────────────────────────────────────────┘
GOODHART'S LAW:
┌─────────────────────────────────────────────────┐
│ "When a measure becomes a target, │
│ it ceases to be a good measure" │
│ │
│ Example: │
│ Target: Reduce bug count │
│ Result: Team stops logging bugs as bugs │
│ │
│ Solution: Measure outcomes, not activities │
│ Focus on customer value delivered │
└─────────────────────────────────────────────────┘
Best Practices
Anti-Patterns
✗ Lines of code as productivity measure
✗ Individual leaderboards
✗ Metrics used punitively
✗ Measuring activity over outcomes
✗ Gaming metrics (Goodhart's Law)
✗ Secret dashboards management sees only