Kanban Planning: Estimation and Forecasting
The Answer
Kanban planning replaces the sprint commitment with two things: a short replenishment meeting that refills the queue, and forecasting from measured cycle time instead of estimates. Kanban estimation, including the kanban effort estimation that teams arriving from scrum expect to keep, is optional, and many mature teams drop it entirely, because once a board has six to eight weeks of history the question “how long will this take” is answered better by what similar items actually took than by anyone’s judgement in a planning session. Where estimation survives, it usually shrinks to rough size buckets used for splitting work rather than for predicting dates.
How Planning Works Without Sprints
There is no planning event that scopes a batch, because there is no batch. Instead, planning happens in three places, each smaller than sprint planning was.
Replenishment. A short recurring meeting, typically weekly and often under thirty minutes, where the team refills the ready queue with the next most valuable items. Nobody commits to finishing them by a date. The queue holds a handful of items rather than a fortnight’s worth, and it gets topped up whenever it runs low.
Pull decisions. When a slot opens, someone takes the top item. That is a planning decision too, made many times a week with better information than a Monday-morning session had.
Ordering the backlog. Continuous, and the real work of prioritisation. Because the queue is short, the order at the top is what matters, and arguing about position forty is wasted effort.
The net effect is that planning gets spread across the week in small doses rather than concentrated into one event. Teams moving from scrum usually find the total time spent goes down while the quality of the decisions goes up, since a request arriving on Wednesday no longer waits nine days for the next session.
Do You Estimate in Kanban?
Estimation is optional and plenty of teams stop. Kanban’s own literature leans towards probabilistic forecasting rather than estimation, on the argument that historical data beats judgement for predicting duration.
Three positions teams land on, all defensible:
- No estimation. Forecast entirely from cycle-time history. Works well once the board has enough data and item sizes are broadly consistent.
- Size buckets. Rough small, medium and large, used to decide whether an item needs splitting rather than to predict a date. This is where most teams I have worked with settle.
- Full estimation kept. Usually because a stakeholder or a governance process requires the numbers. Workable, though the estimates and the cycle-time data will disagree, and the data is generally right.
What rarely survives contact with a flow system is story points used for capacity planning. Points exist to fill a sprint, and without a sprint to fill there is not much for them to do.
Forecasting From Cycle Time
This is the mechanic that replaces estimation, and it is simpler than it sounds.
Collect the cycle time of your last twenty to thirty completed items. Sort them. Read off the percentiles. If 85% finished within nine days, then “within nine days, 85% of the time” is your forecast for a similar item, and it is grounded in what your team has actually done.
Two rules keep this honest:
- Quote a percentile, not an average. Averages hide the tail, and the tail is what makes stakeholders angry when it arrives.
- Say the confidence out loud. “Nine days at 85%” invites a sensible conversation about whether they want the 95% number instead, which will be longer.
For a batch of items rather than one, throughput does the work: if the team finishes six to nine items a week and the release needs thirty, that is roughly four to five weeks. Kanban metrics covers how to collect both numbers and how much history you need before trusting them.
The reason this lands better than estimates is that it survives contact with reality. An estimate is a claim about the future made by someone with an incentive to be optimistic. A percentile is a description of the past.
Capacity Planning and Prioritisation
Kanban scheduling works differently from the sprint version: capacity is set by WIP limits, not by a planning session. The board can hold what the caps allow, and adding more people does not raise throughput unless the limits change with them. This catches teams out: hiring into a system whose bottleneck is review does not speed anything up, it just grows the review queue.
For prioritisation, three approaches that work on a flow system:
Cost of delay. Order by what it costs to not have the thing, which is closer to the real question than business value alone.
Classes of service. Categories agreed in advance that determine how an item is treated, so urgent work does not require a negotiation every time. Kanban principles covers the four conventional classes and the important rule limiting expedites to one at a time.
Simple ordered queue. For small teams, a single ranked list where the top item is genuinely next. Less sophisticated and often entirely sufficient.
Release Planning
Release planning on a flow system means picking a scope and forecasting a date from throughput, or picking a date and forecasting the scope that fits. Both work from the same historical numbers.
The practical approach: count the items in the release, take your weekly throughput range, and divide. Thirty items at six to nine per week gives roughly three and a half to five weeks. Present the range. Then update the forecast every week as real throughput comes in, which is the part teams skip and the part that makes it useful, because a forecast that gets revised weekly stops being a promise and starts being information.
Where a hard external date exists, such as a regulatory deadline or a contracted launch, the fixed-date class of service handles it: the item gets scheduled backwards from the date rather than pulled in queue order.
What About the Backlog?
Kanban has a backlog, though it usually behaves differently from a scrum product backlog. Ordering matters most at the top, refinement happens close to the point of pulling rather than in bulk, and the queue between backlog and in-progress is deliberately short. Kanban backlog covers how to structure it, whether to keep user stories, and how the ready queue works.
The failure mode worth naming is a backlog nobody prunes. Kanban gives you very little structure to hide behind, so a board with a thousand unordered items and no replenishment discipline will happily run for a year while everyone wonders why the right things are not getting done. Replenishment is what stops that, and it only takes half an hour a week. Kanban meetings covers the full set of cadences and which ones small teams actually need.
FAQ
Can you do sprint planning with kanban?
You can hold a recurring planning meeting, and many teams do. It stops being sprint planning once the team is not committing to finish a fixed batch by a date, at which point it is replenishment with a longer agenda.
How do you answer “when will it be done” without estimates?
From cycle-time percentiles for a single item, and from throughput for a batch. Both come from your own board’s history, and both are quoted as ranges with a stated confidence level.
Does kanban use story points?
Not by default. Teams arriving from scrum often keep them for a while and then drop them, since forecasting from cycle time answers the same questions without the estimation overhead.
How far ahead can you plan with kanban?
As far as your throughput data supports, which for most teams means a quarter with reasonable confidence. Beyond that the forecast degrades for the same reason sprint plans do, since the work itself changes.