9 Scrum Metrics to Keep Your Team on Track

A group of 3 product managers posting sticky notes on a pane of glass.

8-minute read

This article explores how measuring scrum metrics helps teams evaluate their performance over time to improve team effectiveness and inform product strategy.

A common management adage goes, “What gets measured gets managed.” This rule, attributed to V.F. Ridgway, communicates more than just the importance of measurement. But there’s more to the story. Simon Caulkin summarized Ridgway’s study of performance management this way:

          “What gets measured gets managed – even when it’s pointless to measure and manage it, and even if it harms the purpose of the organization to do so.

When measuring and evaluating performance is paramount, how can product teams ensure they measure and manage the most critical variables? Understanding what scrum metrics are, why they are important, and how they can be used to track important team goals can help product teams track performance and improve their output.

Read on to learn more, or use the links below to jump to the section that most interests you:

What is scrum?

Scrum is a product management framework that helps teams iterate product solutions. In scrum, timelines are scoped in 1-4 week sprint increments, which helps teams structure and estimate work. The scope of work for any sprint estimates how much the team can complete within that sprint. At the end of each sprint, the work delivered should be ready to be delivered to customers.

Scrum frameworks are based on agile project management philosophy. Under agile, teams prioritize collaboration and iteration over processes and tools. Scrum frameworks help teams adapt quickly to changing needs and priorities and ultimately deliver solutions iteratively.

What are scrum metrics?

Scrum metrics are specific data points teams gather and track to improve efficiency and effectiveness. Tracking scrum metrics helps teams estimate workload and project completion timelines, set goals, and improve performance over time.

How can teams gather scrum metrics?

Scrum has different recurring events that can help teams gather data. These events are:

  • Sprint planning: A meeting at the beginning of a sprint to break large priorities into workable tasks. Sprint planning meetings provide a detailed estimate of the scope of the work and the amount of time it will take to complete that work.
  • Daily scrum: A daily meeting where team members share progress updates and roadblocks they are facing. Daily scrum meetings also recap the hours remaining for sprint tasks, which helps teams calculate sprint burndown.
  • Sprint retrospective: A meeting at the end of a sprint to recap what went well, discuss what didn’t go well, and share ideas for improvement.

Why are scrum metrics important?

Although scrum events are pre-set milestones for teams, the events alone don’t guarantee progress or success. These are simply checkpoints throughout a project and do not indicate the quality or efficiency of the work

Tracking scrum metrics enables teams to estimate workload and project completion timelines. Over time, teams can benchmark their performance and guide future projects. Scrum metrics help the team can also help the team craft a compelling story about their work. Over time, these metrics may approximate the satisfaction and effectiveness of the team overall.

Are scrum metrics KPIs?

Although the terms “metric” and “KPI (key performance indicator)” are often used interchangeably, they are not the same concept. Metrics are units of measurement that evaluate the KPIs. On the other hand, KPIs are metrics with a set, time-bound goal. Product teams can use scrum metrics to set KPIs. For agile product teams, KPIs should demonstrate how well the team satisfies customer and market needs and supports company goals.

Scrum metrics to track

Here are 9 metrics that teams can track to evaluate performance and set their own KPIs. Product teams should decide which metrics to track, how often to track them, and how to communicate them with the larger team.

1. Story Completion Ratio

The story completion rate is the ratio of actual stories completed to the number of stories the team committed to. Product teams commit to stories during sprint planning and review the number of stories completed during the sprint review. If a team commits to 10 stories during sprint planning and delivers 8 by sprint review, their story completion ratio is 80%.

Story Completion Ratio = # of Stories Delivered / # Number of Stores Committed

2. Technical Debt Index

In software product development, technical debt refers to the work that builds up when developers implement quick, short-term solutions instead of working through better, more labor-intensive solutions. Technical debt is the cost of slapping a band-aid on a product to make a quick fix or complete an MVP.

Technical debt can be measured using a debt index. You can calculate the debt index by dividing the total technical debt by another metric that represents the full scale of the project or system. For example, you can calculate the debt index by dividing the total technical debt (estimated hours of work or story points) by the codebase size (measured by lines of code). The resulting ratio approximates a scaled picture of the remaining technical debt.

Technical Debt Index = Technical Debt / Codebase Size

3. Velocity

Velocity is one of the most important metrics in product management. Velocity represents the consistency of the teams’ estimates over time.

Actual velocity is the sum of units (often story points) delivered in a sprint and is calculated as the number of delivered units divided by the total number of sprints.

For example, if a team delivers 15 story points in 1 sprint, their actual velocity is 15.

Actual Velocity = 15 story points / 1 sprint = 15

If a team delivers 100 story points in 4 sprints, their actual velocity is 25.

Actual Velocity = 100 story points / 4 sprints = 25

Expected velocity is the total estimated story points divided by the total number of planned sprints.

For example, if a team estimates they will complete 45 story points in 3 sprints, their expected velocity is 15.

Expected Velocity = 45 story points / 3 sprints = 15

Actual velocity isn’t a measure of productivity; it simply represents an average unit of completion based on past data. Actual velocity may change due to outside factors like holidays, team changes, and technical issues. For this reason, teams should use actual velocity as a planning tool. Over time, actual velocity can be compared to estimated velocity to see how team output differs against expectations.

4. Burndown

Sprint burndown helps teams measure the work remaining during the sprint’s execution. Sprint burndown is a visual representation, usually a line chart over time, that represents the rate at which the team completes work compared to how much work still needs to be done. On a burndown chart, the x-axis represents time increments, while the y-axis represents the number of tasks yet to be completed.

A burndown graph representing the decline of outstanding story points over time.

5. Escaped Defects

The number of escaped defects helps product teams evaluate the quality of their product. This metric shows how many bugs, or defects, “escaped” testing and were experienced by users in production. In an ideal world, scrum teams can thoroughly test stories to avoid escaped defects. In reality, sometimes bugs get deployed to production. 

Defect density, which measures the number of defects per software size, such as lines of code, can also help teams understand their product quality.

Tracking the number of escaped defects and defect density over time can help your team understand the quality of releases and whether that quality improves or degrades over time.

6. Sprint Goal Success

Sprint goals are one—to two-sentence statements that outline the goals of a sprint. They are an optional part of the scrum framework, but tracking this metric over time provides insight into whether teams meet their goals. If a team consistently misses goals, this data can help them investigate whether their goals are realistic. Furthermore, it can help them identify roadblocks to goal success.

7. Workload Distribution

A strong product team is essential to creating a strong product. Monitoring workload distribution helps ensure that all team members take on what they can handle. Some team members may be overworked without visibility into workload distribution, while others may be underutilized. Ultimately, both issues can contribute to low employee satisfaction.

Product teams may use workload distribution as a proxy variable for productivity, which can create stress for employees. When tracking workload over time, product teams should take care to create an environment of trust and psychological safety.

8. Team Satisfaction

Team satisfaction is a significant component of a successful scrum team. If your team members don’t feel that their needs are met and aren’t enthusiastic about their work, then no process or methodology can fix your team’s problems. Checking in on workload, work/life balance, happiness, and motivation helps you gather data on your team’s satisfaction and shows that you care about your team as people.

9. Customer Satisfaction (NPS)

While there are several ways to measure customer satisfaction, Net Promoter Score (NPS) is among the most common. NPS measures whether users would recommend the product to others. Strong, consistent NPS scores mean the product team delivers valuable products to customers.

Conclusion

Monitoring and tracking scrum metrics can support agile product management in several ways. By recording and visualizing this data, scrum teams can enhance their efficiency, effectiveness, and ability to adapt quickly to changing needs or priorities. Tracking metrics also helps ensure product teams are satisfied and connected to the organization’s broader customer service goals.

Author

  • Robert Boyd

    Robert Boyd is a CSM (Certified Scrum Master) and CSPO (Certified Scrum Product Owner). Robert began his career with the U.S. Navy, where he worked on nuclear submarines. He transferred his skills to the private sector, working on submarine combat systems at Raytheon for 22 years. During that time he helped streamline processes and systems for the Australian Collins Submarine. He moved to Australia permanently in 2002 and began creating new software development processes for Integrated Research in Sydney. He also introduced agile methodologies to software and product management departments, resulting in a 300 percent increase of feature deliveries. Bob earned a B.S. in computer science from University of Rhode Island. He can be reached at [email protected].

Author:

Other Resources in this Series

Most Recent

Article

Product operations: What is it and does your company need it?

Product operations is a key player in evolving product-centered companies, but why? And should your company consider using it? This article covers everything you need to understand about product ops.
Article

Product Operations vs. Product Management

Explore product operations vs. product management, and learn how these roles work together to build data-driven products.
Article

7 Critical Product Manager Interview Tips

Getting ready for an upcoming product manager interview? This article offers essential strategies and tips for showcasing your skills effectively and using research and practice to make a strong impression.
Article

Women Product Leaders and Changemakers

In the spirit of Women’s History Month, we brought together the insights of product management leaders and Pragmatic instructors Cindy Cruzado and Amy Graham in a comprehensive interview that sheds light on their experiences, challenges,...
Category: Leadership
Article

How to Write a Product Manager Resume

A comprehensive guide to writing a product manager resume with best practices, dos and don’ts for writing a resume, and templates.

OTHER ArticleS

Article

Product operations: What is it and does your company need it?

Product operations is a key player in evolving product-centered companies, but why? And should your company consider using it? This article covers everything you need to understand about product ops.
Article

Product Operations vs. Product Management

Explore product operations vs. product management, and learn how these roles work together to build data-driven products.

Sign up to stay up to date on the latest industry best practices.

Sign up to received invites to upcoming webinars, updates on our recent podcast episodes and the latest on industry best practices.

Subscribe

Subscribe

Pragmatic Institute Resources