Valuable Agile Metrics

What are some valuable Agile Metrics and how do you use them?

Getting an accurate picture of a project and agile team has many benefits. But what resources should you use to get that picture. Hard data is the base. Using these key metrics, combined with sharing the backstory to each, will make every agile team perform at their best.

Benefits of tracking and using these key metrics not only help leadership understand how the agile team is performing, but it will also help the agile team measure experiments, provide confident planning, and increase output quality.

Story Points

⚠ Do NOT use Story Points to measure or compare teams!

Story points are unique to each team and are used to help planning, and a base for some of the metrics listed below. The biggest pitfall teams or leader will face is using story points as a measuring stick.

Now that I got that important warning out of the way, what are story points?

Story points are used to measure the complexity of a user story. Agile teams decide as a team how complex a story may be and assign a number to it in the Product Backlog Refinement ceremony. Most teams use the Fibonacci sequence to avoid equative story points to hours.

Story points will be used as a base for some of the metrics below. For the purpose of this article, the total amount of story points in a sprint is the velocity.

Average Velocity

The Average Velocity is the average amount of story points the agile team is completing. Only use a limited amount of past sprints to calculate the average, 3 to 5 sprints is recommended.

Significance:
Average Velocity helps the agile team identify and plan the upcoming sprint according to capacity. It will also help the agile team forecast the number of approximate number of sprints required to complete a feature.

Goal:
Increase and stabilize over each sprint.

Rationale:
An increasing Average Velocity indicates more value is being delivered by the agile team. As the agile team matures, the Average Velocity should stabilize.

Calculation:
Total of last X sprint’s completed story points / X sprints.
Ex. (35 + 30 + 38) / 3 = 34 Average Velocity.

Velocity Variance

Velocity Variance indicates how stable the team’s velocity is over multiple sprints. Velocity Variance shows the percentage difference what the last sprint’s velocity was compared to the team’s average velocity.

Significance:
Velocity Variance allows an agile team to see that their sprint commitments are reasonable. It will also provide a level of confidence predicting the completion of a feature.

Goal:
Between 10% to -10% Velocity Variance.

Rationale:
If the Velocity Variance is well outside the recommended 10%, teams will not be able to plan long term. Understanding some tolerance is needed to handle reduced capacity, or unplanned production issues.

Calculation:
((Sprint Velocity / Average Velocity) — 1) * 100
Ex. ((30 / 34) — 1) * 100 = -11.8% Velocity Variance.

Committed vs. Completed

Committed vs. Completed is the number of story points that were committed to at the beginning of the sprint vs. the number of the story points that were committed to at the beginning of the sprint that were completed. It is measured as a percentage.

Significance:
Offers insights into whether an agile team is over committing or under committing in each sprint. It will also demonstrate if an agile team us effective at managing their commitments.

Goal:
Depending on the maturity of the agile team, between 85% — 90%.

Rationale:
A strong Committed vs. Completed allows a team to plan slack in a sprint to handle unplanned work or experiments. Maintaining a high ratio consistently is crucial for strong predictability.

Calculation:
(Initially committed Story points done / Initial committed Story points completed) * 100
Ex. (30 / 34) * 100 = 88% Committed vs. Completed ratio.

Backlog Health

Backlog Health is the ratio of user stories an agile team has in their Product Backlog that is ready to work on. This agile metric is based of the total number of story points that meet the Definition of Ready divided by the average velocity.

Significance:
Provide insight in the effectiveness of the team’s Agile Product Backlog Refinement. Will provide more information on the team’s planning performance. Improves the accuracy of delivery timelines the agile team provides.

Goal:
2 — 3 sprints worth of user stories that meet the Definition of Ready.

Rationale:
Having a Backlog Health of greater than 3 can results in stories will lead to user stories becoming stale causing the agile team to refine the user story again. Having one or less Backlog Health will cause the agile team to not be ready for the next sprint which will lead to rushed refining of user stories in Sprint Planning.

Calculation:
Story points meeting Definition of Ready / Average Velocity
Ex. 87 / 34 = 2.6 Backlog Health.

Automated Test Coverage

Automated Test Coverage is the ratio of number of automated user test to the number of functions/modules in the codebase. This agile metric is a percentage, and covers the entire codebase.

Significance:
Automated Test Coverage improves the quality of the work outputted, and allows the agile team to deploy quicker. It is the leading indicator of the quality of software released to production.

Goal:
75% Automated Test Coverage with continuous improvement sprint over sprint.

Rationale:
The higher percentage of code that is covered by quality Automated Test provides confidence that the product being released to production is stable. Low or dropping Automated Test Coverage may be a sign that the agile team is too product focused without time to create Automated User Test. Technical debt and Automated user test may need to be prioritized.

Calculation:
N/A — Gathered through tooling.
Ex. 72% Automated Test Coverage.

Post Production Defects

Post Product Defects is the total number of new defects reported each sprint in a production environment.

Significance:
Post Production Defects will provide insight of the quality of work that is released to a production environment. This agile metric will also highlight what areas of user test need improvement. The Post Production Defects metric may indicate improved user story quality is needed.

Goal:
0 Post Production Defects per sprint.

Rationale:
High performing agile teams strive for high quality releases to create a seamless experience for stakeholders and the end user. Continuing sprints without new Post Production Defects gains the confidence of stakeholders and leadership which will lead to more independence for the agile team.

Calculation:
Count of Post Production Defects reported in the sprint.
Ex. 2 Post Production Defects

Cycle Time

Cycle Time is the amount of time that has passed from when the user story was started as “work in progress” till the user story meets the Definition of Done. This agile metric is very helpful for Kanban teams but Scrum teams could also use it to improve.

Significance:
Cycle Time provides an indication of the average time a user story is being worked on. The Cycle Time report will highlight outliners and opportunities for improvement.

Goal:
The Cycle Time reduces over each sprint.

Rationale:
When the average Cycle Time decreases over each sprint, the agile team is proving their processes are improving. If the average Cycle Time is increasing it could be an indicator that the agile team is not focused, or their processes need improvement.

Calculation:
Time when user story met the Definition of Done — Time when the user story
Ex. June 12, 12:30 pm — June 12, 9:30 am = 3 hour Cycle Time

Conclusion

Tracking and utilizing key metrics benefits not only leadership, by providing insight into the agile team’s performance, but also the agile team itself, by aiding in the measurement of experiments, enabling confident planning, and enhancing the quality of output.

Share in the comments what valuable Agile Metrics that work for you and your team.

👏 If you have enjoyed reading my article, remember to comment, clap, and highlight. It will encourage me to write more content.