最初のスプリントでストーリーポイントをいくつ割り当てる必要がありますか？

チーム内で初めてスクラムを実装するとき、チームの速度がわからないときに、最初のスプリントにあるストーリーポイントの量をどのように決定する必要がありますか？

これは時間の見積もりに基づいており、後の段階でのみポイントを使用する必要がありますか？

あなたが頼る歴史的事実がないので、私はあなたがまったく推測に煩わされないことを提案します。何らかの数式のみに基づいて速度を計算しようとすると、時間の無駄になります。

十分なストーリーを推定し、チームが最初のスプリントでそれらに取り組むようにします。とにかく、彼らは終了したものを終了します。この最初のスプリントの後、実際の速度が得られます。スプリントは1週間（素晴らしい！）なので、非常に早い段階で実際の速度に到達します。

最初のスプリントでどれだけ多くのストーリーポイントを獲得できるか、誰にも言えません。まず第一に、ストーリーポイントはユニットレスの価値です。多くの場合、後から実行されるため、1ストーリーポイント= 6時間などの初期決定を行うべきではありません。また、プロジェクトごとに異なる「サイズ」のストーリーポイントを設定できます。

コミットメントは、製品所有者との計画会議に基づいて行う必要があります。ユーザーストーリーを確認し、POでそれらの詳細を説明します。また、いくつかの受け入れ基準（完了の定義）も提供します。計画会議は（チームのスプリントの長さとサイズに基づいて）時間制限されているため、最初の観察結果は、議論できたユーザーストーリーの数です。POは、POから受け取った情報に基づいて、スプリントで議論できるユーザーストーリーの数を専門的に判断できる必要があります。チームはそれが最初のスプリントであり、まだ何も行われていないことを知っているため、チームはおそらく少量の作業のみをコミットしますが、これは今後のスプリントで増加します。

純粋なストーリーポイントの値は、計画と時間の見積もりに使用しないでください。相対的な複雑さを説明するために使用する必要がありますが、それでも8ストーリーポイントは実際には6-12（フィボナッチ）ストーリーポイントの間の何かを意味する可能性があります。 +初期スプリントの「無駄」（オーバーヘッド）。

主なアジャイルの教義の1つは「Empower People」です。計画とコミットメントは、まさにあなたがチームに与える力です。チームは通勤ユーザーストーリーを配信する責任がありますが、もちろん失敗する可能性があり、最初のスプリントでコミットメントが失敗したことを責められるべきではありません。最初のスプリントはキャリブレーション用です。

1つの方法は、いくつかの中規模のユーザーストーリーを選択し、ポイント単位で任意のサイズを指定し、チームによってタスクごとに分割することです。次に、チームは各タスクを時間単位で見積もります。これを合計すると、ストーリーポイントごとの作業時間のおおよその見積もりが得られます。スプリントの総作業能力を知っていれば、スプリントで理論的に完了できる多くのストーリーポイントを推定することができます。

ただし、これは到達すべき正確な目標として解釈されるべきではなく、最初のスプリントが終わったときにチームの最初の実際の速度が現れたらすぐに忘れてください。

まだ情報がありませんので、推測する必要があります。ただし、同じチームで既にスクラムの外部で作業を行っている場合は、以前の推定経験を使用して推測を導くことができる場合があります。または、時間切れになるまで追加のストーリーを取ることもできます。

とにかく、スプリント計画のためにポイントの見積もりだけに頼るわけではありません。計画中、ベロシティは、スプリント計画を迅速に「提案」するのに役立ち、最終コミットメントを行う前に健全性チェックを支援します。ただし、速度データがいくらあっても、チームは最終的にポイントではなくストーリーにコミットする必要があります。

、心に留め、5×1点物語は1.の非常に小さな値のための1×5点の物語を等しくありませんが彼らは長期的な計画の目的のためにほぼ同等です。

そして、ポイントの主な価値が発揮されるのは、叙事詩やリリースがいつ完了するかを推測する必要があるとき、またはスケジュールされたリリース日に対してプレートが多すぎるかどうかです。

とはいえ、成功したチームは最終的に各スプリントで同数のポイントを計画することになります。ただし、そのスプリント内の特定のストーリーに基づいて差異が発生します。成功したチームは、いくつかの5ポイントストーリーが最初に提案された1ポイントストーリーの5つすべてを実際に相殺しない理由を計画中に明確にすることができます...