http://martinfowler.com/bliki/ThrownEstimate.html

XPスタイルで計画を行っているのであれば、 見積りに関する開発者間の合意を素早くとる必要があるだろう。 こんなときは、ジャンケンで見積りだ。 ジャンケンで見積りを行えば、みんなの見積りが一致していかどうかがすぐに分かる（一致してればそれを記入し、作業に入ろう）。 また、意見の不一致もすぐに分かる（一致してなければ、機能の詳細についてさらに議論を重ねる必要があるということだ）。

顧客が見積りの必要があるストーリーをまとめている。 以下は、それぞれのストーリーに対する基本的な流れである。

  • 顧客はストーリーの概要を開発者に手早く伝える。

  • 開発者は顧客に質問し、ストーリーへの理解を明確にする。ここでは、どうやって実装するかといった技術的な議論はすべきではない。顧客の視点から見たスコープについて尋ねること。

  • 開発者たちは、そのストーリーが何NUTsかかるかを、エイヤと指の数を出し合って示す。私はこれを「ThrownEstimate（ジャンケン見積り）」と呼んでいる。というのも、指の出し方がジャンケンと同じだからだ。

  • 見積り結果が同じようだったら、書記がそれを書き留める。明らかにバラつきがあったならば、そのストーリーについてさらに深く話し合おう——いまこそ、どのように実装するかといった技術的な問題を取り上げるのだ。

指を何本立てるかについては、いくつかやり方がある。 あるプロジェクトでは、指1本で1NUTs、2本なら2NUTs、3本だとストーリーが大きすぎるので要分割、としていた。 またあるチームでは、指を立てられるのは1〜4NUTsまでで、指5本では大きすぎる、としていた。 いずれにせよ、ストーリーに難題があって見積り不可能だと言えるような”取り決め”を必ず設けておいて欲しい——ほとんどの場合はストーリーが大きすぎることによるものだが、なかにはテストできないからというの場合もあるだろうし、もっと他の問題が原因の場合だってあるだろう。

この方法を採用しているチームは、ストーリーの見積りを非常に早いスピードで行っているとのレポートが出ている。 素直に見積りの出来るストーリーには時間を割かず、 問題のありそうなストーリーに集中して議論を行っているのだそうだ。 この方法だと、全員を見積りプロセスに関わらせることが出来る。それに、なんといっても楽しい。