Note:  This post was originally published on November 22. 2013, on AgileAtlas.org, a site of Scrum Alliance.  This site is now defunct.

Update: Sept 2018 – The agile atlas article can now be found on the Scrum Alliance site at this link: Abnormal Termination of a Sprint

Authors: Aashish Vaidya & Dorothy Murray

Agile development is all about adapting to change. It is explicitly called out in the second principle behind the Agile Manifesto, “Welcome changing requirements, even late in development.  Agile processes harness change for the customer’s competitive advantage.” This is why, in Scrum, the Product Owner is responsible and accountable for maintaining the Product Backlog. The Product Owner has the final say over the ordering the list of ideas for a product. This includes selecting a smaller chunk of the Product Backlog as a Sprint Backlog. This gives the Product Owner, the lever on adapting to changing conditions.

The Sprint Backlog is the team’s forecast on completing work for the Sprint duration. It is expected that a team commits to reasonable amount of work based on its velocity and does everything within its power to deliver on these commitments. It is also expected that for the duration of the Sprint, the Product Owner or any other stakeholder is asked to maintain the Sprint Backlog constant. A team also is required to maintain its sprint duration constant so that it can deliver a product increment on a regular cadence.

However, under rare and extenuating circumstances, when a Product Owner or the team realizes that they cannot deliver on their stated Sprint goal, a Sprint has to be canceled or an Abnormal Termination of a Sprint is required.

Reasons for an Abnormal Sprint Termination may include, but are not limited to:

  • The company changes direction
  • Market forces render the work obsolete
  • A major technology change occurs
  • A better technical solution is found that makes the current Sprint’s activity throwaway work
  • Fundamental and urgent external changes that invalidate the Sprint Goal or the bulk of the functionality
  • Urgent bug fix or feature development request that cannot wait until the normal completion of the Sprint

Often times, Product Owners or other stakeholders interrupt teams and redirect them to new goals and priorities while a Sprint is underway. In many cases, this redirection isn’t due to critical needs that cannot wait, but it is because a Product Owner failed to think ahead. If redirection happens on a regular basis, a team will not develop cadence and produce high quality working product increment – the goal of every Sprint.

The act of formally canceling a Sprint makes visible the cost to all stakeholders, as there are overheads associated with stopping a in progress Sprint and in conducting another Sprint Planning meeting. Terminating the Sprint is a good way to ensure that the benefits of changing a Sprint backlog mid-Sprint really outweighs the cost.

The practice follows these general steps:

  1. Certainty by the agile team and product owner that the Sprint goal cannot be met or has changed significantly. The benefit of stopping work mid-Sprint outweighs the costs.
  2. Product Owner calls for Sprint to be abnormally terminated and makes this decision visible to all stakeholders.
  3. If there is critical emergency (such as production down), the agile team attends to the emergency.
  4. The team reflects on the reasons for the termination of Sprint, and plans on taking corrective action, if any are required, during next sprint.
  5. The Agile team and the Product Owner conduct a new Sprint Planning meeting.

Apart from legitimate but rare reasons, Abnormal Termination of Sprint is also a reminder, especially for transitioning organizations new to Agile practices, that every new request shouldn’t always be treated as an emergency.