Doing kanban, there will come a point where you will be faced with holding or breaking the work in progress limit. Here are fours ways of dealing with that situation:
- Case1: Urgency!
The new story has higher priority than work on the board. Accept a temporary violation of WIP, but don’t starting more work until WIP is balanced again - Case2: Pleasant "no"
Bring the stakeholder to the board and ask them if they would like you to throw away for the benefit of their request. - Case3: Can’t say now for Legal reasons
Start an overflow section. Whenever WIP risk being broken, compare the priority to what is on the board and if it is less put the work in a overflow section. The policy being: to put something on the overflow secion requires an email to the sent to the stakeholder saying you can’t do it right now but you may do it somewhere in the future (best solution is to find someone else to solve the problem) - Case 4: Homework has been made
Don’t violate WIP, instead ask the stakeholder to put it in the right priority in the backlog
Don’t forget, the "urgent" story brings information you can learn from. Is it a common or special cause? Is it an undiscovered demand type? Does the stakeholders upstream understand your approach?
Nice post Mattias; we’re starting to use Kanban for our software maintenance. We basically use the overflow concept for work that meets the criteria of an “emergency”. We allw that work to overtake what was originaly a work in progress. Once that is done, we go back to it being in-balance.
Using a set of rules makes it clearer for everyone, part of those rules are a bit more technical in nature (e.g. is there a reasonable work-around in the system) and part of these are business driven. The match of the two in the highest categories constitutes an item worthy of overtaking current work in progress.
Cool! of course interested in where you went to from there 🙂 (at some later stage)