Differences between Scrum & Kanban

Sim Pi m
Wha K n a
Kanban is also a tool used to organize work for the sake of efficiency. Like Scrum, Kanban encourages

work to be broken down into manageable chunks and uses a Kanban Board (very similar to the Scrum

Board) to visualize that work as it progresses through the workflow. Where Scrum limits the amount of

time allowed to accomplish a particular amount of work (by means of sprints), Kanban limits the amount of

work allowed in any one condition (only so many tasks can be ongoing, only so many can be on the to-do

list.)

Sim Pi m
How S ru dK an s e?
Both Scrum and Kanban allow for large and complex tasks to be broken down and

completed efficiently.

Both place a high value on continual improvement, optimization of the work and

the process. And both share the very similar focus on a highly visible work flow

that keeps all team members in the loop on WIP and what’s to come.

Sim Pi m
How S ru dK an f e t?
As alluded to above, there are a number of differences in both the philosophy

behind and the practical application of Scrum and Kanban.

While the individual differences are many, they can be grouped into the following

three buckets:

Sim Pi m
Sc e l , it i n, an d e
Scrum processes place heavy emphasis on schedule. The scrum team is provided with a prioritized list of
story points that need to be completed to deliver a shippable product. The team must decide how many of
the points they feel can be completed within one sprint. Anything outside the scope they commit to must
wait for the next sprint. Optimally, an efficient scrum team will quickly learn their capabilities over the
course of several sprints and their estimates will improve and be optimized as time goes on.

Then, every two weeks (or however long their sprint is) the team produces a shippable product, carries
out a retrospective to discuss optimizing the process, and moves into the next sprint. This iterative
process is designed to allow for accurate estimations of work flow and effective management of multiple
projects. On a Kanban team, there are no required time boxes or iterations. While the Kanban method is
iterative in nature, the continual improvement is expected to occur in an evolutionary fashion as work is
continually completed. The limitations placed on various conditions in the work flow will be regulated early
in a team’s (or organization’s) use of Kanban until an optimal set of limits is arrived at to keep the flow
steady and efficient.

Sim Pi m
Rol d ep bi es
On scrum teams, there are at least three roles that must be assigned in order to effectively process the
work: the Product Owner, Scrum Master, and Team Members. Each role has its own set of
responsibilities, and they must work together to achieve an orderly and efficient balance. The scrum team
itself also must be cross-functional, which is to say that one team must have all the resources necessary
to complete the entire sprint’s work. Under Kanban, no set roles are prescribed. Practically speaking, it
makes sense for someone to serve as a project manager or supervisor, especially for larger more
complex Kanban projects, but the roles should theoretically evolve with the needs of the project and the
organization. A Kanban team is not required to be cross-functional since the Kanban work flow is intended
to be used by any and all teams involved in the project. Therefore, a team of specialists and a separate
team of generalists may be working on different aspects of the same Kanban project from the same
board, and that’s ok.
Sim Pi m
The di l
While very similar, the Scrum Board and Kanban Board are different animals.

On a Scrum board, the columns are labeled to reflect periods in the work flow beginning with the sprint backlog and ending with whatever

fulfills the team’s definition of done. All the stories added to the board at the beginning of each sprint should be found in the final column at

the end of that sprint or the sprint was unsuccessful. After the sprint retrospective, the board is cleared and prepped for the next sprint. On a

Kanban board, the columns are likewise labeled to show work flow states, but with one vital difference: they also publish the maximum

number of stories allowed in each column at any one time. This enforces the team-determined limitations Kanban prescribes for each

condition. Since each column has a limited number of allowed stories and there are no required time boxes (such as sprint length), there is no

reason to reset the Kanban board as work progresses. It will continue to flow for as long as the project continues, with new stories being

added as the need arises, and completed stories being re-evaluated should it be necessary.

Sim Pi m
Wh u K n a n ad Sr
Scrum is arguably the most popular agile methodology in use today, and it does have some similarities to Kanban. There are several key
differences between Scrum and Kanban as well. When determining which of the two is better for a particular team or circumstance, a number
of factors need to be considered.

• Flexibility: If the work flow would benefit from added flexibility and/or the type of work being handled is difficult to accurately estimate before
beginning, Kanban’s more adaptable framework may work better.

• Scheduling: If scheduling is tightly controlled and it’s vital that work be finished by a given time every time to meet business goals, Scrum’s
more structured sprint schedule may be the best choice.

• Team size/collaboration: If the bulk of work on any given project is handled by one team, and especially if that team is co-located, Scrum
works well to allow everyone to visualize the current sprint’s work and collaborate appropriately. Kanban does the same, but in a more flexible
way that can work well for multiple teams and even teams that are not co-located (assuming the technology used to collaborate is up to the
challenge).

Sim Pi m
Wh U e K n in do S r
There are more factors to consider as well, but the real key is to understand that Scrum and Kanban each

have their own pros and cons. There really is no absolutely right answer for any given team or

organization. Often the best option is a hybrid combination of the two that maximizes the best aspects of

each. This is a matter of experimentation and optimization that each team must handle on its own.

To help illustrate these differences and how they can be analyzed, let’s take a quick look at the classic

agile use case: a software development firm. Automatically, Scrum is the obvious choice for an agile

framework to be used in software development. But, below are reasons why three departments in this

organization may be better off going with a Kanban-style solution or creating a hybrid.
Sim Pi m