2

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)?
Improve this question
4
  • 2
    Huh? If you are building a house and you fail to place all bricks on time, you just delay the construction. Sure, the guys in charge of the roof frame will yell at you because they'll have to delay their work, too, but you are not going to abandon the concept of "last row of bricks" just because you failed to deliver it on time. And yes, handling this problem is probably not going to fit in whatever methodological framework you happen to be using - you'll have to be creative!
    – user44761
    Dec 10, 2015 at 9:30
  • 3
    @steven-burnap answered your question well, but I want to point back to the large story as a likely root cause of the issue here. One of the most common problems i see in Agile implementations is not learning how to break stories into smaller parts. It's very hard and requires lots of experience and creativity. It should be exceptionally rare (a few times per year) that you let a story be so large that it endangers a sprint. Some of Mike Cohn's books are really helpful in learning how to decompose a story.
    – pbristow
    Dec 10, 2015 at 14:22
  • 1
    @tibo You're right, but I think he can be forgiven for the suggestion... unfortunately I've seen quite a few primers on agile and scrum that make it sound like you're supposed to throw out the baby with the bathwater on a failed sprint. It's just bad authorship and honest misunderstandings, but unfortunately this confusion persists.
    – pbristow
    Dec 10, 2015 at 14:25
  • Use Kanban. No timebox, so problem solved.
    – RubberDuck
    Dec 11, 2015 at 0:46

3 Answers 3

Reset to default
7

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.)

Improve this answer
3
  • 3
    I would say it's an antipattern to split work like this.
    – Marcin Rybacki
    Dec 10, 2015 at 9:20
  • Regarding your last paragraph: how to prevent teams from doing this? I have seen this done on a regular basis, partly due to the pressure created by the sprint system itself: you have to have a shippable product at the end of each sprint or, in other words, you have to show your work to product owner(s) and customer(s). So you want to make what you have achieved visible. Also, at the end of the sprint you have better knowledge about how to split work than at the beginning, so what's wrong with this practice?
    – Giorgio
    Dec 24, 2015 at 9:59
  • Unfortunately, that's not something that agile itself can solve. It's a management issue. Teams that do this need to be called in it.
    – Gort the Robot
    Dec 24, 2015 at 21:57
3

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:

Day in the life of a 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.

Improve this answer
2

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.