Need help - How to handle when product owner adds but won't remove features

Can you confirm that your referring to adding and removing things from the product backlog and not the sprint.

If that is the case, I wouldn't be to concerned really. The length of this linear product backlog might make it hard to manage or be responsible for, but there's no limit per-se.

The implied part of this question that I perceive is that this is also impacting Release choices. I don't know if you've taken the PSF, but in that we talk about Date based forecasting and Feature forecasting. Make sure an honest conversation is occurring around the impact of these changes on forecasting.

The intent of the product backlog is not to be "all things needed to release." It is instead meant to be "all things that could be done... ever."

Yes, I mean the Product Backlog. I have tried to communicate to him that in using forecasting tools, there is no way that we can complete everything he is asking for within the given timeframe. I have tried to get from him what the absolute most important things are and his answer is 'everything'. I think a more seasoned ScrumMaster could find a way to negotiate with him, make him see that this is unreasonable but I haven't been able to thus far.

So if it's the product backlog, then it's the product owner's choice what goes into it. As Ryan says, it's not a release list.

The way to deal with "everything is important" is to have the priority set sequentially. That is, in the product backlog there is the first most important story, then the second most important story, then the third, fourth, fifth, etc... it will be very challenging for him but that's a part of evaluating and cultivating the product backlog.

It's important that the most valuable things are delivered first, because at some point he will come to the realization that everything can't be done within the time frame he's asking for, so it's better to have less important details be the parts that aren't delivered (until the next release). Encourage him to think iteratively, that is, what is the minimum set of features I could reasonably bring to market knowing that more features will be added later.

How are you forecasting by the way? If you're a new scrum team you won't know your velocity so you can only forecast using traditional methods. I think this needs to be part of the conversation one has when adopting scrum.

That's actually been another challenge. Repeatedly I have asked him to specify which is the most important story, and try to get him to identify which would be the most important after that, and so on. This has been very challenging. He responds with "I want everything" and "The development team should be telling me what they are going to work on". He tries to argue that this is Scrum. I point out that yes, the development team needs to agree to do the work, but based on what HE decides is most important. Our project consists of a few different components and he argues that without one the others are useless and this is true. So I have tried to scale down the pieces that are absolutely necessary but he's not being cooperative. Each sprint has been pulling like pulling teeth just trying to get a specific set of stories from him.

I'm forecasting velocity based on the few sprints that we have completed. It's all I have at this point. Even considering an increased velocity over time, there is no way we can finish everything.

To be quite honest, I think you need a new product owner. This particular PO is not doing the Stakeholders (internal or external) any favors. I can't imagine it will be easy, but that would be my next move.

In the meantime, find passionate stakeholders and get them in the room with the current PO. Find folks who are strategic thinkers. Those who can think strategically across influencing attributes for product backlog order (i.e. risk, learning, new markets, customer types, support, story telling, ...). The more influence they have in the organization the better IMO.

Ryan's advise is good, but you can't always replace the product owner. My suggestions for working with the existing product owner:

- why are all the stories inter-dependent? there has to be a way to break up the functionality to deliver value to deliver a minimum viable product
- try to make your stories more independent. look at http://agilesoftwaredevelopment.com/tags/invest for example.
- scrum is NOT cramming frequent requirement changes into development. scrum IS allowing requirements changes while delivering incremental value - this means new stuff, important stuff can be added, not that more stuff, everything, can be delivered on a preset deadline.

You seem to agree with him that the components are useless without them all being delivered, why is this so? I would work on breaking that down if you can so that you are delivering value consistently.

Also, if he is saying "this is scrum" to "i want everything" there is a counter-argument. In scrum, the only thing that is committed to be delivered by a date is what the team commits to in a sprint. There's no commitment to deliver everything by some preset date many sprints away.

Also if he want to get all "this is scrum" on you, you can quote the scrum guide on him where he has to sequentially decide the priority: "The Product Backlog is an ordered list of everything that might be needed in the product and is
the single source of requirements for any changes to be made to the product." Page 12. Emphasis on ordered list.

It sounds as though the PO is not in a position (for whatever reason) to maximize the ROI of the product on a sprint-by-sprint basis.

The Scrum Master should tackle this impediment and transparency will be key. Here's what I would do...

1) Get the team to size everything that is currently in the Product Backlog (this may already have been done)
2) Establish the current average velocity (already done by the sound of it)
3) Work out the likely completion date of all must-have requirements (again, already done by the sound of it)
4) Make sure that all stakeholders (not just the PO) are in receipt of this information. Dashboard reports are commonly used for this purpose when the intended recipients are off-site and cannot or will not see information radiators.
5) Tell the PO that, as Scrum Master, I intend to help him receive the guidance he needs to maximize the ROI on a sprint by sprint basis, including planning and release management. I'd feel quite comfortable about doing that for 2 reasons: firstly the SM has organizational coaching and transformation as part of their remit, and secondly this matter is clearly an impediment for the team.
6) Follow through on 5. Go straight to the customer and/or management, explain the problem as objectively as I can (using the dashboard I supplied, focusing on the problem and not the person). Propose a solution based on prioritization, effective sprint planning, and incremental release management. Let them decide whether or not the PO is providing value to them or whether he needs training or replacing.
7) Keep stakeholders updated once I have established a line of communication with them. This could take the form of an updated dashboard or, if they prefer, a RAID log.

Thank you everyone for your responses.

Robert, you are correct - it won't be possible to replace the product owner.

It's not that I think every story is essential. There are four main components that need to be there. But he doesn't want to budge on what I see as "extras" that could potentially be left for a later release. He insists that he wants it all.

Coaching him is an especially delicate subject because the PO is my boss within the organization. He also has a closer relationship to the most important stakeholder than I do.

Ian, yes we have done 1-3. I 'm going to think on this for bit and determine the best way that I can approach the PO with your suggestions.

Thanks everyone

Posted By Ryan Cromwell on 19 Sep 2013 11:20 PM
To be quite honest, I think you need a new product owner. ...

Sadly, that seems to me for you the best is to look for an other job :-(

Can "everything" fit in to one sprint? If so, then great! If not, what does your boss (PO) want to see completed first? Perhaps framing the question like this can help remove the fear that "everything" will not get done. I'd also ask your boss (PO) to assign value points to the stories. This could help tease out an order to the backlog as well. It is unlikely that each story has the same value (ROI) so this should lead to some sort of priority. Sometimes reframing the question can make all the difference.

It's important to keep in mind that the development team should work on what the PO deems important... If he says that everything is equal, then the team can pick anything to work on, right? There is risk to this as time and money could run out before "everything" is done. This is a risk that could get your boss's (PO'S) attention as well.

Good luck, these transitions can be difficult. Sometimes it's a matter of trying many approaches until the impediment is removed. I would try to avoid the "this is scrum" debates. That's not likely to lead to potentially releasable software. Try to explain that his direction is vital to the development team working on the "right" things so that the most value can be delivered and the right design emerges based on that value. I think this is much more valuable discussion to have.

--Ryan Ripley