スクラム-製品バックログアイテムの労力はいつ見積もりますか？
スクラムプロセスのどの部分で、特定の製品バックログアイテムを完了するために必要な労力について、チームは知識に基づいた見積もりを行いますか？
たとえば、Sprint 1でスケジュールされている「ユーザーは自分の電子メールアドレスを入力し、パスワードをリセットするためのリンクが記載された電子メールを受信できるようになる」という製品バックログアイテムがあるとします。
非常に大まかな見積もりからスプリントを開始し、それを改善しますか？この「ユーザーストーリー」は、プログラマーが時間内に見積もることができる詳細なアクションアイテムにいつ変わるのでしょうか。 （例：「1つのテキストボックスと送信ボタンでWebフォームを作成する」= 2時間）
スプリントが始まる前に、より細かく、より正確な見積もりを行いますか？スプリントの始めに？または、デザイナー/プログラマーが最終的にタスクにぶつかったときはいつでも、スプリント中に？
通常、見積もりは各スプリントの開始時にストーリーレベルとタスクレベルの2つのレベルで行う必要があります。最良の結果を得るには、製品の所有者とチームが毎回両方を一緒に行う必要がありますが、製品の所有者がいない状態でチームがタスクレベルで見積もりを行うことが許容される場合もあります。
プロジェクトの見積もり/ロードマップの作成（ストーリーレベル）
最初のスプリントでは、スプリントにグループ化されたストーリーと最初の推定予測で構成される合理的なプロジェクトロードマップを作成するために、バックログアイテムの少なくとも80％を見積もる必要があります（プロダクトオーナーはすでに優先順位を付けていると思います）。プロジェクトの長さの。
現時点では、各ストーリーの見積もりは、時間、日、週ではなく、ストーリーポイントなど、サイズの相対的な単位（労力、複雑さ、リスクをすべて同時に含む）を使用して行われます。このフェーズでは、フィボナッチスケールと プランニングポーカー を使用します。チーム全体がこのプロセスに積極的に参加することが重要です。
その後、チームは最初のスプリントで完了することができるストーリーの数を推測する必要があります。これは、最初の推定速度（ポイント/反復）になります。通常、推定精度を向上させるために、1か月のスプリントではなく、2週間または1週間のスプリントの長さを使用するのが最善です。最初の計画は、バックログのサイズ、チームのサイズ、およびスプリントの長さに応じて、通常1日または2日かかります。
この第1ラウンドのストーリー見積もりの後、製品の所有者とチームは、コスト/利益比を最適化するためにバックログの優先順位を付け直したいと思うかもしれません。
あなたはこのようなものになるはずです：
PROJECT ACME ROADMAP
SPRINT 1 (38 points) <= estimated velocity
--------
Story 1 (21 points)
Story 2 (13 points)
Story 3 (4 points)
SPRINT 2 (40 points)
--------
Story 4 (13 points)
Story 5 (13 points)
Story 6 (8 points)
Story 7 (5 points)
SPRINT 3 (39 points)
--------
...
次のスプリントでは、このロードマップは各スプリントの開始時に何度も改訂され、チームが取得している実際の速度に速度を調整し、必要に応じてプロジェクトの長さを再計算します。チームが進化し、要件が変化するにつれて、ストーリーを再推定する必要がある場合もあります。ただし、ロードマップを改訂する時間は半日以内にする必要があります。
このレベルでの進捗状況は、バーンダウンチャートを使用して関係者に表示される必要があります。ここで、X軸はスプリントであり、Y軸はストーリーポイントです。
スプリント見積もり（タスクレベル）
各スプリントの計画フェーズの2番目の部分は、各ストーリーをタスクに分割するために費やされます。ここで、タスクは本質的に高度に技術的であり、時間を使用して見積もられる必要があります。タスクが8時間より長く見積もられる場合は、何があっても、より詳細なタスクに分割する必要があるというポリシーがあります。結果は、ストーリーごとにグループ化されたタスクを含むスプリントバックログと、X/Y軸がそれぞれスプリントの日数と時間数であるスプリントバーンダウンチャートになります。
次のようになります。
Sprint 8
--------
Story 17
Task 1: 8 hours
Task 2: 6 hours
Task 3: 2 hours
Story 18
Task 1: 8 hours
Task 2: 6 hours
Story 19
Task 1: 6 hours
Task 2: 3 hours
...
したがって、基本的に、これらは各スプリントの開始時に実行する必要がある2種類の見積もりです。通常、最初のスプリントでは、最初のプロジェクトロードマップを作成するためにもう少し手間がかかります。
大まかな見積もりは、この特定のアイテムがチームによって選択されると思われるスプリント計画の前に行う必要があります。通常、コンテキストスイッチ中の製品バックログまたはスプリント中のダウンタイムをチェックして、「ストーリーポイント」の新しいアイテムの概算を行います。これにより、製品所有者は次のスプリント計画の前にそれらに適切な優先順位を付けることができます。
私たちのスプリント計画は通常、新しいスプリントの開始時に2時間にタイムボックス化されます。これは、製品の所有者と会い、バックログからアイテムを選択するときです。それらのほとんどは、大まかに見積もられ、正しく優先順位が付けられています。不足している見積もりはその場で行われ、その後、会社の他のメンバーがこれとPOを認識しているという事実を活用して、この時間枠内でストーリーの「きめ細かい」タスクを実行します（通常は非常に激しい作業です）。利害関係者は、詳細について説明されていないものを整理するために利用できます。
もちろん、実装タスクのシーケンスが計画されたタスクと異なる場合があり、それを調整する必要があり、バーンダウンチャートを再調整する必要がある場合があります。
タスクのバーンダウン
バーンダウン測定には、単にタスクの数を使用します。通常、実際の時間や理想的な時間のようなことをしますが、これは私たちにとって十分であり、いくつかの説明が必要なほど興味深いようです。
これらのタスクの時間を見積もることはありません。重要なのは、理想的な人の日に置いたストーリーのストーリーポイントの見積もり（大まかな見積もり）です。
そのストーリーがどのようにタスクに分割されるかは、チームの分散と一般的な進行状況インジケーターの問題であり、正確な時間の見積もりを作成することはあまりありません。
最終的に、x量のストーリーポイントを処理し、スプリントするチームで実際に利用可能な人の日数に関連して、そこからフォーカスファクターを取得しました。
結局、ストーリーポイントの概算は、ストーリーの選択の基礎となるものです（つまり、スプリントで実行できるspの数）。私たちは大まかな見積もりで良くなる傾向があります-そしてこれは重要だと思います。なぜなら、それはチーム内部であるため、製品の所有者は主にこれに基づいてバックログのアイテムに優先順位を付け、タスクの見積もりには決して基づいていないからです。
タスク自体には明確な時間の見積もりがないため、ストーリーポイントの概算に焦点が当てられます。タスクが一緒になって推定ストーリーポイント*フォーカスファクターよりも時間がかかる場合は、大まかな見積もりを間違って行ったか、ほとんどの情報が利用可能または整理されているはずのスプリント計画中に修正する必要がありました。
現時点では、スプリントが開始される前に、詳細なタスクの内訳と見積もりを作成します。これには2つの理由があります。
1）私たちのビジネスは、見積もりが優先順位を決定するのに役立つことを望んでいます。
2）開発チームは、見積もりを達成し、自然な燃焼から逸脱しないようにというプレッシャーにさらされています。
私の意見では、これはアジャイルである能力を取り除くので間違ったアプローチです。プロセスはもっとこのようにすべきだと思います...
1）企業は、計画会議中に作成されたフィボナッチ数を使用して、優先順位を決定できるようにする必要があります。または、少なくとも開発チームからの「空中の指」の見積もりのみを期待してください。
2）バーンダウンチャートは、プロジェクトがどのように進行しているかを示すガイドとして表示され、PBIを追加する必要があるか、優先度の低いものを削除するかを示し、完了するものの確固たる「目標」としてではありません。
このように作業することで、計画と設計に費やす時間を大幅に短縮できます。スプリントの開始時に高レベルの見積もりを作成しますが、スプリントが進むにつれてそれを調整することができます。
私は自分のビジネスと戦う前に、これについてコメントをもらいたいと思っています。