Kanban vs Sprint: Does Kanban Have Sprints?
The Answer
Kanban has no sprints. A sprint is a fixed time box, usually one to four weeks, that scopes a batch of work and ends on a set date, and kanban replaces the whole mechanic with continuous flow: items are pulled one at a time when capacity frees up, and released whenever they are finished. So kanban vs sprint is a question about commitment. A sprint asks the team to promise a batch by a date, where kanban asks only that the team caps how much is in progress at once and keeps it moving. Teams interrupted weekly do better without the time box. Teams whose stakeholders plan around dates usually need it.
What Is a Sprint, Exactly?
A sprint is a fixed-length iteration with a start date, an end date, and a scope the team agrees to at the beginning. The Scrum Guide caps it at one month, and two weeks is the common choice. Three things make it a sprint rather than just a fortnight:
- The time box is fixed. It ends on the date it was always going to end on, finished or not.
- The scope is chosen up front. Sprint planning selects the batch, and the team commits to it.
- Scope holds. Changing it mid-sprint is possible and discouraged, because the commitment is what gives the sprint its meaning.
Take away any one of those and you have a recurring meeting, not a sprint. Plenty of teams that believe they run sprints have quietly lost the third one.
Does Kanban Use Sprints?
No. Kanban has no time box, so there is nothing to plan into and nothing to close out. Work moves across the board continuously, and the constraint doing the real work is the WIP limit rather than a calendar boundary. An item that takes two days ships on day two. An item that takes three weeks ships in week three, without needing to be split to fit inside somebody’s fortnight.
That last point matters more than it sounds. Sprint-shaped work gets sliced to fit the container, which is sometimes good discipline and sometimes an exercise in inventing artificial half-features so the board looks clean by Friday.
Kanban still has rhythm. Most boards I have run keep a weekly meeting to refill the queue, a daily standup walked right to left, and a monthly look at flow numbers. None of those scope the work. They are habits sitting on top of a flow that never stops.
What Replaces Sprint Planning in Kanban?
Replenishment replaces sprint planning. It is a short recurring meeting, usually 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, and nothing carries the weight a sprint commitment carries.
The practical difference is batch size. Sprint planning picks ten or fifteen items every two weeks and locks them. Replenishment tops the queue up to a handful, and the queue gets refilled whenever it runs low. Because the decision happens more often, it happens with better information, and a request that arrives on Wednesday does not have to wait nine days for the next planning session.
Two other scrum events map across cleanly. Keep the retrospective. Nothing in kanban replaces it and it stays the most useful hour on the calendar, so protect it first when the week gets busy. The standup survives too if it helps, walked from the right of the board. Sprint review is the one to drop, or convert into a demo whenever there is something worth showing, since no boundary remains to hang it on. For the fuller comparison, kanban vs scrum covers roles, metrics and change handling.
Kanban Board vs Sprint Board
A sprint board holds one sprint’s worth of work and gets cleared when the sprint ends. A kanban board holds whatever is in flight and never resets. On screen they look almost identical, which is why so many teams assume they are running kanban when they are running scrum with different vocabulary.
| Sprint board | Kanban board | |
|---|---|---|
| Contents | The items committed to this sprint | Whatever is currently in flight |
| Lifespan | Cleared at sprint end | Persistent |
| Unfinished work | Returns to the product backlog | Stays where it is |
| Limits | Sprint scope caps the batch | WIP limits cap each column |
| Adding work | Discouraged mid-sprint | Normal |
| Useful metric | Velocity, burndown | Cycle time, throughput |
The reliable test on an unfamiliar board is to ask what happens to an unfinished card on Friday afternoon of the last sprint week. If it goes back to a backlog, you are looking at a sprint board.
Can You Run Sprints on a Kanban Board?
Yes, and a lot of teams do, though at that point the sprint is doing the work and the board is just the display. Jira makes this easy enough that the distinction gets lost: a scrum board and a kanban board in Jira differ mostly in whether the sprint feature is switched on.
The hybrid worth knowing about is scrumban, which keeps a planning rhythm from scrum and adds kanban’s WIP limits and flow metrics. That combination is genuinely useful. What does not work is dropping the sprint commitment, keeping the ceremonies, and continuing to call it scrum, because stakeholders will keep expecting a batch on a date that nobody is promising any more.
When Is a Sprint Actually Better?
A sprint earns its keep when the team needs a forcing function. Three situations where I would keep the time box:
- Stakeholders plan around your dates. A fortnightly rhythm gives them something concrete, and cycle-time forecasting takes weeks of data before it can replace that.
- The team struggles to finish without a deadline. Some teams genuinely ship more with a date bearing down on them, and there is no shame in designing around that.
- The work is plannable and arrives from one source. Feature development with a single product owner fits a sprint far better than a support queue does.
Against that, drop the time box when requests arrive from several directions on their own schedule, when item sizes vary from an hour to a fortnight, or when the sprint commitment has been broken so often that nobody believes it. That third one is the common case. Once a team has renegotiated scope mid-sprint three sprints running, the ceremony is costing time and buying nothing.
How Do You Forecast Without Sprints?
You forecast from cycle time. Once a board has a few weeks of history, you know how long items of a given size have actually taken, and that range answers the date question with real data instead of estimates. If your last twenty items took between four and nine days, “four to nine days” is your forecast, and the honest version includes both ends.
This is where a board that tracks time pays for itself. Kanbanee logs cycle time and throughput per board and draws a cumulative flow diagram, so the numbers accumulate without anyone maintaining a spreadsheet. Flow metrics get their own guide, including which of them are worth watching weekly.
Stakeholders tend to be more comfortable with the range than teams expect, particularly once they have seen it hold for a month or two. What they dislike is a confident single date that slips twice.
FAQ
Is a sprint the same as an iteration?
Effectively yes. Iteration is the generic term for a fixed-length development cycle, and sprint is the name scrum gives it. Other frameworks use their own labels for the same idea.
Can a kanban team commit to a deadline?
Yes, though the commitment comes from historical cycle time instead of a planning session. If items of this size have finished inside nine days for the last two months, committing to nine days is a defensible promise, and it rests on more evidence than a sprint estimate usually does.
What is kanban sprint planning?
The phrase describes two different things. Some teams mean replenishment, the short weekly meeting that refills the queue. Others mean they are running scrum on a kanban-style board and have kept the planning event. Worth asking which, because the two setups behave differently when an urgent request lands.
Do kanban teams still do standups?
Most do. The format usually changes: rather than each person reporting what they did, the team walks the board from the right, starting with the items closest to done and asking what would move each one forward.