Product Owner depending too much on the team

Question

I am a Scrum Master for two different teams. The product owner of one of the teams left recently, so we have a new product owner. The team is fairly experienced with the product. Since the product owner is new to the product she is relying far too much on the team to come up with user stories and also slicing the stories from epics. In the last two to three sprints she has consumed lot of time from the team by scheduling meetings with them, which is resulting in the loss of valuable time for the developers in completing their user stories.

How should I handle the situation as a Scrum Master so that I can address the following problems?

1. What should I do to ensure that the product owner does not eat away the valuable time of the developers?
2. What should I do to make sure so that our product owner becomes effective and be self sufficient so that she will not overly rely on the team?
3. How should I tell the product owner not to interfere with the team on daily basis?
4. How do I tell her this without affecting her morale and also without affecting the relationship with the team and with me?

Answer 1

TL; DR

For the immediate future, you need to spend more time working with the Product Owner and less time focusing on the development team. You and the Product Owner both need to spend a couple of sprints refining your roles and learning to work together, and you both need to gain a better understanding of your respective roles in the Scrum process.

Fix Your Adversarial Relationship

The Product Owner is part of the Scrum Team, not an outsider. You want an engaged Product Owner; many Scrum Teams would be lucky to have the problem of an overly-engaged one.

So, before you do anything else, make sure you understand that the Product Owner is an active member of the team, and that she is ultimately responsible for setting priorities for the project. The development team sets the pace, while the Product Owner defines what should be done at that pace. If she chooses to allocate sprint capacity to additional planning, training, or story spikes, that's her call. Your job is to make sure her priorities are clearly visible within the project, and communicated clearly within the team and throughout the organization.

Involve Yourself More

As a Scrum Master, you have a number of responsibilities. One of them is educating Product Owners on the role they play in the process. Another is actively working with the Product Owner to perform Backlog Grooming to ensure the Product Backlog is in good shape for Sprint Planning.

Here are some ways you can make sure you're holding up your end of the process.

Education is Needed

If your Product Owner is new to the Scrum process, or not engaging properly within the framework, this is an educational task that you are responsible for. Take the time to talk with her about backlogs, sprints, estimation, and the various meetings and artifacts that go along with Scrum.

In particular, you want to take some time to explain about time-boxing, and about the appropriate meetings for discussing new user stories, decomposing epics, estimating stories, and the other things that she wants to do. The things she wants seem reasonable to me; it may just be the fact that she wants to do them outside the framework that's causing you difficulties.

She may also need some advice or guidance on how to develop user stories, or on how to prioritize them in the Product Backlog. You should be providing that advice, and spending some additional time during Backlog Grooming in particular to make sure that her questions are being addressed properly within the framework. The Product Owner and the Scrum Master must be active collaborators, so step up to the plate in this area in particular.

Adjust Your Velocity Expectations

Keep in mind that on-boarding new team members will have an impact on your velocity. That's fine; it's all part of the process. Adjust your velocity expectations accordingly, and make sure you communicate about the adjustments clearly and non-antagonistically with the Product Owner. It is probably more important for the Product Owner to get up to speed with the team and with Scrum than it is to maintain an artificial velocity level for its own sake.

Part of your role is to communicate effectively about velocity, including what it measures, what may impact it, and how changes to the team's velocity may impact project schedules. Your role is not to control the velocity, but rather to report on it and help the organization to use the metric effectively in its planning.

A new team member, especially a new Product Owner or Scrum Master, will have a big impact on project velocity. As the Scrum Master, it's your job to make this impact transparent and visible, and to help set everyone's expectations accordingly.

Leverage Backlog Grooming and Sprint Planning

If your Product Owner isn't getting enough information, or not understanding how to get the right information within the Scrum framework, then it seems likely that you are dropping the ball during Backlog Grooming, and communicating poorly about when decomposition and estimation should be done.

Backlog Grooming is the defined meeting for the Scrum Master and the Product Owner (and sometimes the entire team) to discuss the Product Backlog. Identifying which stories are epics, which stories will probably need decomposition or refinement before being accepted into a sprint, or discussing the priority of backlog items are all constructive topics for Backlog Grooming.

Decomposition happens either here or in Sprint Planning. It's better to do it in Backlog Grooming when possible, but decomposition often happens in Sprint Planning too, simply by virtue of the fact that Sprint Planning is more about near-term, fine-grained planning.

It's your job to facilitate these framework-defined meetings. Especially with a new Product Owner on the team, you may need to shift more of your attention away from the development side and onto the backlog management side in order to get the entire team back on track.

Make the time. It's your job.

Answer 2

1) Accept the fact that the PO needs help and that the developers are the most qualified people to help.

The product owner and the developers together form a team. Nobody's time is more or less important than another. They work together to develop software. The team can't be expected to use their valuable time effectively if they don't have good stories, so it is in the interest of everyone that they work with the product owner to help her create the stories until such time as she's able to do it herself.

2) Schedule more story workshops at appropriate times

Context switching is the enemy of productivity. To avoid too many context switches for story development, schedule an extra story workshop or two. When you do so, schedule them during the time that the team is least productive. For some that means first thing in the morning. For other teams that might mean right after lunch when their bellies are full and they haven't yet gotten back into their flow.

3) Keep your eye on the prize

Remember, your goal isn't to uphold the principles of scrum and to protect the developers "valuable time", it is to help the team to work effectively together. Even more importantly, the goal of the team is to develop quality software. If they need to work with the product owner for a sprint or two to reach that goal, why is that a bad thing?

Answer 3

Remember the Tuckman's group development

Don't forget that adding every new team member sets all the team to the Forming phase in Forming-Storming-Norming-Performing model. There's no way to skip any of these phases, so get ready to be patient and tolerant and share the knowledge.

Cheer the team

Beware the team catching the spirit that PO "consumes their time" – that should be certainly addressed by you and PO, but developers should treat PO as an unexperienced team member, who seeks for help, not a random person, who interferes their job.

What's underneath?

Also it's a good idea to think of the real reasons, that lead to multiple meetings with the team and constant developers' distraction – maybe, existing user stories, test plans and other team artifacts, that would be helpful to familiarize with the project, are far from being in good shape, so questions arise.

Answer 4

I guess I would disagree that training the Product Owner is the responsibility of the Scrum Master. However I think it is the Scrum Master's responsibility to identify any gaps in the Product Owner's current competence for the role.

If the Scrum Master were to take responsibility for all of an organization's competency gaps that affected her team, she would deserve the job description (and pay) of an organizational development consultant. And her team would still need a Scrum Master. Scrum exposes an organization's weaknesses, but by itself cannot possibly remediate them.

That said, as Scrum Master she can and should play a role in facilitating the Product Owner's growth as they practice and perfect their performance in the role. But taking on the responsibility to train them is a distraction for her and a crutch for the organization.

It's easy to mistake co-dependency for facilitation.