チームキャパシティを変化させてスプリント速度を推定する方法は？
私たちはスクラムではかなりグリーンな4人の開発者の小さなチームです。全国から来て、私たちは家に帰るためにしばしば奇数日休みまたは一週間休みを取ります。したがって、年次休暇のために、チームのキャパシティは1つの反復から別の反復へと劇的に変化します。これにより、反復ごとに非常に異なる速度が発生します。計画会議で速度を推定するとき、チームのキャパシティをどのように説明しますか？履歴データは非常に異なる容量を反映するため、推定速度の平均を導き出すのに1年も待つことができません。
簡単なアプローチかもしれませんが、容量の測定方法に応じて、速度をcompleted story points * capacityまたはcompleted story points / capacityとして計算してみませんか。工数で容量を測定する場合は、秒を使用します。容量を週40時間の割合として測定する場合は、最初の容量を使用します。ストーリーポイントを引き出すときは、特定のスプリントの容量について十分に理解し、プロジェクトの履歴データを使用して、特定の負荷で完了したストーリーポイントを決定する必要があります。
ただし、これにより、すべての従業員を平等に扱うなど、いくつかの潜在的に危険な仮定が行われます。最もジュニアな開発者が1週間休暇を取る場合、またはドメインやテクノロジーで最も経験のある開発者が1週間休暇を取る場合、容量は同じ数値ですが、速度への影響はおそらく異なります。
最終的には、スプリントを計画するときに、履歴データに基づいて専門家の判断を使用します。この場合、チームを含む他の推定スキームへの入力として以前の速度を使用します。私はまた、注意を怠ります。タスクを実行するというコミットメントを削除するよりも、スプリントに多くの作業を取り込む方が簡単です。
容量が同じでも速度は変化する可能性があります。
したがって、速度を信頼するだけで、それ自体がさまざまな容量を処理します。つまり、3番目のスプリントに参加していると仮定して、最後の2つの完了したスプリントの平均をとって、次のスプリントにコミットします。容量のばらつきを心配する必要はありません。
速度は目安であり、目安ではありません。すべてのスプリントの平均（標準偏差を考慮に入れる）と最悪の3つの平均、最高の3つの平均を取り、「私たちは間違いなくこれらを実行します。これらは実行されるかもしれませんが、実行されません。これらは完了しました。」これらの3つの速度とおおまかな締め切りを使用して、（完全に見積もられた）バックログに3本の線を引きます（12のスプリントで12倍の最悪の速度が75、12倍の最高が120で12倍の平均が90であると仮定します）。100ポイントのバックログ、最悪の場合でも、その4分の3を行うことができます。せいぜい、全体を釘付けにし、平均して、そのほとんどを提供します）。
このデータを使用して、POは必要なすべての決定を下すことができます。
究極的には、物事が変化し、要件が出現し、そしてまあ、物事は再び変化します。特定の数値を取得するために、数学の問題を解読しないでください。この種のことを行うには、正確な範囲で十分です。バックログの計算ではなく、ソフトウェアの問題に集中してください。