The 10 Most Helpful Agile Metrics According to Experts

Cumulative Flow Diagram. Work In Progress. Quality Intelligence. Planned-to-done-ratio. Velocity. Flow Debt. Work Item Age. Burndown chart. Burnup chart.

It’s easy to find a list of agile metrics online and start tracking them all. The challenge is identifying which ones will add value to your team.

As with all things Agile, opinions abound about the pros and cons of different metrics. And when you ask an Agile Coach which to track, more often than not, you’ll hear them say… “it depends”. Because it does! So where should you start?

We surveyed dozens of Agile coaches, Scrum Masters, and other practitioners to discover the ten agile metrics they most often use with their teams.

Then, we solicited their expert advice on how and when to use each, so you can understand which metrics to use in which scenarios and develop an informed selection for your team.

In an ideal world, an agile metric is a number that tells the development team the status or performance of an outcome that’s important to them as an Agile team.

What makes a metric Agile is whether it aligns with the Agile manifesto and tracks how effectively a team fulfils one or multiple of its principles and values.

For example:

In the real world, metrics are sometimes used – even “weaponized” in the words of one expert – against teams to set targets, rewards, and even punishments.

The conflict between how agile metrics should be used (to benefit the team) and how they are traditionally used (to the benefit of higher-ups) arises from the longstanding focus of managers on output and enforcing predictability.

One key difference with agile metrics is that they should be primarily useful for the team, rather than anyone higher up. Instead of creating aspirational goals, they focus on realistic predictability. The focus is on helping a team improve their work continuously over time.

For example: A traditional manager, for example, may insist on specific deadlines for tasks, which a team then gives but hardly ever meets. An agile metric like Cycle Time would solve this by predicting delivery based on actual past performance, like “90% of our tasks finish within two weeks.”

We found that the 10 most popular Agile metrics are:

We compiled this list by surveying 38 Agile practitioners from around the world – including South Africa, Australia, the United Kingdom, India, Vietnam, and the USA – to determine the ten agile metrics they use most with their teams.

Note: Participants were able to select multiple options

Let’s cover these Agile metrics to understand better what they set out to track and why practitioners use them so often.

Cycle time measures how long it takes a team to complete tasks. You can measure cycle time by tracking how much time tasks spend in the “in progress” stage of your Kanban or Sprint board.

You can single out any items with an anomalously high time to completion for further discussion.

Cycle time is a helpful metric because it conveys a lot of information about:

Cycle Time was by far the most popular Agile metric selected by Agile Coaches, Scrum Masters, and other Agile practitioners.

Velocity is calculated as the number of estimated story points a team completes during a Sprint or other period of work. It is usually measured per Sprint.

Average Velocity tracked over a longer period can help the team reliably forecast how much work they can do in one Sprint. This may then be factored into Sprint Planning.

For example:

Velocity can also signal issues or areas for improvement when the number goes up or down.

While Velocity was the second most popular metric in our survey of most helpful Agile metrics, it was also the Agile metric one most commonly mentioned as unhelpful.

As with all Agile metrics, its utility depends on how it’s deployed. Measuring Velocity can be incredibly helpful and empowering for teams, but when they become fixated on keeping the velocity up for the sake of satisfying “velocity goals”, then it becomes counter-productive and prone to manipulation by the team.

Work In Progress (WIP) can be calculated as the total number of items a team is working on at any given time.

WIP is a critical metric for keeping teams focused and ensuring a continuous flow of work. Teams can calculate this by noting how many items sit in the WIP or “In Progress” column of their Kanban board or Scrum board.

WIP is especially powerful when teams take a Kanban-style approach and set a maximum number of items they can have in progress simultaneously.

This limit forces prioritization discussions. When someone wants to add a new item to the WIP column, they need to make space for it by finishing another task first or moving one to the Product Backlog.

A Burndown chart visually presents how many story points a team has completed during a Sprint and how many remain to be completed. Usually, the chart has an “ideal burndown” line that shows the progress needed to arrive at zero remaining story points by the end of the reporting period, and an “actual burndown” in the form of remaining story points.

A Burn Chart – as it’s sometimes called – is helpful because it makes it easy for everyone to see whether the team is on track to reach the Sprint goal. It also visualizes when the team’s speed increases or decreases during a Sprint, which might be a signal to investigate further during the Sprint Retrospective.

A Burndown chart only shows how many story points the team has completed and how many remain. It doesn’t give any deeper indication of why that’s the case. A Burndown chart by itself is therefore not sufficient alone to determine whether a team is performing well or not.

The Happiness metric is an indicator of how the team feels about their work. Jeff Sutherland, the creator of the Scrum framework, explains how it works in his book Scrum: The Art of Doing Twice the Work in Half the Time.

At the end of the Sprint, each team member answers four questions:

This Agile metric brings the human, emotional side of any changes or struggles the team faces to the surface, which is impossible with the other metrics.

Teams can adapt the exercise above with whichever questions make most sense to them. You can also take Jeff Sutherland’s questions and focus them on the team rather than company-level.

The Cumulative Flow Diagram (CFD) is a strange metric because… well, it’s actually diagram that pulls several metrics into one visual. That’s what makes it such a powerful tool, and why many in the Agile community list it among their favorite ways of tracking Agile metrics.

The x-axis in a CFD represents time, the y-axis represents work items, and each graphed series represents a stage of the work process. Through this visualization, you can instantly grasp how work is flowing through a system.

While CFDs can be overwhelming at first, they are helpful for communicating a lot of information quickly. At least after you’ve had a bit of practice with them. You can also measure the distance between two horizontal points, for example, to get Cycle Time. Do that vertically, and you can check your WIP at any point in time covered by the CFD.

The CFD is the Swiss army knife of Agile metrics. 

📌 An excellent book that goes deep on Cumulative Flow Diagrams is Actionable Agile Metrics For Predictability: An Introduction by Daniel Vacanti.

Lead time is the entire period a work item spends in your process from the moment someone creates it. Essentially, it’s Cycle Time plus the time a task sits around in your Backlog waiting to get pulled into the WIP phase.

A focus on Lead time keeps the Backlog lean and clean. For some teams, this isn’t a worry, but it’s critical when you use the Backlog for prioritization and planning since you could have dozens or even hundreds of stale backlog items hanging around there.

Throughput is the number of work (WIP) items the team completes in a specific period, usually measured per Sprint.

This metric is different from Velocity, which measures the number of story points delivered per work cycle. Since one work item usually represents multiple story points, the numbers differ.

As you measure average Throughput over many Sprints, the metric helps predict how many completed features or user stories a customer or other stakeholder can expect each Sprint.

A low Throughput can also indicate other issues, for example, that your team’s user stories are too big, which is a signal to start Story Splitting or to more broadly consider whether there’s a deficiency in the way your team estimates Story Points.

The escaped defect rate measures the percentage of defects that are identified in work after code has shipped to production. It measures how many issues slip through QA testing.

Some teams only track problems found by customers and end-users. Others also include problems discovered during QA or other phases outside of the development team’s realm.

In Agile utopia, teams fix all problems before delivering a piece of work. In reality, this rarely happens. Without measuring the Escaped Defect Rate, it’s difficult to determine how many issues slip through the team’s process unnoticed.

The Escaped Defect Rate can be a good prompt for diagnosing problems and suggesting improvements in the team’s Sprint Retrospective.

Blocked time counts the time a work item can’t move forward, usually caused by a dependency or other issue outside the team’s control.

Most teams measure this metric in days, but some measure it in hours.

Blocked or Stuck items may have their own column on the Kanban board, making it relatively easy to calculate.

Often teams categorize blocked items by causes, then add up and track the total blocked time for each category to get a sense of persistent problem areas. This gives teams clear data from which to prioritize improvements.

Blocked time can be a great way to figure out bottlenecks and the root cause of delays. Such insight sometimes provides opportunities for improvement outside of the team’s direct control. For example, another department or external supplier consistently delivers their input or task requirements too late.

These two metrics didn’t make it into the top 10 but deserve a mention as they can prove valuable in the right circumstances:

Even if you could measure all of the above metrics simultaneously, that would be a bad idea. A team can only process and act on a few metrics at a time.

Focus on the few metrics that address your most pressing issues or goals. Here’s advice on picking the right ones, inspired by feedback from the experts we polled.

Start by asking why you want to track a specific metric. What do you hope the number will accomplish? How will it be reported and visualized? What will you do with it?

Such questions might seem obvious, but often, a metric sounds helpful in theory but turns out to be unhelpful when you run it through one or two scenarios of how you intend to actually use it.

The fewer agile metrics you set for a team, the more attention they get. Or, as the old saying goes: “When everything is a priority, nothing is a priority.”

Think of metrics as an “overhead.” Every number you decide to track requires some effort to report on and causes noise and sometimes pressure for the team.

If one metric holds absolute power, its power will corrupt absolutely.

For example, if you choose to only focus on Cycle Time, and it decreases, you might think the team is improving their work processes. That’s until you check Team Happiness and realize it’s plummeting because excessive overwork is the real reason for shorter cycle times.

Another all-too-common example is fixating on increasing Velocity. When that happens, the team may feel pressurised and stress. But they may also be inclined to manipulate the metric by boosting their estimates of how many story points a task requires to complete.

This recommendation from one expert is brilliant in its simplicity: Frequently ask the team which metrics they’re actually using. Which numbers sparked conversations, insights, or actions? Discard any metrics that didn’t.

Many Agile teams aim to be self-managed. In Scrum, it’s even explicitly stated. So give the team a say in what metrics they think they should be tracking. Since developers on a team are closest to the work, they may be best placed to come up with meaningful metrics.

Sprint Reviews and Retrospective meetings are the natural stage for agile metrics to make an appearance. If a specific metric isn’t coming up very often, ask the team if it’s still useful to them.

Transparency is one of the core values of Agile. And that extends to your metrics! Many of the experts we surveyed also recommended that agile metrics be visible for everyone involved in a team. That helps create transparency which improves and speeds up communication, ensures problems can be identified faster, and avoids information hoarding or silos.

After making them visible, check that the team and stakeholders you work with all understand what each metric tracks and why. All that transparency isn’t much good if your team members don’t know what they’re looking at or why it’s being tracked! If anyone is confused about a particular metric, like Throughput or Cycle Time, you can always send them this article!

Even helpful metrics can inadvertently create anti-patterns when wrongly used. As the adage one expert invoked goes: “you get what you measure.”

Compare and rate teams on Velocity, and their numbers will converge. Judge Scrum Masters on the number of teams they work with, and that metric goes up. Reward predictability and it will increase, until it comes crashing down.

Agile metrics should serve a team, a purpose, and each other. That’s how to ensure they’re helpful, lead to continuously improving work processes, and, ultimately, more customer value and team happiness, the pinnacles of Agile.