Canceling an Iteration

Having lived in Florida, I am used to preparing for and dealing with hurricanes. These are events that cannot be accurately predicted, but we know they are likely to occur because of the environment we live in.  Scrum teams can face similar natural disasters.  While the iteration represents a team's commitment to build a potentially shippable increment of work, events can occur that can impede, or even destroy, that commitment.  Teams and management need to be prepared in advance for these types of natural team disasters.

Knowing the Facts
Teams that are following the Scrum methodology should be aware that:

• Iterations can be cancelled before the allotted timebox of days is over
• The team can cancel the iteration if they feel they are unable to meet their iteration goal
• Management can cancel the iteration if external circumstances negate the value of the iteration goal

When to Cancel
There are various conditions under which a team might consider cancelling an iteration:

• Business conditions change that nullify the value of the current iteration commitments
• Technology discoveries threaten the completion of most of the commitments
• Team members are unexpectedly pulled from the team or forced onto the team due to changes in other projects.

It's important to understand that these conditions may not be sufficient for a team to justify cancelling an iteration. Cancellation is a last resort, like a pilot jumping out of his aircraft, and should occur at most once or twice a year. Teams that tend to cancel iterations too easily can erode the trust of the stakeholders and impact the collaboration that is critical to have with customers on an agile project.

How to Cancel
Scrum provides very clear guidelines for teams on how to handle these types of emergencies and to get back into the rhythm of iterations.

• Declare the iteration cancelled
• Dispose of all work in progress
• Immediately hold a retrospective to understand the conditions that led to this emergency and what impact it has on the product backlog
• Based on team findings, conduct a new iteration planning meeting, where the reason for the termination is reviewed and the revised product backlog is moved into iterations.

The second step may seem somewhat drastic, but keeping untested code and partial designs in your code base is confusing to the people who work with these artifacts. In the worst case, you may find teams building new functionality on top of the untested code, which is a disaster waiting to happen.   Also, by communicating the costs of cancelling an iteration (i.e. effort and money wasted), teams and stakeholders will learn the importance of keeping iterations on track.

Avoiding Cancellations
How can a team avoid cancelling an iteration?

• Keep iterations as short as possible (1 to 2 weeks).
• Make it clear to team members and stakeholders that canceling an iteration is an option that should only be used when there is no hope of keeping current iteration commitments.
• Let team members and stakeholders know the "signals" for a canceled iteration.  Make it visible at the time of the emergency and at the next iteration review.  Include lessons learned from the retrospective.

We hope you will never be faced with these natural team disasters, but by keeping these approaches in mind, you will be well prepared to recover quickly and restore the flow of business value.