web-dev-qa-db-ja.com

スクラム:スプリントを計画する際の容量と速度

現在のプロジェクトでは、これまでに11のスプリントを完了しました。ほとんどのスプリントでは、十分に燃え尽きておらず、通常、スプリントの終わりに近づくにつれて速度勾配が平坦化して終了します。ただし、最後のいくつかのバーンダウンを振り返ると、次のスプリントに引き継ぐ作業量と一貫しているようです。

現在、キャパシティドリブンプランニングを使用しており、2週間のサイクルで1人あたり50時間を割り当てています。しかし、速度がおおむね一貫しているので、過去のスプリントの平均速度を見て計画の補助として使用する方が良いのではないかと思います。

3
Allan

私の意見では、ここには2つの異なるタイプの計画があります。

速度ベースの計画:通常、速度はスプリントの完了したストーリーポイントとして追跡されます。ストーリーポイントの平均速度の11のスプリント後に良いアイデアが得られ、チームが次のスプリントで達成できる「ポイント」の数を予測できるはずです。

ストーリーの見積もりを行った後、次のスプリントで取り組むことを選択したストーリーの数は、この歴史的なスプリント速度に基づく必要があります。

容量(時間)計画:ストーリーを選択した後、タスクの計画が開始され、何が行われるか、および各タスクにかかる時間の見積もりが開始されます。これにより、何時間の作業が必要であるかを確認できます。チームの平均キャパシティに基づいて、これは最初のポイントベースの計画がまだ軌道に乗っているかどうかを検証するのに役立ちます。

私の考え:主に容量を使用して、特定のスプリント内の実際の可用性を追跡していることを確認します。チームの平均時間は1人あたり約50時間ですが、12月15日以降のスプリントについてはどうでしょうか。突然、多くの人々が休暇と休暇をとっていて、スプリント容量が影響を受けています。このため、チームの現在の能力を推定するために履歴容量を使用するとは思いません。

私のアドバイスは、確立したストーリーポイントの速度を使用して、どのストーリーを採用するかを決定し、リソースの可用性に基づいて次のスプリントの真の容量を構築することです。

3
Jay S