Scrum metrics are the standards for measuring the deliverables of the scrum team and the number of values is being transferred to the customer.
They also help in analysing the effectiveness of the scrum team. By effectiveness, we mean that the impact of scrum team practices is having in providing customer satisfaction and improving business aspects.
Even the scrum team metrics available to check its health and understand the problems in their working and how they can improve.
We will discuss some of the scrum metrics used by enterprises to evaluate their scrum teams.
Velocity uses the story points as a measuring unit in the scrum framework. A story point is the measure of the amount of completion sprint after sprint.
Velocity is calculated as the average of the total number of story points accepted by the stakeholders in the last few sprints.
Velocity trends are generated by graphically comparing the average story points with the story points in each sprint. Here average story points are regarded as 100% and each sprint’s story points relative to it.
The velocity can also be calculated by monitoring the fluctuation of story points per sprint. According to the enterprise’s standards, the upper limit bracket and the lower limit bracket is defined.
The story points are expected to be within these limits. If it’s not then there is some problem.
There can be many reasons possible for this like,
- Team members are changing very frequently
- Unavailability of proper requirements
2. Commitment Reliability
Commitment Reliability is also measured with story points as a unit. It tells about ‘ how reliable the commitment of the scrum team is?’.
It is analysed by comparing the total number of story points accepted with the number of story points acceptance committed at the beginning of the sprint.
The formula for calculating it is equal to (accepted points/committed points)*100. Accepted points mean the number of points validated by the product owners.
3. Capacity Utilisation
It is measured based on efforts estimation. The efforts are estimated based on the time invested in hours or days.
Capacity utilisation is the measure of what percent of the time is utilised by the scrum team to deliver from the whole sprint time available.
The formula used to calculate it is equal to (Committed/Available)*100.
It helps in realising that ‘is the team working to its full potential or not?’. It may also explain the reason for the delivery of weak product in the market.
4. Efforts Estimation Variance
There are two kinds of capacity. First one is the planned capacity and another one is committed capacity. At the end of the sprint, the scrum reporting is required to check the actual efforts the team put.
There are two kinds of values generated in this agile development metrics:
- Over Estimation, which is equal to ((Estimated – Actual)/Estimated)*100.
- Under Estimation, which is calculated by the formula equal to ((Actual – Estimated)/Estimated)*100.
The values generated helps us to realise that we over or underestimated the capacity of the scrum team. It guides that what changes should be done in a team or it is working so that the difference between the estimated and actual capacity can be minimised.
5. Scope Change
Scope Change is also measured in the unit of story points. At the time of sprint planning, many user’s story points are committed to achieving.
But when the actual sprint starts there is the situation that may arise like the product owner informs to add or remove some story points.
It is very common in real-life practices that during a sprint in progress some requirements may feel like unnecessary or some more requirements are felt necessary to include.
These practices are not considered to be good. There are some descoped story points and some added story points associated with a sprint.
- So De-scoped is calculated as (D/C)*100
- Scope increase is equal to (A/C)*100
Above given ‘A’ refer to Added, ‘D’ refers to Removed and ‘C’ to Committed story points.
There can be various reasons for significant trends observed in scope change metrics like:
- A backlog is not fully defined or groomed at the time of sprint planning.
- Dependencies that block the stories to reach the team before the spring begins.
- The product owner is not clear about the requirements.
6. Defect leakage
It is defined as the total number of defects detected after sprint closure. When a sprint reaches its end phase the testing is done by the development team and the product owner and in this process some defects are detected.
These defects are fixed but before the deployment of the story points the User Acceptance Testing is carried out and the number of defects encountered during this stage is called defects leakage.
Defects leakage is calculated by the formula equal to (Defects during UAT/Defects during Sprint)*100.
If this percentage comes out too high there is some loophole in the QA process of the sprint. It informs ‘if there is any special attention required in the testing process of a sprint or not?’.
7. Backlog Health
Backlog health is measured on story points and analysed by comparing the total story points in the backlog ready to be committed in the next sprint with the average velocity of the last few sprints.
The story points can be
- Less than the average velocity
- Meets the average velocity
- Meets twice of the average velocity
- Meets thrice or more of the average velocity.
It explains how ready the team is to ensure quality work in future sprints.
8. Burndown Charts
The scrum teams use burndown charts to measure the work progress. In this, a graph is drawn with the number of story points in a sprint are represented on the Y-axis and the days in the sprint on X-axis.
It explains the pace at which the team is committing user’s story and the path following is right or not.
If the pace is very slow then the team need to find out a way to get back on track otherwise they will not be able to complete the stories within the timeline.
And if the pace is very fast then it should be checked that they are not missing something.
So these are some of the most commonly used scrum metrics to check the team and the process productivity and efficiency.