Interruption Driven Development
Scrum talks about having minimum disruptions during the sprint so that the team can work effectively in achieving their target. The Scrum master, is responsible for removing those impediments which might hamper the velocity of the team. However, in a practical situation, when the team is churning out deployable increments of functionality, they have to support production issues along with new feature development. These interruptions, might seem like a disruption to the team but they are important impediments to the system users and the product owner. The product owner, would not see any value in adding new functionality to the system if the existing system is not working fine.
- Tech support that can't be handled by first line support techs
- System maintenance tasks
- Requests for investigation of weird system behavior
- Requests for system data that is not easily available and requires a developer to get
- Customer customization requests
- Production problems (e.g., system outage or bad performance) that require developer attention
All the above scenarios could potentially become more important than the new feature development. So what is the way of handling such interruptions in a sprint?
Two backlog approach – one for development features and the other for production support issues. The product owner defines the ratio of work to be done from each backlog.
In this scenario, teams may need a burn-down for their development stories and a burn-up for their production support.
Bugs as Feature Requests – interruptions are put on the product backlog with the estimated business value and size. Geoff preferred this approach in prioritizing the production support interruptions with respect to the other features. Geoff notes that the key here is to avoid getting into an argument over whether something is production support or something else.Teams that can absorb this discussion rather than draw absolute lines will be the more effective and productive.
Emergencies – interruptions which have to be resolved immediately. Scrum Master and Product Owner are the best judges of an emergency.
If the issue is a true emergency, the Product Owner should have the authority to play the "emergency card," as long as he is aware of the costs of doing so— not completing the items we planned to and, potentially, jeopardizing the sprint goal.
The other important question is "Who should work on the interruptions?" Production support can be boring and there is a general reluctance in the team members to sign up for that. So is having a support team a good idea? Geoff mentioned, "having a support team causes an unnecessary split along with the associated confusion." An option is to have a support role on a sprint-by-sprint or weekly basis. This helps in increasing the cross-functional behavior of the team and has secondary benefits of increasing the overall knowledge of the system.
Another option, suggested by Alistair Cockburn, for handling interruptions, is in the form of a project management pattern by the name “Sacrifice one person”. According to him, the solution to the problem is to assign one person dedicatedly to take care of that interruption. Though, this one person would feel sacrificed, rest of the team can make progress by working on the primary task.
In summary, when deciding how to handle interruptions, consider to put them on the product backlog and prioritize them on the basis of business value. This would help in making sure that the team is always doing the right thing. However, if the interruption is an emergency, then there is a cost involved and the decision depends on weighing the cost versus immediate resolution.
Re: Placeholder story
Kevin E. Schlabach
I've had pretty good success with just using a placeholder story for ongoing maintenance work. Then folks can simply log time against it. At the beginning of the sprint, the team collectively estimates the amount of time that will be required for the "maintenance bucket", based on previous sprints.
I, like Kurt, find myself coaching teams to do this also. It allows the team to explain why they couldn't deliver as much (when this fluctuates), and help them be motivated by an achievable velocity.
The downside of this is that it is an overhead (waste!) that only adds value to explain what is going on. At some point, the value of this is minimal because the team and management learn enough from history to accept the "support velocity" and continuing to track it becomes one of those processes for process sake. So I advise that you do this for a time-boxed time and have a retrospective on how to decrease it, how much to accept as normal business, and how to remove the tracking of this stuff and simplify the process. In the end, I hope to have the team just lower their velocity goal by X points and accept that the loss is for whatever support is normal (and a self-managed team will be accountable to taking care of it).
As for Alistair's idea to sacrifice one team member, I do believe he supports that this is a rotating role (per iteration or sub-time window)... and that it is important to assign your most important person first to make it clear that it is an important role and is not dumped on the newer/weaker people in the team. It can become something that breaks the team dynamics into a group of superstars (those that create) and pledges (those that support).
Kevin E. Schlabach
Re: Placeholder story
Re: Placeholder story
One team I worked with had a similar problem, and decided to put a bright green task card on the task board for each interruption. There were a lot of green cards in two weeks! At the end of just one sprint the team had unanimously resolved to clamp down on interruptions. All it took was making the scale of the problem visible. They stopped using green cards right away, they were no longer needed.
From that point, interruptions were triaged: support work came out of a support "bucket" and plain old interruptions were dealty with firmly: yes, we can put that in the next sprint.
Eran Kinsbruner May 05, 2015