1. Sprint Velocity
Sprint velocity is a popular Scrum metric that enables you to get a historic overview of how much value you have delivered during each sprint.
In order to calculate this metric, you need to sum the story points completed at all sprints and divide them by the number of sprints.
For instance, let’s calculate sprint velocity based on the below data:
- Sprint 2: 5 user stories x 12 story points = 60
- Sprint 3: 6 user stories x 12 story points = 72
- Sprint 4: 7 user stories x 12 story points = 84
- Total: [Sprint 2] + [Sprint 3] + [Sprint 4] = 216
2. Scope Change (SC)
Scope change is an effective Scrum metric that allows you to analyze the root causes of no meeting commitments.
Specifically, this metric helps you track the number of stories added/removed within the project during a sprint or release.
‘Descope’ and ‘scope increase’ are two indicators that will determine when and why any mistakes or changes were made.
The formulas calculate them are as follows:
- Descope: = (D/C) * 100
- Scope increase = (A/C) * 100 , where D – removed SP, A- added SP, C – committed SP.
3. Effort Estimation Variance
Effort estimation variance is one of the wide-spread Scrum reporting metrics which allows you to measure under- and overestimation rates.
Put it simply, it is a metric that allows you to track actual efforts made over the estimated hours.
Let’s consider an example of how to calculate effort estimation variance.
Here is a table of sprints, estimated hours, and actual efforts in hours that were spent:
Based on the table data, you can see that only sprint 3 has no over/underestimation which means that no extra/lacking efforts were put into the software development process. Other sprints were either over- or underestimated.
There are two simple formulas to calculate over/underestimation values:
- Overestimate = (E-A)/E * 100
- Underestimate = (A-E)/E * 100
4. Defect Leakage
As your software product grows, you will definitely find multiple bugs as it’s a default and normal situation dedicated to the human factor.
These errors influence the final estimate, client satisfaction, and team happiness.
If you are wondering whether there is a method or metric to track a bug ratio within your project and improve on, you should use defect leakage.
It is one of the key Agile metrics which allows you to track the summarized number of defects detected when a sprint or release are done.
At Ascendix, we have incorporated a company RAG (red, amber, green) status. It helps us get a high-level overview of a project’s activity, generate a relation coefficient/variance, and measure all our projects by specific upper and lower limits.
The formula to calculate a defect leakage value is as follows:
- Defect leakage = (Post sprint defect count / defects detected during sprint) * 100
How to Make Scrum Metrics Effective?
It’s worth mentioning that metrics are only instruments to help you evaluate specific project activities or progress. NOT ALL Scrum metrics should be implemented to every project you carry out as different projects require different measurements.
The value delivered is the key and the only result you should focus on while developing projects. So, if metrics are of great help for you and they provide value measurement, only then it’s a great idea to implement them and start analyzing.
You should keep in mind that METRICS ARE ABOUT VALUE, not about numbers.
At Ascendix, we have built 5 key rules that should be followed to make the most out of the Scrum metrics you use. Let’s take a look at them:
- A metric should be used by the team
- A metric should be based on a conversation
- A metric should answer concrete questions
- A metric should be used together with other metrics
- A metric should be easy to calculate and understand
Bottom Line
We shared with you the Scrum metrics we use when developing software. They can help you better analyze and measure your team’s performance and project progress to improve on.
However, they are NOT a single source of truth. So, try and test them for your project, measure whether they help you evaluate the iterative or final value delivered, and make your own choice.
If you want to read a full article, feel free to ping us out in the comments so that we can share the link.
What ways do you use to measure software quality? Do you use any metrics? Share your experience in the comments below.