How to manage technical conflict between Product Owner and developers?

Question

Imagine you are a Product Owner. And you have planned a sprint, prepared every detail, broken down the epics into stories and already presented your roadmap to management and promised the releases ahead. In the sprint planning you also give 10 features to your engineering team. The developers tell you that they are not willing to work on two of your requirements at this time and give you some technical talk which is hard for you to follow and tell you that they want to actually have two additional requirements of their own for the sprint. How do you respond?

Answer 1

Imagine you have planned a sprint, prepared every detail, broken down the epics into stories and already presented your roadmap to management and promised the releases ahead. In the sprint planning you also give 10 features to your engineering team. The developers tell you...

If I were the PO who had done this, I would first of all own that I had messed up, in so many words, rather than "it happened" which makes it sound like it was a thunderstorm or something. :)

I would go back to the development team and say, OK, I messed up. Here's what I already told management. Can you explain to me, in terms that they will understand, what is blocking the development of those 2 features? Is there any way we can get any of them into this schedule?

About the 2 requirements they want to add: it is entirely common for development teams to identify non-user-facing requirements that will improve quality, reduce risk, decrease technical debt, or increase productivity. Investing 20-30% of the development effort towards these items is perfectly reasonable, especially if the product has a lot of complexity under the hood. I would ask whether their 2 requirements fall into any of these categories, and ask about the risk of deferring them.

Essentially, in talking to the dev team, I would admit we had a problem that I had created, and look for help or wiggle room in getting out of it. If I'm lucky, they'll see me, the PO, as part of the team, and my problem as our problem, and they'll help me out if they can for the sake of the team's rep.

But whether I get any help or not, eventually I have to go back to management, and say to them something like, "That detailed schedule I gave you was premature. After further consultation with the development team (which I'll do before I talk to you next time, to reduce the chance of this happening again), it turns out that we need to give up either scope or schedule, etc etc."

Which, if they understand and have bought into agile, should not be a big shock, because agile plans are forecasts not promises.

Good luck. Trust your team, & work more closely with them next time. :)

Answer 2

It isn't clear from your question if you are following the Scrum framework, but if you are then the Scrum Master should be pointing out the following from the Scrum Guide:

The Product Owner is the sole person responsible for managing the Product Backlog.

The team can ask the Product Owner to add items to the backlog. It is up to the team to create a convincing argument and the Product Owner is under no obligation to follow their advice.

No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality

The development team does own what goes in to sprints. However, in your question you say:

some technical talk which is hard for you to follow

The development team should be making a huge effort to make their technical decisions clear. The Product Owner has to talk to stakeholders who are often non-technical and needs to understand what is going on to do their job properly.

Rather than dealing with this particular incident I would recommend you look for a long-term solution.

Sit down with the whole team and thrash out ways of working. Create a working agreement that describes:

• The role and responsibility of the Product Owner
• The role and responsibility of the development team
• What behaviour is acceptable and what behaviour is not acceptable

It is much better to have this explicitly stated than to continually deal with disagreement on a case-by-case basis. If you have an Agile Coach in your organisation, now would be a good time to get them involved.

Answer 3

You’ll have to negotiate the scope with both parties (your team and the stakeholders) because it looks like you forgot to understand the technical implications of your plan.

I think it's important to mention three important aspects of a product owner:

• They don't set deadlines, only those working on the tasks can do it
• They often make trade offs in order to meet deadlines
• Understanding what is the effort required to accomplish certain tasks is crucial to develop a plan

As Barnaby suggested, solve the root cause of the problem by having a talk on ways of working and responsibilities ;).

However, I don't fully agree with him in the development team making a "huge effort" to explain technical decisions, on ocassion it's just not possible to explain clearly why and stake holders sometimes don't care, I would rather focus on:

• Trusting the team timelines
• For the product owner to present clearly to the team the vision and requirements of the product, so that the development team can in turn give a sound understanding of what's needed to accomplish the plan

In the end, what you'll be discussing with everyone is: these are the tasks, these are the deadlines, and hence this is the plan I'm making out of it.

Answer 4

I'd go to top management and tell them to drop the entire Product Owner role and replace it by "Manager". Then developers just do what their Manager bloody tells them to do.