Measuring Team Health and Flow Without Gaming the Numbers

Measurement in agile teams has a mixed reputation. Used well, good measures help a team see where work gets stuck, predict delivery more honestly and notice problems early. Used badly, numbers become targets, teams learn to game them, and trust erodes.

The difference usually comes down to who the measures are for. Measures that help a team understand and improve its own work tend to stay honest. Measures used to rank, reward or punish teams tend to get distorted.

This guide covers three complementary kinds of measurement: flow metrics, the DORA software delivery metrics and team health checks. It also explains why velocity, one of the most familiar agile numbers, should not be treated as a productivity score.

Flow Metrics: How Work Moves

Flow metrics describe how work moves through a team's process from start to finish. The Kanban Guide, published online by a group of flow practitioners, lists four flow measures that it calls mandatory for Kanban, and they are useful for any team.

• Work in progress (WIP): "The number of work items started but not finished."
• Throughput: "The number of work items finished per unit of time."
• Work item age: "The elapsed time between when a work item started and the current date."
• Cycle time: "The elapsed time between when a work item started and when a work item finished."

These four work together. High WIP tends to stretch cycle times, because attention is split across too many items. Work item age is especially useful because it is a leading indicator: you can see that an item is getting old while there is still time to act, rather than learning about it after it finishes.

To start, define clearly what counts as started and finished for your team, track those dates for each item, and review the numbers together regularly. Charts that show the spread of cycle times are usually more informative than averages, because they reveal how unpredictable delivery can be.

DORA Metrics: Software Delivery Performance

For teams that build and run software, the DORA research program provides a widely used set of software delivery performance metrics. As of its guide last updated in January 2026, the DORA website lists five metrics in two groups.

Throughput measures how quickly changes reach users.

• Change lead time: how long it takes for a code change to go from committed to deployed in production.
• Deployment frequency: how often changes are deployed to production.
• Failed deployment recovery time: how long it takes to recover when a deployment fails and requires intervention.

Instability measures how often deployments cause trouble.

• Change fail rate: the share of deployments that require immediate intervention, such as a rollback or hotfix.
• Deployment rework rate: the share of deployments that are unplanned and made in response to an incident in production.

Older articles often describe "the four DORA metrics" and use some different names, so check the DORA website for the current definitions. DORA itself warns against misuse. Its guide says that setting metrics as goals "increases the likelihood that teams will try to game the metrics," and that the goal is "to improve your team's performance over time, not to compete against other teams." It also notes that the metrics are meant to be applied at the level of an application or service.

Team Health Checks

Flow and delivery metrics say little about how people are experiencing the work. Team health checks fill that gap. One well-known example is the Squad Health Check model published by Henrik Kniberg and Kristian Lindwall on Spotify's engineering blog in 2014.

In that model, a team discusses roughly ten areas, such as how easy it is to release, the health of the codebase, clarity of mission, learning and fun. For each, the team agrees on a color: green for good, yellow for some important problems, and red for serious trouble. It also notes whether things are improving, stable or getting worse.

You can build your own version. Choose a handful of areas that matter to your team, run the check every month or two, and use the results to start conversations in retrospectives. The value is in the discussion, not the score. The Spotify authors explicitly warn against comparing teams, writing that a manager's attitude should be "how can I help?" rather than asking why one team looks worse than another.

Why Velocity Is Not a Productivity Score

Velocity is the amount of estimated work, often in story points, that a team completes in a sprint. It can be a useful planning aid for the team itself, helping it judge how much to take on. Notably, the Scrum Guide does not mention velocity or story points at all.

Problems start when velocity is used to judge productivity or compare teams. Story points are relative estimates that each team calibrates differently, so one team's 40 points has no fixed relationship to another team's 40. And when velocity becomes a target, the easiest way to raise it is to inflate estimates, which makes the number go up without any change in actual delivery.

Ron Jeffries, a longtime agile practitioner and writer, wrote in a 2019 essay, "I like to say that I may have invented story points, and if I did, I'm sorry now." In the same piece he states that "comparing teams on quality of estimates or velocity is harmful."

If leaders want to understand delivery, flow metrics and DORA metrics measure real outcomes, such as elapsed time and deployment results, rather than estimates.

Using Measures Well

A few principles keep measurement healthy.

• Let teams own their measures and review them in their own improvement conversations.
• Track trends over time for one team instead of comparing different teams.
• Pair numbers with conversation; a metric tells you where to look, not what is wrong.
• Balance speed measures with stability and health measures so no single number is optimized at the expense of others.
• Retire measures that no longer lead to useful decisions.

Key takeaways

• WIP, throughput, work item age and cycle time show how work flows and where it gets stuck.
• DORA currently lists five software delivery metrics grouped into throughput and instability; check the DORA website for current names.
• Team health checks capture how people experience the work and should start conversations, not rank teams.
• Velocity is a team planning aid, not a productivity score, and should never be used to compare teams.

Sources

• The Kanban Guide
• DORA, DORA's software delivery performance metrics
• Henrik Kniberg and Kristian Lindwall, Squad Health Check Model (Spotify Engineering, 2014)
• Ron Jeffries, Story Points Revisited (2019)
• The 2020 Scrum Guide