The Role of the Product Owner in Planning Poker

The Product Owner is essential to planning poker - but not as a voter. Their role is clarifier, not estimator. When that boundary blurs, sessions fall apart.

What the PO should do

Clarify scope. The PO is the authority on what the story requires. When developers ask "does this include mobile?" or "what happens in the error case?", the PO answers.

Resolve priority conflicts. If the team uncovers a fork - "we could do A or B, but not both in one sprint" - the PO makes the call.

Accept or refine the Definition of Done. The PO confirms that the team's understanding of completion matches the business expectation.

What the PO should not do

Vote. The PO shouldn't cast story point estimates. They estimate business value; developers estimate technical complexity. These are different things, and mixing them produces noise.

React to estimates. When developers vote 13 on a story the PO hoped would be a 5, the PO's job is to understand why, not to express disappointment or push back. Visible disappointment suppresses honest estimation.

Explain what you want the estimate to be. This is more common than you'd expect: "I think this should be a 3, what do you all think?" This anchors the team before they've formed their own views.

What to do when the PO is doing it wrong

Coach it directly, in private: "Your reaction when estimates are high is making the team anchor low. Can we try keeping a neutral face during the reveal?"

Most POs aren't doing this deliberately. Once they understand the impact, they adjust.

When the PO is absent

If the PO isn't available for the session, don't estimate stories that require their input. It's better to skip them than to estimate based on assumptions that turn out to be wrong.

The PO who asks questions and stays quiet during voting is the one whose team delivers what they actually need.