スクラムでの見積もり(ストーリーポイント)

この記事ではスクラムにおける見積もり、ストーリーポイントについてのお話をします。見積もりについて多くの開発現場では作業工数を用いて見積もりをするケースが多いと思います。スクラムにおいてはストーリーポイントを用いて見積もりをしているケースが多いと思います、本記事ではその見積もり、ストーリーポイントについてお話します。なお本記事は以下書籍を参考にしつつまとめています。ぜひ合わせてご覧ください。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

新品価格￥3,456から (2019/1/16 21:35時点)

見積もり

まず見積もりは外れることがある、という認識を持つことが大切だと僕は思っています。

あくまで見積もりだよね、ということと時間を多くかければ精度が上がるものでもないということは大切な点だと思いますので少なくとも所属しているチーム内などでは認識合わせができているといいかと思います。

ずっと見積もり作業をしていても精度が上がるものでもないですよね、この点については下記不確実性コーンを見ても初期の段階では見積もりの精度が非常に低いことがわかります。

出典：プロジェクトの本質とはなにか(不確実性コーン)

さて、アジャイル開発の現場での見積もりの話ですがアジャイルの開発手法において前述のようにポイントを用いた見積もりをするケースが多いでしょう。ただ、ポイントを用いた見積もりはあくまで手段です。その本質的な理由については個人的にはアジャイルな見積もりと計画づくりに記載のある内容がシンプルで腹落ちしています。

見積もりと計画づくりがアジャイルでないのに、プロジェクトがアジャイルであるということはありえない。出典：アジャイルな見積もりと計画づくりイントロダクションより

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

新品価格￥3,456から (2019/1/16 21:35時点)

開発手法をアジャイルに変えたのであれば計画づくり、見積もり方法も変える必要があるよね、という話です。

なぜポイントを用いるのか

さて、ではなぜポイントを用いた見積もり方法を用いるのでしょうか。

こちらについてデータを見ながらお話していきます。下記はマイクロソフトでのポイントによる見積もり精度に関するデータです。

出典：Scrum + Engineering Practices: Experiences of Three Microsoft Teams

真ん中の赤いラインが実際にマイクロソフトのチームがプランニングポーカー(後述)を用いて見積もりをした結果になります。横軸が時間軸、縦軸が見積もり誤差です。初期の段階から見積もり誤差が少なく抑えられていることがわかりますね(下記論文内の内容を意訳しています)。

The Microsoft teams felt the use of Planning Poker enabled their team to have relatively low estimation error from the beginning of the project. Figure 1 depicts the estimation error for Team A (the middle line) relative to the cone of uncertainty (the outer lines). 出典：Scrum + Engineering Practices: Experiences of Three Microsoft Teams

これらのデータを見てもポイントを用いた見積もりが非常に効果的であることがわかるでしょう。不確実性コーンのデータを見てもここまで初期の段階から見積もり誤差を抑えられるのであれば使わない手はないですよね。また、ポイントを用いた見積もり、プランニングポーカーには他にもいい点があります。