User Tools

Site Tools


What is the Purpose of Sprint or Iteration Goals?

Or “Why don't we just say the Sprint Goals the list of stories that we commit to?”

Or “What is the difference between establishing the Sprint Goals and committing to a list of Stories?”

Or “What is the purpose of PI Objectives?”


Teams should establish Sprint (or Iteration) Goals during Sprint (or Iteration) Goals Planning. The purpose of Sprint (or Iteration) goals is to:

  • Increase transparency by being clear about what we are delivering by restating the incoming requirements (user stories) in terms of the desired business outcome we expect to get
  • Help the team understand the purpose of the Sprint (or Iteration) and so increase engagement (remember the Drive video)
  • We are focused on delivering business value / outcome and so setting goals provides flexibility to the team in how they deliver the business outcome.
  • They provide context against an overall plan. Most Sprint (or Iteration) Goals should be couched as a stepping stone aimed at meeting the team’s Release (or in the case of a SAFe implementation) PI Objectives.
  • It closes the feedback loop. In many ways the user stories represent a “wish” from the customer. By having the Team restate the expected outcome from their perspective it helps ensure common understanding and helps manage expectations.

Note that a lot of the discussion here is also related to PI Objectives. In many ways PI Objectives are like “Uber-Sprint (or Iteration) goals” in that teams development for an entire Program Increment length of time rather than just a Sprint (or Iteration). Reading below if you see “Sprint (or Iteration) goals” you can substitute “PI Objectives” and for “stories” read “features”.


The idea that a Sprint (or Iteration) Goals “provides flexibility” is often a stumbling block for new teams. Many teams do not differentiate between the user stories they are committing to in a Sprint, and the Sprint (or Iteration) Goals. The Sprint (or Iteration) Goals should not just be a restatement of the user stories. Often it is a summary of the stories, combining a few together, but that is a side result, not the purpose of the goals.

One of the main ideas behind having Sprint (or Iteration) Goals is that it gives the team a degree of flexibility on how they meet those goals. For example, if the team finds that a user story they have in the Sprint does not make sense because of something they have learned, then the team can make adjustments (delete user stories, make new stories) and still meet the Sprint (or Iteration) Goal. Can anyone say “decentralized decision making?”

One question that is often asked is “why don't we just say its the list of stories that we commit to”. There are a couple of problems with this approach:

  1. In order to set expectations with our stakeholders, we need make sure we isolate the “wish” for something from what value the team expect’s to be able - their understanding of what they deliver. While the goal might be a direct reflection a story, the act of re-writing ensures there is reduced opportunity for “but this is what the story said”-type finger pointing. The goals help ensure that everyone is on the same page about expected outcomes.
  2. The problem is that often we focus on success being “we delivered the stories”. With an agile approach we want to focus on a business outcome the goals should be written in the form of a business outcome that is understandable by all. In some situations “delivery stories” may not in fact mean you have delivered the desired business outcome. As we learn more we can make adjustments to the plan based on our understanding of the goals and ignore the initial planned work if that makes sense to do. Here is the cool thing - the team can make that call because they have a clear understand of the desired outcome.

The goals can also include other things such as “improvements” the team is expecting to do. For example, you’ll often see things like “develop initial working agreements” or “learn how to work as a team in agile” in the first Sprint (or Iteration).

As a final note, especially with respect to the improvement goals. You'll want to be clear about “how you will know you have achieved these goals”. For example, what does it mean to “learn how to work as an agile team” in this first Sprint. Perhaps the measure is “team thinks we are better prepared for the next Sprint” or some such and before your Sprint (or Iteration) Demo you have a quick survey (Fist of Five vote?) to validate, but you want to be able to say “we’ve met this goal” in some way.

Want To Know More?

/home/hpsamios/ · Last modified: 2020/06/02 14:21 (external edit)