Built-in work in progress limit in Scrum

Last post 01:47 pm December 29, 2020
by Thomas Owens
4 replies
08:28 pm December 28, 2020

In a discussion with a co-worker we came to the following doubt: which element already present in Scrum is a better example of WIP limit: the Sprint Goal or the Sprint Backlog? I had thought of Sprint Goal, as it is what really defines what is important in a Sprint. However, the decomposition of work items is in the Sprint Backlog. 

What do you think?

09:57 pm December 28, 2020

I'd suggest that it is the Sprint itself which represents a WIP limit. The time-box is the constraint. Although the work to meet the Sprint Goal is emergent, there's only so much work a team is able to fit in.

11:09 pm December 28, 2020

The Sprint Backlog is now defined as being:

composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

Each of these elements can be relevant to limiting WIP as Developers might:

  • only commit to a Sprint Goal that represents what they understand could be achieved within a Sprint
  • decline work that decreases the likelihood of achieving the Sprint Goal
  • only pull the particular Product Backlog Items that they forecast being "Done" within a Sprint, and
  • have an actionable plan that includes a workflow that explicitly limits WIP, according to some kind of policy.


11:12 pm December 28, 2020

And to pick up on the title of this topic, any built-in WIP limit in Scrum relies on the Scrum Values; otherwise, it would be very easy for a Scrum Team to go through the motions of having a Sprint Backlog that does not limit WIP in the slightest.

01:47 pm December 29, 2020

This may not be a popular take, but Scrum doesn't have any "built-in" work-in-progress limits.

To start off, it's important to define what "work-in-progress" is. It could mean different things from different perspectives. For example, the Developers may see work-in-progress beginning when they actively begin a work item and ending when that work item is complete. A more broad definition may start at a point in time such as a work item being deemed ready for a Sprint or selected for a Sprint and ending with delivery. To talk about work-in-progress, it's important to define your workflow and have a clear point at which work is considered started and finished.

I agree with Simon Mayer's statement that WIP limits in Scrum, without applying outside techniques like Kanban, rely on the application of the Scrum Values. I'm particularly looking at the values of Courage, Openness, and Commitment. The team needs to be open with themselves and others about their way of working, the courage to say no to taking on more work than they believe is appropriate, and ensuring that they can make goals that they can commit to.

I see five elements of Scrum that could be seen as work-in-progress limits - the Sprint, the Sprint Goal, the Sprint Backlog, the Product Goal, and the Product Backlog. However, none of these actually force the team to limit how much work they are actively working on. They do support a team focusing on a particular objective or outcome and add timeboxes, but there is no active limit that says that a team can only have N work items in progress or that only work items directly related to the current goal can be in the backlog.

Scrum does pair nicely with Kanban, as shown in the Kanban Guide for Scrum Teams. If you're interested in how these elements can be enhanced to help a team add WIP limits, that would be a good place to start.