Mfcttrf

I had a following question in my PSK assessment.

When using Scrum with Kanban, who can change the WIP limits in the Definition of Workflow when a high priority work emerges from the Sprint?

• Product Owner


• Scrum Master


• Development Team


• No one, as WIP limit cannot be changed in the Sprint


• No one, as 'High Priority' work is not a valid reason for changing the WIP during the Sprint.

Following one the reference topic for this question but unable to answer this question.

• Limiting Work in Progress (WIP) in Scrum with Kanban - What / When / Who / How


• 
  The Kanban Guide for Scrum Team - can help in understanding meaning of all terms used in this question like WIP limit, DoW (Definition of Workflow), Scrum Sprint with Kanban etc.

According to reference document: Development team can do it but when it comes to Sprint Backlog. There is no clear indicator this question belongs to Sprint Backlog only. And if this question covers entire Sprint then The Scrum Team decides what to do with high priority task.

What can be the best answer out of all choices.

There is no clear indicator this question belongs to Sprint Backlog only.

I believe this is wrong.

The urgency of the work, to me, implies that it cannot wait until the next Sprint. The team must bring this work into the current Sprint and therefore is responsible for making the determination on increasing the WIP limits. Since the Development Team owns the Sprint workflow, I believe they would be the ones to determine if the WIP limit should be (temporarily) increases or if they should find a way to remove work from the Sprint. If work is removed from the Sprint, then they may need to collaborate with the Product Owner if the Sprint Goal is in jeopardy.

Update: This Answer assumes, incorrectly, that by WIP the OP meant Sprint capacity (a limit on how much work can be included in a Sprint), not Kanban WIP limits (a limit on how much work can exist in a single status at a time). I'm leaving it for posterity, but it does not answer this Question.

I would argue that the only valid answer is:

No one, as 'High Priority' work is not a valid reason for changing the WIP during the Sprint.

The Sprint capacity is how much work the Development Team thinks it can accomplish. High-priority work is not a valid reason to increase this amount. Even if you really, really need to give birth to two children, a pregnant mother can't just suddenly decide to have twins.

If work really needs to get done now, then you have two options:

1. Build slack into your Sprints so that capacity can be increased on a temporary basis without making a permanent change


2. Take something out of the Sprint so that capacity is preserved.

My other Answer answers a different question that the OP has clarified is not what was intended to be asked. I'm leaving it for posterity. This Answer addresses changing the Kanban WIP limits during a Sprint.

In this case, I would argue that the best answer is not actually listed. There are two aspects to this issue.

1. What to do about this particular high-priority work coming in when the Team is at the WIP limit.


2. What to do about permanently increasing the WIP limit.

For the first, there are already existing Questions on pmse that address this, so I won't get into it here. The short answer is 'it depends'. What I would personally (probably) do is just ignore the WIP limit.

For the second, Scrum provides an ideal tool for this. The Sprint Retrospective. During the Retro, the Team can discuss what happened, and whether or not to increase the WIP limit.

So, I guess, I would answer:

No one, as WIP limit [cannot should not] be changed in the Sprint