I was in a Backlog Refinement meeting the other day and you would have thought I was in divorce court where the parties were negotiating (fighting for) everything.

Each time the team asked clarifying questions around a user story, the Product Owner would begrudgingly answer. It felt like they thought they were wasting time trying to explore the story.

It was clear that what he really wanted was…an estimate.

So the team felt the pressure and stopped asking question. Instead they went immediately into Planning Poker for each story. And as you might expect, the estimates were sort of…all over the place.

But what I didn’t necessarily expect was the Product Owners reaction to the estimates. First, for each story he obviously had a number in mind before the team voted. And his number was LOW. Imagine that?

So as the estimates (and discussion) unfolded, he would be challenging everyone and everything. Here are some of the discussion points:

• 10 to 20 points? You’ve got to be kidding me. I think that’s a 5-point story AND I’m being generous.
• Refactoring? I don’t want you to do refactoring, I want the simplest and quickest implementation you can possible deliver. Why can’t you just “hack something together”?
• Is everyone listening to me? We’ve got tremendous pressure to get these stories “out the door” by August 1’st.
• Didn’t I explain the Minimal Viable Release expectations for August 1’st? And the emphasis here is on the minimal.
• I can’t take these estimates back to (1) my boss, (2) your boss, or (3) the CEO. We need to do better than this!
• And when he didn’t say anything, he displayed obviously negative body language whenever the team said something he didn’t agree with.

All of this is WRONG!

I later pulled the Product Owner aside and tried to correct his “behavior”.

I explained that in Scrum, the Product Owner should not have a strong voice in four key areas:

• The size of the estimates;
• The design or implementation approach;
• The team adherence to their Definition of Done;
• And the teams use of development tactics, for example: Unit Testing.

These are not yours to challenge or overly question. There are not yours to allow or disallow. These decisions are FOR the team and you are not part of them. Period!

Sure, you can ask questions in order to understand the teams approach and recommendations, but you have to be honestly exploring and not trying to get to a preferred approach or answer.

In fact, I’d argue that you should be supportive of your team. THEY are the ones who have the experience and more importantly, the ones that have to do the work and live with their estimates!

Wrapping Up

Often it boils down to three things:

1. Pressure: are you succumbing to external pressure and are you allowing that to color your interactions with your team?
2. Trust: do you trust your team? Their intentions, their competency, and their professionalism?
3. Role: the role of the Product Owner is focused towards the ASK or requirements. It is NOT focused towards the HOW or the HOW LONG! That is for the team.

A few weeks ago I was teaching a Product Owner class and I was asked if PO’s can estimate in Backlog Refinement sessions. My answer was no. Then I was challenged…a lot.

A few of the Product Owners didn’t like that answer. Mostly because they had technical experience and domain experience and felt that they “could” provide an intelligent estimate.

My response was still the same. No!

IF they felt that they wanted to estimate, then they should drop their Product Owner role and join the team. Otherwise, they needed to trust and empower their teams. Oh, and not bully them into seeing things THEIR WAY.

Wax on…Wax off…and

Stay agile my friends!

Bob.

Contact Us to See How You Can Provide Support for Your Team