ストーリーポイントを使用してタイムボックス化されたスパイクを推定する方法
したがって、私のチームと私はスクラムにかなり慣れていないため、今日では、理想的な時間での見積もりからストーリーポイントへと移行しました。すべてが健全な理論的根拠のようですが、タイムボックス化されたアクティビティがあります。これがケースです。非常に複雑なユーザーストーリーがあり、根底にある技術的な未知のものを探るためにスパイクが必要です。理想的な時間は簡単です。1つの理想的な日（理想的な8時間）にタイムボックスで入力します。ここで、速度に向けた探索的作業を説明します。それで、差し迫った質問は、タイムボックス化されたアクティビティにストーリーポイントをどのように与えるかです。制約：過去のデータが正しく収集されておらず、現実を反映していないため、この理想的な1日をストーリーポイントに変換する方法がわかりません。
ここでは個人的な意見ですが、第一に、ストーリーのポイントよりも複雑さの観点から考えることを好みます。ストーリーのポイントは人によって意味が異なる可能性があるため、それらについて話し、それらに基づいて見積もるときに、混乱のポイント（意図的なしゃれはありません！）が発生する可能性があります。
第二に、スパイクの推定について心配する必要はありません。少し時間をかけて（8時間ごとに）、もう一方の端が飛び出すのを確認します。複雑さが何であるかを知ることが目的なので、複雑に割り当てることはできないと思います。それ以外の場合は必要ありません。
第三に、私は速度計算にスパイクを含めません。すべてのスパイクが異なることを期待していて、必ずしもスパイクの結果を期待しているわけではないからです。したがって、その時間を含めると、速度が歪む可能性があると思います。私は、開発者が病気の場合にオフタイムを書くのと同じ方法で、そのオフタイムを書きます。
個人的な意見：
スパイクにポイントを割り当てるべきではないと思います。スパイクの理由は、いくつかの未知数のためにポーカープランのストーリーをポーカーすることができないからです。
あなたのスプリントの「外」にタイムボックスします。
- ストーリーポイントに関して何かを見積もることができないため、スパイクが必要であることに気づく
- 1日（または1/2日）以内に何ができるかを調べてください。
- 1日の終わり（または1/2日）に、見積りの準備ができているかどうかを判断します。そうでない場合2。
これは速度には反映されませんが、追加の手段として「平均スパイク時間」を使用することもできます。スパイクが必要な場合、これは将来の推定量として役立ちます。
速度に向けた探索的作業を説明します。
どうして？ Velocityは探索的作業ではなく、リリースを出荷する前にどれだけ多くの反復が必要かを測定するため、または反復数を固定した場合は、特定の時間内に実行できる作業を測定するためのものです
それで、差し迫った質問は、タイムボックス化されたアクティビティにストーリーポイントをどのように与えるかです。
あなたはしません。タイムボックス化されたアクティビティ、つまりスパイクを実行します。（1）実際のユーザーストーリーにストーリーポイントを付与し、後でスプリントで実行します。（2）複雑/大きなと思われる場合はそれを解除します。
この理想的な1日をストーリーポイントに変換する方法はわかりません。これは、履歴データが正しく収集されておらず、現実を反映していないためです。
スクラムを理解している私が知っている人は誰もこれを行いません。実際のプロジェクトでは、たとえば、3ポイントのストーリーに15時間、5ポイントのストーリーに9時間、つまり、それほど複雑ではないストーリーにより多くの時間を費やすことができます。これはどういう意味ですか？これは、ほとんどの5ポイントストーリーは3時間と比較してより多くの時間を費やすことになりますが、3ポイントストーリーが通常の平均時間よりも多くの時間を要する可能性がある場合、25％の確率と言うことができます5時間の物語。
履歴データを収集すると、3ポイントストーリーで3〜18時間、平均約4.5時間費やしたようなものになります。 5ポイントのストーリーでは、3〜14時間、平均して約10時間費やしています。