2. Kanban vs Scrum
o Team
o Project Type
o Boards and WIP
o Daily Meetings
o Iterations
o Reporting and Metrics
Kanban and Scrum
3. Team
Scrum
o Prescribed Roles
Product Owner
Scrum Master
Dev team
o Team Size
7+-2 team members
o Personnel
Cross Functional
Kanban and Scrum
Kanban
o No Prescribed Roles
o Any Team Size
o Personnel
Not needed to be
Cross Functional,
specialists allowed
4. Project Type
New Software Development
Maintenance Projects: Corrective, Adaptive, Perfective, Preventive
Kanban and Scrum
Scrum
o Best results in new software
development
o Challenging in maintenance
projects with an SLA in place
Kanban
o Best results in maintenance projects
o Shows good results in new software
development too.
5. Visualization – Board and WIP
Scrum
o WIP limit is for the entire sprint/
iteration
o Scrum board is reset with each
sprint.
Kanban and Scrum
Kanban
o Define WIP per workflow state
o Kanban board never gets reset – it is
always persistent
6. Daily Meetings
Scrum
o Prescribed to be held everyday
o Time Boxed – 15 mins
o 3 questions:
progress made yesterday
plan for today
any impediments
o Person Oriented
Kanban and Scrum
Kanban
o Not prescribed, not forbidden either
o Not time boxed
o Anyone can join
o Board / Card Oriented
7. Iterations
Scrum
o Time Boxed – 1 to 4 weeks
o Cadences:
Sprint planning (start)
Sprint retrospection (end)
o Unplanned tasks – not allowed
Kanban and Scrum
Kanban
o Continuous workflow – not time
boxed
o Cadences – optional
o Unplanned tasks - allowed
Choosing between Scrum and Kanban depends upon the following topics
Team – Size and type of the team
Project – Project type
Boards WIP – The visual representation of the work
Daily meetings – Need for regular meetings
Iterations – Iterative development for rapid and continuous development.
Reporting and Metrics – Metrics and charts used for reporting and estimation
Scrum:
The optimal team size prescribed for a scrum team is between 5 and 9 team members. This does not include the product owner or the scrum master unless the also execute the work.
Scrum teams also call for the team members to be cross functional, meaning all the team members should posses a good knowledge of all the stories so that the team can rally and close all the stories by end of the sprint.
Kanban:
Kanban on the other hand does not prescribe roles. Although, in practice teams identify a team member having added responsibility to a maintain the board (backlog items, WIP count, cumulative chart)
Kanban does not prescribe an optimal team size either but studies have shown that it has worked great for teams of varying sizes
Kanban also does not call for the team members to be cross functional as cards are tracked at an individual level and not at a sprint level.
Maintenance Projects
Corrective Maintenance: Reactive modifications of a software product performed after delivery to correct discovered problems
Adaptive Maintenance: Modification of a software product performed after delivery to keep the product useable in a changing environment
Perfective Maintenance: Modification of a software product after delivery to improve performance or maintainability.
Preventive Maintenance: Modification of a software product after delivery to correct latent faults before they become effective faults
Scrum has proven to be challenging in maintenance projects, specially corrective maintenance projects which usually SLA’s in place as newly identified item requires the scrum master to frequently modify the scrum to meet the SLA.
Kanban:
Kanban prescribes only 2 rules while designing the board
Visualize your work flow: This is usually denoted by columns on the Kanban board with flow of work moving from left to right. These columns or lanes may be named – Backlog, Development, Testing, Deployment etc.
Limit the WIP: Defines the max number of items per person in a column or a workflow state. This encourages the team to focus on the tasks at hand which helps the team members to collaborate better.
Scrum:
Scrum prescribes to have daily stand ups that need to be attended by the Product owner, Scrum Master and the development team only
These daily standups are time boxed to 15 minutes where each person from the development team needs to answer 3 things:
What did I do yesterday to help the team achieve the sprint goal
What do I plan to do today to help the team achieve the sprint goal
Are there any impediments/ roadblocks in my way.
The scrum master needs to ensure that the stand ups are completed within 15 mins and setup follow up meetings with only the required team members.
Kanban:
Kanban does not prescribe to have daily meetings but it also does not forbid you from having it.
Kanban meetings are not time boxed and board or card oriented meaning the team members do not have to talk about the 3 questions Scrum prescribes. Instead the team talks about the cards and their progress. Any impediments or blocked cards need to be addressed/ escalated (if they cannot be addressed).
Note that it is not necessary for each team member to speak as the focus is on cards and not individuals.
Kanban:
A Kanban board is never reset and has a continues workflow
It does not define any cadences and one can customize it to best fit the team. Ex: 1 week planning cadence or 3 week development cadence
Kanban is also very flexible on adding any new tasks to the board. Usually, the product owner prioritizes the cards in the TODO lane so that the development team can pull the task when they complete their card/s in the “In Progress” lane.
Burn down chart:
Tracks work remaining
X axis – iteration/ duration
Y axis – story points
Note that the effort denoted by this chart is the effort left and not the effort spent
Analyzing a burn down chart:
Entire work done before end of sprint – under estimation of work
Incomplete stories left after sprint completion – over estimation of work
All stories are done on time – optimum situation, usually achieved after 4 sprints cycles
Burn up chart:
Tracks work completed
Inverted burn down chart
X axis – iteration/ duration
Y axis – story points
Very useful in release planning as by analyzing the burn up chart it can easily be determined when a piece of work will be completed
Cumulative Flow Diagram:
X axis – iteration/ duration
Y axis – story points/ number of features
The CFD clearly denotes:
Items in backlog
Completed Items
Items in development WIP
Items in testing WIP
Total WIP - Dev WIP + Testing WIP
Cycle time – Time taken from development to deployment
Lead time – Time taken from the inception of the card on the board to deployment
