Imagine a typical situation. Another sprint planning is coming close to an end. You have a sprint backlog for the next two weeks. Everybody is ready to leave the room and rush to development. That’s when someone asks out of the blue, ‘What about the sprint goal?’ Smile is gone from your face. This damn sprint goal! Not again! How do you expect me to think it up? I don’t have a slightest clue!
Did you ever find yourself in a situation like this one? Especially in the late stages of product development when the backlog mostly consists of gloss and shine stuff. I did and not once. Eventually, I’ve come up with a simple technique that helped me to overcome doubt and start creating decent sprint goals.
The Right Question to Ask
Usually, at the end of a sprint planning you already have a more or less prepared sprint backlog. Choosing stories for a sprint seems to be an easier task. Now take a look at your sprint backlog. What do you see there? Read through the sprint backlog items. Now ask yourself one simple question: ‘Why have you put exactly these items in the sprint backlog and not some other?’ Answer to this question is going to be your sprint goal.
Here’s how it works. Unless you’ve pulled the items from the product backlog in a completely randomized order (say, by throwing dice or choosing blindfolded) there’s been some rationale, some common theme behind your decisions. You just did this unconsciously, without realization. The sprint goal is already in your head and you already know it. The only thing remaining is too make yourself aware of it and bring it to light. You do this by contemplating the sprint backlog one more time and introspecting— through asking the question. Easy. Now confirm it with the rest of the team and you are good to go.
Let me give you a few examples to illustrate the idea. In your sprint backlog you have:
- Simplified horizontal search bar
- New bright attractive ‘Pricing’ button
- Narrower navigation panel.
Now ask yourself, why exactly these items? Turns out, you want to clean up your pages to make them look neater to end users. So, the goal might be ‘Improve UX of the main site functions’.
Another example:
- Refactor shopping cart
- Migrate to new payment service provider
- Pre-fill payment details
The items are a bit all over the place, but after a few minutes of thinking you are able to see a common theme pulling them together. A possible appropriate goal in this case could be ‘Remove blockers to further development of payment options’.
You may ask at this point, what if even after thorough inspection you can’t find a common theme? A sprint implies there’s a more or less tangible result in the end and a sprint goal helps a team stay focused on that result. In addition, it gives them a guideline for making own decisions. If you can’t state a goal, you deprive the team of focus and sense of direction and make the task much harder than it should be. So, if you can’t formulate a goal even after carefully looking at your sprint backlog, this is a hint to you that your sprint backlog is not good enough and you need a new one.