In the agile world, navigating the success of a project relies on understanding and mastering key performance indicators, better known as KPIs (Key Performance Indicators).
Key points
In this article, we’ll dive into the essence of agility by exploring five essential metrics : Business Value, Velocity, Reliability, Cost, and the dreaded “Project Burndown.”
In addition, we will unveil five recommended KPIs, such as “Sprint Burndown“, Anticipation, Predictability, Responsiveness, and adding a touch of human measurement, TurnOver and the famous Kiffometer. Get ready to demystify these metrics and skillfully integrate them into your agile project management arsenal.
Essential Agile Metrics
Business Value
| Definition |
| Progress of the delivered product in business value |
| Measure |
| Sum of the estimated business value of the product’s delivered user stories |
| Target |
| = The target business value of the final product * number of sprints produced / total number of sprints |
| Comment |
| The progress of an agile project is measured by the business value of the product delivered without taking into account the current sprint. The Product Owner’s responsibility is to maximize the business value of the product. |
Reliability (Quality)
| Definition |
| Functional quality of the product delivered at the end of the sprint |
| Measure |
| %Reliability = 100% – Defect rate. Defect rate = Number of bugs detected and proven after the sprint compared to the sum of the sizes in story points) of the delivered user stories |
| Target |
| target reliability (0.2 per story point = default rate of 0.1 if 1 story point = 1d RTU and if RTU/Project coeff = 2) |
| Comment |
| Measures the team’s ability to deliver a functional and operational product. Products delivered by agile teams are generally of higher quality than with traditional methods where teams are less accountable |
Velocity
| Definition |
| Team effort capacity per sprint |
| Measure |
| Sum of the estimated sizes (in story points) of user stories delivered per sprint. |
| Target |
| = sum of the estimated sizes (in story points) of the remaining user stories in the Product Backlog divided by the number of sprints remaining |
| Comment |
| Measures the team’s ability to turn user stories into product increments. Velocity increases and then usually stabilizes after 3 sprints (at equivalent capacity in number days produced), except in the case of a change in resources. in the team or problems encountered in the development |
Cost
| Definition |
| Cost (or overhead) of developing the story point |
| Measure |
| Budget (or load) consumed per sprint divided by velocity |
| Target |
| = budget (or load) of the project in relation to the estimated size (in story points) of the project Estimated velocity project < remains to be done * number of sprints remaining |
| Comment |
| Allows you to track compliance with the allocated budget (or initial expenses) |
Project Burndown
| Definition |
| Measuring the team’s ability to deliver the Product Backlog |
| Measure |
| Sprint-by-sprint progress report that shows the follow-up of the remaining work throughout the project. The X-axis represents time and the Y-axis shows the size (in story points) of the remaining user stories in the Product Backlog by priority level |
| Target |
| Estimated < project velocity * number of sprints remaining |
| Comment |
| The monitoring of the burndown of the project is an important indicator for the Product Owner to estimate up to what level of priority the user stories will be treated in the product |
Recommended Agile Metrics
Sprint burndown
| Definition |
| Measuring the team’s ability to deliver the sprint backlog |
| Measure |
| A daily progress report for sprint tasks that shows the tracking of remaining work throughout the sprint. The X axis represents time and the Y axis shows the amount of work that remains to be done (in hours) |
| Target |
| Estimated < remaining capacity of the sprint remains to be done |
| Comment |
| The day-to-day monitoring of the achievement of the sprint objective is the responsibility of the development team. It is not useful to bring this indicator up to the sponsor level as the sprints are short. The BurnUp of the sprint in User Story is an additional indicator of the progress of the sprint. |
Kiffometer
| Definition |
| Level of trust in the team |
| Measure |
| At the end of each Sprint, average satisfaction of the SCRUM team. It materializes in the propensity (on a scale of 0 to 5) of each member to recommend the team and the project to a colleague (including the Scrum Master and the Product Owner |
| Target |
| >3 |
| Comment |
| The success of an agile project through customer and team satisfaction. Requires a good degree of maturity. |
TurnOver
| Definition |
| Level of stability of the Team Resources |
| Measure |
| Number of resource changes in the team compared to the total number of resources in the team (including Product Owner and Scrum Master) |
| Target |
| <20% |
| Comment |
| This indicator has a direct impact on velocity. Take into account voluntary replacements of resources even if they are beneficial to the project because they generally denote poor initial staffing and impact velocity. To be presented to the customer in control mode. |
Predictability
| Definition |
| Level of confidence in the team’s commitment to sprint planning |
| Measure |
| %difference between the estimated size (in story points) of user stories delivered in Sprint Review compared to the estimated size (in story points) of user stories engaged in Sprint Planning |
| Target |
| >80% |
Reactivity
| Definition |
| Average processing time for priority requests for change or correction |
| Measure |
| The number of days between the date a new request was created in the Product Backlog and the date the request was delivered to the product |
| Target |
| <2 sprints |
| Comment |
| In a DevOps approach, talk about CycleTime, i.e. the time between the issuance of a request and its actual use in production. It is possible to measure it in average time by priority/size of the request. |
Anticipation
| Definition |
| Refinement level of Baklog Product items |
| Measure |
| Sum of the estimated sizes (in story points) of the ‘Ready’ user stories. to be expanded in the Product Backlog |
| Target |
| velocity |
| Comment |
| Measure that refined Product Backlog items are transparent, sufficiently understood, and granular to be considered for Sprint planning and chosen for Sprint. Allows you to estimate the level of risk of breaking loads for the development team |
0 Comments