Sprint Goals for Scrum Teams: Creation and Implementation Best Practices
Why do we use sprint goals? How are they beneficial for scrum teams? How do we come up with a “good” sprint goal? How do we know our sprint goals are keeping us on the right track? How should a sprint goal affect our sprints? The answers to these questions can help us change our approach to creating and implementing sprint goals and better collaborate in order to make the best of them.
In this blog post, I am going to share some lessons I have learned after several years of working as a quality engineer in agile teams and then making a career jump to the Agile world. By the end of the article, you will have learned several best practices for writing and implementing valuable sprint goals for scrum teams that you can use for the betterment of your organization and its products.
Defining Sprint Goals
A team will not have enough tools to come up with a sprint goal if there is no context of the immediate and long-term future. The sprint goal is another aid we use to ensure we are on the right path and that we are all on the same page regarding the focus we should have during the sprint. To come up with a sprint goal, we need a general understanding of the purpose of the things we are trying to build and deliver each iteration. This understanding comes and rises from constant communication, so that when we come to sprint planning we all are clear on what our goal for this sprint is and, more importantly, why that is the goal.
In my experience, a great approach to start defining a sprint goal in planning is by asking: “What are we going to focus on accomplishing during the sprint?” The reasoning behind this is that, for some sprints, the main focus may not be clear enough, or we may have several things we are trying to accomplish all at once. But no matter the scenario, there is generally one thing that holds the higher priority. Setting goals will allow us to stay lined up with that priority and will be the guide that the development team follows during the sprint to ensure we are on the right path. When needed, we will adjust our efforts accordingly during the sprint to meet that goal.
How we define the priority is the result of three practices:
1. The development team and product periodically discuss and agree on the priorities for delivery of value and usable code for each iteration: During sprint reviews and planning, we review delivered work and upcoming work; this conversation helps ensure we are on the right track. How do we know which is the right track? It is defined by the outcomes, epics, and bigger milestones that our stakeholders and product define for us.
2. The development team and product discuss and/or build the roadmap of larger milestones (outcomes and complete features) and have the necessary discussions to understand what it takes to get there: When we are thinking about our sprint goals, we are also thinking about what we will need to make ensure we meet our larger commitments. We often ask ourselves, “what is the higher level of value our constant delivery will achieve?”
3. The development team and product construct and prioritize engineering objectives that enable the delivery of value without jeopardizing quality: We know that infrastructure, tech debt, quality, and maintenance are also part of our sprint work and should be considered when we are discussing what the priorities of a team should be each iteration.
Understanding the ‘Why’ behind the iteration
It is important for the team to define what tools, conversations, and ceremonies work best to ensure transparency and that everyone (development team, product, stakeholders) is aligned with the priorities and the ‘why’ behind the work. For example, project kick-offs, quarterly planning, sprint planning, and daily stand ups are all methods or ceremonies that we can use to discuss the “why” behind what we are doing. A team that understands this will have the necessary input to help define what the sprint goal should be to ensure we are really delivering the value expected from stakeholders and users.
During planning sessions, our scrum teams write the sprint goal collaboratively. Sometimes the product team has a very clear goal on value delivery, so they guide the rest of us; sometimes the development team has a clearer vision of what we need to accomplish in order to deliver the value expected by product, so they guide the setting of the goal; sometimes we cannot deliver immediate “value”; but if we all know what we are trying to achieve and why we are trying to achieve it, then we can collaborate together to set that focus and path so we can consider that closing this iteration and meeting the goal will get us closer to success. It is important for a development team to understand what the value of what they are delivering is. It is also important for a development team to understand why that delivery is considered valuable.
Let’s consider a project starting with no infrastructure. We first need to lay down the infrastructure and bases to make sure we can start delivering usable code as soon as possible. That infrastructure, any research, any environments, etc., would be the value we will try to deliver that iteration. It may not be viewed as immediate value, as it is not something our users can interact with or see, but it will allow us to start building the feature that, in the end, we want to send to the users.
The content of a sprint backlog will always change, so the goals for a sprint should consider our bigger goals and milestones. By understanding the ‘why’ of the things we are doing during the sprint, we can call out priorities and goals that will help us accomplish these milestones.
Some tips that have worked with my teams when writing and using sprint goals:
• Keep it short! One sentence should be enough.
• Check confidence. Before committing to a sprint plan and goal, ask the team if they have confidence that they can achieve the goal. An exercise I like to do is “The fist of five”: zero being no confidence at all and five being absolute confidence that we can meet the goal. If someone has a confidence lower than 4, we can ask if there is anything we can do to help raise that confidence, or if there are any risks around meeting the goal that we need to address.
• Make it visible during the sprint. Use daily stand-ups to discuss progress towards meeting the goal. Celebrate with the team if we meet the goal. Address risks and concerns on time and find solutions to help us meet the goal. Don’t wait until the end of the sprint to ask if we met it or why we didn’t meet it if we had so many opportunities to try and adapt during the sprint.
• If we don’t meet the sprint goal, inspect and adapt. What can we do better next time? Why didn’t we meet our goal?
• If possible, make it measurable. You can try using the SMART goal framework (Specific, Measurable, Attainable, Relevant, and Time-bound).
• As often as possible, sprint goals should be value-focused.
Of course, there will always be scenarios in which these practices or ideas won’t work as well. But in those cases, we continue to inspect and adapt in order to do what is best for our teams. We are using sprint goals because we have harvested a lot of benefits from them and, as teams, we have matured our planning processes thanks to the questions we asked when planning sprints and goals.
Benefits of Sprint Goals for Scrum Teams
Some of the benefits our teams have experienced from using sprint goals and their best practices have been:
• Increased productivity: The team works towards the same objective.
• Helps focus daily stand-ups: We are checking on daily progress but also on our objectives to make sure our daily progress is aimed right.
• Cohesive feature development
• Efficient decision-making: When priorities are clear, decision-making is easier.
• Helps stakeholders understand the aim of the sprint and the progress of the development team
• Gives a reason to celebrate!
• Helps team focus on a common goal instead of individual stories: Collaboration increases as the development team work together to make sure they achieve their goal; it is not about, “I am done with my part of the work.” Rather, it is about, “what can I do to make sure we meet our goal?”
Keep in mind that sprint goals are not:
• “Complete these 10 stories”
• The sum of all the work in a Sprint
• 2-week-long to-do lists
• Doing as much work as possible
• Making sure you’re 100% busy
To summarize, a good sprint goal can be built when we practice collaboration and communication between product and development teams, sustained by a strong understanding of the ‘why.’ We can ensure a sprint goal is valuable by following up on it during our daily scrums and learning from our process. Collaboration between team members and product is enhanced when teams come up with the sprint goals together and agree on committing to them during sprint planning. By having clearly defined sprint goals that guide our sprint focuses, stakeholders will have greater visibility and the development teams will have a better understanding of priorities, making the decision-making process a lot easier for everyone involved.
