3

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?

  • 2
    There are a few things that are unclear. Who is involved in planning the Sprint? What is this "roadmap" being presented - is it the ordered Product Backlog, a Sprint Backlog, or something else? What is your role on this team or in this organization? – Thomas Owens Jul 22 '18 at 16:33
  • 3
    "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." Before getting buyin from the development team? Why would you do that? – Vicki Laidler Jul 22 '18 at 22:15
  • @ThomasOwens so sorry for my incomplete question , im the product owner ! – Reza Najafi Jul 23 '18 at 17:16
  • @VickiLaidler i know it was wrong but it happened ! – Reza Najafi Jul 23 '18 at 17:16
4

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. :)

  • Not just if you're lucky - if the developers don't see the PO as part of the team, that's probably the biggest problem that requires being worked on. – Erik Jul 24 '18 at 5:18
  • Well, considering that the PO just acted as if he was in charge of, rather than part of, the dev team by presenting a plan to mgmt without their input, I think the PO will be lucky if they don't hold that against him & respond in kind! But I agree with your point in general. – Vicki Laidler Jul 24 '18 at 13:13
  • Also the developers may think that their 2 features are dependencies of yours. And don't do this to them again: If you came to me as suggested in this answer, then I would be everything I could to help. If you did it in the next sprint, I would drop you in it (that is the mess that you made for yourself), like a rock through a wet paper bag. – ctrl-alt-delor Aug 9 '18 at 13:01
5

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.

  • 1
    This answer would be improved if it's more explicit about "sprint planning" being something the whole team does, not something the PO does on their own. – Erik Jul 23 '18 at 6:12
  • 1
    Although I think this answer is correct in the information that it contains, I'm not sure that it addresses all of the problems presented in the question, because the question has insufficient information to define the problems. – Thomas Owens Jul 23 '18 at 9:34
1

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.

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.