Just Like Many People
Thinking back to the days when I was first a Scrum Master, new to Scrum, of course I made mistakes. Probably many more than I care to remember.
I had read some blogs, a book or two and of course the Scrum Guide. I thought I was prepared and full of understanding.
With those first teams I knew the team should use a Sprint Goal. Mostly at that point our Sprint Goals were simply a list of the User Stories included in the Sprint. As that seemed redundant & rather obvious, over time we stopped using them.
If your teams Sprint Goals look like a bulleted list of stories, or you are not using one at all, read on to see why you should reconsider.
The Purpose
Sprint Goals are meant to define the overarching purpose of each Sprint. What does the Product Owner believe will be useful or meaningful to the customer? What would generate the most amount of value?
Typically a Sprint Goal will be one sentence, perhaps two. But as the name suggests, it’s a singular purpose, not a laundry list of stories or tasks to perform.
As Scrum teams do not work for free, the Sprint Goal should help ensure that the team is doing meaningful work. At $50,000 to $100,000+ per Sprint in team costs, the Goal should represent equal or greater value to the customers.
If stated to a customer, the customer should respond “yes, I’d pay for that”.
Why not used?
Most teams I’ve encountered skip this useful practice. Similar to my beginnings with Scrum, they are not finding value in creating a Sprint Goal by restating of the stories included in the Sprint Plan. Or it’s a very generic “get things done” type sentence.
Something else in common with teams that do not use Sprint Goals is that their backlog typically is a list of tasks. These are most often written from a coding perspective such as “update the database” or “call this API”. While these are valuable things to do, the customer really doesn’t care how the product works internally, they care about how it changes their life by making things easier for them.
A common misunderstanding
For teams that are attempting to use Sprint Goals, the process that I see most often used goes like this during Sprint Planning:
- Product Owner brings a prioritized Product Backlog
- The team works through capacity for this Sprint using velocity and planned absences.
- The team selects a number of backlog items based on the above for the Sprint Backlog.
- The team crafts the Sprint Goal based on stories selected.
It’s actually item #4 which seems to be the tripping point. Creating the Sprint Goal after the items have been selected makes it rather simple to create a Sprint Goal which only restates the items selected. That doesn’t seem very useful.
I coach teams to reorder the list above, and for the Product Owner to create the Sprint Goal before Sprint Planning. So the process goes more like this:
- Product Owner states the Sprint Goal
- The team and PO review the Product Backlog and make any alterations to backlog items necessary to support the Sprint Goal. This might include reprioritization, creating additional stories, or perhaps even removing some.
- And then Sprint Planning proceeds as normal, the team selects stories that they believe will deliver the Sprint Goal.
Remember, the Sprint Goal should be something for which the customer is willing to pay. Selecting items that deliver the Goal helps to ensure the money spent to hold the Sprint has a much greater probability that the result will be of high value.
Switch to a Value focus!
Properly using Sprint Goals should provide a number of benefits, here are 2 top ones:
- It forces the Product Manager/Owner to think in terms of the Customer. Your backlog items should take on the perspective of the Customer. Your entire mindset should be Customer-centric. And if you’re thinking from the perspective of the customer, you’re thinking in terms of value rather than tasks to finish. All of this is a good thing!
- It helps Product Owners to define a short term Roadmap. Generate a loosely defined set of Sprint Goals for the next few Sprints. Be transparent, show this to the team and stakeholders. But be flexible too, it should not be set in concrete. If you are in a scaled environment, this list of Sprint Goals would typically define the plan for completing a Program Feature or two in short value focused statements.
Wrapping Up
If you’re not using Sprint Goals, or they are pretty much just a restatement of the Sprint Backlog, consider reworking how they are used by the team. It’s an often misused practice that can be beneficial to Scrum Teams.
Think about some of the items I’ve mentioned above. Consider how they could provide direction to the team and stakeholders.
Perhaps have a conversation at the next Retrospective about incorporating the above into the team’s ways of working.
If you liked this post and want to learn more about Agile, Lean or Leadership, please consider purchasing a book from my Recommended Reading page.
Until next time!
