Built-in work in progress limit in Scrum

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.

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.

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.

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.