スクラムによるストーリーの再推定
stand-up の後、私のチームと私は各ストーリーの見積もりを更新します。私たちのやり方に問題があると感じているので、あなたの助けが必要です。
これが俺たちのやり方です：
ストーリーAの見積もり：24時間（1日あたり8時間-測定には「理想的な日」を使用）
- N日目：デベロッパーは午前中にストーリーAの作業を開始します（1日の終わりまでに8時間の作業が完了します）
- N + 1日：ストーリーAの再見積もり= 16時間（ストーリーAからN日目から1営業日を取り出します）
- N + 2日目：ストーリーAの再推定= 8時間（N + 1日目からストーリーAから1営業日を取り出して）
- N + 3日目：ストーリーAは今までに完了する必要があります。しかし、そうではありません。開発者は、完了するまでにさらに3時間かかると考えています。ホワイトボードのストーリーを更新し、それに応じて burndown を更新します。
- N + 4日：ストーリーAは、3時間ではなく1日で終了しました。これで完了です。 5時間の違いは、計画では完全に考慮されていません。
ストーリーを毎日再評価するにはどうすればよいですか？
違い、5時間は、計画では完全に考慮されていません。
はい、次のタスクが遅れているため、暗黙的に考慮されます。その開発者専用のバーンダウンチャートがあった場合、開発者が別のタスクを実行するのに十分早い段階でそれを終えていた場合、曲線は1日「フラット」のままであるのに気付くでしょう。
毎日の会議中に再推定する方法に問題はありません。再推定は、各タスクの正確な遅延を追跡することよりも、スプリントの終わりにそれを作成できるかどうかを判断することの方が重要です。スクラムで計画を毎日調整できるようにするために必要なのは、スプリントの進捗状況と、スプリントの目標（通常はバーンダウンチャート）からどれだけ離れているかを示すものです。
あなたが尋ねるべき質問は次のとおりです：私達は私達の物語を再推定する必要がありますか？
次の速度を計算するとき、アジャイルの「マジック」が反復の過小評価と過大評価のバランスを取ることを許可する必要があると私は主張します（これが値を修正する唯一の理由です）。詳細については、Mike Cohnの Agile Estimating and Planning を参照してください。
ただし、再推定する必要がある場合があります。つまり、作業のカテゴリについて学んだことが将来のすべての推定を調整します。
例えば。データベースに列を追加するのに理想的な時間がかかると見積もられているが、誰も考慮しなかった何らかの要因およびのために3時間かかることが判明した場合データベースにフィールドを追加するたびにその係数が適用されるように見えます。次に、その性質の作業のall見積もりを調整する必要があります。あなたが取り組んでいるもの。
私が最も効果的であるとわかったのは：
- ポイントごとにストーリーのサイズを決定します（またはTシャツのサイズ。）
- 製品バックログのストーリーをいつでも再見積もりします（特にスプリント計画の直前）。
- このスプリントで予定されているストーリーを再推定しないでください-スタンドアップで懸念を持ち出すことは自由ですが、推定は変更しないでください。
- 昨日の天気を使用してスプリントをスケジュールする
ストーリーがenteringであり、偽の見積もりを伴うスプリントである場合、スプリント前の計画を再見積もりすることで、問題になる前に修正することができます。チームが楽観的すぎるためにストーリーが予想よりも長くかかっている場合、昨日の天気が順調に進みます。
あなたが質問で説明したように、残っているものの毎日の再推定は完全に偽である傾向があります。完了/残り作業は、「十分に懸命に」作業しているように見えるように設計された偽の数値です。 「いつ完了すると思いますか」と質問し、ストーリーに問題がある場合は、チームが支援することを明確にすることをお勧めします。
これは問題ないと思います。むしろ、経験不足かもしれません。スクラムをフォローするほど、より正確な見積もりを提供する開発者が増えます。これは、5か月後にスクラムを実装した経験です。
planning pokerセッションでは、開発者が各PBIと最初のスプリントの各タスクについて非常に多様な見積もりを提案していました。ただし、現在、時間と見積もりはほぼ同じです。スクラムをどのくらい使用していますか？それほど多くない場合は、少し時間をかけてください。しかし、それが長い時間である場合は、@ pdrが示唆しているように、より高いリスクのタスクにマージンを追加することを検討してください。たとえば、チームがUIのクロスブラウザーを作成するたびに、見積もりを渡します。したがって、常にブラウザー間タスクの見積もりに係数を掛けて、確実にカバーできるようにします。
スプリント中にコミットされたユーザーストーリーを再推定しても意味がありません。時間を無駄にするだけです。あなたはすでに約束をしました、そしてあなたが再推定をするかどうかは問題ではありません。
異なる状況は、現在のスプリントにコミットしていないユーザーストーリーの場合です。時々、再推定を行うのが良いです（計画の前に、スプリントごとに1回だけ）。再推定することが合理的である理由は次のとおりです。
- 製品所有者がユーザーストーリーを変更した
- 製品所有者がユーザーストーリーを分割またはマージする
- 製品所有者がユーザーストーリーを追加しました
- 最後のユーザーストーリーでは利用できなかった追加の知識があります
- 一部のユーザーストーリーは関連していて、まだコミットされていない別のユーザーストーリーの一部をすでに実行していることがわかりました
- 等.
すべてのユーザーストーリーを必ずしも再推定する必要はありませんが、可能です。完全に再推定するには、通常、高速な方法が必要です。ポーカーの計画は、非常に遅く、非効率的で、退屈で、推定に10〜20ストーリー以上かかる場合は不正確になることもあります。代替は 魔法の推定 にすることができます。