What does a product owner really do?
According to the Scrum Guide 2017, a product owner:
- Is responsible for maintaining the product backlog
- Helps the team decide which backlog items to add to each sprint plan
- Accepts (or rejects) backlog items and features resulting from each sprint
- Works with the team to refine (clarify, prioritize) the backlog
If a Product Owner follows the Scrum Guide to the letter and focuses on just the above tasks, will this really optimize value the team delivers? What’s missing?
Use sprint goals to communicate intent
The best research into human communication tells us that we understand each other better through the use of stories, and a particularly powerful storytelling technique is the use of metaphors. How is the relevant to the product owner role?
A list of backlog items – like a “to do” list – is a great way to break a goal into constituent, individually achievable pieces. But without knowing what the goal is, a list of backlog items is missing a key element. What’s missing is the intent. With a clear goal, we communicate intent. Just as a picture can be worth a thousand words, a statement of intent can bring meaning to many backlog items.
The purpose of having sprint goals is to focus the team on the desired outcome, as opposed to simply implementing a bunch of discrete user stories. It helps provide the team with the why, in addition to the what, and helps to focus sprint planning on what really matters to deliver the outcome. Developers are smart people. Knowing why they are working on a given set of tasks will help focus their intellectual efforts.
Good sprint goals help the team focus on what matters, and can help the team deal with uncertainty when the product owner is not present.
Sprint goals also help facilitate stakeholder communication. Imagine coming across an executive at the office water cooler and she asks you what the team is working on. If you rattle off a list of backlog items in the current sprint, their eyes will glaze over from the detail. If you can tell them a coherent sprint goal though, your story is told effectively in a sentence or two.
Having goals encourages everyone to “think before you act”.
Tips for better sprint goals
Sprint goals can be of different types, for example goals might be to deliver a feature (“get the widget ordering feature ready for release”) or to address a risk (“ensure system architecture delivers adequate system performance”). And a single sprint may have multiple goals.
A good sprint goal clearly specifies intent and is measurable.
Some good and bad sprint goals:
- “Complete the 7 user stories pulled into the sprint plan from the product backlog” (BAD: Does not specify helpful intent)
- “Improve widget XYZ” (Bad: Vague and not measurable)
- “Customers can recalculate a site annual budget in less than 10 seconds” (GOOD: Specifies intent and is measurable)