How can a SAFe team end a failing sprint early?

Question

In Scrum, the team has the power to bring a sprint to a premature end if it becomes clear that the Sprint Goal cannot be achieved (or if it becomes irrelevant). How can a SAFe team do the same thing?

Although I have actually done this once, what we did was really made up on the spot, so I'm looking for some tried-and-tested suggestions. Also, we were in the fortunate position of having no dependencies to/from other teams in the Release Train, so after cancelling the sprint and holding a brief retrospective, we were able to re-plan the remainder of our PI without having to involve other teams. But I would like recommendations for what to do when the situation isn't quite so simple.

Due to the Release Train synchronised cadence, we ended having to plan a half-length sprint so that our end date aligned with the other teams. Is that the Right Thing to do? And do we need to perform an Iteration Review for the aborted sprint?

As a Scrum Master, what do I need to know, to guide my team through this potentially stressful time?

---

N.B. this question is not the same as What is the framework "escape hatch" for a SAFe ART that is running down the wrong track?, as that is about the entire ART discovering it can't meet its PI Objectives, whereas here I'm talking about a single team and a single iteration (though we obviously expect a knock-on effect on the subsequent iterations).

Answer 1

The Scrum Guide says very little about canceling a Sprint - the Product Owner can cancel a Sprint if the Sprint Goal becomes obsolete. Other criteria for canceling a Sprint, including the Sprint Goal being unachievable, are not given. Scaled Scrum frameworks also don't mention Sprint cancellation. The word "cancel" doesn't appear in the Nexus Guide, although since Nexus is Scrum, it may be implied that the Product Owner can cancel the Sprint if the Nexus Sprint Goal becomes obsolete. The LeSS framework and the Scrum@Scale Guide also do not mention cancellation, and it's harder to draw conclusions based on the relationships between teams, Sprints, and Increments in these frameworks.

The first question is: Does cancellation make sense?

Cancellation implies that the Sprint ends. In Scrum, when one Sprint ends, the next Sprint begins with Sprint Planning. I'm not sure this makes sense in a single-team environment, much less a scaled environment where multiple teams are synchronizing their events with each other and with external stakeholders.

As recent as the 2017 Scrum Guide, Sprint cancellations were described as "traumatic to the Scrum Team". In environments where you want highly motivated people, you want to avoid traumatic experiences. Although this terminology was dropped in the 2020 revision, I don't see how it doesn't apply today.

The Scrum Guide also doesn't say what happens when a Sprint is canceled. The Scrum events happen on a cadence. If the Sprint is canceled, there is no guidance for what the Scrum Team should do between the cancellation and the next Sprint Review, Sprint Retrospective, and Sprint Planning. If the cadence begins with an immediate Sprint Planning, the team will either adopt a new cadence (which may or may not work for stakeholders, who especially need to be involved in Sprint Review) or plan a short Sprint.

In my experience, having cadences is valuable. This is true in Scrum, scaled Scrum, and SAFe. Any action that would change the cadence should be avoided. This means that "canceling a Sprint" really means "pausing and refocusing the work". The team(s) affected either stop (and throw away) or wrap up any work-in-progress, depending on whether that work remains useful and valuable. They use the rest of the time in the Sprint to reorganize and refine the backlog and prepare for the next Sprint (and, in SAFe's case, the rest of the PI). The regularly scheduled Sprint Review (and, in SAFe's case, the System Demo and Iteration Review) would be a good time to synchronize with key stakeholders from outside the team to ensure their backlog reflects the current understanding of the state of the world and plan the next steps. and the Sprint Retrospective would be a good opportunity to understand what happened and if it is possible to detect and adapt earlier. Depending on the amount of effort needed to prepare the backlog, this could also be a good time for the team to pay down technical debt, do any kind of tool improvements, or pick up training and personal improvement.

Is this true to Scrum or SAFe? I'm not sure. However, I believe it more closely aligns with the reality of work. When something so disruptive happens that it invalidates the current plan, it's good to take some time and organize the pieces for the future to set up for longer-term success.

Answer 2

Having said in the question that my experience may be too ad hoc to be valuable, I think it's actually worth presenting (which at least allows for critique, but may also present options for others who find themselves in similar situations).

I've actually experienced iterations that have gone off the rails by the halfway point (of a two-week sprint) in two different ways:

Goal became unachievable

In this instance, all the work turned out more difficult than expected. Stories took more effort to develop, and the testing exposed necessary rework and some latent issues that had been lurking for months or years.

The action in this case was to:

1. Pause the sprint.
2. Spend half a day in an emergency Backlog Refinement, capturing the newly-exposed tech debt and any deferrable rework into new stories¹.
3. Put everything back into the product backlog and re-prioritise it all.
4. Repopulate the remaining half-sprint and the subsequent iterations.
5. Re-start the sprint, with unchanged Iteration Goal (which will be only partially achieved)
6. Inform the ART what happened, and communicate the expected effect on PI Objectives (changed timescales and/or scope). Confirm this at the next ART Sync event.

This set of actions allowed work to continue with the existing cadence; notably, no retrospective or iteration review was held during the re-plan - those happened at the usual times.

¹ Stories created after PI Planning are labelled as such in our ticket tracker, so we have visibility of how much this happens in each PI.

Goal became irrelevant

When we found that the team was working towards the wrong thing, the Iteration Goal was no longer appropriate or useful. Large sections of planned development needed to to be replaced with a different approach.

1. Stop the sprint.
2. Inform the ART that we have a problem, and that we will be formulating a new plan to deal with it.
3. Hold a retrospective on the half-sprint.
4. Remove all the irrelevant work from backlog (including future planned iterations) and add stories for the newly-discovered line of development.
5. Hold a "mini PI Planning" for the team to create a new plan for the rest of the PI (starting with a short iteration to re-synchronise with ART cadence). Stakeholders and other teams' representatives were asked to be available to join as needed.
6. Commit to the new PI Objectives created in the mini-planning.
7. Start the new half-length sprint (with its newly-created iteration goal).
8. Inform the ART of our new plan and objectives, and confirm at ART Sync.

Again, by restarting with a half-length iteration, the team was able to maintain synchronisation with the rest of the ART.