10 Powerful Questions to Create Better Sprint Goals

If you prefer to listen instead of read, you can also listen to this post on our podcast.

Almost everybody sees the value of Sprint Goals. But most teams struggle with them nonetheless. Unfortunately, there is no silver bullet to creating good Sprint Goals. Sure, there are helpful canvasses and conceptual models out there, like this one and this one. But ultimately, creating Sprint Goals is a matter of asking powerful questions to your Product Owner and Developers. Sprint Goals easily become too vague and unspecific, defeating their purpose. Or they become too technical or too large.

In a previous post, I explored how Sprint Goals balance a trade-off between what is valuable or the most uncertain now. I also shared examples of real Sprint Goals that did just that. I’ve consistently found that asking powerful questions that focus on this trade-off is a great way to get Product Owners and Developers to come at their Sprint Goals from the right angle. That is; from a perspective of deciding what is the most valuable way to spend the upcoming Sprints while leaving the rest for later.

Without Sprint Goals, the goal then becomes to finish all the work on the Sprint Backlog. And since complex work is tough and unpredictable, this leaves no space teams to change their Sprint Backlog as needed. Illustration by Thea Schukken.

10 Powerful questions

So what are powerful questions? Here are the ones I like the most. What they share is that they are specifically ambiguous. They help teams move their thinking in the right direction (specific) while giving them ample freedom to explore possibilities (ambiguous) at the same time:

1. If we don’t work towards this Sprint Goal, what will be inevitably lost or become much harder later? 
2. If we wouldn’t have another Sprint after this one, what would be the one thing we’d have to deliver in order to return some value?
3. If we were paying for this Sprint with our own money, what work would give us the highest chance to get that money back?
4. When we achieve this Sprint Goal, what has clearly changed or improved from the perspective of stakeholders?
5. Which steps are required to achieve this Sprint Goal? Which are the least required or could we do without if we really have to?
6. If we suddenly have half the team available and we can do only half the work required for the Sprint Goal, what should absolutely be in there in order for us to still be okay with the outcome? What can we let go of for now and return to later?
7. If there’s an ‘AND’ in the Sprint Goal: Which would you naturally do first if you have to choose? What is irrevocably lost if we do that thing first, and the second thing in another Sprint?
8. What would need to happen while working on this Sprint Goal that would be cause for celebration?
9. What worry about our product is keeping you up at night? What can we build or test this Sprint to make you sleep a bit better?
10. In terms of value and learning about what else is needed from us a team, what is the worst way to spend the upcoming Sprint? What should we focus on this Sprint to prevent that?

Although these questions don’t give you the Sprint Goal on a platter, they do help you discover what is the most uncertain and valuable right now, and thus input for your Sprint Goal.

But wait! These don’t help me because …

Now, you may discover that these questions don’t help in your situation. Because how do you answer them when you are working on multiple products at the same time? How do you answer them when your Product Owner has no say in what order to implement work? How do you answer them when your Scrum Team is unable to deliver working software within a single Sprint, ready to release to users afterward? What if you have a component team that only works on one layer of the product?

The question here is not how to craft Sprint Goals given your constraints, but to explore the impact of those constraints on your ability to work empirically. How does working on multiple products in one Sprint impact your ability to focus on delivering working software to stakeholders? How does a Product Owner without the mandate to re-order the Product Backlog impact your ability to play into surfacing needs of stakeholders? How does being unable to deliver working software every Sprint impact your risk of building something that stakeholders don’t find as valuable as you thought it would be?

As it turns out, struggling to craft Sprint Goals is generally a clear sign that work is needed elsewhere. Ignoring those constraints is like asking how you can become fit and healthy by maintaining your burger-based diet and without making an effort to exercise. Sprint Goals are great at finding the impediments that are truly getting in your way.