High Priority Interrupt Work in Scrum

Imagine that you have new, high priority work, that gets identified during the sprint.  In other words, you don’t even know many of the stories or issues or tickets until after the Sprint Planning Meeting.  A support team is a classic example of this.

How do you organize things in Scrum to handle this?

The first, question is whether all the so-called high priority work really is high priority. Often it is not.

Second, seek the root causes of why the high priority work is being identified so late. Example: If the quality is low when we release to production, let’s fix the quality issues (maybe caused by lots of interruptions to the Team).

Third, shorten your sprint length.  Maybe from 4 weeks to 2 weeks. Or from 2 weeks to 1 week.  Note that the so-called Scrum overhead of the meetings adjusts proportionally to the sprint length.  So, it’s a 4 hour (max) Sprint Planning Meeting (SPM) for a 2 week sprint, and a 2 hour SPM for a 1 week sprint.

Fourth, in the SPM set up box of velocity, say 5 story points out of your total velocity of 20, is  ‘to be discovered’ work.  The PO has to manage the usage of the box against ‘tickets’ as they arrive.

Fifth, as an alternative, substitute items. Example: Plan for the full 20 SP; but if a high priority ticket comes in, substitute that 2 SP ticket for the 2 SP story at the bottom of the Sprint Backlog.

That means: we have the Sprint Backlog items in priority order.  We complete them in priority order and we story point each new ticket. Just as we have story pointed each user story into the sprint backlog.

Principles

What are the key ideas behind all this?

Minimize disruptions. It is demoralizing and wasteful for the Team to be disrupted. It may still happen, it is part of life, but the Team and the firm should try hard to minimize disruptions.  Making the Team ‘happy’ is not the sole and only value in life, but it is important.

Mura, is a lean principle from Japan.  Mura is the negative, the lack of  evenness of flow.  So, we want an even flow through the system. This is reflected, in part, by having all the Product Backlog Items in a Sprint Backlog about the same size.

Muri.  Another lean principle from Japan, is in the negative, over-stressing the system. This never helps. It does help to challenge the Team. An idea to discuss in another post. Never ask them to do more than they can in a Sprint. It only reduces their capability. After they have completed everything they ‘committed to’, then they can start another story at the end of the sprint.

Do the most important thing first. (Enough said.)

Understanding business value is difficult. So, in this case, just because someone says this new ticket is very important that item ‘interrupts’ the sprint backlog.  Many contribute, and if the decision is not obvious, the PO makes the final decision. Note: The main thing the PO is trying to do is maximize the business value out of the Team.

Scrum and Kanban

Some people have recommended Kanban for interrupting work.

I do recommend Scrumban.  Where Scrum and Kanban are combined. Much as Toyota uses Kanban within the broader context of all the Lean ideas and tools.

I recommend converting the basic Scrum board (which already includes Kanban board ideas) into a fuller Kanban board once you have some experience with Scrum. A good Kanban board executed well by a strong Team is a wonderful thing.

Now, setting up a truly good Kanban board is hard. The best Kanban boards have high requirements, and are not suitable for many situations. A beginning Team or a difficult situation may well be better served by the basic Kanban board in the normal Scrum board.

Especially with lots of interruptions, convert the Scrum Board into more of an advanced Kanban board.

I do not recommend ‘Kanban’ as I often see it played ‘out there’. Where we have groups of people, not Teams. Where there is no time box (no sprint). Where there is no Sprint Planning Meeting, no Sprint Review, no Retrospective, no Daily Scrum.  No roles, no artifacts. (Or, if they have a few of these, they are much too weak.)

***

Do these comments help? Your comments please.

« « Kent McDonald on Release Planning || Do only high benefit/cost work! » »