Scrum and Kanban are two different frameworks. But did you know that your Scrum Team can use some of Kanban’s crucial elements to optimize workflow and deliver value sooner? Combining Kanban with your Scrum practice doesn’t involve replacing events, accountabilities or artifacts. It’s about integrating Kanban’s complementary tools to achieve better outcomes with Scrum.
According to the Kanban Guide for Scrum Teams, Kanban is “a strategy for optimizing the flow of value through a process that uses a visual, work-in-progress limited pull system.” This article will discuss some of the critical elements of Kanban and how you can use them to optimize Scrum.
Visualization
Visualization is one of Kanban's most powerful tools, and one many Scrum teams already use. Visualization is a way to add transparency to the Sprint Backlog (or the Product Backlog) by creating a visible representation of the work, showing the current workflow state of each item.
Start by unpacking the steps your work goes through to deliver value and then visibly document those steps.
We commonly refer to this visualization of work as either a Kanban board or Scrum board. Some teams choose a physical board (using sticky notes or a whiteboard); others prefer an electronic version. You can find electronic boards in commonly used platforms such as Jira, Rally or Team Foundation Server.
Limiting Work in Progress (WIP)
When a team limits their work in progress, it means that they agree to put a limit on the Product Backlog items they will work on during a particular stage of the value delivery process. For example, if a Scrum Team lists one of the stages on the Kanban board as development, then the team may decide to limit the number of Product Backlog items in development at the same time.
It’s hard to overstate the benefits of limiting work in progress. By agreeing to these limits, the team improves the ability to focus on the highest ordered work first, improving the flow of their work and creating a positive impact on the quality of the product.
Focus
Imagine that you are the Scrum Master for a team using two-week Sprints. The first day of the Sprint, the team immediately begins work on all of the selected Product Backlog items. The Developers might end up working on two or three Product Backlog items at a time. What happens? The team’s scattered focus means they make only a small amount of progress on each item.
In contrast, when you limit WIP, the team can combine their focus on the highest Product Backlog items in the Sprint before moving on to the next. By improving focus and eliminating task switching, the Developers can close each item faster.
Flow
Because Scrum Teams are cross-functional, individuals with different specializations will likely work together during a Sprint. Both developers and testers are often on one team, for example. Limiting WIP allows for improved, steady work flowing from developers to testers. There are fewer gaps in the process.
Quality
In my experience, limiting WIP increases quality because fewer errors and bugs emerge when the team focuses on completing the highest ordered work items first before moving on to the next. Teams struggling to deliver an Increment each Sprint often see improvement when they begin to limit their WIP.
Pull
Limiting WIP has the effect of creating a pull system. No one pushes work into the queue. Instead, when an individual is ready for more work or the WIP limit is higher than the team’s defined capacity, they can pull in a Product Backlog item.
The famous I Love Lucy episode called “Job Switching” is an excellent illustration of the perils of a push system. In this episode, Lucy and Ethel take jobs in a candy factory. As candy moves around the factory using a conveyor belt, their job is to wrap each piece before it moves to the next processing step. Hilarity ensues when candy begins to come down the conveyor before Lucy and Ethel have finished wrapping the pieces in front of them. First, the quality of the work starts to suffer and finally, Lucy and Ethel cannot deliver any work at all.
Using a pull system is even more impactful for teams doing complex work. A pull system ensures that each item gets Done before the next begins. For Scrum Teams, this means they don’t start all of the work on day one of the Sprint. It might be several days into the Sprint before they begin some work items. This approach creates more collaboration opportunities as team members band together to complete active items rather than starting more work. It also dramatically increases the likelihood of delivering a usable increment that meets the Sprint goal by the end of the Sprint.
Conclusion
Scrum and Kanban are two different frameworks, but many common Kanban practices can improve the flow of work within a Scrum Team. If you want to learn more, the Professional Scrum with Kanban course will show you how to combine Kanban practices, such as limiting work in progress and visualization with Scrum.