Scrum is an Agile framework that organises software work into fixed-length sprints, with defined roles and a set of regular ceremonies. Kanban is the alternative Agile framework: work flows continuously on a visual board, with limits on how much is in progress at once and no fixed sprints.
Two ways to do Agile
Scrum and Kanban are the two most widely used Agile frameworks. Both are ways of building software in small, frequent steps rather than one large delivery at the end, and the UK government's Service Manual recommends this agile approach for public-sector projects.
They are not rivals to each other and they are not the alternative to Waterfall: that's a separate choice. Scrum and Kanban both sit inside Agile. The question this entry answers is narrower: once you've chosen Agile, which of these two frameworks should the team use?
What Scrum is
Scrum organises work into sprints: fixed-length blocks of time, usually two weeks, in which the team commits to a planned set of work. The Scrum Guide, the framework's defining document, sets the sprint at one month or less.
Scrum also defines three roles, a Product Owner who decides priorities, a Scrum Master who keeps the process running and the developers who do the work, and a set of regular ceremonies: sprint planning, a short daily stand-up, a sprint review and a retrospective. The rhythm is the point. Every sprint ends with something to show.
What Kanban is
Kanban has no sprints. Work flows continuously through a visual board, split into columns such as "to do", "in progress" and "done", and each task moves across the board as it progresses. Atlassian's Kanban guidance describes it as a method built on visualising work and managing flow.
Its defining rule is the work-in-progress limit: the team caps how many items can be in any column at once. If a column is full, no new work starts until something finishes. This stops the team taking on too much at once and keeps work moving steadily rather than piling up half-done.
Scrum vs Kanban: side by side
The two frameworks differ on the things that shape how a project feels to run:
| Scrum | Kanban | |
|---|---|---|
| Cadence | Fixed-length sprints, usually two weeks | Continuous flow, no fixed timeboxes |
| Roles | Three defined roles: Product Owner, Scrum Master, developers | No roles prescribed; the team keeps its existing structure |
| Routine meetings | Planning, daily stand-up, review and retrospective | None required; the board is the main coordination point |
| Handling change | Scope is fixed for the sprint; new work waits for the next one | Priorities can change at any time, within the work-in-progress limit |
| Best suited to | Defined projects that benefit from a planning and demo rhythm | Ongoing work with shifting priorities, such as support |
The pattern behind the table is rhythm against flow. Scrum gives a project a steady, predictable beat. Kanban gives a team the freedom to re-prioritise at any moment. Which you want depends on whether your work arrives in planned batches or as a steady stream.
Which should your project use?
Scrum tends to fit a defined build, a new product or a major piece of functionality, where regular planning and a demo every couple of weeks give a client confidence and a clear point to give feedback. It's the more common choice for a fresh software project.
Kanban tends to fit ongoing work where priorities shift week to week: support, maintenance, bug fixing or a small team handling a steady stream of requests. Many teams also blend the two, an approach often called Scrumban, keeping Scrum's sprints and ceremonies while adopting Kanban's work-in-progress limits. A good supplier will recommend the framework that fits your work and explain why, rather than applying one by default.
Wondering how your project would actually be run? Scrum or Kanban is a delivery decision, and the honest answer depends on whether your work is a defined build or an evolving stream. Red Eagle Tech will explain how we would run your project, and why, as part of any bespoke software development engagement. The form below is the place to start the conversation.
