Nine user story metrics I care about while coaching Scrum teams
Goal: put in numbers the team performance. Numbers talk to everyone. When we see 98% performance there is no discussion.
Before you measure metrics, make sure they represent the team efforts. How many of us did study hard for an exam and ended up with a low mark? I can tell you that ones in university I study day and night for the networking exam and I ended up with 0.25 out of 10. It was the lowest mark I ever took in my academic path. That was a life lesson my teaches taught me: work smart and with a purpose. Understand where you are heading and learn to measure your performance.
Years later that’s the number 1 goal before starting to measure:
- Understand why we measure performance.
- What will happen with the metrics
- How do we use the parameters?
- WHO uses the metrics?
The team must agree on the answers to the questions above. Only after that, it makes sense to track metrics.
Below the list of my prefered metrics to track and how I use them:
1. Goals.
As an Agile Coach, I care about the team achieving the sprint goals. Stories are essential of course, but if the target can be achieved with other user stories, that’s perfectly fine. We can have story points done, but if they aren’t related to the sprint goal, or they don’t serve the purpose, it doesn’t help. The goals must be specific, measurable, achievable, realistic, timeable. The goals are a health indication for everyone on the performance of the team. Are we achieving the goals?
2. Velocity. Velocity is about consistency. We need the persistence to build predictability. Here is where the waterfall project management fails. There are multiple estimation techniques which work depending on the seniority of the team and time working together. But Velocity is about going long run on the natural pace of the group. The estimation is not calculated mathematically, but natural. Statistically speaking, it is proven to be more reliable than any mathematical calculations. A constant Velocity is the indication of a strong team and sustainable development. The velocity is used to plan the product roadmap and future sprints. So next time, instead of counting the story points as velocity, count the predictability of the speed.
3. Burndown. While looking at a burndown chart, I can think about plateau and drops. The plateaus indicate a lot of stories in progress and not finished. And the big drops usually follow the plateaus show high risk. It is either an indication of lack of daily discipline in updating the team board or multiple stories started but not finished. I always recommend teams to have fewer stories “done” that can go on production than numerous stories began, and nothing ready to be released.
4. Defect count per sprint. It is a simple count of the number of defects raised during the active sprint. Anomalies are unpredicted but urgent work. It makes it impossible to plan.
5. Defect count per story. Hard to track, but it’s worth the effort. I like to track these metrics because it shows us problematic user stories (if there are, trends, the cause of defects and as a team, we can find a solution to it.
6. Story completion ratio. I use this metric mostly in retrospectives. It is a metric to help the team to identify the root causes and solutions to respect the definition of done and arrive at the end of the sprint with more stories completed than half “done”.
7. Story point completion ratio. It is a handy tool for the team and the way they forecast the capacity. You can calculate this user story metric by the number of stories completed vs the number of user stories planned. Very important to include user stories abandoned from the sprint and stories carried over from previous agile sprints.
8. Time blocked per story. To measure these metrics, you first need to track the blockers linked to the scrum user stories they are blocking. You’ll count the time from the moment the user story is blocked until the impediment is resolved. This metric will tell you how much is the workflow affected by the barriers. The blockers are usually sign-offs, approvals, handovers.
9. % of items blocked. This metric measures the percentage of user stories in a sprint are blocked by impediments. As a benchmark, you can have a maximum of 10% of user stories stuck. This metric must be used to investigate the root-cause analyses of the issues outside the scrum team that slows down the scrum team.
Conclusion: while numbers are fascinating to watch, make sure that the scrum team and the other stakeholders are using the metrics to deliver better products.
You might be interested in:
