Skip to main content

Why Limiting Work in Progress Matters for Scrum

October 3, 2022

The heart of Scrum is the Sprint, which is a time-boxed event during which the Scrum Team delivers a valuable increment at least once per calendar month.  During the Sprint Planning event, Developers select which Product Backlog items (PBIs) they will deliver in the upcoming Sprint, create a plan for delivering them, and identify a Sprint Goal that provides a focus for the upcoming Sprint. The purpose of the Sprint is to deliver a done increment of valuable Product that meets the Sprint goal.  Sounds simple, right?  Yet many teams struggle with delivering a Done increment that meets the Sprint Goal.  

Did you know that adding the complementary Kanban practice of limiting the amount of work in progress (WIP) can help?

It’s a common myth that if you want something done sooner, start it earlier.  That might work in simple environments or when there is only one thing to do, but in complex environments, with many team members working together to deliver a variety of tasks, this practice can actually delay delivery.  

Take a look at the image below, which shows a sample Sprint Backlog. On the left is a list of PBIs the team selected for the Sprint. On the right are sample tasks we might create to deliver each one. 

Kanban board Day 1

Now imagine that on the first day of the Sprint, we immediately start working on all of the items and tasks in the Product Backlog.

 

 

Kanban board Day 2

 

It might seem like a good idea until you realize this is complex work.  If we start all tasks on the same day, we reduce the team collaboration that could have happened had we limited the WIP. 

Say that Developer A and Developer B each have a PBI they plan to complete during the Sprint.  If each independently starts work on their PBI, they might be able to complete it.  But, if instead of working alone, Developers A and B work together on the first PBI, finish it, and then work together on the next, they will likely be able to complete both PBIs sooner by collaborating.  

Collaboration helps teams identify creative or streamlined solutions to complex problems.  For example, several years ago, I was the Scrum Master for a team focused on reducing the run time for batch jobs.  The goal was to reduce the run time from eight to six hours to fit the job into the schedule.  The developers decided to pair program, and during the Sprint, they came up with a solution that reduced the run time to just 15 minutes and eliminated quality issues that had been repeatedly causing the job to fail.  Both acknowledged that this solution could not have happened without collaboratively focusing on the same problem.  

Even if teams are not pair programming, reducing WIP benefits teams by increasing focus and reducing task switching, which enables quicker value delivery.  

Multiply this by the size of your team, and you will see the advantages even in this simple example.  When we also consider the increased quality that results from limiting WIP, we see that starting work sooner is not always the best path.

The image below shows a sample Sprint Backlog for a team limiting their work in progress.  This is known as a Kanban board, a tool that allows team members to visualize the status of work for the Scrum Team.  This board shows that the team has started some — but not all — of their work following the Sprint Planning event.   By limiting WIP, the team can focus on those items in progress and finish them faster than if they tried to split their focus and concentrate on everything all at once.

 

Kanban board Day 2
 

Conclusion

It’s a common myth that if you want something done earlier, start it earlier.  While this may hold in simple environments, it doesn’t always work out that way for complex work.  

Scrum is a framework that addresses delivering complex products in complex environments. While Scrum is the most popular agile framework, many teams are unaware that you can implement practices common to Kanban – such as limiting WIP — to improve team effectiveness.  Combining Kanban with your Scrum practice doesn’t involve replacing events, accountabilities or artifacts.  It’s about integrating some of Kanban’s complementary practices to help improve the flow of work within the Sprint.  

Sign up for Rebel Scrum’s upcoming Professional Scrum with Kanban class to learn more about how to use Kanban practices such as WIP and visualization to improve the effectiveness of your Scrum Team.

 


What did you think about this post?