直近開催のScrum Alliance認定スクラムマスター研修のご案内
ストーリーポイントの見積りは何故時間の見積りより良いのか
みなさんこんにちは。@ryuzeeです。
よく聞かれるネタではあるのですが、スクラムの父ジェフ・サザーランド氏がストーリーポイントの見積りがなぜ時間の見積りよりも良いかについて過去にブログに書かれたものを意訳・抜粋にて紹介します。 以下の訳文は原文にしたがって、CC BY-NC-SAとします。 原文はこちら
左図: 不確実性コーン 右図: マイクロソフトによるストーリーポイント見積りの正確性
ストーリーポイントを使うとより正確な見積りを得られ、計画の時間を劇的に減らすことができ、リリース日をより正確に予測できるようになり、チームのパフォーマンスの改善の助けになる。 時間を使った見積りは、よくない見積りとなり、システムに大量のムダを生み出し、プロダクトオーナーのリリース計画の妨げとなり、どのプロセス改善が本当に役立っているのかチームがわからなくなる。
新たな興味深い調査結果が公開された。 スタンディッシュグループは過去10年の数千のデータの分析を元にしたプロジェクトの成功確率に関する調査結果の改定を行った。 それに加えて、マイクロソフトはアジャイルな見積りが従来型のプロジェクトの見積りに比べて驚くほど正確であるとの新しい調査結果を示した。
Scrum + Engineering Practices: Experiences of Three Microsoft Teams （スクラム + エンジニアリングプラクティス：マイクロソフトの中の3つのチームの経験から） Laurie Williams, Gabe Brown, Adam Meltzer, Nachiappan Nagappan IEEE Best Industry Paper award winner
時間を使ってプロジェクトを管理している人の多くは、何故ストーリーポイントが良いのかを理解するのが大変だろう。 彼らは、60年以上にわたって世に出てきた業界の文献や最新の調査に基づく基礎的なデータを理解できていない。
まず、プロジェクトの失敗に関する最新のデータをみてみよう。 昨今の国際金融システムの分裂の中で、ITプロジェクトの失敗確率は増え続けている。 最新のスタンディッシュグループの調査では、アジャイルプロジェクトの成功率は従来型のプロジェクトの3倍あると示している。 ジム・ジョンソンは、全てのプロジェクトでアジャイルなプラクティスを全面的に利用することを推奨している。
実際にフォレスターグループの最新の研究でも以下のように言っている。
Common Project Management Metrics Doom IT Departments to Failure （従来型のプロジェクトマネジメント指標はIT組織を失敗に追い込む）
私が一緒に働いているベンチャーキャピタリストたちは、ボードミーティングで正しいガントチャートを見たことがない、と言っている。 問題を掘り下げてみると、スクラムを導入する前はマネジメントチームは誰一人としてチームのベロシティを知らなかった、とも。 チームの生産性を知らないということは、ボードミーティングで正確なリリース計画を立てることに常に失敗してしまうことの根本的な原因だ。
これらのデータが彼らのふるまいを変えてくれると思いたいところだが、多くの企業はそれでも好んで失敗し続けているようだし、プロジェクトマネジメントのやり方を改善するよりも他社に買収されたり破産することを好んでいるようにさえ見える。
ランドコーポレーションの1940年代のレポートでは、人間は時間で見積もることが得意ではないことをはっきり示しており、実際の経験においてもその調査の結果を繰り返し確認している。 彼らは広域デルファイ法とソフトウェア開発の世界では呼ばれる見積りのためのデルファイ法の導入を推奨した。
プロジェクトのリリースのためのマネジメント指標は、生産性を単位とするべきだ。 生産性は収益のための前提条件で、収益や手数料を増やすこと（プロジェクト計画ではしばしば逆のことをやっているにもかかわらず）が本業だと企業はいっている。 少なくともベンチャーキャピタルのグループにとっては、それらは全てお金についての話であり、お金は生産性と製品の品質からなることを明確に理解している。 時間は経費でありできる限り減らされるべきだ。
個人の開発者のパフォーマンスについての一番のデータはエール大学から出されたもので、過去にこのブログでも紹介した。 プロジェクトの中の最高の開発者はあるタスクを1時間で終わらせるのに対して、プロジェクト内の最低の開発者は10時間かかり、全体で見ると25時間かかる人もいる。 チームによって1桁違うということもあるのだ。ラリープットナムの出したデータでは、最も生産的なチームの1時間は、最も生産的でないチームの2000時間にあたる、としている。
完了した作業の時間は、どれだけの機能をプロダクトオーナーが出荷できいつ出荷できるのかをまったく示していない。
大事な指標は、カレンダーの単位でチームが出荷できるストーリーポイントの数値だ。 スプリントごとのこのポイントがベロシティだ。 それゆえに、プロダクトオーナーのために、全てをポイントで見積もり、そうすることで、チームのベロシティにもとづいてリリースのロードマップをプロダクトオーナーが作り、ベロシティが変われば計画を調整するのだ。
ストーリーポイントでの見積りのやり方は時間での見積りに比べて正確でブレのない良い見積りになる。 あるCMMIのレベル5の企業では、ストーリーポイントでの見積りが、典型的なウォーターフォールチームに比べて、見積り時間を80%もカットし、多くの見積りができるようになった。 あるテレコムの会社では、プランニングポーカーによるストーリーポイントでの見積りは、ウォーターフォールの見積りのやり方よりも48倍速くなり、同じかそれ以上に良い見積りができることに気づいた。
ストーリーポイントは、時間での見積りと比べて、速くてより良くて安価な方法であり、高パフォーマンスのチームは、時間での見積りがチームを遅くするムダに見えれば、全部の時間見積りを廃止している。
若干補足しておくと、時間での見積りの面倒くささは
- 時間が規模を表していない
- 時間で見積もると、人によって見積りの結果が異なる。そして調整が面倒
- 時間で見積もると、その時間で終わらせるという約束とみなされやすい
- チームの成長を考慮していないので、プロジェクトが進むにつれてチームの能力があがったときに見積りのやり直しをしなければいけなくなる。
などが挙げられるでしょう。他にも色々あるはずです。 チームがそれなりに成熟していれば時間で見積もろうと、ポイントで見積もろうとあまり差は無くなってくるとは思いますが、最初のうちはポイントで見積もっていた方が分かりやすいと思います。
なお、ストーリーポイントじゃかかるコストが分からないのでは？という質問を良く受けますがそんなことはありません。
スプリント数固定
この場合は、単純に1スプリントあたりの人件費＋固定費あたりを掛け算すれば良いだけです。 この時に、どれくらいの機能が作れるかは、ベロシティによります。 例えば開発チームの平均ベロシティが10で、残り10スプリント開発できるとすれば、開発できる量はプロダクトバックログの上から100ポイント分で、そこから先はたぶん開発できないことになります。 逆に言えば、平均ベロシティがない第1スプリントでは、どのくらいの量が作れるかは分かりません。 第1スプリントが終わってベロシティが測定できた場合も、そのベロシティが安定的かどうかは分からないので、その時点での数値もまだ精度は不明です。 しかし数スプリントを経てベロシティが安定してくれば予測の精度は向上します。
フィーチャー固定
プロダクトバックログがある程度固定化されている場合は、全項目をラフにポイントで見積もれば良いです。 そこで残りのストーリーポイントの合計が200ポイントで、ベロシティが10だとすれば、残り20スプリント必要になるので、20スプリント分の人件費＋固定費が費用になります。 これも上記と同じで、まだ実績のない第1スプリントでの予測精度は低く、スプリントを経るごとに予測が正確になっていくはずです。
