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 Development Team. Sprint Goals easily become too vague and unspecific, defeating their purpose. Or they become too technical or too large.
In a previous post, we explored how Sprint Goals balance a trade-off between what is valuable and what is the most uncertain now. We also shared examples of real Sprint Goals that did just that. We’ve consistently found that asking powerful questions that focus on this trade-off is a great way to get Product Owners and Development Teams 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.
10 Powerful questions
So what are powerful questions? Here are the ones we 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.
The following set of questions help to identify a general direction for the Sprint Goal:
- If we just canceled the next Sprint and went on vacation, what would be inevitably lost or become much harder later?
- 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?
- In terms of value and learning about what else is needed from us as a team, what is the worst way to spend the upcoming Sprint? What should we focus on this Sprint to prevent that?
Sometimes, creating a constraint is a great way to zoom in on a valuable Sprint Goal.
- If we wouldn’t have another Sprint after this one because we ran out of money or time, what would be the one thing we’d still have to do in order to deliver at least some value?
- If we were paying for this Sprint with our own money, what work would give us the highest chance to get that money back?
- When we achieve this Sprint Goal, what has clearly changed or improved from the perspective of stakeholders?
The following questions are helpful when you’re trying to identify what should go on the Sprint Backlog in order to achieve the goal. They can also help narrow down the Sprint Goal when it is too ambitious for a single Sprint:
- Which steps are required to achieve this Sprint Goal? Which are the least required or could we do without if we really have to?
- 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?
- 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?
- What would need to happen while working on this Sprint Goal that would be cause for celebration?
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 certain constraints are getting in the way. 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 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.
Sprint Goals give flexibility and purpose to the work that is done in the Sprint. Don’t fall into the trap of postponing the use of Sprint Goals until you’ve removed all the constraints that are making it hard. Imperfect Sprint Goals are still better than no goals. Without Sprint Goals, the implicit goal then becomes to complete everything on the Sprint Backlog. That doesn’t give any flexibility to the team nor does it clarify the purpose and value of the work. Instead, it implicitly signals to teams to put their blinders on and work as fast as possible. It undermines the ability of a team to self-organize their collaboration around a common goal.
So whatever you do, don’t ignore Sprint Goals. Use the powerful questions in this blog post to identify them. And let us know in the comments what happened because of that. Or what other powerful questions you like to ask.