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

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

Or “What is the purpose of PI Objectives?”

Teams should establish Iteration (Sprint) Goals during Iteration (Sprint) Planning Meeting?. The purpose of Iteration (Sprint) 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 Iteration (Sprint) 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 Iteration (Sprint) 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. When Teams are functioning well the Product Owner will often have a set of Iteration (Sprint) Goals in mind as they come into the Planning meeting with a related set of user stories based on an understanding of the capacity of the Team to deliver, and as a result of conversations with the Team (for example, during the Backlog Refinement events) represent a “wish” from the Product Owner. By having the Team restate or update 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-Iteration (Sprint) goals” in that teams development for an entire Program Increment length of time rather than just a Iteration (Sprint). Reading below if you see “Iteration (Sprint) goals” you can substitute “PI Objectives” and for “stories” read “features”.

The idea that an Iteration (Sprint) 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 an Iteration (Sprint), and the Iteration (Sprint) Goals. The Iteration (Sprint) 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 Iteration (Sprint) 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 Iteration (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 Iteration (Sprint) Goal. Can you 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 updating or re-writing ensures there is reduced opportunity for “but this is what the story said”-type finger pointing. The Iteration (Sprint) 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 “delivered 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.

As mentioned, as the Team increasingly work together and trust each other, the Product Owner will often have a set of Iteration (Sprint) Goals in mind. The result of Iteration (Sprint) Planning in this case might actually only be a validation of these Iteration (Sprint) Goals rather than a re-write or creation activity during Iteration (Sprint) Planning. This is a good thing: we want our Product Owner to provide on-going vision and direction to the Team based on a solid understanding of the Team capacity. Note that this level of trust and understanding will take some time to establish and so in the first few Iterations (Sprints) the Planning event will be where these Goals are developed. No matter what, if the Team feels they are unable to meet the expectations of the Product Owner, they should push back and establish the Iteration (Sprint) Goals based on what they realistically expect to achieve. Its a negotiation, aimed at ensuring aligned expectations, where they Team decides how much they can take on.

The Iteration (Sprint) 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 Iteration (Sprint).

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 Iteration (Sprint). Perhaps the measure is “team thinks we are better prepared for the next Iteration (Sprint)” or some such and before your Iteration Demo (Sprint Review) 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.

Specifically on goals:

• For a scaled implementation basic guidance for Goals is provided at SAFe’s explanation of iteration goals. There’s also a shorter blurb on the SAFe site in the iteration planning guidance page
• What Should Our Iteration (Sprint) Goals Look Like?

Related to the idea of goals:

• How Do We Talk About Iteration (Sprint) Commitments That Have Not Been Met?
• Why Do We Assign Business Values to PI Objectives?