Kanban Calculator: Size a Pull System Before You Commit to It

The Kanban Calculator does one job. It calculates the number of kanban cards needed to maintain flow given demand, lead time and safety stock. That is a small question with a large consequence, because the card count is what sets the amount of work allowed in a process at any one time.

It sits in the Improve phase of RDMAICS. By the time you open it, you have already recognised a problem, defined its boundary, measured the process and analysed what is driving the behaviour. The Improve phase is where a diagnosed cause becomes a change worth piloting. The calculator is the step that turns the intent to pull work rather than push it into a number you can act on.

Reach for it when your analysis points to queues, batching or uncontrolled work in progress. If the evidence says work piles up between steps and nobody knows how much is in flight, a card count gives you a limit. It also gives you something rarer in improvement work, which is a way to size the gain before you commit resources to the change.

The example used throughout this guide is fictional. It is the sample data that ships with the tool, and it is there to show the method rather than to report a real result.

The sample case is an invoice approval process. The team handles an average demand of 90 invoices per day. Time through approval, the lead time, is 0.5 days. Invoices move in batches of 5 per kanban card, which is the container size.

The team also wants a buffer. The safety factor is set at 1.2, which is a 20 per cent allowance. That covers normal variation in arrival and handling without needing a separate forecast of every disruption.

Those four inputs are everything the calculation needs. Notice what is absent. There is no headcount, no cost per invoice, no software licence. The calculator deliberately works on flow mechanics alone, because that is what the card count controls.

The worksheet is a simple table. Each row is a parameter with a value, a unit and a note. The discipline is in the units, not the arithmetic.

Average demand is recorded as 90 invoices per day with the note Daily volume. Lead time is 0.5 days with the note Time through approval. The safety factor is 1.2, described as a multiplier giving a 20 per cent buffer. Container size is 5 invoices per card, the batch per kanban. The final row holds the output, kanban cards needed, with the formula shown as demand times lead time times safety factor, divided by container size.

Fill the table in that order and the units cancel cleanly. Demand per day multiplied by days gives units. Dividing units by units per card gives cards. If your units do not cancel, one of your inputs is measured in the wrong period and the result will be wrong by a factor you may not notice.

Spend your effort on lead time. Demand is usually easy to count from records. Lead time is the input people guess, and it is the input the result is most sensitive to. Take it from your Measure phase data rather than from memory.

The tool breaks the calculation into three visible steps. First, demand multiplied by lead time gives 45 units. That is the work in the system at any moment if everything runs to plan. Second, the safety factor of 1.2 is applied as a buffer. Third, the output is expressed in cards. The result is 11 cards required.

The formula shown is ceil of demand times lead time times safety factor divided by container size. The ceiling function matters. You cannot issue a fraction of a card, so the tool rounds up. That rounding is a small, conservative bias in favour of flow.

The tool marks the calculation as verified and offers an AI review that explains the result in plain language. Use the review as a second pair of eyes on your inputs rather than as a substitute for judgement. The arithmetic was never the hard part.

The headline number to carry forward is 11 cards. Each card covers 5 invoices, so the card system caps the work in progress at a known level rather than an unknown one.

A number on its own is not an improvement. What the 11 cards give you is a concrete pilot design. You can print 11 cards, release work only against a free card, and observe what happens. That is a change small enough to run and specific enough to evaluate.

It also supports a sizing conversation before you commit. You can see what the inputs are doing. Demand times lead time gives 45 units of work in flight. If analysis in an earlier phase suggested lead time could be reduced, you can re-run the calculation with the lower figure and see the card count move. The calculator makes the relationship between lead time and work in progress visible, which is the argument most improvement proposals struggle to make.

Container size is the other lever. At 5 invoices per card, the system is sized at 11 cards. Changing the batch per kanban changes the number of cards without changing the underlying workload. That is a design decision about granularity and handling, and the calculator lets you test it on paper first.

Finally, the result gives you a control point for the later phases of RDMAICS. Once the pilot runs, the card count becomes something to monitor. If the real process needs more cards than the calculation predicted, one of your inputs has drifted and you have an early signal.

The first mistake is mixing periods. Demand per day with lead time in hours produces a result that looks plausible and is not. Convert everything to one time unit before you enter it. In the sample, both sit on a daily basis, so 90 and 0.5 combine cleanly to 45.

The second mistake is using a target lead time instead of a measured one. If approval actually takes longer than 0.5 days, the card count will be too low and work will stall waiting for a free card. The system will then be blamed for the shortfall rather than the input.

The third is treating the safety factor as padding to be inflated when people feel nervous. The 1.2 multiplier in the sample is a stated 20 per cent buffer. Raise it and you raise permitted work in progress, which is the opposite of what most pull systems are introduced to achieve.

The fourth is forgetting that container size is a real constraint. If 5 invoices per card does not match how the team physically moves work, the cards will be worked around within a week.

With 11 cards as the design point, the pilot has a shape. Issue the cards. Allow no invoice batch into approval without one. Record how often cards run out and how often they sit idle.

Keep the worksheet alongside the pilot. When somebody asks why there are 11 cards and not 15, the answer is on the page: 90 invoices per day, 0.5 days of lead time, a 1.2 safety factor, and 5 invoices per card. That traceability is what separates a sized change from a preference.

Set a review point before you start. Decide in advance what evidence would make you change the card count. Without that, the number hardens into policy and stops being a hypothesis.

It will not tell you whether a pull system is the right answer. That judgement comes from the Analyse phase. If the cause of your delay is a single approver who is unavailable for half the week, limiting work in progress will reveal the problem but will not solve it.

It will not forecast demand. The 90 invoices per day is an average you supply. Seasonality, month end peaks and growth are outside the formula. The safety factor of 1.2 absorbs ordinary variation, not a structural shift in volume.

It will not cost the change or estimate savings. There is no money in the worksheet. If you need a financial case, build it separately using the work in progress figure of 45 units and the card count of 11 as inputs to that case.

It will not manage behaviour. Cards work when people respect them. The calculator gives you a defensible number. Making the number mean something in daily practice belongs to the Control and Sustain phases, and that is where most pull systems are won or lost.