Should Our Agile Team Use Scrum or Kanban?

Originally published at:

Once a team has decided to gamble on the idea that an agile approach will at least be better than the controlled chaos of the status quo, the terminology of Agile starts to take on a new significance. Suddenly what was simply a manager telling people what to do and a team trying to get all the work done on time becomes a minefield of new labels, processes, roles and tools. This can be intimidating to managers and team members alike.

If you would like a refresher on agile, you might want to take a look at the Agile Manifesto, where the basic principles of agile are laid out by the people who codified the concept. For more details about the two approaches discussed in this essay, you can visit Scrum Methodology and Everyday Kanban, two sites that provide a good overview of Scrum and Kanban. You can also review some of the other articles published here at SitePoint on agile approaches to workflow management.

Choosing a Process

One of the first decisions that come up is which flavor of agile is the most appropriate for the team.

There are many popular approaches that have been formalized, in addition to the custom flavors a many companies end up adopting.

There can be a strong impulse toward choosing the approach that offers the fewest differences from what hasn't really been working so far.

For some companies, "getting agile" means sprinkling a few new titles and terms around without really changing how the work gets done, and calling it agile. It's worth giving your team a chance to follow a legitimate agile workflow first, all the while paying attention to what works and for whom.

Two of the most popular approaches to agile workflow are Scrum and Kanban. Since they are both agile, there are many similarities between the processes and tools you use when implementing either. But Scrum and Kanban provide a different set of advantages that are optimized for different applications.

Iterations or Slices

While both Scrum and Kanban are legitimate and complete ways to structure an agile process, and there are advantages (and disadvantages to choosing either one over the other,) it is worth starting out with the pure form of either approach before trying to customize them.

Both approaches have evolved and matured over the years, and no matter how deep you are into the weeds of your own office jungle, it is unlikely that your project requirements are outside the scope of what they have been designed to handle.

For teams looking to release new versions of a product on a regular schedule, while adapting to a constantly changing marketplace, Scrum is an excellent choice.

Scrum combines a clear set of roles, rituals and artifacts that can be adopted and used immediately.

Scrum is versatile enough to handle teams as small as five and can span organizations consisting of thousands.

It supports autonomy for the developers, transparency for the managers and accountability for the organization as a whole.

By having the team commit to an agreed contract for a time-limited sprint and then iterate based on how well things went, Scrum allows the team to adapt continuously without hindering the self-direction of every member of the team.

Teams operating in a service mode often prefer Kanban over Scrum.

While Scrum is optimized to deliver iterations of a product to customers on a regular basis, Kanban supports a constant stream of independent improvements and optimizations.

One of the key strengths of Kanban is that it focuses on controlling the amount of work the team has in progress at any point in time.

While both Scrum and Kanban benefit from clearly defined stories that can be completed and delivered independently, Scrum leaves it up to the team to decide how much to work on simultaneously, while Kanban focuses on limiting the number of items the team has in progress.

The difference may seem subtle, especially when looking at a Kanban board and a Scrum board side by side.

A key distinguishing factor is that Scrum measures sustainable levels of productivity in terms of the team's velocity, and controls for how many agile points a team will commit to during a sprint.

Kanban controls for sustainable work in progress and limits the number of stories the team will commit to working on at the same time.


Both Scrum and Kanban have adopted the practice of a daily stand-up meeting during which members of the team report on what they've done since the last stand-up, what they plan to do before the next one and whether they have any blockers preventing them from working to their fullest capacity. In both approaches, the developers are the only ones who are supposed to report during a stand-up, while product owners and managers pay attention and use the time immediately after stand-up to follow up on specific issues.

Scrum gives the team an entire sprint to decide how to self-manage the work before reflection while Kanban carefully monitors the workflow through the team every time a new story is started.

This has significant implications for the way that managers, product owners and developers work together.

With Kanban, the team can adjust the work in progress level dynamically to avoid idle or overworked developers, and that is something that can be tracked by management.

In Scrum, the team self-adjusts work in progress based on the number of stories they have committed to the sprint, with the goal of making every story meet their agreed definition of done.


The rhythm of Scrum is agreed to by the team based on the type of work being done, and usually falls into sprints of two to four weeks.

Every sprint, the team undergoes a set of rituals to demonstrate the value they have provided, learn from what worked well and what could have gone better. Then they commit to a new set of stories for the next sprint.

Because Scrum is patterned around time-based iterations, the rituals are baked into the process.

Kanban iterations are much more flexible.

In Kanban, the decision for when to pause the workflow for the sake of reflection and agreement can be triggered by date, by milestone, or by other metrics agreed to by the team before the work begins.

The risk for a Kanban team is that the irregularity of the process might encourage them to skip or give little attention to the reflection necessary to help the agile process iterate and improve.

Making Agile Work

It's important for your team to consider carefully which approach makes the most sense, given what you're trying to accomplish.

If you're developing products, you might find that Scrum is a more likely choice. If you're providing services, you might find Kanban suits you better.

Different teams in different circumstances call for different approaches.

Fortunately, at the core of agile is the expectation that your team will learn from what is working so you can make decisions about what to maintain and what to change as you adapt in an agile manner.

Once a team has worked effectively in an agile manner long enough to know its own rhythms, it is possible for a legitimate agile process to adapt to a wide variety of implementations.

But the self-awareness necessary to take advantage of the versatility of agile should not be considered a license to pick and choose aspects of agile from one approach or another, and try to create something new from the start.

I recommend that you give your preferred flavor of agile a try in its purest form for several cycles before you decide whether it is right for you.

Continue reading this article on SitePoint

You don’t have to choose between Scrum and Kanban - it is just a matter of choosing the right tools (Kanban Tool for example) to manage your work and prioritize tasks. The end result of such a combination is Scrumban. Scrumban contains the best rules and practices of both methods and fits me perfect.

Can the original poster fix the link in the first paragraph of this post? All the links in the post actually just link back to this page.

Thanks, Good catch, here, same as with the original article, the links have empty hrefs

Thanks guys. Links fixed!

Hi, thanks for the article. It gives a good introduction between Scrum and Kanban. It’s good that you emphasize that both Scrum and Kanban are possibilities to move to an agile way of working and to lead to improvements.

I certainly like your point that teams should be self-aware; and if they are new to agile – start with adopting an agile framework by the book (first stage of Shu-Ha-Ri).

There are differences and similarities between Scrum and Lean/Kanban. Both focus on delivering value to the customer. To reach this both make bottlenecks and impediments painfully visible in an organization and its processes, which should lead to actual improvements being made – otherwise you remain stuck; without delivering added value. There are some differences between Lean and Agile (Scrum) in the basic philosophy: e.g. regarding the strive for perfection and the way people are considered.

I would not stick to the prejudgement that Scrum or Kanban are optimized for a specific application. I am cautious to hear for example that Kanban is only for operations and maintenance tracks (if you’d ask David Anderson, he would certainly disagree). I am objective to all, and what suits the best is dependent on the organization’s context and situation.

It is true that Kanban is less prescriptive than Scrum – as a framework. Kanban it’s basically a WIP limited pull system to establish a continuous flow and to implement evolutionary incremental change to realize systemic improvements. With Kanban one measures flow to control and optimize for efficiency in flow from beginning to end. Kanban does not require you to change roles and responsibilities in the organization to form a team, and you start from the existing process. (On the other hand, I think Scrum is on a good spot on a scale of prescriptiveness when comparing to other (non-agile) project management methodologies)

The freedom you get in Kanban comes with more responsibilities: you have more options to organize yourself. For example: you can organize using iterations (establish a regular cadence as in Scrum); you should have a daily status team meeting align the work of the day (as in Scrum); you can establish regular review and retrospectives (as in Scrum). Otherwise around: in Scrum you can introduce WIP limits if you see too many items are consistently in progress and “not 100% done”. But remember: creating a visualization board or choosing a tool doesn’t make you agile.


This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.