Agile, Scrum and Kanban: which one to choose

The Agile Manifesto was written in February 2001, when seventeen software practitioners met at a lodge in Snowbird, Utah. Among them were Kent Beck, Martin Fowler, Ken Schwaber, Jeff Sutherland, Alistair Cockburn and Ward Cunningham, people running different lightweight methods (Extreme Programming, Scrum, Crystal, DSDM, Feature-Driven Development) who wanted to name what those methods had in common. The document they produced is short enough to read in a minute and states four preferences:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

The sentence people skip is the one that closes it: while there is value in the items on the right, the authors value the items on the left more. That is a statement about priority under conflict, not a licence to abandon documentation, contracts or plans. Most of the damage done in the name of agility comes from reading four preferences as four prohibitions.

Twelve principles sit behind the four values. Rather than reciting them, it is more useful to see what they cluster into. Roughly five ideas: deliver something usable early and then keep delivering on a cadence of weeks rather than months; treat late change as information, not as a failure of planning; put the people doing the work and the people who need it in direct contact, daily, in conversation rather than through documents; work at a pace that can be sustained indefinitely, with attention to technical quality and to simplicity, defined as maximising the work not done; and let the team inspect and adjust its own process at regular intervals.

Note what the Manifesto does not contain. No sprints, no standups, no board, no story points, no roles. Every one of those comes from a specific method built on top of it, and none of them is required in order to be agile. A team that ships weekly, talks to its customer, and changes its process when it stops working is agile without owning a single piece of Scrum vocabulary.

Scrum is defined by the Scrum Guide, maintained by Ken Schwaber and Jeff Sutherland and last substantially revised in 2020. The Guide is deliberately short and describes itself as intentionally incomplete: it defines a framework and leaves the practices inside it to the team.

Accountabilities. The 2020 Guide dropped the word roles in favour of accountabilities, and there are three. The Product Owner is accountable for maximising the value of the product and owns the Product Backlog: one person, not a committee, whose ordering decisions others must respect for the arrangement to work. The Scrum Master is accountable for the team's effectiveness and for Scrum being understood and enacted, which in practice means removing impediments and protecting the team from interruption rather than managing it. The Developers are everyone who does the work of creating the increment, whatever their specialism. There is no project manager and no separate QA accountability in the framework; the Guide expects a team of ten or fewer that is cross-functional enough to finish work without handing it outside.

The Sprint and the events. The Sprint is a fixed period of one month or less that acts as a container for everything else. It starts the moment the previous one ends, its length does not change to accommodate unfinished work, and it is never extended. Four other events sit inside it, each timeboxed. The maximum lengths in the Guide are stated for a one-month Sprint and scale down proportionally for shorter ones.

A team on a two-week Sprint therefore has roughly four hours of planning, two hours of review, ninety minutes of retrospective and two and a half hours of Daily Scrums, about ten hours of scheduled meetings per fortnight for the whole team. That is the real cost of Scrum, and it is worth stating plainly before adopting it. The formats that make those hours worth spending are covered in standups and retrospectives.

Artifacts and their commitments. Scrum has exactly three artifacts, each paired since 2020 with a commitment that makes it measurable. The Product Backlog is the ordered list of everything that might be needed, and its commitment is the Product Goal. The Sprint Backlog is what the Developers selected plus their plan for delivering it, and its commitment is the Sprint Goal, a single objective that gives the Sprint coherence and survives even when individual items are dropped. The Increment is the usable output, and its commitment is the Definition of Done, the shared standard that decides whether something counts as finished. Backlog ordering is where prioritisation frameworks like MoSCoW and RICE earn their place, and the Product Goal is the level at which OKRs connect to sprint work.

Two rules do most of the work and are the two most often broken. Scope is not added to a Sprint in flight without the Product Owner and Developers renegotiating it, and the Sprint length never changes. Break either one and Scrum becomes a status cadence with no forecasting value, because nothing about it is stable enough to measure.

Kanban comes from Toyota's production system, where a physical card (the kanban) signalled that a downstream station was ready for more material. David J. Anderson adapted it to knowledge work in the late 2000s, and the adaptation kept the essential move: a workstation pulls work when it has capacity instead of having work pushed onto it by whoever is upstream. Kanban is usually described as six practices.

• Visualise the work. Every item in flight is a card on a board whose columns are your actual process, not an idealised one. If work really does bounce back from review twice, the board says so.
• Limit work in progress. Each column carries an explicit cap. When the cap is reached, nobody starts anything new in that column; they help finish what is already there.
• Manage flow. The thing being optimised is the movement of work across the board, not the utilisation of the people. Idle capacity is acceptable; stalled work is not.
• Make policies explicit. Written rules for what ready means, what done means, and how an item gets expedited. An unwritten policy cannot be improved because it cannot be disagreed with.
• Implement feedback loops. Regular reviews of the board, the flow metrics and the delivery, at whatever cadence suits the team.
• Improve collaboratively, evolve experimentally. Kanban is explicitly a change-management method: start with what you do now, and change it incrementally rather than replacing it.

The WIP limit is the part that feels wrong and matters most. Capping work in progress looks like it slows the team down, and for the first week it does. What it actually does is expose the constraint: when the testing column is full and nobody can start anything, the queue in front of testing becomes visible to everyone, including to the people who could go and help clear it. Without a cap, that same bottleneck is invisible because the work simply piles up in a column nobody is counting.

Kanban's arithmetic is Little's Law, from queuing theory: average work in progress equals average throughput multiplied by average cycle time. Hold throughput steady and cycle time rises in direct proportion to the number of things underway. That is why a team with twenty items in flight delivers each one late even though it is working flat out, and why cutting WIP shortens delivery times without anyone working faster.

The metrics follow from the same model. Cycle time runs from the moment work starts on an item to the moment it is done; lead time runs from the moment it was requested, which is the number the customer experiences; throughput is items finished per week. None of these require estimating anything. They are measured from the board's own history, which is why Kanban teams can forecast without story points.

The two are often presented as rivals. They are better understood as answers to different questions. Scrum asks what can we commit to for the next two weeks; Kanban asks how quickly does work move through our system and where does it stop.

One asymmetry is worth naming. Scrum is a framework with rules you either follow or do not; the Scrum Guide is explicit that removing an element leaves you with something that is not Scrum. Kanban is a method you apply on top of whatever process you already have, and it has no equivalent notion of being incomplete. That makes Kanban far cheaper to try and far easier to let decay into a board with no limits on it, which is the most common way it fails.