Last year, it seemed that Scrum was so common that I heard people regularly using it synonymously with “Agile.”
More recently, Kanban seems to be the big buzz word. Organizations that have mastered Scrum are moving to Kanban. More ALM vendors are adding Kanban features to their offerings, and the conferences and user groups are filled with sessions on how to work “lean” or with “continuous flow” which often equates to the use of Kanban. But what exactly is Kanban and how does it differ from Scrum? Can the two be used together? In this tip, project managers and team leaders get a closer look at Scrum and Kanban, both how they are different and how they might be complementary.
Difference in deliverables
There’s plenty of debate about what makes software development “Agile,” but there’s more definition about specific methodologies. As mentioned in the blog post, Exploring Kanban, Agile development’s new rising star, and in Kanban vs. Scrum by Henrik Kniberg, Scrum is said to have nine rules, and Kanban only three.
Scrum “rules” dictate that the team use the following:
- Scrum Master
- Product Owner
- Sprint planning meeting
- Daily Scrum
- Sprint review
- Product backlog
- Sprint backlog
- Burndown chart
Kanban only requires the following:
- Visualize the workflow
- Limit work-in-process (WIP)
- Measure and optimize flow
Differences in measurements used to track progress
In Scrum, the team works with iterations which are “time-boxed” or done in specific increments of time, called sprints, typically two to four weeks. At the beginning of each iteration, there is a sprint planning meeting in which stories are chosen from the product backlog and chosen to be developed in the next iteration.
In order to determine how much work can be done in each iteration, the team’s performance is tracked using a “burndown chart” where the x-axis represents the estimate of work to be done and the y-axis is the iteration timeline. The burndown chart measures the team’s “velocity,” which is a measure that indicates how productive the team is in each iteration.
The task of estimating each story, often done in “story points,” is needed in order to properly split tasks to a size that they can be completed within an iteration.
In Kanban, different measurements are used to determine whether or not the project is on track. Queues are used to represent workflow. For example, there might be a queue that holds all the items in the backlog, a queue for development, a queue for test and a queue for deploy. Often a Kanban board is used and story cards are moved across the board as they progress.
Rather than time-boxing a story, mandating that the story must be complete within an iteration, Kanban limits WIP or work-in-process. The team must determine the WIP limits for each activity, but once that WIP limit is met, team members must work together to clear any areas that are blocked. The total cycle time is the time it takes to complete a story. By measuring this over time, the team will get a sense of how long it actually takes to complete stories. Proponents of Kanban believe that using cycle time will ultimately allow teams to make accurate estimates when needed.
Difference in roles and meetings
Scrum defines very specific roles and meetings that must occur. There must be a Scrum master, a product owner and a team of developers who code and test the stories. The Scrum master facilitates the meetings and helps to remove any impediments that are blocking the team from progressing. The product owner represents the business or users and helps to prioritize and clarify the stories.
Scrum dictates that there is a sprint planning meeting to determine which stories are going into the sprint. There is a daily Scrum meeting, sometimes called the daily stand-up, which is a short status meeting to let the team know what each member did the day before, their plans for the day and any impediments. At the end of the sprint, there is a sprint review meeting to demo the working software and hold a retrospective, examining what went well and what could be improved.
Kanban does not require the roles and meetings that are defined in Scrum; however, many teams that transition from a Scrum methodology maintain the roles and meetings that were used on their Scrum teams. Kanban does dictate that flow is measured and optimized, so the team does look at project measurements and works towards continuous improvement.
Differences in transition
Scrum, being more prescriptive than Kanban, is usually a more difficult transition for software development teams. There is a specific framework that must be followed and if the team is currently using a traditional software development approach, it can be a big shift for teams to work in a new way and have new roles.
Kanban is designed to start with the process you are using and work towards continuous improvement. Teams are encouraged to map out their current workflow processes and determine bottlenecks. The process is meant to evolve to a unique and optimized work flow for the team.
Are Scrum and Kanban complementary?
As we’ve seen, Kanban is not meant to dictate your methodology, but rather improve your processes by optimizing flow. Kanban can be used with Scrum, though there are some differences in the ways stories or tasks are assigned and measured. Those practicing both Scrum and Kanban may use techniques considered “Agile” such as test-driven development or continuous integration. In both cases, teams work towards measuring and improving.