Kanban metrics for forecasting: WIP, cycle time and throughput

Everyone is flat out, but we’re not delivering anything.

MAURICIO BOTERO
Software Engineer

A while back I worked on a twenty-person team that missed every single sprint goal and couldn’t explain why. The Kanban board had been recording how work moved for months, but nobody looked at that data to decide anything. That’s where my interest in Kanban metrics for forecasting started: to stop arguing about how much work the team should complete and start analysing how much it actually could, using historical data and expressing the results as probabilities.

Three metrics are enough: WIP, cycle time, and throughput. With those plus the history your board already stores, you can answer — with a probability attached — how many items fit into a sprint, when a backlog of 100 tickets will be finished, and what is taking longer than usual.

The day story points stopped being useful

Planning on that team ate up a full day. Twenty people adding and subtracting hours, estimating how much time each person could put in, assigning every ticket in the sprint in that same session. The next day, someone called in sick, and the plan was worthless.

The underlying problem wasn’t the length of the meeting; it was that we were converting story points into hours. Points were designed to compare the relative size of stories, not to decide when something will be ready. If what you want is a forecast in hours, work in hours directly and accept what that implies.

When I sat down to review the data, the correlation everyone took for granted simply wasn’t there:

• Items estimated at 2 points that took two or three weeks to close.
• Items with far more points that were finished in one or two days.

With no correlation between the estimate and the real completion time, making decisions on that metric means committing to things that probably won’t happen. And it’s the person doing the development who pays for it, because the pressure to hold up a date that never had any basis lands on them.

There was a second, more subtle symptom: the feeling that everyone was busy. Being busy and delivering are not the same thing. No one knows whether something adds value until it is finished and can be validated, so a team working at full capacity with nothing completed is not delivering: it is building up inventory.

One distinction is worth making: a high-level estimate is useful; treating it as a commitment isn’t. In software development, you discover the real problem once you start working on it. Measuring the process as it actually happens —not as we’d like it to happen— is what lets you decide better.

The three metrics that do describe the process

A Kanban board —it doesn’t matter whether you work with Scrum, another agile framework, or none at all— already records what you need. With Jira, Trello, or any other ticket tracker, you have access to the flow metrics the Kanban Guide considers mandatory:

• WIP (work in progress): the number of items in progress, meaning started and not finished. It signals multitasking, queues, and congestion. The rule of thumb: more WIP means more waiting, and more waiting means more time to finish. WIP is the system’s inventory: if it grows with the same team, delivery time grows with it.

• Cycle time: how long an item takes from whatever point in the process you decide to monitor until it’s closed. The key is reading it by percentiles (p50, p85, p95) rather than by average. Outliers (the handful of items that deviate wildly from the rest) skew the mean enough to lead you into the wrong decisions, whereas a percentile gives you a probability conversation: “there’s a 70% chance this closes in 40 days or less”.

• Throughput: the number of items finished per unit of time, weekly or daily. It’s the system’s real output capacity, and its history is the raw material of any forecast.

The three are connected through the law Little formulated for queueing systems, which applies just as well to a work board:

WIP = Throughput × Cycle Time

Cycle Time = WIP / Throughput
Throughput = WIP / Cycle Time

The practical reading: if you keep output steady and raise inventory, delivery time goes up. And to bring cycle time down, there are only two levers: limiting work in progress or improving the effective capacity of the process. It’s a law of averages: it works well in stable systems and worse when the process is out of control.

Using Kanban metrics for forecasting on a real project

On the client project I’m running now, we have these metrics wired to the board, and the order in which I look at them is always the same.

1. The cumulative flow diagram shows the WIP for each day and how items move through every stage. A bottleneck shows up as a band thicker than the rest, and the most common case is development delivering faster than QA can test. If you don’t limit what reaches the testing team, by the time QA finds something to fix, whoever developed it will already be on another task: they’ll have to stop and rebuild a context they’ve forgotten.
2. The daily throughput chart makes the delivery pace visible. In the first few weeks, the chart was flat: the team at full capacity and nothing coming out, because the stories didn’t allow anything to be validated or delivered. Once we adjusted how tickets were written, it started moving.
3. The cycle time distribution is the past: items already closed. It’s there to answer “how long does this normally take?” with data, and to see whether the times are where they should be.

With that history, you can start running simulations, and that’s where the conversation changes. Give it the sprint start date and its duration, and the simulation returns something like this: with 85% probability, the team closes 6 items or more. With that number and the product owner’s priorities, planning goes from a full day to a few minutes: you start with the six priority items, and the rest gets picked up as people finish.

The same calculation works for the medium term. With 100 items in the backlog and starting today, the simulation gave us an 85% probability of taking 166 days: estimated date, 21 June. That doesn’t close the conversation; it opens it: if the business needs it sooner, you cut scope with months of runway instead of discovering the problem in the final week.

Risk management: the one chart that looks at the present

Everything above describes what already happened, but the chart I actually use daily is a different one: the aging work in progress chart, which shows the items in progress and how many days they’ve been there, grouped into bands by age. When a ticket crosses from one band into the next, the probability of it dragging on goes up, and that turns the chart into an alerting system: more than 20 days is already a risk signal.

Putting that in front of the team doesn’t point the finger at anyone: when you’re deep in development, you lose the full view of the board. Decisions are made as a group, and they’re almost always one of three kinds:

• Ask for help, when someone has been stuck for days.
• Break the story down, when it’s bigger than it looked.
• Tag the blocker, when it depends on something outside the team.

That last point hides a design detail that made all the difference: the blocked story stays in its column with a tag, so we keep visibility of where it’s blocked —in development, in testing— and how long it’s been that way. The dashboard also lets you set alerts: more than five days in the same state, for example.

I presented all of this in an internal Knowledge Sharing session, and the Q&A left one caveat and one open question. The caveat came from David Rueda, a colleague and engineer at Orbitant, who agreed it works for almost any project, with the exception that on projects with loose deadlines it may be more than you need.

It’s applicable to practically every project. On the ones that are a bit more relaxed about dates, I’d maybe see it as overkill.

DAVID RUEDA
Software Engineer

The open question came from another colleague, Lucas Jin: if one ticket takes four hours and another takes a week, what is the metric actually measuring? My answer is that expecting them all to be the same size is impossible, but you can set entry criteria for the backlog:

1. It can be validated as soon as it’s finished.
2. It’s as independent as possible.
3. It’s a reasonable size to close within a few days.

The noise that’s left gets absorbed by the percentiles.

The next step is taking these metrics to other projects and checking whether they add value in each context: the goal isn’t to standardise a board; it’s to have the full toolbox and reach for the tool that fits the problem. If planning on your team is still a negotiation over hours, start with the cheapest thing you can do: look at the cycle time of the last three months by percentiles and compare it with what you’re promising. That gap is the real size of the problem.

Frequently asked questions

Do I need to abandon Scrum to use flow metrics?
No. These metrics come from the board, not from the framework. You can use them with sprints, without them, or with any process where items move through defined states. In a Scrum context, they replace point estimation as the basis for deciding sprint scope.

How much historical data do you need for a forecast to be reliable?
Volume isn’t the only thing that matters — stability is. If the throughput of the last few weeks is erratic because the process or the team is changing, the simulation will inherit that noise. It’s worth stabilising the flow before making business decisions on top of the projections.

What do I do if my team’s cycle time comes out sky-high?
It’s a diagnostic signal, not a verdict. Check the cumulative flow diagram to locate the stage where work is piling up, look at whether WIP is above what the team can sustain, and check whether tickets are framed so they can be closed independently.