Is Cancelling a Sprint the Only Option?

The sprint planning session has ended, the team has committed to the appropriate user stories and all is well….or so it seems. Five days into the sprint, a high-ranking executive approaches the scrum team with an extremely urgent client issue that must be resolved. Your team has the knowledge and experience to resolve the issue, but if they take on any extra work, the sprint commitment will be in serious jeopardy. The rules of scrum tell you to cancel the sprint and re-plan, taking the urgent client issue into account – most likely as the highest priority user story. However, a lot of time and preparation went into the sprint planning session and the team is certainly not looking forward to having another planning session so soon because they have momentum and do not wish to stop. Things to take into account when deciding what to do are:

  • Team maturity. Where are they in Tuckman’s stages of team development?
  • Ceremony overhead. Are your sprint planning sessions all-day affairs that can be quite contentious or are they smooth, short affairs?
  • The real urgency of the client issue. It may not be as urgent as you have been lead to believe.
  • The risk of addressing the issue right now vs. the risk of addressing it later. Can it wait? If so, what is the associated cost?
  • What day of the sprint is it? Is it early in the sprint or later?
  • Magnitude of the code change. Will require some investment by the team – time box this to an hour.
  • Is it really a defect….or an enhancement disguised as one?

 

You can certainly cancel and re-plan, but there are other options that should be assessed. Here are a few:      

Ask the team. They may look at it for a few minutes and decide they can do it or they may say “no way”.      

Timing. It will depend on where the team is in the sprint from a chronological standpoint. It is easier to cancel earlier in the sprint because the team has less time invested in the sprint backlog at that time. The later the incident occurs, it decreases the likelihood the team will cancel the sprint due to the time and effort invested as well as the potential results achieved. It may be advantageous to just plan to address the urgent issue in the next sprint.      

Negotiate. Work with the source of the interruption. The executive is probably just the messenger. Find out where this really came from and work with them. If it came directly from a client, have the account representative or the implementation team, whichever is appropriate, work with the client in order to set expectations on when a resolution can be delivered.      

Time buffer. If this is a frequent occurrence, create a consistent slice of time in each sprint to provide for these types of urgent situations. Take into account Parkinson’s Law, “work expands so as to fill the time available for its completion”. Discipline is needed by the team so that if this time goes unused toward the end of the sprint, another story is picked up instead of ‘goldplating’ the current stories in the sprint.

In summary, canceling a sprint is an answer, but it is not the only answer – you do have other options. Have you done something different than any of the above options? If so, please reply. I would love to hear of other alternatives.

Author: Tom Westervelt

Tom Westervelt is a Lead Scrum Master at DST Systems, Inc. With 25+ years of IT experience in both development and project management, Tom has been instrumental in leading DST's Agile adoption since 2008.

Leave a Reply

Your email address will not be published. Required fields are marked *