What happens if Sprint Goal is not met?

Question

I've been reading Scrum Guide and one part is missing for me. What happens if Sprint Goal is not met at all? Let's say the Sprint Goal is a big part of a functionality which cannot be broken into parts further so devs have, say 2 weeks (the Sprint duration) to accomplish it or not, but they fail to do it. What happens with this functionality?

• Should it be tossed away? (unlikely)
• Should it be continued in the next Sprint? If yes, doesn't it break the rule of creating an Increment of potentially releasable product in each Sprint and also the rule that the duration of Sprint is fixed (technically the rule will stand but practically there will be a Sprint of 4 weeks)?

Answer 1

The sprint goal should be placed back into the backlog and then reevaluated along with all the other stories in the backlog. In most cases, this will mean it will be prioritized to the top of the backlog and pulled into the next sprint. In theory, if business needs have changed since the backlog was last prioritized, it could be left for a later sprint or even thrown out. But the key concept is that it is just treated like any other story in the backlog.

If this happens often, you need to reevaluate how you are writing stories as this means you may not be creating fine-grained enough stories to be finished in a single sprint. But the vagaries of development mean that it will happen from time to time to even the best team.

(I have seen some teams react to this situation by splitting the story into two at this point, the first being the work that was completed and the second being the new work required. I dislike this because I think it makes things look artificially good after-the-fact.)

Answer 2

It sounds like you say "Sprint Goal" and mean "a really big bit of something the product needs to do that it currently doesn't." This can be a separate discussion of how to craft better Product Backlogs including Epics, themes, story maps, etc.

For now, here are things to focus on improving:

1. Gain better understanding of Sprint Goal
2. Spend time removing impediments to decomposing work into more manageable sizes
3. Craft Sprint Goals based on work that can be accomplished in a single Sprint

I can help you with #1 :D

First, the Sprint Goal does not exist in the Product Backlog. Per the Scrum guide, a Sprint Goal is

...an objective set for the Sprint that can be met through the implementation of Product Backlog.

The Sprint Goal is crafted by the whole Scrum team (read: Product Owner, Development team and Scrum Master) after the Development team forecasts the work it can get done in the coming Sprint. The Sprint Goal may then be understood as:

...an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Here's a visual representation of how a Scrum Team might handle forecasting work from their Product Backlog, form a Sprint Goal, react to unforeseen work, and still achieve their Sprint Goal:

If the Product Owner is unable to define work in the Product Backlog for which the Development Team can forecast completion in a Sprint, do not say/do the following:

• Lengthen the Sprint
• Say, "Scrum just can't work here"
• Take work into the Sprint that the Development Teams cannot finish

Ironically, shortening the Sprint (Product Owner decision) will many times force Scrum Teams to find innovative ways of producing smaller chunks of valuable, working software.

Instead, ask "what would need to change?" This constructively leads discussion towards the art of the possible which in turn inspires us to work for change.

Take only work into a Sprint that the Dev. Team thinks it can accomplish. Doing otherwise invites death marching (shudders).

Producing working software in 30 days or less is one of the most important aspects of agility that Scrum teachs. Please consider making these improvements a top priority for the health of the team and the organization.

Answer 3

I think this should be discussed and post mortem'ed in the Sprint Retrospective. Conclusions regarding the sprint goal will obviously vary, but ultimately the decision to give it up or carry it over to the next sprint should belong to the Product Owner.