2. 2 | 2
Similarities between Scrum and Kanban
Both are empirical models that embrace principles of lean and agile
development.
Both encourage:
1. Early and frequent delivery
2. Self-organized teams
3. Continuous improvement
4. High quality requirements /
acceptance criteria
5. Prioritizing of requirements
based on business value
3. 3 | 3
Differences between Scrum and Kanban
Scrum is much more prescriptive in nature, requiring certain components:
• Roles: The scrum master, the product owner, and the development
team
• Artifacts: Product backlog, sprint backlog, and product increment
• Time-boxed events: The sprint, which includes sprint planning, daily
standups, sprint reviews, and retrospectives
Kanban, on the other hand, is not prescriptive at all. It has only three rules:
• Visualize workflow
• Limit work in process (WIP)
• Measure and improve flow
4. | 4
1. Visualize (the work, workflow, and risks to
flow/value delivery)
2. Limit WIP (Work in Process)
3. Manage Flow
4. Make Process Explicit
5. Implement Feedback Loops
6. Improve Collaboratively, Evolve Experimentally
(using models and the scientific method)
The Kanban Core
Practices
5. 5 | 5
Visualize (the work, workflow, and risks to
flow/value delivery)
Visual ways for teams to keep their plan up-to-date and
transparent, to see opportunities to collaborate in order to
complete the Sprint Goal, and to identify forecasted items
that may not be completed by the end of the Sprint
6. 6 | 6
Limit WIP (Work in Process)
Kanban boards specify WIP limits in
different stages of work that the
development team performs.
In Scrum, the Sprint itself is a WIP Limit.
A Sprint limits the number of USs that a
Development Team forecasts it can
complete during a fixed period. Limiting
WIP is an effective way to drive deep
collaboration at the team level, but WIP
limits should be at a optimum level that
they push the team beyond what
they’re comfortable with and used to.
7. 7 | 7
Manage Flow
In Kanban, cycle time is a measure of the amount of time that has passed as an
item on the Kanban board moves between two stages in a value stream. In scrum,
the team can look at the cycle times of USs for information on where there is room
for improvement.
Teams monitor aging/staleness on an
ongoing basis (e.g. during the Daily
Scrum) to identify stalled/struggling USs
and find ways to help them along.
Here, the team’s focus is on the healthy
flow of work. The Scrum Team may also
identify opportunities to decrease the
amount of time it takes to get work to
production.
8. 8 | 8
Make Process Explicit
Kanban encourages Scrum Teams to bring additional transparency to their
process, not just their work. Healthy discussions about questions such as, “why
do we do things this way?” or “how will changing this policy affect our
flow/results?” will come with implementation of explicit policies such as the WIP
limit for each lane or each person, visualizing and dealing with blockers, and how
to prioritize work in limiting situation.
9. 9 | 9
Implement Feedback Loops
To take the classic Sprint
Retrospective one step
further, consider running a
Sprint Retrospective in a
quantitative data-driven
way. By using reports such
as cycle time control charts
and cumulative flow
diagrams, Scrum Teams can
gain deeper insights into
the flow of work, thus
driving improvement
experiments with better
results.
10. 10 | 10
Improve Collaboratively, Evolve
Experimentally (using models and the
scientific method)
The Kanban method suggests that a scientific approach is used to implement
continuous, incremental and evolutionary changes. There are various models
that you can use, including:
• The Theory of Constraints (the study of bottlenecks)
• The System of Profound Knowledge (a study of variation and how it affects
processes)
• Lean Economic Model (based on the concepts of “waste” (or muda, muri and
mura))
As part of the Sprint Retrospective, Scrum Teams can consider adding the use of
models and the scientific method to guide their evolution empirically.
Retrospectives are the place to design experiments based on ideas of how
something might improve the team’s capabilities
13. | 13
10 Points Question
State a practical example of how you would use Kanban
principles to effectively apply to one of the project you are
managing.
Scrum leaves the decision to the team – how much to work on the same time, while Kanban focuses on limiting the number of items the team has in progress. Scrum does not limit the work in progress, but if you start too many stories – you may not produce useful deliverables at the end of the Sprint. A key difference factor is that Scrum measures the levels of teams’ productivity in terms of the team’s speed, and controls – how many agile points a team will score during a sprint. Kanban controls for continuous work in progress and limits the number of stories the team will accept to working on at the same time.
Scrum leaves the decision to the team – how much to work on the same time, while Kanban focuses on limiting the number of items the team has in progress. Scrum does not limit the work in progress, but if you start too many stories – you may not produce useful deliverables at the end of the Sprint. A key difference factor is that Scrum measures the levels of teams’ productivity in terms of the team’s speed, and controls – how many agile points a team will score during a sprint. Kanban controls for continuous work in progress and limits the number of stories the team will accept to working on at the same time.
Sees the flow of Product Backlog items from idea identification, through refinement, analysis, design, coding, testing, and deployment; all the way to “Done.” This is what Kanban teams call the value stream.
Typically, Kanban boards specify WIP limits in different stages of work that the development team performs (e.g. design, coding, testing, deploying, etc.) Once the limit is reached in one stage, instead of starting a new task, members of the development team help others deal with the current tasks already in progress. This can mean helping others in your area of expertise or helping others in their areas of expertise (e.g. coders help testers, testers help business analysts, etc.).
In Scrum, the Sprint itself is a WIP Limit. A Sprint limits the number of USs that a Development Team forecasts it can complete during a fixed period. Limiting WIP is an effective way to drive deep collaboration at the team level, but WIP limits should be at a optimum level that they push the team beyond what they’re comfortable with and used to. That way the team will be engaged to improving their engineering practices, using techniques such as acceptance test-driven development (ATDD), reducing batch/USs size, cross-training, or any other technique to make the WIP Limit more manageable.