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.
Scrum Alliance wiki defines some examples of interruption as
- 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?
Geoff Watts discussed his thoughts on how these interruptions can be handled with Scrum.
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.
