Scrum issue #08: The Product owner can’t provide enough details

It’s going to happen, sooner or later, but what I would like to write about is the scenario when the issue becomes a repetitive habit.

In some organisations, the role of the Product owner is some sort of promotion or higher step in a corp. career path. A good example would be a development department (a couple of teams), developing complex software (the platform) for internal use within the company. As expected, there would be many clients/users/stakeholders using the platform within the different departments, e.g. the management, sales agents, marketing folks, project and account managers, IT, SYS, HR, etc… They all are going to provide requirements and feedback to fill into the platform backlog. So far, so good.

Let me engage your mind with a tricky question. Who is the most appropriate person for the role of a Product owner in this scenario? To your surprise in many similar cases the manager of the development department will be given the honor. As a result the guy will be overwhelmed with emails and other comms full of requirements and features to feed into the platform backlog. But as he is already a manager, with a lot of responsibilities, do we expect him to clarify and negotiate all those items? Hell, yeah… but it simply does not happen.

As a result during the Grooming sessions you will get used to hear something like ‘And here is a very important story for the next sprint, could you guys groom it a little bit and estimate’… then the team start asking questions and the answer is ‘It comes from Melinda – the chief of Marketing and unfortunately I can’t offer any more details than what she wrote, maybe you could find some time and talk to her before the next sprint planning.’

Okie-dokie… in Agile we are used to the team effort and support and as we love our Product owner we accept him as part of the family, even if he is not developing and delivering stories. And we are going to help him, either the Scrum master or somebody from the team is going to speak to Melinda, clarify the stuff and contribute to the story or the acceptance criteria. In the best possible scenario it works … almost ok.

And let me explain why… The role of the Product owner in Scrum is similar to the role of the Executive in PRINCE2, or the Lead project manager for a project. He is the budget holder, and he is responsible to approve the requirements, the priorities and deliveries negotiations with all the clients, users, parties and stakeholders. He also is solemnly responsible for the approval of the deliveries. Difficult job indeed. In our scenario the Product owner should trust the team’s ability to catch Melinda’s explanations completely and to manage her expectations well. Surprise, surprise – in the end of the sprint the story delivery and approval only led to a new story (rework of the last sprint item), and Melinda communicated she is not happy with the delivery. And it happens again and again with different stakeholders.

What could be done better?

• Convince the Product owner to dedicate more time understanding the stories, the business value and the use cases. He needs to work closely with all the clients and users. Will be difficult – he is a manager already spending a lot of time, for example with the higher level management (his boss)
• Invite Melinda for the next grooming or planning session to explain the story and negotiate acceptance in the presence of the Product owner. Sounds good … if Melinda is available. (if not - ask for a somebody to represent her)
• Invite Melinda for the sprint review. Still the Product owner will approve the story, but Melinda might come up with a follow-up story and requirements based on the functionality delivered
• Don’t be afraid to ‘interrogate’ the stakeholders – for example ask the ‘five whys’ to get to the root of the use case and what the users really want to achieve
• Negotiate deliveries with the stakeholder. Almost all features consist of more and less important parts – reduce scope and commit to deliver only what is needed today (and tomorrow)
• Have the Product owner presence be some sort of assurance (to the stakeholder and the team) regarding the clear commitment
• Assign more Product owners (be careful). It’s not ideal but for a complex product like ‘the platform’ there might be a product owner for each team and a ‘chief product owner’ to resolve conflicts (for example priority ones). Those ‘team-product-owners’ should be empowered and would be expected to dedicate full time working with the clients/users/stakeholders and the team on the other side
• Don’t rely on written information only. It’s all about conversation and negotiation for each story

And to answer the tricky question above:
The most appropriate person for a Product Owner is a business person, who communicates to clients and users on a daily basis. A person, who communicates clearly, negotiates with ease, manages own time well and is not afraid of taking responsibility for his decisions. Account manager or project manager, business analyst, even sales person in some cases could make a good product owner. Technical knowledge is usually not required, and user empathy and the ability to clearly understand what the user would like to achieve is. Depending on the product you would expect at least 50% of the person’s time to go for PO activities (in our scenario it would be at least 95% to manage the amount of stakeholders).