Scrum Developmentのメーリングリストの最近のスレッドで、 Tri Nguyen氏が尋ねているのは、製品オーナーは、プランニングポーカー に参加すべきかどうか、ということである。大方のコンセンサスは？ Ron Jeffries氏が端的にそれを表現している:
オーナーは、そこにいるべきか？ イェス、何が欲しいかを説明するために。
オーナーは、見積りすべきか？ ノー、彼がそれをコーディングするのでなければ、ノーだ。
すなわち、 プランニングポーカーの間、製品オーナーは、各ストーリーの完了の基準を明確にする責任がある－ 例えば、どの機能が含まれるべきで、どれが外されるべきか、どの標準に従うべきか、など。しかしオーナーは、チームがそのような基準に合わせるのに、どのくらいの工数が必要かを見積もるのを助けるべきでない。定量的な工数見積り－プランニングポーカー の形式で－は、開発チームだけの責任でなければならない。
製品オーナーを プランニングポーカーの場に入れない理由は，単純だ。開発チームメンバーは、次のスプリントで完成させる機能についてコミットする必要がある。もしオーナーがコミットメントに対して不当な影響を与えることになると、チームは、そのコミットメントを本当に自分たちのものとは、言えなくなり、Scrumの自己組織化の力を失うことになる。
しかし、製品オーナーがプランニングポーカーの場で自分の工数見積もりを提供する必要があるような、特別な状況がある。Dan Rawsthorne 氏が指摘するのは:
製品オーナーは，役割であり、人である，ということを忘れないで欲しい。その人は、他の役も演じるかもしれない，その役割の中に、工数見積もりの部分があるかもしれない。
製品オーナーも開発者の場合、実際に、製品オーナーは、プランニングポーカーの場で、工数見積もりに貢献する必要がある。しかし、製品オーナーの役割にかける時間を考えると、製品オーナーで、開発者の仕事もこなせる能力を持つことは、比較的まれである。
製品オーナーは、プランニングポーカーで、チームが提供する工数見積について全く沈黙を守るべきか？そんなことはない。プランニングポーカーは、 製品オーナーと開発チーム間での誤解を検知する、価値あるツールである。これらの誤解は、見つかり次第修正されるべきである。 Henrik Kniberg氏は、彼の本、 塹壕よりScrumとXPの中で、例をあげている：
チームとプロダクトオーナはスプリント計画に満足して、ミーティングも終わりに差し掛かっている。Scrum マスタは「ちょっと待った、この『ユーザ追加』ストーリーだけど、見積が抜けてるね。見積もろう！」と言う。計画ポーカーを何度か繰り返した後、チームが20 ストーリーポイントで合意するや、プロダクトオーナが怒って立ち上がる。「ナニー！？」で、数分の熱い議論の後、「ユーザ追加」のスコープに関するチームの誤解が明らかになる。彼らは「ユーザの追加、移動、削除、検索ができるナイスなWeb のGUI」だと思ってたのが、プロダクトオーナは単に「手動のSQL でDB にユーザ追加する」というつもりでしかなかったんだ。彼らは見積もり直して、5 ストーリーポイントに落ち着いた。
この場合には、プランニングポーカーは、ユーザ ストーリーのスコープについて、ひどい誤解を防ぐ、クロス チェックとして機能している。