Imagine that you have a lot of new work, high priority new work, that
gets identified every sprint. During the sprint.
In other words, you don’t even know about 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?
First, question whether all the so-called high priority work is really high priority. It often is not.
Second, go to 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 interrupts 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 a box of velocity, say 5 story points out of your total velocity of 20, for ‘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 we took 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. And explain any disruptions that remain. Making the Team ‘happy’ is not the sole and only value in life, but it is important.
Mura. A lean principle (Japanese). Mura is the negative, the lack of an 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 have about the same size.
Muri. Another lean principle (Japanese), in the negative. Over-stressing the system. And this never helps. (It does help to challenge the Team. Idea to discuss in another post.) Never ask them to do more than they can in a Sprint. It only reduces their capability. But, 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 very important, we do not have to believe that person. The Team should judge for itself, based on benefit/cost ratio and other factors, whether that items deserves to ‘interrupt’ 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 that you use Kanban for high interrupt 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 good experience with Scrum. A good Kanban board executed well by a strong Team: that’s 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.
And, especially in this case, with lots of high-interrupt work, you should want to convert the Scrum Board into more of an advanced Kanban board sooner.
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.
In other words, you don’t even know about 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?
First, question whether all the so-called high priority work is really high priority. It often is not.
Second, go to 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 interrupts 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 a box of velocity, say 5 story points out of your total velocity of 20, for ‘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 we took 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. And explain any disruptions that remain. Making the Team ‘happy’ is not the sole and only value in life, but it is important.
Mura. A lean principle (Japanese). Mura is the negative, the lack of an 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 have about the same size.
Muri. Another lean principle (Japanese), in the negative. Over-stressing the system. And this never helps. (It does help to challenge the Team. Idea to discuss in another post.) Never ask them to do more than they can in a Sprint. It only reduces their capability. But, 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 very important, we do not have to believe that person. The Team should judge for itself, based on benefit/cost ratio and other factors, whether that items deserves to ‘interrupt’ 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 that you use Kanban for high interrupt 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 good experience with Scrum. A good Kanban board executed well by a strong Team: that’s 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.
And, especially in this case, with lots of high-interrupt work, you should want to convert the Scrum Board into more of an advanced Kanban board sooner.
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.
No comments:
Post a Comment