Kanban and Scrum

Making the most of both

SDC2010 Gteborg
March 17, 2010

Henrik Kniberg
Agile/Lean coach
www.crisp.se
Board of
directors

henrik.kniberg@crisp.se
070 4925284

Purpose of this presentation

To clarify Kanban and Scrum by comparing them
...so you can figure out
how these may come to use
in your context.

Henrik Kniberg

Scrum in a
nutshell
Henrik Kniberg

Split your organization

Scrum in a nutshell
Split your product
Large group spending a long time building a huge thing
Small team spending a little time building a small thing
... but integrating regularly to see the whole

Optimize business value

Optimize process

$$$

Split time
January

April

Henrik Kniberg

Typical Scrumboard

Henrik Kniberg

the unofficial

The bottom line

Core Scrum

If you achieve these you can ignore the

rest of the checklist. Your process is f ine.

These are central to Scrum. Without these

you probably shouldnt call it Scrum.

Delivering working, tested

software every 4 weeks or less
Delivering what the
business needs most
Process is
continuously improving

Clearly def ined product owner

(PO)

Scrum Checklist

Retrospective happens af ter

every sprint
Results in concrete
improvement proposals
Some proposals actually
get implemented
Whole team + PO
participates
PO has a product backlog
(PBL)

Henrik Kniberg
Recommended but not always necessary
Most of these will usually be needed, but not always all of them. Experiment!
Team has all skills needed to
bring backlog items to Done
Team members not locked into
specific roles

Sprint tasks are estimated

Estimates f or ongoing tasks
are updated daily

PO is empowered to
prioritize

Top items are prioritized

by business value

Iterations that are doomed to

fail are terminated early

PO has knowledge to
prioritize

Top items are estimated

PO has direct contact with

team

Estimates written by the

team

PO has product vision that is in

sync with PBL

PO has direct contact with

stakeholders

Top items in PBL small

enough to fit in a sprint

PO speaks with one voice

(in case PO is a team)

PO understands purpose
of all backlog items

Team has a sprint backlog

Have sprint planning meetings

Highly visible

PO participates

Updated daily

PO brings up-to-date PBL

Owned exclusively by the

team

Whole team participates

Whole team participates

All items in sprint plan have

an estimate

Everyone on the team

participates in estimating

PO uses velocity f or
release planning

PO available when team is

estimating

Velocity only includes

items that are Done

Estimate relative size (story

points) rather than time
Whole team knows top 1-3
impediments
SM has strategy f or how to
f ix top impediment
SM focusing on removing
impediments

Problems & impediments

are surf aced

Escalated to management
when team cant solve

Whole team believes plan

is achievable
PO satisfied with
priorities

Team has a Scrum Master (SM)

SM sits with the team

Timeboxed iterations
Demo happens af ter every
sprint
Shows working, tested
software
Feedback received f rom
stakeholders & PO
Have Definition of Done (DoD)

Henrik Kniberg

DoD achievable within

each iteration
Team respects DoD

Iteration length 4 weeks or

less
Always end on time
Team not disrupted or
controlled by outsiders
Team usually delivers
what they committed to
Team members sit together
Max 9 people per team

Velocity is measured

PBL and product vision is highly

visible

Results in a sprint plan

Daily Scrum happens

PBL items are broken into

tasks within a sprint

Team has a sprint burndown

chart
Highly visible
Updated daily
Daily Scrum is every day, same
time & place
PO participates at least a
f ew times per week
Max 15 minutes
Each team member knows
what the others are doing

Scaling

Positive indicators

These are pretty f undamental to any

Scrum scaling ef f ort.

Leading indicators of a
good Scrum implementation.

You have a Chief Product

Owner (if many POs)

Having fun! High energy level.

Dependent teams do Scrum of

Scrums

Overtime work is rare and

happens voluntarily

Dependent teams integrate

within each sprint

Discussing, criticizing, and

experimenting with the process

PO = Product owner SM = Scrum Master PBL = Product Backlog DoD = Definition of Done
http://www.crisp.se/scrum/checklist | Version 2.1 (2009-08-17)

Kanban in a
nutshell
Henrik Kniberg

Which team needs

most improvement?
Team 1

Todo
orem ipsum dolor
sit amet, co nse
ctetur
orem ipsum dolor
sit amet, co nse
ctetur orem ipsum dolor
sit amet, co nse
ctetur

orem ipsum dolor

sit amet, co nse
ctetur
orem ipsum dolor
sit amet, co nse
ctetur

Managers who dont know how to

measure what they want
settle for
wanting what they can measure

Russel Ackoff

Team 2

Done

Doing
orem ipsum dolor
sit amet, co nse
ctetur
orem ipsum dolor
sit amet, co nse
ctetur
orem ipsum dolor
sit amet, co nse
ctetur

orem ipsum dolor

sit amet, co nse
ctetur
orem ipsum dolor
sit amet, co nse
ctetur

Avg lead time:

Henrik Kniberg

Todo

this week

Doing

Done

this week

orem ipsum dolor

sit amet, co nse
ctetur

orem ipsum dolor

sit amet, co nse
ctetur
orem ipsum dolor
sit amet, co nse
ctetur
orem ipsum dolor
sit amet, co nse
ctetur

orem ipsum dolor

sit amet, co nse
ctetur
orem ipsum dolor
sit amet, co nse
ctetur

orem ipsum dolor

sit amet, co nse
ctetur

orem ipsum dolor

sit amet, co nse
ctetur

20 days

orem ipsum dolor

sit amet, co nse
ctetur

Avg lead time:

orem ipsum dolor

sit amet, co nse
ctetur

3 days
8

Kanban @ Imperial Palace Gardens

Henrik Kniberg

Kanban

Visual Card

Signaling system
Visual
Limited in supply

Henrik Kniberg

10

Kanban in your wallet

Darn. Forgot to
limit.

Henrik Kniberg

11

Kanban @ Toyota
Buyer

Consume

Detach

Supplier

Receive

Ship

Allocate

Manufacture

The tool used to operate the

[Toyota Production] system is
kanban.

Henrik Kniberg

Taiichi Ohno
Father of the
Toyota Production System

12

Kanban in SW development
Visualize the workflow
Limit WIP (work in progress)
Measure & optimize flow
Explicit policies (definition of Done, WIP limits, etc)
Backlog
5

Dev
3

Pioneered by
David Anderson
in 2004

UAT Deploy Done

3
2
orem ipsum dolor
sit amet, co nse
ctetur

orem ipsum dolor

sit amet, co nse
ctetur

orem ipsum dolor

sit amet, co nse
ctetur

orem ipsum dolor

sit amet, co nse
ctetur

orem ipsum dolor

sit amet, co nse
ctetur

orem ipsum dolor

sit amet, co nse
ctetur
orem ipsum dolor
sit amet, co nse
ctetur

orem ipsum dolor

sit amet, co nse
ctetur

FLOW

Henrik Kniberg

Avg lead time:

12 days

13

Evolve your own unique board!

Henrik Kniberg

Some of these photos courtesy of

David Anderson, Mattias Skarin,
and various other people

14

Typical Scrum => Kanban evolution

Scrum step 1
Feature
team 1

Feature
team 2

Feature
team 2

Scrum

Scrum

Scrum

Scrum step 2
Feature
team 1
Scrum

Feature
team 2
Scrum

Feature
team 2
Scrum

Operations / support team

Scrum

Henrik Kniberg

Scrum + Kanban
Feature
team 1
Scrum

Feature
team 2
Scrum

Feature
team 2
Scrum

Operations / support team

Kanban

15

Compare for
understanding,
not judgement
Henrik Kniberg

16

Thinking tools

a.k.a. mindsets or philosophies

Tool
anything used as a means of
accomplishing a task or purpose.
- dictionary.com

Lean

Physical tools

Agile

Systems Thinking

Theory of Constraints

Toolkits

a.k.a. frameworks
RUP

Scrum

XP

Kanban

Process tools

a.k.a. organizational patterns

Product Owner role

Pair programming

Visualize the workflow

To do
5

Dev
3

Test

Release

Done!
A

K
FLOW

Henrik Kniberg

17

Any tool can be misused

The old tool

was better!

Never blame
the tool!

18

Henrik Kniberg

18

Compare for understanding, not judgement

More prescriptive

More adaptive

RUP
(120+)

Architecture Reviewer
Business Designer
Business-Model Reviewer
Business-Process Analyst
Capsule Designer
Change Control Manager
Code Reviewer
Configuration Manager
Course Developer
Database Designer
Deployment Manager
Design Reviewer
Designer
Graphic Artist
Implementer
Integrator
Process Engineer
Project Manager
Project Reviewer
Requirements Reviewer
Requirements Specifier
Software Architect
Stakeholder
System Administrator
System Analyst
Technical Writer
Test Analyst
Test Designer
Test Manager
Tester
Tool Specialist
User-Interface Designer
Architectural analysis
Assess Viability of architectural
proof-of-concept
Capsule design
Class design
Construct architectural proof-ofconcept
Database design
Describe distribution
Describe the run-time architecture
Design test packages and classes
Develop design guidelines
Develop programming guidelines
Identify design elements
Identify design mechanisms
Incorporate design elements
Prioritize use cases
Review the architecture
Review the design
Structure the implementation
model
Subsystem design
Use-case analysis
Use-case design
Analysis model
Architectural proof-of-concept
Bill of materials
Business architecture document
Business case
Business glossary
Business modeling guidelines
Business object model
Business rules
Business use case

Business use case realization

Business use-case model
Business vision
Change request
Configuration audit findings
Configuration management plan
Data model
Deployment model
Deployment plan
Design guidelines
Design model
Development case
Development-organization
assessment
End-user support mateirla
Glossary
Implementation model
Installation artifacts
Integration build plan
Issues list
Iteration assessment
Iteration plan
Manual styleguide
Programming guidelines
Quality assurance plan
Reference architecture
Release notes
Requirements attributes
Requirements
management plan
Review record
Risk list
Risk management plan
Software architecture
document
Software development
plan
Software requirements
specification
Stakeholder requests
Status assessment
Supplementary business
specification
Supplementary specification
Target organization assessment
Test automation architecture
Test cases
Test environment configuration
Test evaluation summary
Test guidelines
Test ideas list
Test interface specification
Test plan
Test suite
Tool guidelines
Training materials
Use case model
Use case package
Use-case modeling guidelines
Use-case realization
Use-case storyboard
User-interface guidelines
User-interface prototype
Vision
Work order
Workload analysis model

Henrik Kniberg

Scrum
(9)

XP
(13)

Whole team
Coding standard
TDD
Collective ownership
Customer tests
Pair programming
Refactoring
Planning game
Continuous integration
Simple design
Sustainable pace
Metaphor
Small releases

Scrum Master
Product Owner
Team
Sprint planning meeting
Daily Scrum
Sprint review
Product backlogt
Sprint backlog
BUrndown chart

Kanban
(3)

Do Whatever
(0)

Visualize the workflow

Limit WIP
Measure and optimize lead time

Do not develop an attachment

to any one weapon
or any one school of fighting
Miyamoto Musashi
17th century samurai

19

Lean & Agile process toolkits

Values & Principles

Lean, Agile, Theory of Constraints, Systems Thinking, etc

Kanban

XP

Other lean tools

(Value Stream Mapping,
Root Cause Analysis, etc)

Scrum

Henrik Kniberg

20

One day in
Kanban land
Henrik Kniberg

21

One day in Kanban land

http://blog.crisp.se/henrikkniberg/tags/kanban/

Henrik Kniberg

22

Scenario 1 one piece flow

Next

Backlog
A

Dev

In production :o)

Ongoing

Done

G
C
F
H
J
M

D
I

L
K

Henrik Kniberg

23

Scenario 1 one piece flow

Next

Backlog

Ongoing

Done

C
F
H
M

In production :o)

Dev

D
I

L
K

Henrik Kniberg

24

Scenario 1 one piece flow

Backlog

Ongoing

Done

C
F
H
M

In production :o)

Dev

Next

D
I

L
K

Henrik Kniberg

25

Scenario 1 one piece flow

Dev

Next

Backlog

Ongoing

In production :o)

Done
A

F
H
J
M

I
L
K

Henrik Kniberg

26

Scenario 1 one piece flow.

Dev

Next

Backlog

In production :o)

Ongoing

Done

G
D

A
B

F
H
J
M

I
L
K

Henrik Kniberg

27

Scenario 2 Deployment problem

Next

Backlog
PO
A

Dev

In production :o)

Ongoing

Done

G
C
F
H
J
M

D
I

L
K

Henrik Kniberg

28

Scenario 2 Deployment problem

Next

Backlog

PO

Ongoing

Done

C
F
H
M

In production :o)

Dev

D
I

L
K

Henrik Kniberg

29

Scenario 2 Deployment problem

Dev

Next

Backlog
PO
G

In production :o)

Ongoing

Done

F
H
J
M

I
L
K

Henrik Kniberg

30

Scenario 2 Deployment problem

Dev

Next

Backlog
PO

Ongoing
C

G
D

In production :o)

Done
A

F
H
J
M

I
L
K

Henrik Kniberg

31

Scenario 2 Deployment problem

Backlog
PO

G
D
F
H
J
M

Dev

Next

In production :o)

Ongoing

Done

!?

I
L
K

Henrik Kniberg

32

Scenario 2 Deployment problem

Backlog
PO

F
H
M

In production :o)

Ongoing

!?

Dev

Nexet

Done
A

I
L
K

Henrik Kniberg

33

Scenario 2 Deployment problem

Next

Backlog
PO

F
H
M

In production :o)

Ongoing

Done
A

Dev

I
L
K

Henrik Kniberg

34

Scenario 2 Deployment problem

Next

Backlog
PO

Dev

In production :o)

Ongoing

Done
A

G
D
F
H
J
M

B
C

I
L
K

Henrik Kniberg

35

Scenario 2 Deployment problem

Backlog
PO

In production :o)

Ongoing

Done

A
B

Dev

Next

C
I

L
K

Henrik Kniberg

36

Kanban
compared to
Scrum
Henrik Kniberg

37

Scrum prescribes roles,

Kanban doesnt

Henrik Kniberg

Product
owner

Team

Scrum
Master

PO
SM

38

Both are empirical

Capacity

Lead time

Quality

Predictability

(aka velocity)

(aka cycle time)

(defect rate, etc)

(SLA fulfillment, etc)

Kanban is more configurable

Many small teams

Low WIP limits
Few workflow states

Few large teams

Many workflow states

Long iterations

Little planning

Lots of planning

Henrik Kniberg

Oh no, more decisions!

High WIP limits

Short iterations

.... etc ...

Great! More options!

.... etc ...

39

Kanban www.crisp.se/kanban/example
kick-start example

Henrik Kniberg

Next
2

Analysis
3

Development
3

Ongoing

Ongoing Done
2009-09-01

orem ipsum dolor sit

amet, co adi pis cing
elit nisl

2009-08-20
orem olor sit amet, co
nse ctetur adi pis cing
elit nisl

orem ipsum dolor

sit amet, co nse
ctetur

2009-08-29
orem ipsum dolor sit
amet, nse ctetur adi
pis cing elit nisl

orem ipsum dolor

sit amet, co nse

2009-08-25
orem ipsum dolor sit
ctetur adi pis cing elit
nisl

orem ipsum dolor

orem ipsum dolorsit amet, co nse
sit amet, co nse ctetur
ctetur

Definition of Done:
Goal is clear
First tasks defined
Story split (if necessary)

Feature / story
Date when
added to board

2009-09-30

(description)

Done

orem ipsum dolor

sit amet, co nse
ctetur

orem ipsum dolor

sit amet, co nse
ctetur

2009-09-02

2009-08-20

Ongoing
orem ipsum dolor sit
amet, adi pis cing elit
nisl

orem ipsum dolor

sit amet, co nse
ctetur

xxxx kjd
orem ipsumdjdolor
d xxx
sit amet, co nse
ctetur

orem ipsum dolor

sit amet, co nse
ctetur

Acceptance Prod
2
2009-08-27

2009-09-08

2009-08-30

orem ipsum
dolor sit
orem ipsum dolor
amet,
co nse
amet, co sit
nse
ctetur
ctetur
adi pis cing
elit nisl

Done

version 1.2
2009-11-16

Definition of Done:
Code clean & checked in on trunk
Integrated & regression tested
Running on UAT environment

Hard deadline
(if applicable)

= priority
= panic

Who is analyzing /
testing right now

Definition of Done:
Customer accepted
Ready for production

Task / defect
(description)

=task

(description)

Why

(description)

(description)

(description)

=defect

What to pull first

Panicfeatures

Priority features
Hard deadline features

= completed
= blocked
= who is doing
this right now

(should be swarmed and kept

moving. Interrupt other work
and break WIP limits as
necessary)
(only if deadline is at risk)

Oldest features

Scrum prescribes timeboxed iterations

Scrum team
Kanban team 1

week 1

week 3

week 4

Sprint 1

Plan & commit

Kanban team 2

week 2

week 5

week 6

week 7

week 8

Sprint 2

Review
(release?)

Retrospective

week 1

week 2

week 3

week 4

week 5

week 6

week 7

week 8

week 1

week 2

week 3

week 4

week 5

week 6

week 7

week 8

Retrospectives (4w)
Planning cadence (2w)
Release cadence (1w)

Kanban team 3
Retrospectives (4w)
Planning (on demand)
Release (on demand)

Henrik Kniberg

41

Scrum backlog items must fit in a sprint

Scrum

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Kanban
Long running task
WIP limit = 3

Henrik Kniberg

Long running task

42

Both limit WIP, but in different ways

Kanban board

Scrum board
To do

Ongoing Done :o)

To do

Ongoing Done :o)

A
B

B
C

D
FLOW

WIP limited per unit of time

(iteration)

Henrik Kniberg

FLOW

WIP limited per workflow state

43

Id like to have E!

Scrum discourages change

in mid-iteration

PO
Wait until a To Do slot
becomes available!
Or swap out C or D!

Wait until next sprint!

Kanban

Scrum
To do

Ongoing Done :o)

To do
2

Ongoing Done :o)

2

FLOW

FLOW

Policies

Henrik Kniberg

44

Scrum board is reset between each

iteration
Scrum
First day of sprint

Mid-sprint

Last day of sprint

Kanban
Any day

Henrik Kniberg

45

Scrum prescribes cross-functional teams

Scrum team
Kanban team 1

Cross-functional
team

Henrik Kniberg

Kanban team 2

Specialist Cross-functional
team

Specialist
team

46

Scrum prescribes cross-functional teams

Kanban supports both specialists & generalists
Scrum team
Kanban team 1
Kanban team 2
Backlog

orem ipsum dolor

sit amet, co nse
ctetur

Design

Fold

orem ipsum dolor

sit amet, co nse
ctetur

orem ipsum dolor

sit amet, co nse
ctetur

Tape

Trim

Draw

orem ipsum dolor

sit amet, co nse
ctetur
orem ipsum dolor
sit amet, co nse
ctetur

orem ipsum dolor

sit amet, co nse
ctetur

orem ipsum dolor

sit amet, co nse
ctetur
orem ipsum dolor
sit amet, co nse
ctetur

Cross-functional
team

Henrik Kniberg

47

Scrum prescribes estimation and velocity

V= 8

V= 7

2
2

Sprint 1

Henrik Kniberg

2
3

1
Sprint 2

V= 9

1
3

1
2

2
2

Likely velocity: 8 per sprint

(sustainable pace?)

Sprint 3

48

Estimation

Typical
Kanban

Tasks

Features

1. Dont estimate features. Just count them. 1. Skip tasks

2. Dont estimate tasks. Just count them.

2. Estimate features in t-shirt size

S
Hours?

M
Days?

Weeks?

3. Estimate features in story points

1sp 2sp

5sp

4. Estimate features in ideal man-days

1d

3d

Henrik Kniberg

6d

3. Estimate tasks in days

0.5d

2d

1d

Typical
Scrum

4. Estimate tasks in hours

4h

8h

12h

49

Both allow working on multiple products

simultaneously
Kanban example 1

Scrum example 1
Green Product

Green team

Scrum example 2
All products

Cross-product team

Henrik Kniberg

Color-coded tasks
Yellow Product

Yellow team

Scrum example 3
All products

Cross-product team

Kanban example 2
Color-coded swimlanes

50

Minor difference:

Scrum prescribes daily meetings

... but many Kanban teams do that anyway.

Henrik Kniberg

51

Minor difference:

Scrum prescribes a prioritized product backlog

Scrum:
Product backlog must
exist
Changes to product
backlog take effect next
sprint (not current sprint)
Product backlog must be
sorted by business value

Kanban:
Product backlog is optional
Changes to product backlog
take effect as soon as
capacity becomes available
Any prioritization scheme can
be used. For example:
Take any item
Always take the top item
Always take the oldest item
20% on maintainance items,
80% on new features
Split capacity evenly between
product A and product B
Always take red items first

Policies
Henrik Kniberg

52

Minor difference:

In Scrum, burndown charts are prescribed

No specific types of diagrams
prescribed in Kanban. Teams
use whatever they need.

Cumulative Flow

Henrik Kniberg

53

Final points

Henrik Kniberg

54

Kanban & Scrum

www.crisp.se/henrik.kniberg/kanban-vs-scrum.pdf

Comparison summary
Similarities
Both are Lean and Agile
Both based on pull scheduling
Both limit WIP
Both use transparency to drive process
improvement
Both focus on delivering releasable
software early and often
Both are based on self-organizing teams
Both require breaking the work into
pieces
In both cases the release plan is
continuously optimized based on
empirical data (velocity / lead time)

Henrik Kniberg

Differences
Scrum

Kanban

Timeboxed iterations prescribed.

Timeboxed iterations optional.

Team commits to a specific amount

of work for this iteration.
Uses Velocity as default metric for
planning and process improvement.
Cross-functional teams
prescribed.
Items broken down so they can be
completed within 1 sprint.
Burndown chart prescribed

Commitment optional.

WIP limited indirectly (per sprint)

Estimation prescribed
Cannot add items to ongoing
iteration.
A sprint backlog is owned by one
specific team
Prescribes 3 roles (PO/SM/Team)
A Scrum board is reset between
each sprint
Prescribes a prioritized product
backlog

Uses Lead time as default metric for

planning and process improvement.
Cross-functional teams optional.
Specialist teams allowed.
No particular item size is prescribed.
No particular type of diagram is
prescribed
WIP limited directly (per workflow
state)
Estimation optional
Can add new items whenever
capacity is available
A kanban board may be shared
by multiple teams or individuals
Doesnt prescribe any roles
A kanban board is persistent
Prioritization is optional.55

Free download
http://www.infoq.com/minibooks/kanban-scrum-minibook

Henrik Kniberg

56

Dont be dogmatic
Go away! Dont talk to us!
Were in a Sprint.
Come back
in 3 weeks.

Henrik Kniberg

Though Shalt
Limit WIP

57

Essential skills needed

regardless of process
Splitting the system into
useful pieces

Software
craftsmanship

Retrospectives

As a buyer
I want to save my shopping cart
so that I can continue shopping
later

Henrik Kniberg

58

Take-away points
1. Know your goal
Hint: Agile/Lean/Kanban/Scrum isnt it.
2. Never blame the tool
Tools dont fail or succeed. People do.
There is no such thing as a good or bad tool. Only good
or bad decisions about when, where, how, and why to
use which tool.
3. Dont limit yourself to one tool
Kanban coaching workshop
with David Anderson
Learn as many as possible.
Compare for understanding,
March 29-31, Stockholm
not judgement.
Limited to 8 participants
www.crisp.se/utbildning
4. Experiment & enjoy the ride
Dont worry about getting it right from start.
The only real failure is the failure to learn from failure.
Henrik Kniberg

59

Expand your toolkit!

www.crisp.se/utbildning

Kanban coaching workshop

with David Anderson
March 29-31, Stockholm
Limited to 8 participants
www.crisp.se/utbildning

Henrik Kniberg

60