If you already know what a Sprint Goal is, skip this paragraph. Still here? Well, then. Allow me to explain what a Sprint Goal is before we talk about what a weak Sprint Goals are. Sometimes, software teams work in short bursts of anywhere from 1-4 weeks. These periods are called Sprints. During this time, they plan and execute in an effort to have something complete at the end of the Sprint. Part of this process is setting a goal for the team to achieve during the Sprint. This is called the Sprint Goal.
Do you have weak Sprint Goals? Are you skipping the Sprint Goals altogether? Ever ask yourself, “How do I know a Sprint is successful or done?” Well, you are not alone. I find the Sprint Goal to be one of the most misunderstood and misapplied elements of Scrum and similar iterative processes. What’s worse is that most teams who haven’t relied on Sprint Goals don’t fully understand the value in a good Sprint Goal. Who can blame them? Like most elements of agile processes, seeing is believing. So, I’ll try to show you the harder to see benefits of the Sprint Goal, some common pitfalls to avoid, and some suggestions on how to make weak Sprint Goals stronger.
The biggest value out of the Sprint Goal is context. In Scrum, and most agile practices, we borrow from Lean manufacturing ideals. One of those is separating value from waste and eliminating that waste. Many people think that Agile means we stop documenting. This comes from the stark contrast between the more traditional hundred-page design documents and user stories that can be fit on one index card.
There is an old agile joke about an Agile enthusiast who runs into an old friend at a conference. The friend says to him, “It’s so good to see you! I wanted to tell you that over the past couple of years, my company has undergone a total Agile transformation. We are 100% Agile now!” The man winces a bit, knowing that Agile transformations are journeys and are never finished. Seeking more understanding, he asks the old friend, “Really? That’s great! 100 percent, huh?” And the guy replies, “Yeah! We don’t document anything.” Jokes aside, a lot of the Agile processes culminate in reductions in waste in the backlog. After all, it is arguably the last end point before execution. The Sprint Goal is no exception.
The context that the Sprint Goal brings gives us the ability to read a simple User Story fit on one index card and understand, in the context of the goal, what we need to build to help achieve it. If you are having trouble with teams needing more details in their stories, they may benefit from more context. You can help refine this context at many levels by cascading this context through Product Vision, Product Goals, and finally Sprint Goals.
The Product Vision is the overall long-term goal of a product. This is what we want from our product. It should be inspiring and achievable. Product Goals are more of an intermediate goal for the product. What is the next big step for this product? Finally, Sprint Goals are what we want from this current Sprint.
This cascading goal structure should give all kinds of context, because the developer can know how the story they are working on contributes to the Sprint Goal and the desired outcome for the Sprint, which contributes to the Product Goal and our next step, and finally how that helps us realize our Project Vision. You can see how this would make a lot of what is typically found in a requirements document redundant or how weak Sprint Goals leave out a lot of crucial context.
Another benefit of a good Sprint Goal is transparency, and through it, accountability. Stakeholders can hold us accountable, but more importantly, we can hold ourselves accountable. When we publish our Sprint Goal, stakeholders know what to expect from the Sprint, and what to look for in the Sprint review. Also, our teams know what success looks like.
I frequently am asked, “How do we know our Sprint is successful?” I always say, ask yourself if you have met the Sprint Goal. I then like to drop the bomb that it is possible to not finish all the work items and user stories planned for the Sprint and still meet the Sprint Goal. Alternatively, it is possible to complete every item in a Sprint, and still not meet a Sprint Goal. This gets to a recently popular distinction of outcomes over outputs. We should focus less on the output of percentages or number of stories completed and try and focus on if we achieved our goal.
But what if that goal is crap? We all have seen weak Sprint Goals:
- “Do whatever Sales and Marketing needs of us”
- “Finish all the items in the Sprint”
- “Complete X, complete Y, complete Z…”
Sprint Goals have a habit of becoming over-technical or fall into the trap of roughly listing the items in the Sprint. This is not much of a North Star, and provides little context or guidance into how the work in the Sprint contributes into the overall goals of the Product. So, how do we get a better product Goal. I like how Henrik Kniberg coaches his teams to improve weak Sprint Goals, mentioned in “Scrum and XP from the Trenches.” He asks a simple question:
“Why are we doing this Sprint? Why don’t we all just go on vacation instead?”
The answer to this question is often framed in terms of clear value and a true goal. Here are some examples of good Sprint Goals:
- “Expand to include Canadian customers”
- “Create the permissions screen”
- “Build a predictive search function”
While these goals don’t make me wince, it’s hard to declare a good Sprint Goal in a vacuum. It’s going to change from team to team based on their needs. I can say this. A good Sprint Goal helps provide a point of external and internal accountability, connects our day-to-day work to our overall vision, tells us where we can declare victory, and reduces the need for comprehensive documentation. Let me know what I missed. What are some of the other benefits and pitfalls around the Sprint Goal. What have you found that helps with avoiding weak Sprint Goals?
Thanks for reading!