DEV Community

loading...
Cover image for How We Measure Software Product Quality: Scrum Metrics We Use

How We Measure Software Product Quality: Scrum Metrics We Use

ascendixtech profile image AscendixTech ・5 min read

The article was originally published on Ascendix Tech Blog.

We want to share the ways we measure software product quality with Scrum metrics to keep our project progress and team productivity on track.

So, you will learn about:

  • Scrum metrics we apply for quality measurement
  • Formulas to calculate each metric
  • Examples of metric charts and tables
  • Reasons to use Agile metrics.

Let’s get down to business.

1. Sprint Velocity

Sprint velocity is a popular Scrum metrics which 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

This way, your average sprint velocity is 216 / 3 = 72.

Here you can review an example of a sprint velocity chart:

An Example of Sprint Velocity Chart

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.

Let’s now check the example of committed, added, and descoped stories within a project:

scope-change-table1

So, the sprints 2, 4, and 5 were modified by adding or de-scoping story points.

Now let’s calculate the scope change variance to see the added/descoped sprints:

scope-change-table2

In order to analyze and demonstrate these changes more vividly to stakeholders, you can build a scope change chart and see changes from sprint to sprint.

Scrum_An Example of Scope Change Chart

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:

effort-estimation-variance-table1

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

, where A – Actual effort and E – Estimated effort.

So, they allow us to easily calculate the effort estimation variance in percent:

effort-estimation-variance-table2

Based on the data above, you can safely assume, that Sprint 2 was excessively over-estimated while Sprint 4 was underestimated.

If you see a negative variance, it is a sign that something is wrong.

Below you can see an example of an effort estimation variance chart:

An Example of Effort Estimation Variance Chart

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.

Here is an example of the way we categorize possible variance values based on our RAG status:

defect-leakage-table2.pmg

Now let’s take a look at the example where we summarize the detected sprint defects:

defect-leakage-table2

The formula to calculate a defect leakage value is as follows:

  • Defect leakage = (Post sprint defect count / defects detected during sprint) * 100

It allows us to measure the variance value for each sprint:

defect-leakage-table3

Additionally, you can create a defect leakage chart that indicates deeply the volume of defects within every completed sprint:

Scrum_An Example of Defect Leakage Chart

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 project require different measurement.

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.

Want to get more information about our best practices in measuring the project’s progress? Feel free to read the full blog post: How We Measure Software Product Quality: Scrum Metrics We Use.

What ways do you use to measure software quality? Do you use any metrics? Share your experience in the comments below.

Discussion (2)

Collapse
trueneu profile image
Pavel Gurkov

Thanks for the article.

Got a couple of questions: "If you see a negative variance, it is a sign that something is wrong." -- what do you mean by variance here? What's negative variance? Whenever I see variance, I think (average squared) deviation from mean, so it can't be negative :)

Second, what metric do you use as basis for story points? What the estimation process looks like?

Collapse
ascendixtech profile image
AscendixTech Author

Pavel, thanks for your question!

According to your first question:

Nothing too complex here. We just use the formula: (E-A)/E * 100. In case Actual spent exceeds Estimated, we’ll receive negative number. Meaning we underestimated scope.

As for story points, it all depends on the team. Usually, we take the simplest thing to do as 1 story point and go from there.

Hope these answers will help you!

Let us know if still have some!

Forem Open with the Forem app