How not to do backlog maintenance

Opening story

Product Owners who are new to Agile/Scrum often fall into the trap of thinking they'll just potter along and come up with stories as there's a need or just let the team create the backlog and priority

Scenario 1: Backlog meeting

The team is sitting around the table getting ready to review the upcoming stories.

Product Owner: "Alright guys, what do you think we should do next and what do you feel you can take on!"

Lara: "I think we should do functionality X. There's been a number of users telling me they need functionality X and I think function X would be fun to do."

Product Owner: "Ok, that sounds great, let's do that."

Later in the week...

Stakeholder: "What are you doing for next sprint"

Product Owner: "The team thinks we should do function X."

Stakeholder: "That is not what my clients really need, you should really do function Y"

Product Owner: "Ok, I'll see if we can do function Y"

Scenario 2: 

The team is sitting around the table getting ready to review the upcoming stories.

Product Owner: "Alright team, according to what we learnt from our previous sprint, our users needs function X. Does the team think this is reasonable?"

Lara: "If our users think we should work on that then that's what we should do."

Rich: "But is that really in line with what we want to accomplish?"

Product Owner: "Considering what we want to accomplish, by doing function X we will be able to get closer to our goal in less time than if we were to follow our old plan."

Bob: "Ok, that makes sense."

Later in the week...

Stakeholder: "What are you doing for next sprint"

Product Owner: "The team thinks we should do function X."

Stakeholder: "That is not what my clients really need, you should really do function Y to accomplish our goal"

Product Owner: "Well, as a result of the experiments we did in our previous iteration we found that your clients actually need function X to be able to reach their goals, and by doing it we have eliminated the need to do function Y and we can reach our goal much quicker."

Summary

Product Owners should avoid going into a backlog maintenance meeting unprepared and not know what priority the different functionalities have to accomplish the final strategy.

Context

You are all working as part of a team, but the PO has to have the strategy outlined in front of them. The PO have to understand how to use what has been learnt previously to accomplish what has been set out to be done.

Problem

A Product Owner who just listens to what the team wants to do, without thinking about the big picture and what really needs to be accomplished.

Forces

Product Owners who are new to Agile, is often falling under the pressure to deliver something, and/or doesn't know exactly how to accomplish the final strategy.

Therefore

Essence of the solution

Product Owners need to be coached on the agile process how to empower the team to do the right work. 

More about the solution

The Product Owner must come into the meeting understanding what needs to be done to accomplish the final strategy. The PO needs to understand what is important, and not let the team dictate what to do without necessarily have the larger strategy in mind.

It is of utmost importance that the Product Owner keeps their "eye on the prize", and can at all times explain both to the team, and the stakeholder, why they are going in the current direction.

Resulting Context (positive and negative consequences)

If the Product Owner let's the team lead the effort from hearsay, or just do what the team thinks would be fun or interesting to do, there is a risk the team will not be finishing what they have set out to do, but instead veer off in the wrong direction. There is also the risk that if the Stakeholder says to do a different function instead the planned one, and what was decided to be done in the next iteration, the team may not feel like they are being listened to or respected.

When the Product Owner knows at all times what the effort is about, and can use what has been discovered during the previous iteration(s), the team may even be able to skip certain steps that was thought they would have to do at a certain stage in the project. Knowing what is the right thing to do, based on earlier experiences, the Product Owner can motivate to, and convince if need be, the Stakeholder and team why they are going to do in the next iteration what has been presented and/or outlined.