Iteration goals include a top summary of the technical and business goals that a team agrees to achieve in an iteration. An iteration goal should reflect the following: technical or business milestones architecture, feature slices, compliance activities, exploration, infrastructure, and other things, like refactoring, documentation, and maintenance. Iteration goals are accomplished by finalizing backlog items, even if it may be unnecessary to complete every story to achieve the goals. In essence, iteration goals supersede any particular story.
A sprint goal is a top summary of the goal a business owner would love to achieve in the course of a sprint. This is commonly elaborated by using a specific set of backlog items for a product. A sprint goal is usually short, maybe one- or two-sentence note describing what the team wants to accomplish during the sprint. It is written by the team in collaboration with the product owner. A sprint goal provides the team with a shared goal by showing the anticipated outcome of an iteration. It also helps the team focus on accomplishing a goal by showing them which goal has to be defined before the sprint starts. Ideally, having one goal for every sprint will help ensure that everybody is on the same page. Once a goal has been chosen, it has to be implemented by the team. However, firstly, it is important that the product owner clearly defines the goal of a sprint, then the team implements it to create a “Product Increment,” and lastly, the stakeholders validate the goal and give feedback.
Typically, Sprint goals are defined at the initial stages of the Sprint Planning Meeting. The main steps include:
Although it is easy to have a set of backlog items to work on during a sprint, however, it is a bit more difficult (yet more valuable) to have a bunch of backlog items that fit perfectly. Having a set of well-fitting backlog items provides more business value. The merits of having a sprint goal include:
A sprint goal, just like any operational goal, should be SMART, that is: Specific, Measurable, Attainable, Relevant, and Time-bound. Naturally, every sprint goal is time-bound because sprints are normally time-boxed iterations. This means that the goal has to be accomplished at the end of the sprint. By using a Specific and Measurable sprint goal, you can determine success. Being specific requires that you are explicit about the purpose and type of the goal. For instance, you shouldn’t just write “develop a model” as a sprint goal. Instead, write “develop a paper model of the user signup feature to test the interaction ideas of our users.” Performing sprint planning activities will guarantee that a sprint goal is attainable. Usually, this means choosing user stories that are needed to achieve the goal until the team’s capacity has been exhausted. Sprint planning enables the team and product owner to understand if a chosen goal is achievable. This aids you in calling the appropriate stakeholders and be assured that they can give meaningful feedback. Impractical sprint goals waste the time of stakeholders and lessen their willingness to be involved in the process.
Setting great iteration goals is easier than you imagine. The best time to set your goals is at the start of each iteration planning session. By doing this from the onset, you can dictate the context for what the team will be addressing over the next iteration. Equally, the team is better equipped to choose the stories that will back the goal. When setting your goals, it is important to remember that the best goals are usually specific enough. This means there is no ambiguity, neither is there a constrain to the flexibility of the team to adapt their iteration plan when deciding the best way to achieve the goal.
You may ask yourself where iteration goals come from? When setting an iteration goal, a lot of people are tempted to just choose stories as a norm during the iteration planning phase and then simply get an iteration goal out of any similar patterns they see in such stories. Although, initially, this method may appear better, however, it usually results in vague iteration goals that barely define the least common theme in every selected story for that iteration. This makes it difficult to quantify whether completing the goal added any value to the organization or whether the goals were even achieved at the end of the iteration. In essence, you should start by reducing your goal into iteration-sized chunks. This makes each chunk the starting point of the iteration goal.
Setting clear iteration goals gives your team the understanding that their work in each iteration is a fragment of something bigger. This will not only equip them in making better-informed technical decisions in the course of the iteration, but it will also provide them with valuable insights into the product’s overall vision and how they are contributing to that achieving the vision.