Emergency Work In Scrum

Red box with axe in case of emergencyScrum strikes a useful balance between flexibility and focus. In sprint planning, the product owner presents the most important objectives to the development team. The development team commits to as many of those as they believe they can deliver in the sprint. Once sprint planning is over, the business doesn’t change their mind about what they want. The development team is able to focus on delivering the product backlog items to which they committed. At the beginning of the next sprint, the business has another opportunity to change direction in any way they need to.

Every so often something comes up that can’t wait until the next sprint cycle. This could be a problem that has arisen, such as customers not being able to log in. It could be a business emergency such as needing a feature rushed into production in order to land a new client. Such unplanned work is the subject of something that I call “the emergency protocol.” The emergency protocol isn’t an official part of scrum, but it’s a useful addition that many organizations choose to adopt.

Declaring An Emergency

First off, we need one person with authority to declare something an emergency: the product owner. The product owner’s job is to make sure the team always focuses on the most valuable outcomes. Therefore the product owner decides if this urgent thing is more important than the team’s current work. Is it worth putting the sprint goal at risk?

Dealing With The Emergency

After declaring an emergency, the product owner shares the emergency with the development team. It’s important that they go to the whole team, because we want the team to take ownership of this emergency and decide how best to resolve it. Maybe the whole team will swarm on the issue. Perhaps the team will decide that two or three members can address the emergency while the rest of the team continues with the planned work. It’s important that the team decides, not somebody outside the team.

After The Emergency

After the emergency has been resolved, the team gathers together and considers whether they still have full confidence they can deliver all the sprint backlog items and achieve their sprint goal. If they believe they can, then they move forward as usual. If, however, they no longer believe they can get everything done, then the product owner decides what items to remove. If the business is not going to get all of the originally committed product backlog items, then deciding which ones should be sacrificed is a business decision we want the product owner to make. The product owner selects one or more product backlog items to remove until the team has confidence they can complete the remaining items.

How does this affect the team’s velocity?

Since the emergency was unplanned work, there are no story points associated with it. Velocity is a metric that tells us the rate at which planned work is getting done. Unplanned work reduces the rate at which the planned work gets done. That is to say it reduces velocity. Remember: story points and velocity are a tool for predictability, not a way to keep score.

Does your organization have a different way of handling emergency work? Leave a comment and let us know.

Cheers,

Chris

This entry was posted in agile. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>