Scrum and Kanban: What’s the difference?

When working in an agile model, two task management techniques are often at the top of the list of approaches a team might take – Kanban and Scrum.

Some call these processes in themselves, but the way I see it is they’re more of a practice or tool for managing tasks. They’re really very similar approaches and, in fact, one might be called a subset of the other. But in the end, some subtle differences make quite a paradigm shift when it comes to how the project overall is managed.

What is Kanban?

Kanban is a simple methodology used to manage work in a way that requires minimal command and control, but nonetheless ensures that everything important eventually gets done (or perhaps, if it wasn’t that important, canceled).

Task cards (in a low-tech implementation, usually in the form of Post-It Notes) are organized in lists or columns that indicate their state at any given time. Every task begins in the backlog (some call it simply a “to do list” or “inbox”) and works its way through various phases of the process until it can be considered “done” (or, in some instances, “canceled” or “on-hold”).

Kanban is useful for continuous projects with either one big timeline or no timeline at all. In the software business, this could mean a project that’s already in maintenance mode (your backlog consists mainly of support tickets and known issues), or a continuous improvement initiative.

The nature of Kanban in which ideas can be added to the backlog easily and processed in due time also makes it a good choice for more unpredictable projects where we don’t necessarily know clearly how much work is coming in and when.

While Kanban is used often in software projects, it’s also frequently used in other lines of work such as in sales, in which CRM’s often use a Kanban board to process leads, and in recruitment teams, where candidates can be processed in a “pipeline”.

Interested in trying Kanban for your project? Check out my free Trello board templates and open the Kanban template made just for this purpose!

What is scrum?

Scrum is a more time-bound approach to agile, in which the entire project is worked on in short, incremental bursts called “sprints”. This approach allows teams to regularly assess and change direction as needed, as the objective and content of each sprint is decided at the beginning of it.

The product backlog still exists but everything can be considered tentative until it’s been selected for work in a particular sprint. In a way, I would say Scrum is simply a variation of Kanban with short bursts of work (sprints) in addition to the overall backlog.

Scrum introduces a new role (which is optional but generally recommended) called a “scrum master”. The scrum master typically facilitates sprint plannings and retrospectives, as well as daily stand-ups. In more traditional organizations, this might be equivalent to a project manager, though as in most agile processes, teams and members are also expected to drive the work themselves.

Compared to Kanban, scrum is more focused in terms of effort, as there is a sprint target to set and meet on a regular basis. “Velocity” (the average number of story points or estimated effort accomplished per sprint) is introduced and tracked as an indicator of how much work the team can do in a given sprint.

Due to the time constraints implemented in a sprint, scrum can be ideal for projects with a roadmap that has more predictability in terms of load but (as in most software projects) less predictable in terms of how the final product turns out. That means development efforts for new features might benefit from the short bursts of progress and tracking that scrum better facilitates.

Interested in trying Scrum for your project? Check out my free Trello board templates and open the Scrum template made just for this purpose!

A quick comparison

To summarize the differences between scrum and kanban, here’s a quick comparison:

Scrum	Kanban
Short, incremental bursts called “sprints”	One big timeline (or no timeline at all)
More focused work, with both short-term and long-term objectives	Can be effective for more open-ended projects where work comes and goes at its own pace
A “scrum master” role might be necessary to facilitate sprints	Potentially more self-driven as the approach is straight forward and requires minimal facilitation
“Velocity” is an important metric as it gives you an idea of how much work you can take in the next sprint.	Velocity is not measured but “burndown” is a good way to see how work is going.
Effective when the volume of work is more or less consistent, but the requirements are likely to change (e.g. product roadmaps)	Effective when workload is unpredictable (e.g. support tickets) but the requirements are relatively stable.
Ideal for product or feature development projects	Ideal for maintenance and support projects

Take all of this with a grain of salt though, as approaches are always bound to circumstances and countless other factors. While I’ve personally experienced each approach to work better in certain situations, your mileage may vary.

In the end, task management is all about aligning everyone on where you currently are and where you’d like to be in your project and both ways can work towards that end.