Developing and Delivering Products Professionally [P3]: Optimizing Flow - Limiting Work in Progress (WIP) in Scrum with Kanban - What / When / Who / How

Question 1

Main aim of limiting work in progress?

Answer 1

and stabilizing Work in Progress

Question 2

Who should define the WIP Limit?

Answer 2

Holistically - Scrum Team if PO is involved and PB considered

Question 3

Should WIP limits be changed to deal with mid-sprint high-priority work?

Answer 3

• (1) decision needs to be made whether to pull this item into the Sprint Backlog
  
  • core Scrum question
  • team must decide whether to pull it in
• (2) can they start it right away?
  
  • If the team is at their WIP limit they shouldn’t pull in that new item until some room frees up
  • If their backlog items are pretty small, an empty WIP slot will free up pretty quickly.
  • If items are big, it can take a while.
• The longer it might take to get a normal pull slot ready, the more pressure there might be to actually expedite this card.
• What is expediting?
  
  • going beyond the current WIP limits and pushing this item along on top of the existing flow.
• The typical way to do this is NOT to change the WIP limit definition but to go above WIP and note a WIP exception. These exceptions can then be a topic for inspection and adaptation come time to retrospect

Question 4

When should the WIP limits be inspected and adapted?

Answer 4

• don’t recommend changing WIP limits on a whim just because there seems to be a need during the Sprint
• rathersee an exception and discussionrather than hide the problem under a policy change
• Most of the time, Scrum Teams should adjust WIP limits during the Sprint Retrospective out of an attempt to create a better flow strategy, not a way to manage at the tactical level
  
  • Like DoD → don’t change mid sprint if we have a problem with delivering an increment
• note the exception, maybe even fail to create a really Done Increment, and we discuss the definition during our Retrospective
• Having said that,there is nothing stopping them from adjusting WIP limits at ANY point throughout the Sprint. In other words, There’s a difference between CAN and SHOULD

Question 5

How should Scrum teams limit their WIP?

Answer 5

You could limit the amount of work in progress per person, per the entire team throughout their workflow, or actually, you could limit WIP by time. E.g. “we won’t work on more than 10 items this week”