A fully functional, high-performing scrum team includes both a product owner, a scrum master and a development team. The product owner’s formal responsibilities are prioritization and funneling requests from the outside world into the product backlog, while the team and the scrum master grabs work from the backlog and turns it into potentially shippable increments.
However, this is not the full story. Many product owners struggles with the many responsibilities that comes with the role, and therefore – sometimes as a desperate measure to prioritize among their many business activities – delegate a lot of the responsibility to the team and to the scrum master. On the other hand, many teams expect all contacts with the outside world to occur through the product owner, or that they do not need to worry about managing the product backlog (since that is the responsibility of the product owner).
When the product owner delegates too much to the team, it might leave the team feeling abandoned by the product owner. A good team might seize the opportunity to go ahead a prioritize the backlog themselves – which might work, but also might lead to suboptimal end results. A more challenged team might loose their agile practices altogether. After all, what point is there in having a demo, if nobody cares about the results?
Similarily, when the product owner is unable to fulfil the team’s expectations, the product owner might be frustrated by the teams inability to take the initiative. From the product owner’s point of view, it might seem that the team is waiting around to be spoon-fed ready-to-go-tasks.
I think of this as the product owner-team gap. That is, there is a gap between the decision level, where the product owner has the majority of the responsibility, and the operative level, where the teams technical expertise is required to refine and execute work.
This gap might seem superficial, because in no overview of Scrum there is such a gap. In reality, though, it almost always exists, at least at first.
One of the key ingredients in getting the entire scrum team to a higher level of performance, is to make sure that this gap is bridged. Either the product owner understands the importance of taking a step towards the operative level, and makes an effort not only to be present at refinement meetings, sprint planning meetings and so on, but also to truly understand the teams work environment and the teams needs and wants. Or, the team takes a step up to the decision level, and helps the product owner understand and prioritize the backlog. This means – among other things – that the team must make an effort to explain the contents of technical work on a level that the product owner can understand and relate to. The team must also explain why they need a product owner present in their day-to-day work.
For either of these solutions to work, it requires patience, good understanding of agile values and preferrably the presence of an agile coach. Also, a key to success is interest in making it work. Without that, as usual, all approaches will fail.