Sharing My Playbook on KPIs
Over the years, I've put together a set of Key Performance Indicators (KPIs) that have helped my teams focus on what matters. I thought it might be useful to share them here. Take what you like, adapt what you don't—every team is different.
As always, numbers don't tell the whole story. KPIs are just a starting point. They are meant to be a guide, not a rule.
Inputs: Setting the Stage
Team Environment
Assess whether the team has the right mix of experience and roles.
A balanced team tends to perform efficiently and adapt to challenges.
Backlog Health
Align the number of groomed items with the team’s velocity.
Formula: Backlog Health = Number of Groomed Items ÷ Average Items per Sprint.
A healthy backlog keeps the team moving without downtime.
Backlog Stability
Percentage of planned items that remain unchanged after the sprint starts.
High stability means fewer mid-sprint surprises.
Accountability
Ratio of delivered work to committed work.
Reflects the team's ability to meet its commitments.
Outputs: Measuring What We Deliver
Deploy Frequency
Number of deployments per day.
Frequent deployments enable faster feedback and value delivery.
Deploy Size
Percentage of the codebase changed in each deployment.
Smaller deploys reduce risk and make troubleshooting easier.
The 5% threshold is completely arbitrary—consider it a starting point. You know your product suite and codebase better than I do.
Failure Rate
Percentage of deployments that result in failures.
Lower failure rates indicate effective testing and high code quality.
Recovery Time
Average time to recover from failures.
Quick recovery minimizes customer impact.
Example Team KPI Analysis
To illustrate how these KPIs can be applied, here's a look at five fictional teams. Remember, these are just examples—your team's context might lead to different interpretations.
| Team Name | Team Environment | Backlog Health (%) | Backlog Stability (%) | Accountability (%) | Deploy Frequency | Deploy Size (%) | Failure Rate (%) | Recovery Time |
|---|---|---|---|---|---|---|---|---|
| The Firebirds | High Performing | 200% | 85% | 92% | 1.5/day | 4% | 0.8% | 8 mins |
| Thunderbolt Guild | Needs Improvement | 150% | 78% | 87% | 0.5/day | 6% | 1.5% | 12 mins |
| Stormriders | At Risk | 50% | 75% | 65% | 2/day | 5% | 3% | 15 mins |
| Iron Giants | High Performing | 300% | 90% | 96% | 0.2/day | 3% | 0.5% | 5 mins |
| Dragonfly Order | Needs Improvement | 250% | 80% | 90% | 1/day | 14% | 1% | 10 mins |
The Firebirds
The Firebirds
Balanced metrics and overall stability.
Consider smaller chunks, more frequently, but you know your codebase better than I do.
Thunderbolt Guild
Thunderbolt Guild
Strong overall performance with consistent deployments.
Look into backlog stability. Are you fending off feature requests all day? Are there a lot of customer complaints and defects?
Stormriders
Stormriders
High deployment frequency shows a strong delivery focus.
Maybe consider feature flags and/or blue+green deployments a bit to boost quality.
Iron Giants
Iron Giants
Excellent stability and low failure rates indicate robust processes.
The size of deployment is small, but infrequent. Why?
Dragonfly Order
Dragonfly Order
Stable performance with a healthy backlog.
Overall health, releases are a bit large. Have you looked at root causes?
Bringing It All Together
These KPIs aren't about grading teams or pointing fingers. Think of them as signals—indicators that help us understand where we might need to focus our attention. Teams can use these metrics to escalate risks, ask for help, or simply benchmark against their own past performance.
The key takeaway is that these KPIs are tools to aid continuous improvement, not strict standards to enforce.
Remember, this is just my playbook. Feel free to adapt it, ignore parts that don't resonate, and make it your own.