EvolutionInsights

Two days of parcels

Imagine a courier with a van.

On Monday, she delivers five small parcels, two kilos each. On Tuesday, two large parcels, five kilos each.

Both days, ten kilos left the van. On paper, identical days.

In reality, completely different. Monday had five customers waiting, five addresses to find, five doorbells rung, five people who can now stop waiting. Tuesday had two.

If you only measured weight, you’d never know the difference. And that’s exactly what happens in a lot of sprint reviews.

The two numbers

Velocity is the weight. It’s the number of story points a team completes in a sprint. Because points reflect size, velocity tells you roughly how much work got done.

Throughput is the count. It’s the number of items a team finishes in a period, whether that’s a sprint, a week or a month. It ignores size completely.

A team that delivers 24 points might have finished eight small stories, or three large ones. The velocity chart looks the same either way. The sprint felt completely different.

What velocity is good at

Velocity is a planning tool for the team that produced it.

If your team has averaged 24 points over the last few sprints, 24 is a sensible starting point for the next one. Adjust for leave, holidays and anything unusual, and you have a realistic commitment rather than a hopeful one.

It also works well for release forecasting within a team. If there are 120 points left and you complete about 24 a sprint, you’re looking at roughly five more sprints. Not a promise, but a reasonable estimate you can update each sprint.

What velocity is bad at

Comparing teams. Story points are relative. A five in one team means whatever that team decided it means during their estimation conversations. A five in another team is a different thing entirely. Comparing them is like comparing two people’s definitions of “a short walk”.

Being a target. The moment velocity becomes something to increase, teams inflate their estimates. Nothing improves except the chart. If you’ve ever seen velocity climb steadily while delivery feels exactly the same, you’ve seen this happen.

Showing flow. Velocity tells you how much work finished. It says nothing about how work moved, where it got stuck, or how long each item waited.

What throughput is good at

Throughput is simply a count, which makes it surprisingly powerful.

It’s hard to game. You can inflate points. It’s much harder to inflate the number of items you actually finished.

It doesn’t need estimates. Some teams stop estimating altogether and forecast from throughput alone. If a team finishes seven items a week, a backlog of seventy items will take around ten weeks. That forecast is based on what really happened, not on what people hoped during planning.

It supports probability-based forecasting. With a history of weekly throughput, you can run a Monte Carlo simulation and say “there’s an 85% chance we finish by week 16.” That’s a far more honest answer than a single date, and stakeholders usually appreciate the honesty once they understand it.

It works across teams. Items finished per week is comparable in a way story points never are, as long as the teams work on broadly similar things.

What throughput is bad at

It ignores size. Ten tiny items and ten substantial ones look the same. That’s precisely why you don’t use throughput alone either.

Watching them together

This is where it gets interesting, and where most teams never look.

Velocity flat, throughput falling. Your stories are getting bigger. The same amount of work is arriving in fewer, larger pieces. That matters more than it sounds: bigger stories mean feedback arrives later, integration happens later, and more work sits unfinished when the sprint ends. Points look healthy. Flow is quietly getting worse.

Velocity rising, throughput flat. Either the work genuinely got harder, or estimates are inflating. Worth a gentle look at recent items to see which.

Both falling. Something real is happening: people away, blockers, unplanned support work, or technical debt slowing everything down. Look at the causes rather than the numbers.

Both stable. The most underrated result. A predictable team is a valuable team, even when nobody is celebrating it.

A worked example

A team’s last six sprints:

Look at the points column alone and everything is fine. Velocity is rock solid, between 24 and 26 every sprint. Any dashboard would show green.

Now look at the item count. It’s dropped from nine to five while the points stayed the same. The team is delivering the same weight in half as many pieces.

That’s worth a conversation in the retrospective. Are stories being split less? Is one large piece of work dominating? Are items sitting unfinished across sprint boundaries? None of these are visible in velocity, and all of them affect how quickly the team learns whether it built the right thing.

What to do with this

Track both, starting this sprint. You don’t need a tool. Two columns in a spreadsheet will do: points completed, items completed. After four or five sprints you’ll have a trend worth discussing.

Bring them to the retrospective, not to management. These numbers are for the team to learn from. The moment they’re used to judge people, they stop being honest.

Watch the gap, not the absolute values. Nobody outside your team should care that your velocity is 24. What matters is what changed and why.

Split stories when the item count drops. It’s the simplest, most effective response to this particular pattern.

Add cycle time when you’re ready. Velocity tells you how much. Throughput tells you how many. Cycle time tells you how long. Together they cover most of what you need to know about delivery.

The mistake to avoid

The mistake isn’t choosing the wrong metric. It’s believing that any single number describes a sprint.

A sprint is people, dependencies, interruptions, unclear requirements, good days and bad ones. A number is a summary of one aspect of it. The moment we treat that summary as the truth, we start managing the number instead of the work.

Metrics are conversation starters, not verdicts. The value isn’t in the chart. It’s in the question someone asks after looking at it.

In one line

Count the parcels. Weigh them too. One number never tells the whole story.