Question

How should a product owner in scrum deal with very detailed questions from the team regarding the features they are implementing that he cannot instantly answer himself? When it would clearly be the faster solution for the developer to directly talk to the customer himself?

I wonder if direct communication between the team and the customer undermines the role of the product owner. I feel like the PO should exclusively represent the customer and therefore answer all questions regarding the requirements - even if that takes longer. Bypassing him seems to weaken him and eventually make him superfluous...

Is there a best practice in scrum?

Was it helpful?

Solution

It is always a good idea (especially in so-called Agile projects) not to stick to some cargo cult or text book telling you "who should (not) talk to whom", but switch on your brain and do whatever works best in a project.

Though the communication between PO and the customer should be the standard (because of the reasons scetched by @PatrickHughes in his comment), you may face a situation where a complex business requirement has to be clarified, and the direct communication between a dev and a business expert will speed up things a lot. In such a situation, one should avoid playing "chinese whisper" with the PO in the middle, and let the dev and the business expert directly talk to each other - for this restricted context.

However, the PO should never be bypassed. Ideally, he takes part in that conversation, probably as a moderator. He can verify the customer does not bring up completly new requirements on the table during the talk, or requirements contrary to what was agreed upon before.

This depends also on the people involved, and the situation. The PO might have enough trust in the specific dev and the customer's expert, to let the two talk alone about a specific topic, and let him or her report what was said afterwards. In another situation, with other people involved, he might prefer to take a more active part. To get this decisions right is the core of good project management.

OTHER TIPS

You have to remember that the customer of the company who employs you as a developer has different goals to the company who employs you.

The product owner has to represent the goals of your company rather the goals of the customer. So if the devs go straight to the customer they can undermine thier own company.

To the developers, the product owner IS the customer. Ideally (and I know that's not always possible) the product owner should be a direct representative of the customer, a domain expert and future user of the system.
That's the best way to ensure you have direct and correct information available and the shortest lines possible into their processes.

Ideal example is probably the team I'm working with now. Product owner is a senior end user and domain expert with full authority to authorise design decisions on the spot (and the willingness and ability to actually do so). He's an integral part of the team and directly assists the analyst and designer in writing the user stories, as well as programmers and testers in building the product by providing near instant feedback on implementation questions and test scenarios.
Lines can't really be shorter than having your future user sitting next to you while coding :)

Licensed under: CC-BY-SA with attribution
scroll top