EIGHT METRICS YOU SHOULD START CAPTURING TODAY AS A SCRUM TEAM!

What metrics do you currently track as a Scrum team?

What metrics have you used before?

Why should we even track and capture metrics in the first place?

If you have read the Scrum guide, which I suppose you have done so on multiple occasions, Scrum is founded on empiricism. If you are asking what empiricism is?

Please don’t bother, I got you.

Empiricism emphasizes that knowledge comes from experience and making decisions based on what is known. We have an idea of our team’s velocity, and based on this knowledge, we can make better planning decisions.

We may make assumptions, experiments, etc., which are all crucial product discovery and delivery aspects. However, we make decisions based on the experimentation’s outcome (s). Now that we understand the importance of empiricism, capturing the right metrics is crucial to continuously pivoting your team (s) in the right direction.

During my career as a Coach, I have been very blessed to mentor some of the best Scrum masters. They have often reached out on many occasions with questions like Coach, I want to suggest or introduce these changes to the team, and my question has always been very simple; on what justifications?

We don’t introduce changes or make policies simply because we read somewhere or heard someone mentioned somewhere. Our individual environments differ and are unique; what makes sense in one environment may not in another. The challenges a team at Apple faces may ultimately differ from those at Meta. Having quantitative and qualitative data within your local context should serve as the basis for making crucial decisions.

Why is it essential to capture metrics in the first place?

Without knowledge, we have nothing to build on, no data to initiate a discussion, no baseline, nothing to determine progress, and no growth plan. Metrics can help the team and business assess how well they meet their goals, be it Sprint or release goals; it provides the anchor for teams to continuously inspect and adapt their processes.

It helps promote transparency within the team and business stakeholders and can help the team better plan, as we shall see in the subsequent paragraphs.

That said, what are some simplistic qualitative and quantitative metrics that teams can measure?

1. Velocity

Velocity is a crucial metric for every Scrum team and one of my best metrics as an Agile practitioner. It measures the amount of work a team can complete in a Sprint. Most Scrum teams plan, estimate, and deliver their work in story points (sps). The amount of work they complete in a Sprint is their velocity, and taking an average throughout 3-5 Sprints can serve as a good planning tool.

Teams that do a great job tracking and capturing their velocity are better placed to make accurate planning decisions. They can predict the amount of work they can complete in a Sprint, which becomes very important for business stakeholders making release decisions. Velocity can be tracked at the team and train level.

2. Sprint Burndown Chart

This simple visual chart shows the amount of work remaining in a Sprint. It is a critical metric to help the team visualize progress and determine if they’re on track to complete the planned work. The graph shows the number of stories that have been burned or completed, what is still to be completed, and the days left in a Sprint.

This can help teams ascertain if they’ll be able to hit their goals, be it Sprint or release goal (s), and be able to help make crucial decisions or help businesses make critical decisions. Contrary to popular opinion, burndown charts can also show Scope creep, which is extra work picked up after the start of Sprint.

3. Lead Time and Cycle Time

Lead time tracks and captures the total time it takes from receiving a work request to its delivery. On the other hand, cycle time represents the duration taken to complete one unit of work, be it a story. The time it takes a developer to pick up a story, code, and push to QA and the time it takes for a QA to test a story and push it to ‘Done’ are some examples of cycles.

Tracking these flow metrics is vital to uncover where there may be bottlenecks within the flow to improve efficiency. For Scrum teams working in a Kanban environment, I encourage you to capture the time a unit works cycles through a state in the workflow process.

4. Defect Rate

This metric captures the number of defects identified during a sprint or release, which is a crucial factor as far as product quality is concerned. In Scrum, you can measure the defect rate using the formula:

Defect Rate = (# of defects/total work output) * 100. 

For example, let’s assume Team Optimism planned 40 story points of work in a given Sprint, and at the end of the Sprint, 5 defects were found. Using the formula above, the team’s defect rate for that particular Sprint is determined as thus;

5/40*100 = 12.5%.

You may be asking what the acceptable defect rate for a Scrum team is. The goal of every Scrum team is to aim for zero defects, which is not feasible in real life. However, the minimal the defect rate, the better, and it shows how robust the quality management system of the environment is.

5. Sprint Down-Time

Downtime is another crucial metric to capture for your team. What is the time that a team member or your team has gone without working because of a downtime factor? Downtime can be caused by reasons out of control, including system outages, environmental instabilities, sickness, or other factors. Are we tracking the down-time?

Are we quantifying this downtime? Capturing this downtime can help us determine its impact on the team’s productivity.

We can uncover significant trends and make critical decisions based on these discoveries. We have been discussing quantitative metrics all along. What about qualitative metrics?

What are some qualitative metrics you have captured as a team?

6. Backlog Health

How healthy is your backlog? A healthy backlog is the recipe for a successful Sprint and release. What do I mean by a healthy backlog? We have often been told it is the responsibility of the Product Owner to ensure backlog readiness. It is the team’s responsibility to ensure a healthy backlog. The Product Owner owns the product’s vision within the team; they communicate it to the team, and a good team coach or Scrum master works with the team and the PO to ensure the vision is chiseled in the right product backlog items and prioritized in the backlog.

I have observed teams decide what they want to deliver during Sprint planning, which is already an indication of failure or a recipe for disaster.

  • A good Scrum master or team coach understands that a team should, at any given point, have ready stories in the backlog that can fill up two Sprints of a team’s velocity.
  • A good coach understands the importance of backlog checkpoints with the PO.
  • A mature Scrum master understands the importance of backlog refinements as a team.
  • An excellent Scrum master understands the importance of preparing technical artifacts like wireframes well beforehand.
  • A great Scrum master understands what it means to have ready user stories.
  • An experienced Scrum master knows when a PO lacks backlog management competencies and knows how to partner with the PO to embrace these practices. Backlog readiness must be treated with utmost importance.

7. Team happiness or health

This is an excellent metric to help gauge the morale and attitude of team members, the morale of the team as a whole, their morale and attitude within the business, etc.

You will agree that successful teams and products are built around happy and motivated individuals. Agile Manifesto principle #5 posits building projects around motivated individuals and give them the right environment, support, and trust them to do the work. How well do you know what motivates your team?

What keeps them awake? There are no right or wrong ways to gather this feedback. I have created simple trust pilot-type qualitative surveys and used retrospectives to gather these data. I think a big part of success lies in how well you craft the questions for the survey, how you communicate the raison d’etre for the survey, and how you deliver the survey.

Metrics should and must not be used to punish or shame teams. Matrices are there to help improve. It’s all about inspection and adaptation.

What other metrics have you helped your team capture in the past?

Please use the comment section below to suggest other metrics you have used in the past so we all can learn from them.
  • Interested in SAFe 6.0 Scrum master training and Certification?
  • Are you interested in SAFe 6.0 Release Train Engineer (RTE) training and Certification?
  • Are you interested in SAFe 6.0 Product Owner training and Certification?
  • Are you interested in Jira training?
  • Are you interested in Scrum master, Release Train Engineer, or PO interview prepping?

Feel free to browse our training and certification page.

Let us know other topics you’ll like us to share our knowledge on and we will gladly do so.

2 Comments

  1. Please cover what are tips or ways to track project milestones and commitments in the quarter within your team or PI

Leave a Reply

Your email address will not be published. Required fields are marked *