How shall developers clarify PBI during its implementation?

Question

Should developers have direct communication with stakeholders during Product Backlog Items implementation for their clarification. Or should all communication go through Product Owner?

On the Scrum Guide we can read the following:

On the one hand the Product Owner should:

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items;

• ...

But on the other hand:

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

So, theoretically the Development Team may communicate with stakeholders for the clarification of the PBI.

But is this a good practice? I always think, that the Product Owner is the single entry point for all requirements.

I see 4 options in this situation:

• Developers may clarify PBIs with stakeholders during implementation. But in that case we have a risk, that the stakeholders view on this PBI may be different than the Product Owner's view (for example, the stakeholder may want to make the scope bigger or thay may have a different view on the aPBI even among themselves). The Product Owner may lose control of the PBIs scope.

• Developers may clarify PBI's only with the Product Owner. This is the way I always work. But in one case I know of, the Product Owner physically doesn't have time enough to do all this work. What shall we do in this case?

• Ask the developers to take more initiative and to resolve all issues at their sole discretion.

• Force to define PBI very well before taking it in Sprint, and after it is taken, forbid the developers to ask any question about it (it's not a joke, it's the real situation. I read about it in this article. Unfortunately, it's only in Russian, so just believe me, that described situation is the real case).

So, how shall developers clarify PBI during its implementation? Maybe exist better solution, than described above?

---

Important note: I'm talking about PBIs, that are already in Sprint, and that need additional clarification during work.

Answer 1

Excellent question:

To answer the question directly, yes, the developers can and should talk with the customer when possible. As you've pointed out though, the logistics of this can be difficult.

Something that is rising in use, that directly addresses this, is the Product Owner Team (also known as the agile business team and the agile customer team).

Product Owner Team: This is a direct recognition that a product owner is often not able to be the "single owner". Whether for lack of knowledge or because there are too many cooks in the kitchen (in large enterprise companies the PO rarely gets final decision).

A POT builds a team around the PO which has as its product the Backlog. The POT's job is to make sure the backlog is well ordered, well defined and meets the definition of "ready" or a story that is able to be picked up and run with by the development team without further work.

The POT is made up of the PO, a technical "architect", a QA representative, and potentially customer support, operations, or even the customer. The technical architect role can either be a senior person with technical and business knowledge (more common in larger companies), actual representatives from the development team or both. This allows a story to be fully explored before you ever get to the Sprint Planning meeting.

The POT is the way I recommend engaging the customer on Product Backlog Items.

Answer 2

As a Scrum Master I encourage team members to talk with the stakeholders. But I suggest they either do it in the presence of the Product Owner or brief the Product Owner as soon as possible after the conversation has finished.

The Product Owner sees the big picture. What sounds like a perfectly reasonable request to a developer might actually be a bad idea in the context of conversations had with other stakeholders.

This is not a critisism of developers. They simply do not have the time to continually bounce ideas off of stakeholders and build an understanding of the market for the product.

The Product Owner role is full time and is very demanding. The developers should look to support the Product Owner at every opportunity, but never bypass them.