ああ！記憶から書くのに適しています。
もちろん、ストーリー ポイントは見積もりに関連しています。スプリントでどれだけのことができるかを把握しようとする場合、ストーリー ポイントは、機能の一部または全体を実装するために必要な「作業」の 1 つの単位です。1 つのストーリー ポイントは、1 日、1 時間、またはその間の何かになります。以下の「見積もり」と「ストーリー ポイント」を混同してしまい、何を考えていたのかわかりません。
私が最初に書いたのは「見積もり」と「ストーリーポイント」でした。私が書きたかった (そして以下で編集した) のは、「ストーリー ポイント」と「ベロシティ」です。
ストーリー ポイントとベロシティは密接に関係しており、それらが連携して「一定期間内にどれだけの作業を完了できるか」という感覚を与えようとします。
例を見てみましょう。
たとえば、機能を数時間で見積もるとします。見積もりが 4 の機能は、1 人で完了するのに 4 時間かかるため、そのような見積もりをすべての機能に割り当てます。したがって、リソースの競合に関しては、その機能、またはその「ストーリー」を 4 ポイントの価値があると見なします。
また、プロジェクトに 4 人がいて、それぞれが通常の週 40 時間働いているとします。しかし、サポート、マーケティング担当者との会話、会議など、彼らの周りで他のことが起こっているため、各人は次のことしかできません。 75% を実際の機能に使用し、残りの 25% を他のタスクに使用します。
したがって、各人は毎週 30 時間利用可能であり、4 人すべてを数えると、その週の合計は 30*4 = 120 時間になります。
また、3 週間のスプリントを作成しようとしているとします。つまり、3*120 時間分の作業を完了することができます。これは、速度、移動速度、完了することができる「ストーリー ポイント」の数です。
速度の単位は、ストーリー ポイントの単位と互換性がある必要があります。「これを実装している間に開発者が消費するカップの数」ではなく、「何時間利用できるか」ではストーリーを測定できません。
次に、合計で 120 点に近いが 120 点を超えないフィーチャのセットを、優先度によってランク付けして見つけようとします。これは単純に、合計が 120 ポイント以上になるタスクに到達するまで、上から下へ累積的に合計することです。ひっくり返った場合は、タスクを含めないでください。
日数や開発者が消費するコーヒー 1 杯を簡単に見積もることができます。これは、数字があなたが行っている仕事の種類を表すのと同じように、実行する実際の作業 (つまり、どのように行うか) に関連している可能性があります。十分な時間があります）。
また、各スプリント後にワークロードを評価して、その 75% という数値が正確かどうかを判断する必要があります。たとえば、やろうとしていたことの半分しかできなかった場合は、機能の見積もりが間違っていたのか、それともワークロードの見積もりが間違っていたのかを調べてください。次に、次のスプリントの見積もりと計画を立てるときに、学んだことを考慮に入れます。
また、機能が大きくなりすぎた場合は、機能を分割する必要があることに注意してください。これの主な理由は、より大きな推定値にはより多くの不確実性が組み込まれているためであり、サブ機能に分割してそれらを推定することでそれを軽減できます. 大きな全体的な機能は、すべてのサブ機能の合計になります。また、さまざまなサブ機能をさまざまな人に割り当てることで、機能を複数の人に分割することもできます。
経験則として、見積もりが 1 日以上かかる機能は、おそらく分割する必要があります。*