[QUESTION] The Product Owner Says #NoEstimates From the Team. Now what?

What would you do if your Scrum Product Owner decided that customer value should be the sole focus of the scrum team and therefore wants to eliminate estimation (#NoEstimates) from the scrum development team’s process?

Kerrin Asmundson | Free Estimates | Flickr

Kerrin Asmundson | Free Estimates | Flickr

Perhaps the scrum product owner read the exchange between Neil Killick and me and decided that #NoEstimates is the way to go. Is it possible that I failed to express the benefits that estimates can bring?


But in this case, the answer is pretty simple. As a scrum master I would remind the scrum product owner that he/she does not have control over the team’s practices or their estimates. There is a misconception in some organizations that a product owner is a “manager”.

This simply isn’t true.

The scrum product owner is responsible for optimizing the value of the scrum development team does. This is primarily achieved by providing a well refined and prioritized product backlog.

Scrum teams are self-managing and own their processes. The team is responsible for continually inspecting their practices and results – usually in a sprint retrospective – looking for continuous improvement.

Following that explanation, I would then ask the team what they think about the scrum product owner’s request.

Scrum is a “developer play” after all. So it only makes sense to ask the team what value they see in estimating (or not estimating) their work.

If after such a discussion, the team decided to go the #NoEstimates route, I would fully support them.

There are some topics that the team would need to speak to with capacity being one of them. Forecasting for the product owner would be another. As long as the team as figures out how to meet these business expectations, then why not give #NoEstimates a shot? Scrum is based on empiricism. Inspect and adapt!

In this example, the scrum product owner decided that estimates are overhead. This sentiment is hard to disagree with. Estimates are pretty worthless. They expire quickly. When requirements change they expire even faster. Worse of all, estimates are almost always wrong.

But that is why scrum teams estimate often. We are not trying to hit a date or measure the accuracy of our estimates. Rather, scrum teams uses estimates to guide them on how much work they can complete in a sprint.

The estimates can also be used by the team to discover their sustainable pace and to forecast a few sprints out to see where stories (features) could be delivered. These activities have value to a scrum team and to the product owner during release planning activities.

But these benefits diminish if the estimates are not continually updated. During these multiple planning poker (estimation) sessions, the team learns quite a lot about the story in question and about each other. These interactions can lead to a much better team and product.

As a scrum master you should be looking for opportunities to empower your team to make their own decisions. In this case, the scrum product owner wanted to dictate how the team estimates (or doesn’t estimate) their work. Instead, the better approach is ask the team to discuss the idea and decide for themselves whether or not to give it a try.

Question: Have you ever taken an idea to the team that you may not have agreed with? What did the team decide? Did you support the decision? You can leave a comment by clicking here.

Please note: I reserve the right to delete comments that are offensive or off-topic.

  • Henrik Ebbeskog

    I can give my point of view 🙂

    I don’t think #NE is a goal in itself. This opinion might vary. And how one defines the meaning of the hashtag.

    Anyway, I don’t think anyone should “force” or even suggest that “#NoEstimates is the way to go”. Perhaps it can be worth trying (as in the suggestions Vasco and Neil have). But I don’t think: “We want to try it” really should be the driver. Be good at retrospectives and see what comes out of that instead.

    In my opinion #NE isn’t even something to try. I don’t even think it’s a “thing”. It’s more of a topic, a discussion.

    #NE might be an outcome when working in a flow a la Kanban. But it doesn’t have to, and shouldn’t be the goal, in my opinion.

    The goal here might not be to answer “When/how much?” with #NE, but instead to arrange your work in such a way that you seldom/never get those questions.

    #NE for me is more of a mindset. A mindset of not relying too heavily on estimates or let them drive you. And also try to lessen or eliminate the misuse of estimates that – in my experince – seems to be quite common.

    In that way – for me – #NE works more like a denominator for lots of things.

    • Hi Henrik, thanks for the comments. It really comes down to a question of value. If the team decides during a retrospective that the estimating process is not leading to better software then the #NoEstimates discussion becomes very relevant. I agree that it is not a goal, but more of a conversation/mind set.

      External force against the scrum development team is a smell that a good scrum master must sniff out and deal with quickly. We must also remember that the management team that is using force are typically not bad people.

      They are using the tool and techniques that they have been successful with for many years. This is why I’m a big fan of #CoachingUp. If we can get these individuals to understand how to manage in an agile environment, #NoEstimates could become a moot point.
      Thanks again for feedback. I appreciate it!