Throughput

Deciding how much to take on over the next two weeks requires knowing how much got done over the last two. The long-standing way of answering that was to size each item and total the sizes.

That approach has a price. Setting sizes means the team sits down and discusses each item, and thirty items consume two hours. The sizes are also wrong. An item called an 8 finishes in two days while an item called a 3 takes five, and that happens every cycle.

The resulting number also cannot travel. Size is a relative unit each team invents for itself, so it cannot be compared with another team's identical figure. Two hours of discussion buys a number that means something only inside the room it was produced in.

Kanban made a different choice: do not measure size at all, and count finished items instead. What it puts in front of that is the work of slicing items to comparable sizes. Keep one card to something that finishes in one to three days and counting cards alone is enough to plan next week. The estimation meeting disappears and that time moves into slicing, which is work that leaves something useful behind.

Count the cards that crossed into the done column within the period you defined. Not their size, not the hours spent — the count.

Three things get settled before counting.

1. Pick the period. Weekly is the most common. Daily swings with the day of the week, and monthly takes too long to notice that the flow changed.
2. Define finished. Only cards meeting the definition of done count. A card that is built but awaiting review does not count this week; it counts in the week it clears review.
3. Decide what is in scope. Write down in advance whether bug fixes and support requests count alongside new features. Changing it midway makes before and after incomparable, and the change is easy to make by accident when a new card type appears.

The arithmetic is addition. Four recent weeks of 12, 14, 11 and 13 give a throughput of 12.5 per week, so next week's plan holds about twelve cards.

The figure does not stand alone. Throughput, cycle time — the time from starting work on a card to finishing it — and the number of cards in progress are locked together. Divide cards in progress by throughput and you get cycle time. Twenty-five cards in progress against 12.5 finished per week means the average card is spending two weeks on the board. Knowing two of the three fixes the third, which is also where the insight comes from that the lever for cycle time is the number of cards in progress.

On a cumulative flow diagram this figure appears as the slope of the done line. Where the line flattens is a week throughput dropped.

Comparing against another team's figure is meaningless. How large a card gets sliced differs by team, so one team's twelve per week and another's thirty may be the same amount of work.

A good throughput is a steady one, not a large one. Four weeks of 12, 14, 11 and 13 support a plan of twelve for next week. Four weeks of 4, 19, 7 and 20 average to 12.5, and that average guarantees nothing. Wide swings have causes worth finding: card sizes are uneven, someone was out for a week, or the definition of finished was applied loosely in some weeks and strictly in others. Look there before adjusting the plan.

The lever is also easy to mistake. Teams decide to raise this figure by working faster, when the cause is usually not slow hands but time cards spend queued. Apply a WIP limit, which caps how many cards may sit in one column at once, and people stop holding individual items and start moving them along, which raises throughput.

The figure to read alongside it is lead time, the span from a request arriving to it being finished, which is what the requester experiences. If throughput rose from 12 to 18 while lead time went from 9 days to 14, the team is picking off small cards and deferring large ones. More items get counted and the people waiting wait longer.

Three reference points do the work: your own figure last quarter, the figure before and after a specific change, and the figure next quarter's plan would require, worked backwards.

"Throughput has been 12 for four weeks and we just loaded 18 cards. Let's take six out."

Providing the evidence that the plan exceeds the record.

"Throughput went up but lead time went up with it. We're deferring the big cards."

The two figures have to be read together to see the real state.

"This card is a week's work. Split it into three and the count stops swinging."

Protecting the condition that counting by item assumes.

At Pagedeck, Mia puts four weeks of throughput and lead time side by side in the weekly meeting. Cards are kept under three days, and anything that looks like it will exceed that gets split.

There was a week throughput fell to 8. Looking into it, nine cards were stacked in the code review column and Theo was the only person working it. Capping that column at four and splitting review between two people brought throughput back to 13 the following month, without anyone working faster.

The most common error is reading throughput as a productivity score. It counts finished items, so more looks like more work. But the figure moves with how cards get sliced: split the same work into two cards and it doubles. Start using it for evaluation and the team drifts toward finer slicing, and six months later twelve per week has become twenty-five while the same amount of product ships.

The second error is assuming it is less accurate because it ignores size. Assigning points looks like the more careful method, so the assumption is natural. But both figures come out of the same record, and this one has no room for an estimate to be wrong. What it does have to protect is keeping card sizes comparable, and when that condition breaks, the figure swings. The difference is in what you have to manage, not in accuracy.