4

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.

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.

Improve this question

4 Answers 4

Reset to default
7

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) increased 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.

Improve this answer
0
4

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.
Improve this answer
1

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

Improve this answer
1

My answer would be

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

The WIP limit, as in the number of tickets that can be in a particular status of development (a column on the board) is not determined by the urgency of the work but by the amount of work that the team can be working on at the same time without incurring inefficiencies.

Instead, when highly urgent work gets added to the sprint's backlog, then the team should come up with a plan to free up some room within the current WIP limits to start working on the urgent work as soon as possible. The two likely actions are

  • Speed up work on a nearly finished work item, so it can move to "Done" a bit faster
  • Move a work item back from "In Progress" to "Not started/Not being worked on". Preferably, this should be a work item on which very little work was done, so the least amount of work gets 'lost'.

If neither action is possible, then you could choose to temporarily ignore the WIP limits, but either that will incur inefficiencies due to context switching or some work items will effectively move to a "Not being worked on" status without this being reflected on the board.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.