0

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?

3
  • 2
    Anchoring is inherently an anti-pattern for planning poker. Having non-developers anchor the estimates from the start is therefore a bad idea ab initio.
    – Todd A. Jacobs
    Apr 19 at 3:44
  • @ToddA.Jacobs: What do you mean exactly with "anchoring"?
    – Jim
    Apr 19 at 15:10
  • 1
    Anchoring is a known cognitive bias that properly-implemented Planning Poker is deliberately designed to compensate for.
    – Todd A. Jacobs
    Apr 19 at 15:27

5 Answers 5

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.

1

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.

0

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.

2
  • The idea was not that the product owner's estimation has value or pressure for the developers but more of what is the perception of the complexity of a story and making a transparent discussion among the team so developers explain why that estimation is off or not
    – Jim
    Apr 18 at 18:32
  • 2
    @Jim That changes nothing. It's generally accepted that the best estimates come from the people who will do the work. Outside estimates, especially from people who aren't doing the work, can influence their thinking. Especially from a Product Owner, who is seeking to maximize the value delivered. If the PO were to be overoptimistic, neglect considering some technical details, or throw in a few underestimates, the team may commit to goals that are unrealistic. There are a lot of following consequences on team behavior and morale.
    – Thomas Owens
    Apr 18 at 18:53
0

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.

3
  • The idea was not that the product owner's estimation has value or pressure for the developers but more of what is the perception of the complexity of a story and making a transparent discussion among the team so developers explain why that estimation is off or not
    – Jim
    Apr 18 at 18:32
  • If the estimate was just an anchor to hold discussion and clarify things, then that's fine. If you work with a disciplined team, in a psychological safe environment, then you don't even need the estimate; whatever number you come up with is just there to help clarify things. But like mentioned also by Thomas in his comment, you have to be careful for the PO's estimate not to influence the team in some bad way (doesn't need to be intentional... by accident will do). So just out of curiosity? What was the dynamic or how did you carry on when there was not a consensus between PO and devs?
    – Bogdan
    Apr 18 at 19:05
  • The developer's estimation always was kept. There was trust in the team and the discussion about the estimate from the PO's side was so that there was transparency on the reasoning behind a big estimate given by the developers, the PO became better at understanding various other stories how complex they would be in a very early stage and also the developer's got another perspective of how a story could appear as very small for other stakeholders
    – Jim
    Apr 18 at 19:30
-3

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.

2
  • 2
    While I cannot say whether your PO sees this as their task, I cannot find that in the Scrum guide. Can you explain why you think the PO does UAT on sprint items during the sprint?
    – nvoigt
    Apr 19 at 6:05
  • The POs should do the UAT to be sure that the output is ready to be presented to the stakeholders in the sprint review meeting. Apr 20 at 3:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.