Running head: SCRUM AND KANBAN: A COMPARATIVE STUDY 1

Scrum and Kanban: A Comparative Study

Jason Shumway

University of Maryland University College

ISAS 630

Dr. Ernest Eugster

17/06/2020
SCRUM AND KANBAN: A COMPARATIVE STUDY 2

Abstract

The purpose of this paper is to compare the Scrum and Kanban methodologies based on a review

of related papers and articles. Roles, cadence, workflows, and artifacts will be examined.

Keywords: Scrum, Kanban, Agile, Lean, Sprint, Backlog, Work-In-Progress

SCRUM AND KANBAN: A COMPARATIVE STUDY 3

Scrum and Kanban: A Comparative Study

As more organizations look to improve their internal processes some may look to move

away from more traditional methods and look to adopt more nimble methods that provide

flexibility when dealing with change. Two of these alternative methodologies or process tools are

Scrum and Kanban. Scrum and Kanban’s true origins can both be traced back to Japanese

manufacturing. Scrum was created based on Takeuchi and Nonaka’s ‘The New New Product

Development Game’ originally published in 1986 in the Harvard Business Review (Sutherland,

2007). Their work gives examples of companies using alternative approaches to product

development and according to one of Scrum’s creators Jeff Sutherland (2007) “The best example

is Honda and their style of product development” (para.1). Takeuchi and Nonaka describe a

rugby like approach where a team is working together from beginning to end (Takeuchi &

Nonaka, 1986). Scrum is a term used in rugby to describe the restart of play where all the players

are packed together tightly. It visually looks like a huddle in football. Based on this influence

Sutherland and Ken Schwaber formulated Scrum for software development in the early nineties

(Sutherland, 2007). Scrum was designed to deal with the misinterpretation of specifications,

users not knowing what they want until it is visualized, systems that can never be fully tested or

specified, and rapid software evolution (Sutherland, 2007).

Kanban is derived from two Japanese words Kan and Ban, Kan means sign and Ban

means board (Kanbantool, 2020). The Kanban method was created in the early 1940s by Taiichi

Ohno for Toyota in response to improve production and reduce bottlenecks. This was

accomplished by visualizing workflows by monitoring via cards on a board. A very simple but

effective solution that would famously become the Toyota Production System (Kanbantool,

2020). In the early 2000s, Kanban starts being applied to software development and publications
SCRUM AND KANBAN: A COMPARATIVE STUDY 4

such as Mary and Tom Poppendieck’s book Lean Software Development: Agile Toolkit helps

spread the word (Kanbantool, 2020).

Both methodologies fit nicely for those who follow or agree with the Agile Manifesto and

both are based on Japanese manufacturing. To formulate a better understanding of each method,

the roles, cadences, workflows, and work artifacts will be covered in more detail.

Roles

When reviewing the literature related to Scrum and Kanban it becomes very apparent that

Scrum is a much more prescriptive method compared to Kanban. This is highlighted by the fact

that Scrum requires three roles while Kanban does not formally require any (Kinberg & Skarin,

2010). However, in practice, there will be roles in Kanban as some people need to do the work

and some people need to decide what work is needed.

The roles required in Scrum are a Product Owner (PO), Scrum Master (SM), and the

development team. These three roles form what is commonly known as the Scrum team (Lei,

Ganjeizadeh, Jayachandran, & Pinar, 2017). The PO is sometimes known as the Voice of the

Customer (VOC) as they are mainly responsible for the requirements and their prioritization

(Lerche-Jensen, 2019). They often are the bridge between the customers/users and the Scrum

team. The SM is primarily a facilitator of scrum events and has the main responsibility of

keeping the team on track by identifying and removing impediments to the team’s progress

(Lerche-Jensen, 2019). The development team is responsible for accomplishing the tasks that

need to be done and are responsible for producing a valuable product (Lerche-Jensen, 2019). It

should be noted that Scrum teams are self-forming, cross-functional, and usually are co-located.

Although certain roles are not explicit with the Kanban method most practitioners will

have a role like the PO in Scrum where there is an individual responsible for requirements and
SCRUM AND KANBAN: A COMPARATIVE STUDY 5

working with the clients and users. This role may be referred to as a Service Request Manager

(SRM) or a PO just like Scrum (Novkov, A. 2019). Teams are also more than likely doing the

work in Kanban as well. Since there is no formal rule set for teams in Kanban they do not have

to be cross-functional or self-forming.

Cadence

Cadence is the rhythm that a team starts to develop once work has been initiated. As was

the case with roles Scrum once more provides a formal structure to produce a cadence while

Kanban does not. Scrum uses timeboxed iterations known as sprints to create cadence. These

periods typically last 4 to 6 weeks. At the beginning of a sprint, the team will plan out what tasks

out of the product backlog will be completed. During the sprint, the team will focus on

accomplishing those tasks and in the end, the team will produce working product or code and

reflect on what can be improved upon for the next sprint (Kniberg & Skarin, 2010). Daily the

team has a quick stand up meeting in which they address what they have done, what they are

going to do, and any issues they may be facing. These events fit nicely into the 4-week sprint and

allow teams to adjust quickly.

Although Kanban does not impose timeboxed iterations, most will adopt a cadence that

works well with their workflow. Many will choose to conduct daily reviews and conduct

planning sessions, but Kanban offers flexibility to when these events should occur. For those

looking for some guidance regarding cadence and Kanban can refer to Anderson’s seven Kanban

cadences as shown in table 1.

Table 1. Suggested Kanban Cadence.

Event Desc Frequency
Replenishment Meeting Decide what work to do next Weekly
Daily Kanban Track and observe flow Daily
Delivery Planning Plan downstream delivery Based on Delivery Schedule
Strategy Review Go over business goals Quarterly
SCRUM AND KANBAN: A COMPARATIVE STUDY 6

Service Delivery Review Review if expectations are 2x Month

being met
Operations review Review demand and Monthly

capability
Risk Review Review risks Monthly
(Anderson, 2015).

Workflow

Workflows are unique to organizations but both Scrum and Kanban emphasize a visual

process where the work is very transparent. A simple model of to-do, in-progress, and done can

be applied to most. In Scrum, the to-do would equate to the product and sprint backlogs, which

should be visible to the team. The in-progress stage reflects items that are being worked on and

the done stage displays completed items. Scrum indirectly limits the work through the sprint

planning process where the team agrees to what items from the product backlog will form the

sprint backlog. In Scrum, the tasks to be done are given an estimated value usually based on

complexity or business value and these values sometimes are referred to as story points. These

points are used to measure velocity. For example, a sprint backlog could consist of 5 items with

an estimate point value of 22 and during the sprint, only 20 points were finished. This type of

measurement allows the Scrum team to refine their estimates and figure ways to increase

velocity. These estimates can also be used during the sprint to produce a burndown chart where

the current value obtained is compared to the total value in the sprint.

One of the keys to Kanban is the visualization of workflow, the columns on the board

will reflect the workflow states and the cards represent the work tasks. Kanban directly limits the

scope by enforcing work in progress limits on each workflow state (Ordysinski, 2013). Unlike

Scrum, the tasks do not have to be broken down and estimated. However, Kanban measures lead

time which is the time it takes an item to go through all the stages of the board (Ordysinski,
SCRUM AND KANBAN: A COMPARATIVE STUDY 7

2013). If items are too large the lead times more than likely will be high. In Kanban, the

workflow can be optimized by recognizing bottlenecks quickly and using the lead times to

formulate strategies to improve the flow.

Artifacts

Both Kanban and Scrum strive for simplicity and this is evident in the fact there are few

artifacts between the two. The artifacts within the Scrum methodology are the product backlog,

sprint backlog, and the increment (Schwaber & Sutherland, 2018). The product backlog is the

prioritized list of all known requirements that need to be produced. The PO role manages the

prioritization and gathering of requirements in the product backlog. The sprint backlog is the

agreed-upon product backlog items that the team will be working to complete during the sprint.

The increment is the output of the sprint backlog and should be a potentially shippable product or

releasable code (Schwaber & Sutherland, 2018). The artifacts of Kanban are directly derived by

the name. The board and the cards are the only artifacts associated with Kanban. The cards

represent the tasks to be done and the board represents the different states the work items must

travel through to be completed.

Conclusion

Both Scrum and Kanban can be used as tools to help improve productivity within an

organization. They both are intended to visualize workflow and limit work in progress. Scrum

limits the work by time with the use of sprints while Kanban limits the work by putting limits on

each stage of the workflow. Practitioners of Scrum fine-tune the process by measuring velocity

while Kanban does this by measuring lead time. Practitioners of both will adhere to an inspect

and adapt mindset. Organizations that value a more structured and prescriptive approach will
SCRUM AND KANBAN: A COMPARATIVE STUDY 8

probably be more inclined to use Scrum while organizations looking for a more adaptive and less

rigid method may find Kanban better suited to their needs.

References

Anderson, D. (2015, November 22). Kanban cadences and information flow. Retrieved from

https://www.slideshare.net/agilemanager/kanban-cadences-information-flow

Kanban tool. (2020). A history of Kanban. Retrieved from https://kanbantool.com/kanban-

guide/kanban-history

Kniberg, H. & Skarin, M. (2010). Kanban and Scrum making the best of both. [Online Edition].

Retrieved from: http://www.infoq.com/minibooks/kanbanscrum-minibook

SCRUM AND KANBAN: A COMPARATIVE STUDY 9

Lei, H., Ganjeizadeh, F., Jayachandran, P. K., & Ozcan, P. (2017). A statistical analysis of the

effects of Scrum and Kanban on software development projects. Robotics and Computer

Integrated Manufacturing, 43, 59–67. https://doi.org/10.1016/j.rcim.2015.12.001

Lerche-Jensen. S. (2019, May 24). International Scrum Master Foundation. Retrieved from

https://www.scrum.as/academy.php?show=0&chapter=1&name=What%20is%20Scrum

Novkov, A. (2018, August 21). The Kanban roles you’ve probably never heard of. Retrieved

from https://kanbanize.com/blog/kanban-roles/

Ordysinski, T. (2013). Kanban Based Information Management in Organization. Studia i

Materialy Polskiego Stowarzyszenia Zarzadzania Wiedza / Studies & Proceedings Polish

Association for Knowledge Management, 63, 76–85. Retrieved from http://ezproxy.

umgc.edu/login?url=https://search.ebscohost.com/login.aspx?direct=true&db=

asn&AN=93981817&site=eds-live&scope=site

Schwaber, K. & Sutherland, J. (2018). The Scrum guide. Retrieved from https://www.scrum

guides.org/scrum-guide.html

Sutherland, J. (2007, July 5). Origins of Scrum. Retrieved from https://www.scruminc.com

/origins-of-scrum/