あなたのチームは、スクラム プロセスのどの部分で、特定の製品バックログ項目を完了するために必要な労力について、経験に基づいた見積もりを行いますか?
たとえば、スプリント 1 に予定されている「ユーザーは自分のメール アドレスを入力すると、パスワードをリセットするためのリンクが記載されたメールを受け取ることができます」というプロダクト バックログ アイテムがあるとします。
非常に大まかな見積もりでスプリントを開始し、それを改良しますか? この「ユーザー ストーリー」はいつ、プログラマーが時間内に見積もることができる詳細なアクション アイテムに変わりますか? (例: 「1 つのテキスト ボックスと送信ボタンを含む Web フォームを作成する」= 2 時間)
スプリントが始まる前に、より細かく、より正確な見積もりを行いますか? スプリントの開始時？それとも、デザイナー/プログラマーが最終的にタスクにぶつかるたびに、スプリント中に?
通常、見積もりは各スプリントの開始時にストーリーレベルとタスクレベルの2つのレベルで行う必要があります。最良の結果を得るには、製品の所有者とチームが毎回両方を一緒に行う必要がありますが、製品の所有者がいない場合でも、チームがタスクレベルで見積もりを行うことが許容される場合があります。
最初のスプリントでは、スプリントにグループ化されたストーリーと最初の推定予測で構成される合理的なプロジェクトロードマップを作成するために、バックログアイテムの少なくとも80％を見積もる必要があります（プロダクトオーナーはすでに優先順位を付けていると思います）。プロジェクトの長さの。
現時点では、各ストーリーの見積もりは、時間、日、週ではなく、ストーリーポイントなどのサイズの相対的な単位（労力、複雑さ、リスクをすべて同時に含む）を使用して行われます。このフェーズでは、FibonnaciスケールとPlanningPokerを使用します。チーム全体がこのプロセスに積極的に参加することが重要です。
その後、チームは最初のスプリントで完了することができるストーリーの数を推測する必要があります。これは、最初の推定速度（ポイント/反復）になります。通常、推定精度を向上させるために、1か月のスプリントではなく、2週間または1週間のスプリントの長さを使用するのが最善です。最初の計画は、バックログのサイズ、チームのサイズ、およびスプリントの長さに応じて、通常1日または2日かかります。
この最初のストーリー見積もりの後、製品所有者はチームと一緒に、コスト/利益比を最適化するためにバックログの優先順位を付け直したいと思うかもしれません。
最終的には次のようになります。
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 を追加する必要があるか、優先度の低い PBI を削除する必要があるかを示すものであり、完了するものの確固たる「目標」としてではありません。
このように作業することで、計画と設計に費やす時間を大幅に短縮できます。スプリントの開始時に高レベルの見積もりを作成し、スプリントが進むにつれて洗練される可能性があります。
私は自分のビジネスと戦う前に、これについてコメントを得ることに興味があります.