Kanban vs scrum: choosing how your team plans and ships work
The kanban versus scrum question is usually asked at the wrong altitude. It gets framed as a choice of methodology, complete with a preference, when in practice it is a question about one specific property of the work: whether the team can credibly commit to a fixed set of items for a fixed period, or whether the next two weeks will be rearranged by things that have not happened yet.
Answer that honestly and the choice mostly makes itself. Answer it optimistically and the team ends up running scrum ceremonies over a sprint that gets rewritten on day three, which is the most common and most demoralising outcome of all.
Both approaches have published definitions, so this is not a matter of opinion about what they contain. The 2020 Scrum Guide and the Kanban Guide, updated in May 2025, each state what is mandatory. What follows compares them on that basis, then on what running each one actually costs.
What each one actually prescribes
The difference in weight is visible in the definitions before it is visible in practice.
Scrum prescribes structure
The Scrum Guide defines a Scrum Team as one Scrum Master, one Product Owner and Developers, with no sub-teams or hierarchies inside it, typically 10 or fewer people. Work happens in Sprints, described as fixed length events of one month or less, with a new Sprint starting immediately after the previous one ends.
Four events sit inside the Sprint, each with a stated timebox for a one-month Sprint: Sprint Planning at a maximum of eight hours, the Daily Scrum at 15 minutes, the Sprint Review at a maximum of four hours, and the Sprint Retrospective at a maximum of three hours. Shorter Sprints usually mean shorter events.
That is a considerable amount of defined structure: three accountabilities, five events counting the Sprint itself, and three artifacts. It is also the point. The structure is what produces a predictable cadence of inspection.
Kanban prescribes flow
The Kanban Guide is built around a Definition of Workflow, which it calls a fundamental concept. At minimum, a Definition of Workflow has to specify what a work item is, when items are considered started and finished, the states items pass through, how work in progress will be controlled, explicit policies for moving between states, and a service level expectation, which is a forecast with a probability attached, such as 85% of work items finishing in eight days or less.
The visualization of that Definition of Workflow is what the guide calls a Kanban board.
There are three practices: defining and visualizing the workflow, actively managing items in the workflow, and improving the workflow. There are four mandatory metrics: work in progress, throughput, work item age and cycle time.
Notice what is absent. No roles. No meetings. No iterations. Kanban does not say who decides priority or how often anyone talks. It says what has to be visible and what has to be measured.
The comparison that matters
| Scrum | Kanban | |
|---|---|---|
| Unit of planning | The Sprint, one month or less | The individual work item |
| Roles defined | Scrum Master, Product Owner, Developers | None specified |
| Meetings defined | Planning, Daily Scrum, Review, Retrospective | None specified |
| Team size | Typically 10 or fewer | Not specified |
| How change enters | At the next Sprint boundary | Any time, subject to the WIP limit |
| Core discipline | Protecting the Sprint Goal | Controlling work in progress |
| Forecast method | Velocity across Sprints | Service level expectation from cycle time |
| Required metrics | None named in the guide | WIP, throughput, work item age, cycle time |
The last two rows are the ones teams underweight. Scrum's guide names no mandatory metrics, which is why velocity, an invention of practice rather than the guide, gets treated as one and then gets misused as a productivity score. Kanban names four and they are all about time and quantity in flight, none of which can be turned into an individual performance number without obvious absurdity.
Which one fits which work
Scrum fits work that can be committed to
If the team can sit down on Monday and agree on a set of items that will plausibly still be the right set on Friday of the following week, scrum works well. Product development against a roadmap, a feature build with a known scope, a research program with defined questions. The Sprint boundary is a real boundary, so protecting it is a reasonable thing to ask people to do.
The cadence itself is worth something separate from the planning. The Retrospective in particular is the only mandatory moment in either framework where a team is required to examine how it works rather than what it produced.
Kanban fits work that arrives
Support queues, agencies with several clients, operations teams, editorial pipelines, anything where the source of work is outside the team. Committing to two weeks of scope when a client can call on Tuesday is a commitment to breaking a commitment, and doing it repeatedly teaches the team that the plan is theatre.
Kanban absorbs this because the unit is the item, not the iteration. New work enters when capacity exists, capacity is defined by the work in progress limit, and the limit is the thing that gets defended instead of the Sprint Goal.
The test that settles it
There is a quick version of this diagnosis. Look back at the last three two-week periods and count how much of what was planned at the start was still being worked on at the end. Not whether it finished. Whether it was still the plan.
If the answer is most of it, the team has the stability that makes a Sprint meaningful, and the structure will pay for itself. If the answer is half or less, no amount of better planning will fix it, because the variance is coming from outside the team and planning is an internal activity.
The hybrid most teams actually run
A great many teams describe themselves as doing scrum while running something closer to kanban with a two week meeting rhythm. Sprint Planning happens, the Sprint gets rewritten midway, and the Retrospective survives because it is useful. This is often fine, but it is worth naming, because a team that knows it is running a flow system with a fortnightly review can drop velocity, adopt the four flow metrics and stop pretending the commitment was real. A team that does not name it spends every Retrospective discussing why the Sprint was not met.
What each one costs to run
Scrum costs meeting time
The timeboxes add up. For a two week Sprint the events are proportionally shorter than the one-month maximums, but a team of six still spends several hours per Sprint in defined events plus the Daily Scrum. That is a real investment and it produces real value, but it is only recoverable if the Sprint holds. When the Sprint gets rewritten, the planning hours are simply lost.
It also requires two people to hold accountabilities properly. A Product Owner who cannot actually decide priority, or a Scrum Master role handed to whoever is free, produces the ceremony without the mechanism.
Kanban costs discipline
Kanban asks for almost no meeting time and almost no role definition, which makes it look free. It is not. It requires a team to actually control the number of items started but not finished, and stopping work is harder than starting it. The guide is explicit that members must explicitly control that number from started to finished.
It also requires someone to look at the metrics. Work item age in particular is only useful if it is checked while the cards are still open. A team that adopts a board with columns and never sets a limit or reads a number has adopted the appearance of kanban and none of the mechanism.
Changing from one to the other without a rewrite
Switching frameworks is usually described as a migration, which makes it sound larger than it is. Almost nothing about the work itself changes. What changes is where the commitment sits.
From scrum to kanban
The board is already there, so the board is not the work. Three changes do most of it.
First, stop opening and closing Sprints. Work becomes a continuous queue, and priority is decided at the moment a card is pulled rather than two weeks in advance.
Second, put a number on the in-progress column and hold it. This is the whole substance of the change, and it is the part teams skip. Without a limit, removing Sprints just removes the only thing that was previously bounding how much got started at once, and the result is worse than either framework.
Third, replace velocity with the four flow metrics. Velocity is a measure of a Sprint, and there are no Sprints now. Throughput answers the same question without pretending points are units.
Keep the Retrospective. Nothing in kanban forbids a regular meeting, and the improvement practice needs somewhere to happen.
From kanban to scrum
This direction is rarer and harder, because it requires something to be true that was not true before: the team has to be able to protect a period of time. If the interruptions that made kanban fit are still arriving, adding Sprints on top will not stop them. It will just mean the interruptions now arrive as Sprint failures.
The honest version of this move starts outside the team. Someone has to agree that inbound requests will wait until the next boundary, or go to a separate person, or be explicitly allowed to break the Sprint with a named cost. Without that agreement, the framework change is decoration.
Give either change two months
One iteration proves nothing, because the first cycle of anything is dominated by the novelty of doing it. Two months of data is enough to see whether cycle time moved or whether the team simply renamed its meetings.
What the tool has to do
The framework choice puts different demands on the software, and getting this wrong makes the framework harder than it needs to be.
Scrum needs a board that can be reset, a backlog separate from the current Sprint, and somewhere the Sprint Goal is visible. Kanban needs columns that can hold a limit, a way to see how long a card has been sitting where it is, and an entry point that does not require a planning meeting.
Both need one thing above everything: the board has to be what the team actually looks at. A board maintained as a report about work tracked somewhere else is worse than no board, because it is confidently wrong. Where the tool matters most is in whether the same cards can also be read as a schedule when a date question comes up, without maintaining a second copy. That is worth checking in a comparison of how tools handle board types before committing to either framework's tooling.
What to change first
Write down, honestly, what proportion of the last three two-week periods ended with the work that was planned at the start. If it is most of them, scrum's structure is earning its meeting time and the thing to fix is probably the Retrospective. If it is not, stop running Sprints, set a limit on the in-progress column, and start reading work item age weekly. Pinateca gives kanban, Gantt and calendar views over the same cards and is free for up to five people and ten boards, which is enough to run either shape without deciding first.
Q1. Can a team use kanban and scrum at the same time?
In practice many do, and the combination is usually a flow system with a scrum meeting rhythm. The Kanban Guide describes Kanban as a strategy for optimizing flow that can complement other approaches, so layering it on scrum events is reasonable. The mistake is keeping the commitment language of a Sprint while running a board where work enters continuously, because then every Retrospective becomes a discussion about a commitment that was never achievable.
Q2. Does kanban have roles like scrum?
No. The Kanban Guide specifies no roles at all. It defines a Definition of Workflow, three practices and four mandatory metrics, and leaves who does what to the team. The Scrum Guide by contrast defines three accountabilities: one Scrum Master, one Product Owner and Developers.
Q3. How long is a sprint supposed to be?
The Scrum Guide says Sprints are fixed length events of one month or less, and that a new Sprint starts immediately after the previous one concludes. Two weeks is common practice rather than a rule. The stated timeboxes scale with the length: Sprint Planning is a maximum of eight hours for a one-month Sprint, the Sprint Review four hours, and the Retrospective three hours, with shorter Sprints usually meaning shorter events.
Q4. Which one is better for a small team?
Team size alone does not decide it. The Scrum Guide notes a Scrum Team is typically 10 or fewer people, so small teams are squarely in scope for scrum. The deciding factor is whether the work can be committed to for a fixed period. A three person team handling inbound client requests fits kanban better than a twelve person team building a planned product does.
Q5. What metrics should a kanban team track?
The Kanban Guide names four as mandatory: work in progress, meaning items started but not finished, throughput, meaning items finished per unit of time, work item age, meaning elapsed time since an open item started, and cycle time, meaning elapsed time from started to finished. Work item age is the most actionable of the four, because it concerns cards that are still open and can still be helped.
