As a leader in a tech organization, getting up to speed with the many items in the lexicon of agile might feel daunting. Sprint, sprint velocity, daily stand-up…so many concepts to learn, understand and implement. This post is another contribution of ours to make your agile journey easier. We’ll be answering a seemingly simple question: When should a sprint goal be created?
If you’re only interested in the answer to this question, you can directly go to the appropriately titled session “When Should a Sprint Goal Be Created?” But if you’re curious about sprints in general—and I bet you are—you’ll enjoy reading the entire post, since it will cover the concept of a sprint goal in greater detail.
We’ll start by defining sprints themselves, explaining why sprints exist in agile and what role they play. With that out of the way, we’ll move to the more narrow topic of sprint goals. You’ll understand what sprint goals are, why we need them, when they’re created, and who’s responsible for doing so. Let’s get started.
The Basics About Scrum Sprints
Understanding sprints themselves before moving on to sprint goals is a good place to start.
What Is a Sprint in Agile?
Agile software development methodologies have interesting characteristics that set them apart from traditional, waterfall-like development. One such characteristic is that development happens not in sequential phases but in short, iterative cycles. “Sprint” is the name the scrum framework gives to the short, iterative cycle in which development works.
Scrum is the most popular and successful agile flavor that has sprung into existence since the early nineties. Due to this success, the scrum vocabulary has been adopted and applied even to contexts and projects that don’t use this particular framework.
What Is the Purpose of a Sprint?
As we’ve mentioned, “sprint” is simply the name that scrum gives to the short cycle in which work happens in agile. So, a better question would be “What’s the purpose of working in short, iterative cycles?”
The whole spirit of agile can be summed up in four steps:
- You do a little bit of work.
- Then, you reflect on the work you did.
- You use what you learned upon reflection to course-correct and improve your work.
- Repeat.
When you work in short cycles, you start each of them with a planning phase. Similarly, you end each cycle with a reflection session in which you review your performance and decide how you can use what you learned to improve the process.
What Should the Length of a Sprint Be?
According to the scrum guide, a sprint is a fixed-length event and its duration is one month or less. Nowadays, it’s common for scrum teams to adopt two-week or even one-week sprints.
It’s interesting that the scrum length has been updated over time. Older versions of the guide stated that a sprint could take up to two months. But as time progresses and teams and organizations mature in their understanding and skills related to scrum, they become more comfortable with shorter cycles.
Sprint Goals: The What, Why, and How
Having covered the basics about sprints, we’re now ready to move on to sprint goals.
What Is a Sprint Goal?
A sprint goal is exactly what its name suggests: It’s a goal for a given sprint. The sprint goal is the result of the product owner and the development team collaborating together. The resulting document, among other things, communicates to stakeholders what value will be generated by the sprint.
The scrum team meets the sprint goal by implementing the features prioritized by the product owner during the sprint. At the end of the spring, during the Sprint Review, the Scrum team will compare what they achieved to the sprint goals to gauge the success of a sprint.
Why Do We Need Sprint Goals?
The sprint goal is all about communication. As we’ve said, one of the use cases of a sprint goal is to communicate to the stakeholders why that sprint matters and how it will make the project closer to the product goal.
Here are a few more reasons why a sprint goal is valuable:
- It helps in the execution of the daily scrum. A shared sprint goal helps the team members remain focused during the daily scrum meeting.
- It provides focus and teambuilding to the development team. The sprint goal can also give the development team focus during the sprint, besides encouraging teamwork.
- It allows some degree of autonomy to the developers regarding the actual functionality delivered during the sprint. The PBIs that get implemented during the sprint (i.e., the sprint backlog) are less relevant than the sprint goal being met. If the need arises, the items can be renegotiated with the product owner.
- It helps the product owner with release planning and product roadmap. Sprint goals are a big help to product owners. They enable them to have a clear vision of where the project is going, which is immensely valuable when it comes to creating product roadmaps and when planning releases.
Who’s Responsible for the Sprint Goal?
Who’s responsible for the sprint goal?
One could argue it’s the project’s stakeholders. After all, they’re invested—literally—in seeing the project succeed, acquiring more value with each sprint. On the other hand, you could say that’s a job for the product owner. After all, it’s their literal job to make sure the scrum team generates the most value with the project. Finally, the development team itself is a good candidate, since they’re the ones doing the work to add value to the project sprint after sprint.
So, who’s right? As we’ve mentioned before, the sprint goal is the result of a collaboration between the PO and the development team. The product owner starts by communicating the ways in which the project can generate more value. The PO and the development team then work together to create a plan that communicates how that value is going to be reached. That’s the sprint goal.
In other words: The PO and the development team create the sprint goal together for the project stakeholders.
When Should a Sprint Goal Be Created?
The development team and the PO create each sprint goal before starting the actual work for the sprint, during sprint planning. The sprint planning meeting is the event that effectively starts each sprint. During this meeting, the first topic discussed is the value of the current sprint.
By the end of the sprint planning, the sprint goal must be finished.
Sprint Goal vs. Sprint Backlog
The sprint goal is often confused with another of scrum’s artifacts, the sprint backlog. It’s a common misconception, but those are two different things.
The sprint goal is the why of the sprint. Its objective is to answer the question “Why are we doing this?”
The sprint backlog, besides answering the why by incorporating the sprint goal, also answers the what and how. It contains a list of the pieces of functionality (product backlog items) the team has agreed to deliver on that sprint. The PO and the development team collaborate in the creation of this list. This is the what.
The sprint backlog also contains a detailed plan showing how the development team will turn the selected items into value for the project. This is the how.
In short, it’s a simple equation: Sprint backlog = sprint goal + list of selected items + plan for how to implement them.
Sprint Your Way to Your Software Development Goals
If you don’t know where you’re going, it’ll be harder to get there. That’s why having clearly defined goals are so important, not only in life but in software development as well.
Agile software development is all about defining goals that deliver the most value and then working efficiently to meet those goals in a sustainable and adaptive way. In this post, you’ve learned more about the sprint goal, and not only when you should create it, as the post’s title promises, but also what it is and why it matters so much.
Are you interested in learning more about agile and software development projects in general? Well, you’ve made it this far, so I guess you are. If my guess is correct, you might want to give the Dev Interrupted Podcast a try. The podcast offers a great opportunity to learn from the experience of real engineering leaders.
