Sprint Planning or Estimates – Should Product Owners Care?
There seems always to be questions surrounding aspects of the Product Owner role. Folks are always looking for clarity around what the PO should and should not be doing.
The harsh reality is that the role isn’t that clear. Heck, I would argue that no Agile roles are crystal clear. But I do think there are some healthy boundaries and these are what I try to communicate wherever I go.
Two common questions involve the Product Owners role in sprint planning and work estimation. Both of these activities are not directly in the sweet spot of PO responsibility, so there are usually quite a few questions around what they do as the team plans or estimates their work.
My hope in tackling these two activities in this article is to shed some light on the healthy boundaries associated with solid Product Ownership, or to at the very least, give it a go.
If you read the Scrum Guide’s definition of Sprint Planning, it exposes two distinct parts to the meeting.
Topic One: What can be done this Sprint?
The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.
Topic Two: How will the chosen work get done?
Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.
Clearly the Product Owner is required for first part of the meeting. But after that part is completed, nearly every PO I’ve ever met wanted to leave the team to their own devices in planning the sprint. Their hearts are in the right place, but I believe they’re wrong in leaving. They’re missing an incredible opportunity to listen to their team and gain insights into what’s hard and what’s not.
You see second part of Sprint Planning is essentially focused on four things:
- The team plucks each story off of the Product Backlog in priority order;
- They decide, as a team, the strategy they will use to attack the story. Who will do what, where are the hard bits, are their collaborative opportunities for swarming on the story, what is the optimum workflow, what testing will occur and when, etc. The discussion unfolds around the plan of attack for each story;
- Then the team tasks out all of the work associated with delivering the story to meet their (and the organizations) Definition of Done;
- Usually, there is also discussion around the overall level of effort and risk. Sort of a retrospective of the actual work (hourly estimates) and how it stacked up against the original sizing in Backlog Refinement.
Sprint Planning stops when the team is full or at their capacity. I often see teams stop during sprint planning to reassess who is working on what and then reassign / better balance the work to better consider team skills and availability.
Related Article: Agile is a Team Sport
My point in asking that the Product Owner hang around for sprint planning is this – there is an incredible amount of information they can glean by simply listening to their team. For example, they can better understand:
- What stories are inherently harder or more complex than others;
- When teams need to spike stories and how to encourage that earlier in backlog refinement;
- New found insights into testing complexity and effort for different types of stories;
- The skills and capabilities of their team, so that they can better align the backlog with the real capacity of the team;
- Of course velocity reality surfaces in sprint planning, so understanding the team’s true capacity is another benefit.
Product Owners can also simply listen to the strategies the team is discussing to attack the work. If they feel they are missing things, they can suggest alternatives. For example, if the Product Owner feels they’re biting off too much, they can say that. Or if the plan is too risky, they can challenge that as well.
I guess what I’m trying to say is that Product Owners are a member of the team. So they should participate in planning as much as possible to create a balanced and thoughtful plan that is achievable because it’s THEIR plan and THEIR commitment too.
Now let’s move onto the other topic, what part should the Product Owner play in estimation?
Let’s first make it clear that there should be very little one-time estimation in Agile contexts. All of the Agile methods take a two-tiered approach to estimation.
Tier-1 is estimating Product Backlog elements. Quite often you hear of teams estimating in story points or t-shirt sizes. Most of the units have a relative nature to them – meaning that they’re not intended to be time-centric or laser accurate. They’re “in the ballpark” estimations that are relative to one another. For example, a 5-point user story should be roughly twice as large as a 2-point story. Or a medium story is roughly twice as big as a small story.
These estimates are focused on giving the Product Owner a relative view to the size (cost) for each element or user story in the Product Backlog. And remember that the team iterates on estimates as they break stories down in the backlog. So the Product Owner is continuously being exposed to size and cost information as they consider trade-offs and reprioritization (valuation) in their backlogs.
Tier-2 estimation is quite different. It’s directly an output of sprint planning and involves the team breaking the stories down into tasks and then estimating the amount of time and effort for each—usually in hours. So in this case, each sprint the team gets into the inner details of the work and determines their best guesses for tasks and hours. Traditional project managers and planners typically like sprint planning because it gets into the nitty-gritty details.
But only the details for the current sprint.
Product Owners and Estimation?
Back to the question, what role does the Product Owner play in estimation? They need to engage as a team member. They need to challenge the scope and details of estimates. They need to understand the Definition of Done and ensure that their team’s estimates fully support it.
They need to continuously consider their teams capabilities, risk, and complexity when it comes to committing to work. Helping their team negotiate the fine line between over and under commitment – delivering as much, high-value software that they can.
They also have to realize that they can positively (and negatively) influence the estimation process within their teams, not only with their words but with their inflection and body language. If they put incessant pressure on the team to cut their estimates, then they’ll get just that – poor quality, poor estimates, and demoralized team members.
If, on the other hand, they emphasize positive analysis and thinking for example:
- In full support of done-ness
- Supporting solid design and construction
- Building in quality
- Iterating on simple solutions
- Continuously getting customer feedback
- Giving the team space for innovation and creativity
Then their role compliments Agile estimation effectiveness incredibly well.
Let me start this section by saying that the Product Owner role should not have a direct role in planning or estimating.
Why you might ask – since that seems to be contrary to the theme of this article.
Well, because they’re not directly doing the work. The Product Owner is also heavily biased towards delivery, and there’s the potential of them negatively influencing the team.
But with that being said, I think there are important supporting roles the Product Owner can play in both activities, one where their experience and balance can help the team’s execution.
To answer my introductory question, should Product Owners care about planning and estimates? The answer is more than yes; it’s engaging as a responsible teammate, which helps the team deliver on the vision and goals.
Stay agile my friends,