How do I determine the proper number of replenishment/Kanban tokens for my board?

Is there a recommended approach in determining an initial value for the number of replenishment tokens?

As time goes on and metrics are gathered what techniques are best for evaluating if the initial value is good enough or should be modified?

Hi Doug

Here’s a heuristic.

First make sure you know how to size your DBR Buffer.

See here:

Then the number you are looking for is:

Work “in process” at the Constraint + number of items in the buffer + number of items “in flight” upstream of the Constraint.

Hope it helps.

Thanks Steve, this is helpful.

First, I want to say that I am from Dan Vacatini’s “no matter what you pick as your WIP limit, it will be wrong” school of thought. As a result, observe and adapt is key.

In your response, the first two items are covered in the article and easily approximated. The key is the “in flight items that are upstream”

I could guess and then monitor if the number seems to be proper. I saw something in one of your books that indicated the total number of tokens should be equal to the number of people on the team. I might even choose double that as a starting point. That would give me a way of estimating what I want the inflight number to be.

It seems to me that the average time for an item to travel from the constraint to “Done” should also factor into the estimation, since the Kanban token would not be available for a new item to enter the workstream until that item is done. If the downstream time is longer than the upstream time, that could limit items being released into the workstream if the total number of tokens is too small. Seems like there might be a ratio using that time that might help in determining an estimated value.

I’m talking/writing off the top of my head here, but just wondered whether I am making this too complicated. I am fine with guessing, then monitoring, then adjusting. In any case, the buffer size and constraint WIP need to be defined to establish the proper DB part of DBR which I am good with.




Yes, you are making it too complicated. Just like buffer sizing, start with a guess. Use LL to get to a reasonable one. Then increase/decrease depending on what you see. If the Work Process Constraint is not overloaded and not starved, you’re getting it right. If it is overloaded, decrease. If it is starved, increase. Let the DBR Buffer signal be your guidance. That’s why we have the signals.