I engaged a contractor to come over to my home the other day to give me an estimate for doing some external work on my house. I needed some carpentry repairs to my siding, a few windows replaced, and a few repairs to my screened-in porch. 

The weather has been challenging lately in NC so the house has taken on some damage. Not too much, but I like to stay ahead of things regarding maintenance.

He gave me an estimate for his time (hours) and costs to repair each item.

I was sort of taken aback by the estimates. They seemed much longer/larger than the ones I had done on my own so I shared them with him.

When I did, he gave me a sideways stare. He said that if I wanted to do the work, then my estimates were valid. But if I wanted him to do the work, then mine were irrelevant. He noted that this is what he did for a living, that he had glowing recommendations (he did!) and that he stood by his estimates as valid.

He also mentioned that, with all due respect, I was biased. I was the customer so I saw things in a different light (easier, quicker, lower cost) then he did. He also mentioned that I had little (recent) experience ;-)

In the end, he said that I either trusted him or not. And he asked – did I want him to do the job?

I quickly apologized for my presumptuousness, and wholeheartedly said YES.

Back to the Title’s Question

My friend and colleague, Anthony Mersino, recently wrote an article exploring this very question. When I saw the title, I read it immediately and with great interest to see where he stood on the matter. To be honest, I didn’t think there were choices as the answer had always seemed clear to me.

You see, I’ve been a student of product ownership for a very long time and I have strong views regarding specific aspects of the role. One of my discoveries and core beliefs is that the Product Owner should NOT be part of the work sizing / estimation processes within the team.

That is, they are involved. But they need to exclude themselves from providing raw estimates. That is the role and responsibility of the team, or in other words, the people who will be doing the work.

The two primary reasons that Anthony gives for allowing them to estimate are:

  1. They will learn about what makes things big or small. What is simple and what is complex work.

  2. It reinforces that they are part of the team.

To me, both of these are accomplished by including them in the Backlog Refinement sessions and any other activities where estimates are made (ex: via Planning Poker or something else).  

Why?

Because they ARE part of the team, as defined in the Scrum Guide. And as such, they should be engaging in team activity and learning. It’s just that, as in my entry example, they are a bit biased by skill and role focus.

So, both of these happen (or should happen) if they estimate or not.

Wrapping Up

In the article, Anthony mentions that there are split decisions in the agile community around this topic. He mentioned Ron Jefferies who disagrees with him.

He makes it sound like there’s an “even split” in the community around this notion. Again, I don’t agree. I can’t recall very many voices (any) who’ve taken his position.

Anthony is a really great guy and a great agile coach. But sometimes, we all simply get things wrong. Anthony, please reconsider this point, as I think you missed the mark.

Stay agile my friends,

Bob.

Comment