チームキャパシティを変化させてスプリント速度を推定する方法は？

私たちはスクラムではかなりグリーンな4人の開発者の小さなチームです。全国から来て、私たちは家に帰るためにしばしば奇数日休みまたは丸一週間休みます。したがって、私たちのチームのキャパシティは、年次休暇のために、反復ごとに劇的に変化します。これにより、反復ごとに速度が大きく異なります。計画会議で速度を推定するとき、チームのキャパシティをどのように説明しますか？過去のデータは非常に異なる容量を反映するため、推定速度の平均を導き出すのに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は必要なすべての決定を下すことができます。

究極的には、物事が変化し、要件が出現し、そしてまあ、物事は再び変化します。特定の数値を取得するために、計算に失敗しないでください。この種の場合は、正確な範囲で十分です。バックログの計算ではなく、ソフトウェアの問題に集中してください。