Sprint planning estimations and who is involved

Question

In the past but only in 1 team, during the sprint planning, the product owner provided also an estimation for the story discussed, not so much as to use that estimation instead of the developers, but more as a way of discussion and to have more clarity as a team how complex are the various stories.
That approach had worked well for that specific team, due to the composition and product owner, but haven't encountered it again. I was wondering if such an approach is being used in general or it was an exception?

Answer 1

Most product owners I have worked with don't have enough detailed technical knowledge to make good estimates. There are exceptions though. It ought to be up to the development team. If they find it useful to have someone else's input to estimation then why not do that, but the developers should still have the final say on any estimates.

Answer 2

TL;DR

[T]he product owner provided also an estimation for the story discussed, not so much as to use that estimation instead of the developers, but more as a way of discussion and to have more clarity as a team how complex are the various stories.

While this may have worked for you in a particular instance, what you're describing is inherently a Scrum and agile anti-pattern, and often defeats the intended purpose of leveraging the knowledge of a self-organizing group of Developers to meaningfully estimate the relative size of a Product Backlog item, define its essential implementation details, and effectively estimate the level of effort required to deliver it within the Scrum Team's available resources.

Also, please note that Planning Poker is a technique, not a requirement of Scrum. In fact, the 2020 Scrum Guide is extremely non-prescriptive about how work is to be estimated, but the use of estimation techniques like Mike Cohn's Planning Poker is certainly a common practice among agile practitioners.

Why It's a Scrum Anti-Pattern

First of all, while the Product Owner owns the Product Backlog, the Developers own the Sprint Backlog. It is their plan for the Sprint, and only they are truly in a position to know how easy or difficult the work will be for them to perform. While the Product Owner (PO) may answer scoping questions or help refine items, the PO role should never be influencing the Developers' estimation process in the way you're describing. The Scrum Guide specifically says:

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

In particular, the Product Owner doesn't get to opine on how easy or hard a given work item may be. However, if the Developers have questions about the scope or Definition of Done for a particular item, the Product Owner should be a key collaborator in helping to refine the Product Backlog item during Sprint Planning so that the Developers can determine whether the work will fit within the Iteration and whether it's sufficiently decomposed to add to the Sprint Backlog.

Why It's a Planning Poker Anti-Pattern

Mike Cohn is the author of User Stories Applied and Agile Estimation and Planning. In a presentation entitled "Planning and Tracking Agile Projects" (Cohn, Mike. August 15, 2007.) Mr. Cohn lays out several key elements of Planning Poker on pages 19-21:

1. Those who will do the work, estimate the work

2. [Properly done, Planning Poker r]educes likelihood of anchoring

3. Mr. Cohn specifically cites an additional source for the infographic showing the negative impact of anchoring on the estimation process. Citation adapted from page 21:

   "How to Avoid Impact from Irrelevant and Misleading Information on Your Cost Estimates." Jørgensen, Magne and Stein Grimstad. Simula Research Laboratory, Simula Research Labs Estimation Seminar. Oslo, Norway 2006.

If you want a more thorough treatment of why anchoring is a flawed approach to Scrum or agile estimation, I would consider Mike Cohn's body of work to be fairly comprehensive in this regard as far as agile practices go, and there are plenty of professional journals that support the theory that anchoring inherently creates bias. However, if you want an exhaustive list of studies and citations you will have to conduct your own research on the topic.

The triple-net here is that Planning Poker was designed to avoid exactly the sort of cognitive bias (see also https://en.wikipedia.org/wiki/Cognitive_bias) and authority-based target setting that plagues traditional estimation practices. While there is certainly room during Backlog Refinement or Sprint Planning for a Product Owner to collaborate with the Developers to reduce the size, scope, or complexity of a backlog item so that it better fits within the Developers' plan for a Sprint, the Product Owner is not generally the task performer. As a result, the PO's opinion on the level of effort required to deliver a given backlog item is largely irrelevant to the level of skill available from, and the effort required of, the Developers who will actually be doing the work.

Answer 3

The best person (or people) to estimate the work is the person (or are the people) who will be doing the work.

Unless the work is something that the Product Owner will be involved in designing, developing, and testing, then the Product Owner probably shouldn't be involved in estimating the work. In the context of Scrum, if the team has chosen to use estimation, then the Developers are the ones who should be estimating the Product Backlog Items. In addition, estimation should be a part of the ongoing Product Backlog Refinement and not restricted to Sprint Planning, although you may choose to do some additional refinement at Sprint Planning as well.

Answer 4

Most likely an exception. The people who will perform the work are the ones that should estimate. Anyone else that does not do the work or is not responsible and accountable for the outcome of the work, doesn't really have a skin in the game.

A bad product owner might pressure the team by providing a smaller estimate to influence the outcome of the sprint planning, or might question developers on their estimate "come on... is that story really an 8 story points?" Sometimes also, because they don't actually do the work and don't understand all that's involved, they might give a lower estimate and influence the team simply by accident if, for example, the team sees the product owner as someone with more authority within the project.

For reasons like these, it's best to leave estimating to those that do the work, and have the rest of the participants be available for support and clarification.

If however the team finds value in the estimate of the product owner (maybe they are a subject expert in some fields, or whatever) then that's fine too... if you pay attention to the things I mentioned and adapt when there are signs of trouble.

But like I mentioned in the beginning, the example you gave is mostly an exception.

Answer 5

Product owners are doing the UAT, which means they are doing work in the sprint on the sprint backlog items. So, product owners do estimate the stories.