Flow metrics and forecasting for government teams

Flow metrics are four measures that a delivery team takes from its own board: work in progress, throughput, cycle time and work item age. With them the team can forecast a date as a probability, such as “an 85% chance of finishing by 6th March”. The only data it needs is the dates on which it started and finished past work.

The four measures

The definitions here are the ones in the Kanban Guide.

Work in progress is the number of work items the team has started but not finished. The team controls it directly, because the team chooses when to start something.

Throughput is the number of work items the team finishes in a unit of time, such as a week. You use it to forecast how many items the team will finish by a date, or when it will finish a given number.

Cycle time is the time that passed between the team starting an item and finishing it. Sort the cycle times of your finished items and find the figure that 85% of them came in under. If that figure is 12 days, you can tell a stakeholder that 85 in 100 items like these take 12 days or fewer. The Kanban Guide calls that statement a service level expectation.

Work item age is the time that has passed since the team started an item it has not yet finished. You only know a cycle time once the item is done. Age tells you about the item while you can still do something about it. If an item is already older than most of your finished items took, talk about that one at stand-up.

The data you need

You need two dates for each item: the day the team started it and the day the team finished it. Agree as a team which columns on your board count as started and finished, and keep to that. Most board tools record both dates already, so nobody fills in anything new. That fits what GDS asks of reporting in the Service Manual, that it “should show a clear view of progress without creating any extra work for the team”.

How to forecast a date as a probability

The method is called a Monte Carlo simulation, and a spreadsheet or a short script can run it. Take the number of items the team finished in each recent week. For each week to come, the simulation picks one of those past weeks at random and uses its count. It carries on until the remaining items are done and notes how many weeks that took. Then it repeats the whole run thousands of times.

Here is an example with made-up numbers. A team has 30 items left. In its last ten weeks it finished 3, 5, 2, 6, 4, 4, 1, 5, 3 and 4 items. The simulation finishes within eight weeks in about 52 runs out of 100, within nine weeks in 81 and within ten weeks in 95.

Dividing 30 by the weekly average of 3.7 also gives about eight weeks. The simulation shows that the team would miss that date nearly half the time.

So the team can say to its service owner: “We have a 95% chance of finishing these 30 items within ten weeks and about a 50% chance within eight.” The service owner can then choose how much risk to carry when they give a date to anyone else.

Run the forecast again every week. The answer moves when the team’s throughput changes and when someone adds or removes items.

What the forecast leaves out

The forecast uses counts and dates. Nobody estimates the size of each item, and we do not use story points, velocity or percent complete for it.

Two things can still make it wrong. Someone has to keep the count of remaining items up to date, because the forecast can only cover the items on the list. And you are assuming that the coming weeks will look like the recent ones. If half the team is about to move to other work, use past weeks when the team was that size.

Narrow the forecast by starting less

When the number of items finished each week varies a lot, the forecast comes out wide. The first thing to try is a work in progress limit: the team agrees the most items it will have in progress at once. With fewer items started, each one waits less and finishes sooner. GDS describes Kanban in the Service Manual as a way to “control the amount of work you’re doing” and to find the bottlenecks in your process.

Try it on your own board this week

Export the start and finish dates of everything your team finished in the last ten weeks. Count the items finished in each week, and sort the cycle times to find the 85% figure. You now have a throughput history to forecast from and a service level expectation to give your stakeholders.

Our one-day course, Kanban and Flow Management for Government, covers board design, work in progress limits, cycle time, throughput and Monte Carlo forecasting. It costs £695+VAT per delegate. The glossary defines the terms used here.