Posted

A Product Owner is supposed to be the life behind the project, someone who steers the ship sets the vision and supports the team. But sometimes a Product Owners doesn’t quite live up to the job description.

Perhaps you’re a PO struggling to stay on top of your workload. Perhaps you work in an Agile team with a less-than-effective PO. Either way, here are five things to watch out for, because a PO has the power to derail your project…permanently.

  1. Product Owner Doesn’t Turn Up To Meetings

An Agile team can only be effective if they have support and input from customers. A Product Owner who isn’t available for meetings makes it hard to steer the project in the way it should be going.

For example, you could be part way through a sprint, and managing the best you can without input from your PO. Then they do choose to turn up for a meeting, and you realize you’ve been heading off in the wrong direction.

It’s a hard call for a self-organizing team: stop the work or carry on and hope for the best. If this situation feels familiar, turn to your Scrum Master, if you have one. Ideally, they can work with the PO to help them understand the impact their lack of involvement is having on the team and progress.

  1. Product Owner Makes No Decisions

There are two ways this decision-making issue could go.

A PO needs to be senior enough in the organization to make binding decisions. If you constantly find that your PO has to consult other people before coming back to you with a final position, then you probably have the wrong person in the role.

However, your PO could be senior, accountable, responsible and all that good stuff, but still be personally ineffective and fail to give you timely decisions.

If this is an issue for you, think about what is the root cause of the situation. If you are the PO, are you really giving this work the priority it deserves? And if it doesn’t deserve priority, can you communicate that to the team (sensitively) so that you are at least aligning expectations?

If you sit with the team, is it something to do with how you communicate the decisions to be made? Check that you are being 100% clear about what you expect from the PO so there is no doubt that there is a decision to be made.

  1. Product Owner Doesn’t Link Outside The Project

One of the key roles for a PO is to connect the project, and the product, to what is happening in the rest of the organization. These links help you all understand how the product fits into the bigger picture, and how it supports corporate goals. More important in the short term is being looped into organizational decisions that might affect the work.

Typically, the team focuses on the work at hand and relies on the PO to bring in information that they need to know. Of course, team members can keep their eyes and ears open, and pass information on if they hear about it, but a more reliable channel needs to be the PO.

If the PO isn’t fulfilling that role, the project risks at worse becoming irrelevant, or at best missing some crucial detail that would make the output that bit more of a perfect fit.

  1. Product Owner Fails To Prioritize The Backlog…

…Or prioritizes everything!

Another critical PO role is that of prioritization. If your team is like the Scrum teams we know, your backlog is filled with user stories and your grooming sessions are passionate discussions about what needs to come next.

When the PO fails to help the team set clear priorities for the next work period, then there’s confusion. How do you know what you should be working on next?

Equally, if everything is a top priority that gives you the same problem: when everything is important, effectively nothing is.

Again, get help from your Scrum Master to talk about how backlog grooming should work and why a set of prioritized user stories is key for progress.

  1. Product Owner Blames The Team For Failed Sprints

We hope this doesn’t happen to you, but we are aware of situations where it hasn’t been possible to complete the work in the time set. Then the PO has blamed the team for failing to meet their commitments.

Ideally, you shouldn’t let it get this far. It’s common to renegotiate the goals of a sprint, especially in cases where a feature turns out to be much more difficult than estimated. (There are other reasons this happens too, but inaccurate estimates are the most common, we’ve found.)

Alternatively, you have the option of stopping the sprint early, carrying out your retrospective and regrouping. In both situations, the PO has a role to play in helping the team to get back on track.

We know that neither of these are perfect situations, but they are far more palatable than the blame game. Blaming your colleagues for failure doesn’t help anything and it’s a hugely negative position to get into. A culture that allows blame in this way can quickly spiral into a toxic workplace, with low morale.

And none of us want to work there.

Watch out for these five situations and take early action. The best way to deal with this to have an experienced and confident Scrum Master.

If your Scrum Master, or anyone on the team, needs support, Triumph Strategic Consulting can offer tailored coaching to boost your productivity and success. Give us a call today!