Scrum vs. Kanban: How Do They Treat Work in Progress?

Team Scrum or Team Kanban? No matter whose team you’re on, we want to support the first principle of the Agile Manifesto:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”

One way we can achieve early and continuous delivery is through delivering smaller batches of working software and limiting the amount of work in progress (WIP) at any given time. This is why Agile and Lean principles focus on getting things done in small batches. Smaller batch sizes allow completed work to be delivered to the customer faster and enables us to satisfy the customer more quickly.

Scrum creates smaller batch sizes by establishing a timebox (usually 2 weeks). The work items completed within the timebox are delivered as soon as it ends, if not earlier. This is much faster than a traditional waterfall method that batches all work items up into a large release and waits until it is complete to deliver it to the customer.

Kanban creates smaller batch sizes by emphasizing continuous flow and limiting the number of work items in progress at any one time. This focuses the team on getting individual work items completed.

While both methodologies are able to create smaller batches of working software than the traditional waterfall method, Kanban places a more deliberate focus on the significance of work in progress than Scrum does.

Limiting Work in Progress is Integral to Kanban’s Structure

Kanban Board – Effective Kanban boards will always specify WIP limits for each column in the workflow. In the example Kanban board below, you can see there is a WIP limit for each state in the workflow. By explicitly setting and abiding by these limits, Kanban minimizes the number of work items that are in flight at the same time. This focuses effort on getting the work items completed and moved to the Done column.

Focus on Flow – One of the basic principles of Lean software development is flow. By visualizing the work, we can observe its flow. If there is a lack of flow (because of too many work items in progress, blockers, or other impediments) the Kanban board immediately draws attention to the associated columns. The team can then work together to address the problem and resume the flow of work.

In the example above, the WIP limit for the Deployment column is 5 and there are already 5 work items in that state. This causes a bottleneck and will prevent any other work items in the Test column from moving forward until items are moved from Deployment to Done.

Limiting Work in Progress Takes a Backseat to Scrum’s Sprint Timebox

Focus on Timebox – Scrum limits WIP by using timeboxed iterations called Sprints. Focus is a core Scrum value and the primary focus in Scrum is completing the work allocated to the timebox. How the work progresses within that timebox is not a major concern unless the end of the Sprint is drawing near and lots of work remains. Teams then tend to focus on how to deliver the most valuable items and limit their WIP. However, generally speaking, having too many items in flight at the same time is not a primary concern in Scrum.

Scrum Board – The layout of the typical Scrum board makes no mention of WIP limits. In referencing the example Scrum board below, you can see it has the same layout as the Kanban board but with no WIP limits identified. As a result, there is nothing preventing the team working this board from having several work items in progress at the same time. The only true limit is the number of stories that are in the Sprint Backlog and allocated to the Sprint timebox.

Some Scrum boards do indicate WIP limits but these are often not strictly observed since everyone on the team is focused on getting the work done in the Sprint Backlog before the Sprint is over.

Mini waterfall tendencies – Another side effect of having no explicit WIP limits is that old Waterfall habits can creep in. With no limits on how many work items can be in development at any one time, developers might wait to complete all their work items before passing them on to testers. Similar to typical Waterfall environments, the testers end up in a mad scramble trying to finish all those work items before Sprint is over.

Conclusion

We can say in this context; Team Kanban wins the WIP battle over Team Scrum since Kanban places more deliberate emphasis on the significance of work in progress than Scrum does.

Limiting WIP is an essential element of the Kanban method. It appears front and center in the Kanban board and enables flow. Scrum’s primary focus is what happens at the end of the Sprint timebox. Scrum doesn’t restrict how many items may be in flight during the timebox which could result in a mini Waterfall workflow during the Sprint.

Although both methodologies are able to create smaller batches of working software than a traditional Waterfall method, Kanban uses the discipline of limiting WIP to accomplish that goal most effectively.

This blog post is part of our “Scrum vs. Kanban” series, triggered by a working session at one of Excella’s Agile Coaching Circle’s offsite meetings. We explored our experiences with and thoughts about the Scrum Framework and Kanban Method, identifying a series of themes that would enhance the knowledge and understanding of our colleagues. We are pleased to share those lessons with you.

• Scrum vs. Kanban vs. Scrumban – Jaap Dekkinga
• Scrum vs. Kanban: Impact to WIP – Nicole Spence-Goon
• How Do Technical Practices Fit In Kanban – Paul Boos
• Scrum vs. Kanban: “Renting vs. Owning” the Process – Trent Hone
• My Experience with Kanban Outside IT – Mark Grove
• Reflecting on Agile Principles – Jaap Dekkinga
• How do Scrum & Kanban create Psychological Safety? – Nicole Spence-Goon