ストーリーポイント

2013年7月16日

ストーリーポイントは、アジャイルプロジェクトでストーリーのサイズを決定する際に一般的に使用される単位です。XpVelocityと組み合わせることで、ストーリーの完了時期を予測し、計画を支援する手法を提供します。

作業の見積もりを行う際に一般的なアプローチは、スタッフ時間を単位として見積もることです。例えば、プログラマーが「これには2日かかる」と言うような場合です。アジャイルの初期、特にエクストリームプログラミングコミュニティでは、多くの開発チームが、理想時間のアプローチを適用した場合でも、この方法では有用な見積もりを出すのに苦労していることがわかりました。最も効果的な見積もり方法は、ストーリーを互いに比較してサイズを決め、過去の経験からイテレーションでどのくらいの作業量をこなせるかを判断することだとわかりました。[1]

ストーリーのポイントを決定するには、大まかな相対的なサイズを比較します。「foobarをfibbleする」というストーリーを見積もる場合、既にサイズを決めている類似のサイズのストーリーを探します。「シナジービットを反転する」というストーリーとほぼ同じサイズだと感じたら、「シナジービットを反転する」のストーリーポイントスコアを見て、「foobarをfibbleする」にも同じスコアをつけます。

ストーリーポイントを使用するチームは、使用するストーリーポイントの範囲を小さくします。一般的な例としては、1, 2, 4, 8、または1, 2, 3, 5, 8などがあります。[2] 多くの場合、シリーズの上限の数字は「大きすぎる」ことを示し、さらに分割する必要があります。[3]

ストーリーポイントの割り当ては迅速に行うべきです。見積もりについて意見が異なる場合にのみ議論を行うべきで、その場合はストーリーについて何かが明確になっていないことを意味するため、議論することが役立ちます。ThrownEstimateを使用すると、物事を迅速に進めることができます。

時間に基づいて計画を立てるには、XpVelocityを使用します。

ストーリーポイントの使用を好まないチームもあり、代わりにStoryCountingを使用することを好みます。どちらにも好みはありません。どちらも同様に機能するため、チームが試してみて、最適なものを選択する必要があります。

参考資料

ケントと私は、素敵な緑色の本でストーリーポイントについてより詳しく議論しました。アジャイルにおける計画と見積もりについて説明しているほとんどの書籍では、ストーリーポイントについてより詳細に説明されています。

注記

1: 「ストーリーポイント」は最近よく耳にする名称ですが、長年にわたって様々な用語が使用されており、その恣意的な性質を強調する奇抜な名前が付けられることもありました。特に、Joseph Pelrineの**グミベアー**とJosh Kerievskyの**NUTs**(Nebulous Units of Time)は気に入っています。

2: これはフィボナッチ数列です。

3: 上限の数字を「大きすぎる」と解釈する場合、「8」というサイズは「8以上」を意味します。この上限の数字を完了時間などの予測に使用する場合、最終的に分割されると「8」はあらゆる種類の数字になり得るため注意が必要です。偽の指標番号を使用するのではなく、明示的に見積もりが大きすぎることを示す方が通常は優れています。