Scrum and Kanban are the most popular agile methodologies at the moment. How to choose the relevant methodology for your project? Should you follow it for the whole project life? Can you switch the methodologies on the fly? When should you go with Scrum or Kanban? How to do it right? This presentation answer the mentioned questions and shows a practical example of Scrum and Kanban use in the same project in different circumstances.

1. Practical example of
Scrum and Kanban use
in the same project
VS
April 11, 2015

2. • Managing Director
• Agile Enthusiast
• Games Fan
• Traveler
• facebook.com/victor.v.bogomolov
• linkedin.com/in/vbogomolov
• appturn.com
Victor Bogomolov

3. Hands up...

4. Controversial point?
Know better
solution?
Let’s have a
discussion!
Consider a story
through your own
experience
Doing right Scrum
and right Kanban is
the key!
Processes are not
everything!
Use engineering
practices to be
successful!
Disclaimer

5. Free-to-play MMO RPG for iOS
2+ years
2 teams: 10 and 5 members

6. Let the adventure begin!

7. Cross-functional team
Clear backlog
Clear target date for the release
New team members not familiar
with Agile/Lean principles
Solution
Project Kick-off and the first demo

8. No backlog ready
Considering feedback to implement
Creating new Game Design
Document
R&D
work preceding main
development
Solution
Incorporating feedback and research

9. Product development
Productivity
Constraints make difference
Stories split on sprints as mini-goals
Positive stress on commitment
“Relaxation” between sprints
Predictability
Stories split into sub-tasks and
estimated well
Estimation as a way to know what
we need to do
Solution
Main development

10. No backlog ready
Changing game concept
Updating the Game Design
Document
Technical development
Tasks with neither visual
output nor gameplay value
Solution
Direction change

11. Product development
Productivity
Proven statistically
Predictability Solution
Main development 2.0 

12. Estimations don't change plans
Valuable features don't fit one
sprint
Solution
Budget cut

13. Bug fixing stage
Hard to estimate
Solution
Bugfix!!!

14. Event based releases
Minimal marketable feature
set (MMFS)
High responsiveness
Ability to change priorities on
the fly
Solution
The next-best-action strategy

15. Support project
No need to estimate
Unpredictable incoming flow of
issues
Team of specialists
Tools engineer
Operations engineer
Solution
Live operations

16. So, where we’ve arrived...

17. +
Scrum-ban

18. Scrum Kanban
Cross-functional team Required Optional
Team of specialists Prohibited Allowed
Product development
Support project
Bugfixing stage
No backlog ready
Estimations don’t change plans
No need to estimate
Ability to release anytime
Ability to change priorities on the fly (responsiveness)
Productivity and predictability
Use of Scrum Vs. Kanban

19. Similarities
• Both are Lean and Agile.
• Both use 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, the release plan is
continuously optimized based on
empirical data (velocity / lead time).
“Kanban & Scrum: Making the most
of both” Henrik Kniberg and Mattias
Skarin ©
Differences
Scrum Kanban
Timeboxed iterations prescribed. Timeboxed iterations optional. Can have separate cadences for
planning, release, and process improvement. Can be event-driven
instead of timeboxed.
Team commits to a specific amount of work for this
iteration.
Commitment optional.
Uses Velocity as default metric for planning and
process improvement.
Uses Lead time as default metric for planning and process
improvement.
Cross-functional teams prescribed. Cross-functional teams optional. Specialist teams allowed.
Items must be broken down so they can be
completed within 1 sprint
No particular item size is prescribed.
Burndown chart prescribed. No particular type of diagram is prescribed.
WIP limited indirectly (per sprint) WIP limited directly (per workflow state)
Estimations prescribed Estimations optional
Cannot add items to ongoing iteration Can add new items whenever capacity is available.
A sprint backlog is owned by one specific team. A kanban board may be shared by multiple teams or individuals.
Prescribes 3 roles (PO/SM/Team) Doesn’t prescribe any roles
A Scrum board is reset between each sprint. A kanban board is persistent.
Prescribes a prioritized product backlog Prioritization is optional.
Scrum Vs. Kanban Summary

20. 1. What is Kanban? http://www.everydaykanban.com/what-is-kanban/
2. The Scrum Guide™ http://www.scrumguides.org/docs/scrumguide/v1/scrum-
guide-us.pdf
3. What is Scrumban? http://www.solutionsiq.com/what-is-scrumban/
4. Kanban vs. Scrum – How to Choose? http://www.agilevelocity.com/kanban-vs-
scrum-how-to-choose/
5. “Kanban & Scrum: Making the most of both” Henrik Kniberg and Mattias
Skarin http://www.infoq.com/minibooks/kanban-scrum-minibook
6. Kanban kick-start https://www.crisp.se/wp-
content/uploads/2012/07/Kanban-kick-start-v2.pdf
Useful links

21. Experiment!

22. victorb@appturn.com
linkedin.com/in/vbogomolov
facebook.com/victor.v.bogomolov