こんにちは、Habr！ Mike Cohnによる記事「スプリントプランニングにストーリーポイントを使用しない理由」の翻訳を紹介します。
アジャイルの見積もりと計画で説明したように、私は製品のバックログを評価するためのストーリーポイントの大ファンです。 ただし、ストーリーポイントではなく、スプリントバックログを数時間で評価することもお勧めします。 この明らかな矛盾はなぜですか？ 以前にその理由について書きました。 バックログごとに異なる測定単位（ポイントと時間）を使用することをお勧めします。
しかし、私はよく関連する質問をされます。ここで質問したいと思います。
スプリントを計画するためにストーリーポイントを使用していない理由を知りたいです。 ストーリーポイントの速度を測定するポイントは、スプリントでどれだけ取る（または修正する）ことができるかを決定することであると考えました。 長期計画（リリース計画など）にストーリーポイントのみを使用していますか？
ストーリーポイントは長期的な有用な手段であるため、スプリント計画にはストーリーポイントを使用しません。 しかし、ポイントは短期的には役に立ちません。
「平均速度は20ストーリーポイントであり、6つのスプリントが残っているので、これらの6つのスプリントで約120ストーリーポイントを終了します」と言うのが適切です。
チームにとって、「20ストーリーポイントの平均速度があるので、次のスプリントでフィニッシュする」と言うのは不適切です。 これは機能しません。
バスケットボールチームがシーズンの真ん中にいるとします。 これまでに、彼らは41ゲームをプレイし、ゲームごとに平均98ポイントを獲得しました。 「おそらく、シーズンの残りの期間に、ゲームごとに平均98ポイントを獲得するでしょう」と言うのが適切でしょう。 しかし、彼らは特定のゲームの前に言うべきではありません：「私たちは平均98を持っているので、今日98を取ります。」 だからこそ、速度は有用な長期的予測因子であるが、有用な短期的予測因子ではないと言うのです。
速度はスプリントごとに異なります。
だからこそ、チームは製品バックログを見て、できる最も重要なことの1つを選択し、この要素/製品バックログのユーザーストーリーをタスクに分割し、タスクを評価して、自分ができるかどうかを尋ねて、スプリントを計画したいのですこの製品バックログ要素をリリースし、それらが満たされるまで繰り返されるというコミットメント。 ストーリーポイントの議論はありません。 速度の議論はありません。 それは義務の問題であり、製品のバックログのポイントをタスクに分割して評価することで、どれだけ充足できるかを決定します。
チームがこの方法でスプリントの計画を完了すると、知らないうちに追求しているストーリーポイントの数は平均値に近いはずですが、それは変化します。
また、チームが1つのスプリントから次のスプリントまでほぼ同じ時間数を実行することも事実です。 製品のバックログを評価するために使用される単位で示されているように、速度は予約または完了した作業の量の測定を指すために予約されているため、この時間数を指す「容量」という用語を使用します（ストーリーポイントを使用することをお勧めします）
著者について：Mike Cohnは、スクラムソフトウェア開発方法論の著者の1人です。 彼はアジャイルアライアンスとスクラムアライアンスの創設者の一人です。 彼は、企業が高性能なチームを作成するためのアジャイルプロセスと方法の使用を実装および改善するのを専門としています。
参照： アジャイルの推定と計画 、マイクコーン、2005年。
PSスプリントのバックログを時間またはストーリーポイントで評価しますか？
スプリント計画にストーリーポイントを使用しない理由
All Articles