As a Scrum Team, we are committed to deliver Product Backlog items per the Product Owner's priority. The team doesn't understand why we should define Sprint Goals. How does that help?

  • It's not clear to me what you're asking. Is the "goal" in addition to the tasks promised for delivery in the course of the sprint, or in place of them? Commented Nov 27, 2017 at 21:03
  • 1
    @JonKiparsky - in Scrum, the user stories committed to a Sprint are advised to have a unified Sprint Goal. In ecommerce scenarios this can be quite easy (we are building a shopping basket function) but in more layered or Enterprise teams it can be challenging to weave a coherent Sprint Goal from disparate stories (3 bug fixes, data migration and two new Features etc) . The Sprint Goal supports the idea of a Product Increment. Commented Nov 27, 2017 at 21:21
  • 1
    Huh. Never saw that on any team I've worked on. Learn something new every day, I guess. Commented Nov 27, 2017 at 21:23
  • 1
    A lot of teams don't do it. I personally binned it off unless the delivery is very singular its technologies. However it is in the Scrum Guide. "The Sprint Goal is 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." However, it feels like a bit of a crutch for the PO to not articulate the value of each story. Commented Nov 27, 2017 at 21:30
  • 2
    @ToddA.Jacobs Thanks for making questing easy to understand
    – ssharma
    Commented Nov 28, 2017 at 5:41

4 Answers 4



You must define a Sprint Goal for each Sprint for two primary reasons:

  1. It's required by the framework for both philosophical and pragmatic reasons as described in the subsequent sections.
  2. It provides a focus for limited resources within Scrum's iterative methodology.

While it is possible to be agile without a central coherence as provided by the Sprint Goal, the result isn't Scrum. Furthermore, Scrum (or other coherence-based methodologies) may not be the right fit for your organization or project if Sprint Goals can't be constructed or honored.

Why the Sprint Goal is Needed

The Sprint Goal is an essential element of Scrum, which is primarily (although not exclusively) a product development framework. As such, it is intended to iteratively deliver features, as opposed to other frameworks which focus on other mechanics such as throughput or cycle time. Because of this development-centric focus, work is intended to be batched into cohesive themes for each iteration.

If you are "doing Scrum" without setting well-defined Sprint Goals, then you can't actually claim to be following the Scrum model. This isn't just a philosophical distinction. The Sprint Goal is essential to a properly-implemented Scrum framework. The Scrum Guide defines the Sprint Goal as follows:

Sprint Goal

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

In other words, the Scrum Goal provides:

  1. A measurable objective for the time box.
  2. Context (and therefore scope) for the Product Backlog Items developed within the time box.
  3. Context for the daily Scrum, without which it typically devolves into status reporting.
  4. A baseline expectation for measuring variance.
  5. The essential criterion for cancelling a Sprint due to superseded business goals, adaptive learning, or as an escape hatch for errors in Sprint Planning or delivery.

In my professional experience, without the Sprint Goal as a core element, Scrum often fails to provide expected gains in productivity.

Reasons People Try to Skip Sprint Goals

Teams that don't implement Scrum Goals often do this for some common reasons, including:

  1. They aren't really doing iterative time boxing.

    If you aren't respecting the time box, or the team is doing demand-based work rather than building features within a time box, then having an over-arching goal probably doesn't make sense. However, that's often a "project smell" that Scrum is the wrong framework for managing the project.

  2. The team, and especially the Product Owner, isn't leveraging the framework.

    Scrum is meant to deliver a product in thin, preferably-vertical slices of functionality. However, there's a lot of effort that goes into prioritizing Product Backlog into features and related stories that fit within a single time box. It's hard, so skipping the Sprint Goal is essentially a cop-out.

  3. The 100% utilization fallacy and lack of prioritization.

    Some teams, when under pressure to deliver more work in less time, discard the Sprint Goal in order to work on multiple objectives at the same time or to avoid slack in the process. However, deliberate disconnection of a central coherence and multiple priorities competing for limited resources are sure-fire ways to torpedo any possible efficiencies from an iterative methodology.

I'm sure there are other reasons, too. The point here is that, unless you're using Scrum for something other than product development (e.g. administrative or service-oriented programs), failing to define and defend a central coherence is not only canonically-wrong from a framework perspective, but frequently detrimental to the project's allocation of focused resources. This notion of focused (but limited) resources is absolutely essential to the iterative paradigm, and underlies virtually all agile and traditional methodologies. Scrum just makes it much more explicit through the use of the Sprint Goal.

What Next?

If a team is struggling to define coherent Sprint Goals for each iteration, the Scrum Master can and should educate the team (and the organization!) on the importance of setting and adhering to the goals. This should be done not only because it's important to the Scrum framework, but because it is ultimately important to the product development effort.

If the Scrum Master isn't able to provide this level of guidance, or doesn't have sufficient influence within the organization to enforce the framework's essential components, then hiring an Agile Coach to advise the team would be the logical next step. The coach can help the team improve the implementation of Scrum, or suggest alternative frameworks that can succeed without an explicit central coherence for each time box.

  • When to define sprint goal? Define the goal first and then pick stories or pick stories then define goal?
    – ssharma
    Commented Nov 28, 2017 at 6:05
  • 5
    I'm sorry. But your post tells me nothing beyond "because Scrum says so and it's bad(tm) if you don't". Sure it's nice if you can summarize the work to be done under a catchy goal. But I'd really like to know why it's supposedly so terrible if we don't...
    – Kempeth
    Commented Nov 28, 2017 at 8:12
  • I have to agree with Kempeth, my first reaction to his TL;DR item: "...because it is required by the framework...," is unsettling, especially to readers who are generally skeptical of new software development methodologies & frameworks. I think we need to look a bit deeper into what sprint actually is - and that is a concerted effort to produce a 'potentially shippable' product increment within a given timebox. What are the key things the team has to do to present that potentially shippable increment? 3-5 things max. User stories are much more granular. Goals are a summation of intent. Commented Dec 19, 2017 at 18:19
  • @ssharma Generally defining the Sprint Goal and forecasting the Product Backlog items go hand-in-hand. Since the Product Backlog is ordered, the next most valuable features should be near the top. Evaluating the Development Team's capacity and the Product Backlog item estimates provides the other input. Commented Feb 9, 2018 at 2:41
  • Defining the Sprint Goal is less complicated with shorter Sprint lengths because the effort must be more focused. Commented Feb 9, 2018 at 2:42

A sprint goal is a short description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner. So it helps the PO and the team to choose the right set of tasks to work on.

For example the sprint goal is to enhance the application response rate to be one minute instead of five minutes.

So by knowing this you'll know as a team which tasks to work on to deliver the required goal.

  • surely the list of tasks promised for delivery are the tasks the team should work on, no? Commented Nov 27, 2017 at 21:25
  • Whilst this is true, personally, I think the Sprint Goal will eventually be deprecated by the Scrum Guide as it is one of the most onerous of things to try and contort out of a Sprint. Many deliveries have multiple aspects to them and trying to weave a Sprint Goal is more effort than it is worth. It also becomes a milestone deliverable for the PMO or Sponsor to beat the team. "What was the goal?" Well, it was to build the new Feature set. "Is it done?" We got 80% of the stories done and fixed a few bugs. "So the Sprint Goal was not accomplished. Got it. Will tell SteerCo". Commented Nov 27, 2017 at 21:27
  • "80% of the stories done" means the sprint "failed", regardless of any goal. (My team is reconsidering the use of "fail" here, since correct use of scrum means you're going to "fail" about half of the sprints, but that's another issue) Commented Nov 27, 2017 at 21:31
  • I don't consider that a fail; but for those working with non-Agile evangelists a Sprint Goal can very quickly become a way to hang yourself. "You said the widget would be fixed in Sprint 17. Is it fixed?" You said that the gibbet would be developed in Sprint 21 and it wasn't..." etc etc. I coach PO's to use non-quantifiable words. "The Sprint Goal is to strengthen the current security in line with mandatory controls XYZ" etc etc. Like everything else in the Corporate environment, it simply becomes a game. Commented Nov 27, 2017 at 21:33
  • 1
    @Venture2099 Yes, traditionally the language is binary - either we make all of the points, or we don't. If we don't we used to say we'd "failed", which as I say was not communicating correctly what had happened, so now we've changed our language to communicate correctly. Commented Feb 9, 2018 at 4:37

Also the sprint goal is essential to be able to say that the sprint is done. Is the sprint goal not achieved the sprint is not done and therefore the sprint failed. In addition to that the sprint goal id necessary to be able to determine if the sprint has to be stopped. When the sprint goal becomes obsolete the sprint can be terminated.

  • 1
    Sprints are a unit of time, you cant terminate a sprint. You can only change the scope of the sprint.
    – Stephan
    Commented Nov 27, 2017 at 15:57
  • Yes you should change the scope of the sprint if you see that you miss the sprint goal. But if the sprint goal is obsolete you can stop the sprint because you will not generate value with the feature.
    – Krbch
    Commented Nov 27, 2017 at 16:18
  • 3
    I've never seen anyone suggest to stop a sprint early before. Sprints have always been a fixed amount of time, usually 2 weeks. If you complete a feature, great, if you don't, learn from it. But the sprint still completes at the 2 week mark, with or without your feature. If for some reason the only feature got cancelled, you pull in the next off the backlog and continue on. But I've never seen a sprint be of dynamic length in AGILE or any other methodology.
    – Stephan
    Commented Nov 27, 2017 at 16:31
  • 1
    @Stephan The Sprint can (and should) be terminated if the Sprint Goal can't or won't be met. This is explicitly described in the Scrum Guide. This is quite different from dynamic length, and is extremely common in shorter projects where pulling in stories--possibly even the wrong stories!--without scoping, estimating, and planning for a new goal works against the project's limited run-time.
    – Todd A. Jacobs
    Commented Nov 28, 2017 at 5:30
  • @Venture2099 What's factually incorrect? The answer itself, or one of the comments? I find support for everything user3285007 says above within the Scrum Guide, although I don't think the answer provided explains it very well.
    – Todd A. Jacobs
    Commented Nov 28, 2017 at 5:34

The concept of "sprint goal" in scrum is relatively new to me, but it sounds like it's there to help the stakeholders and product owner conceptualize the work they want to see in the sprint, and to communicate that concept to the engineering team. My team does not use this concept, but it sounds like it's more useful in larger organizations with smaller teams that can be devoted to a single-minded pursuit over a given sprint. For a team that is responsible for all of the organization's engineering work (like my team), this concept is probably not helpful.

  • 1
    What you're saying is true so far as it goes, but there's more to it than that. And Scrum is not designed for ongoing support work, although it can certainly be adapted to it—usually by looking like Kanban with some Scrum meetings and time boxing instead of continuous flow.
    – Todd A. Jacobs
    Commented Nov 28, 2017 at 15:30
  • Well, I'm not talking about support work. I'm talking about a team that's delivering on multiple fronts in each sprint Commented Nov 28, 2017 at 17:03
  • 1
    "Delivering on multiple fronts" is not really Scrum, and often isn't agile. At best it's a discounting of the cost of task-switching overhead and a failure to prioritize limited resources, and at worst it's a variant of the 100% utilization fallacy. Either way, while there are occasionally instances where more than one goal should be articulated, the lack of central cohesion is usually a "project smell" or a framework selection error.
    – Todd A. Jacobs
    Commented Nov 28, 2017 at 18:42
  • You work with the resources you have. We're a small company and don't have the luxury of many teams of specialized developers who get to just do one thing, and we don't have the luxury of spending a sprint on just one thing. It seems pretty scrum from where I'm sitting, but really can't be bothered to have the measuring contest you seem to be looking for. Commented Nov 28, 2017 at 18:50
  • 1
    From the Scrum Guide: "Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices." —It's fine if your process is working for you, but it's important to the agile ecosystem to understand that what you're describing is not formally Scrum. Definitions do matter, but I'm glad you're getting the results you want from your existing process.
    – Todd A. Jacobs
    Commented Nov 28, 2017 at 18:55

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