In a recent thread on the Scrum Development mailing list, Tri Nguyen asked whether product owners should participate in planning poker. The rough consensus? As Ron Jeffries concisely expressed it:
Should they be there? Yes, to explain what they meant.
Should they estimate? No, not unless they are planning to code it.
That is, during planning poker, the product owner should be responsible for clarifying the completion criteria for each story—e.g., what functionality should be included, what functionality should be excluded, what standards should be met, and so on. But the product owner should not help estimate how much effort it will take for the team to meet those criteria. Quantitative effort estimation—in the form of planning poker—must remain the sole responsibility of the development team.
The reason for excluding the product owner from providing estimates in the planning poker session is straightforward. The development team members need to make a commitment about how much functionality they will complete in the upcoming sprint. If the product owner is able to exert undue influence over that commitment, then the team can't call that commitment truly their own, thus losing much of the self-organizing power of Scrum.
There is one special situation, however, in which a product owner may need to provide his or her own effort estimates in a planning poker session. Dan Rawsthorne points out:
Remember that the [product owner] is a role, and a person. The person may play other roles and, in those roles, may be part of effort estimation.
When the product owner is also a developer, the product owner may, in fact, need to contribute effort estimates to the planning poker session. Considering how much time the role of product owner takes, however, it is relatively rare to find a product owner that would have the capacity to take on development work as well.
Must the product owner remain entirely mute on the effort estimates that the team provides via planning poker? Not at all. Planning poker is a valuable tool for detecting misunderstandings between the product owner and the development team, and these misunderstandings should be corrected as soon as they are detected. Henrik Kniberg, in his book Scrum and XP from the Trenches, gives this example:
The team and product owner are happy about the sprint plan and ready to end the meeting. The Scrum master says "wait a sec, this story named 'add user', there is no estimate for that. Let's estimate!" After a couple of rounds of planning poker the team agrees on 20 story points whereby the product owner stands up in rage "whaaaat?!". After a few minutes of heated discussion, it turns out that the team misunderstood the scope 'add user', they thought this meant 'a nice web GUI to add, remove, delete, search users', while the product owner just meant 'add users by manually doing SQL towards DB'. They estimate again and land at 5 story points.
In this case, planning poker serves as a cross-check, preventing a gross misunderstanding about the scope of the user story.
