ストーリーのスクラム再評価


14

毎日、スタンドアップの後、チームと私は各ストーリーの見積もりを更新します。私たちのやり方に何か問題があると感じているので、あなたの助けが必要です。

これが俺たちのやり方です:

ストーリーAの見積もり:24時間(1日8時間-基準として「理想的な日」を使用)

  • N日:開発者は午前中にストーリーAの作業を開始します(1日の終わりまでに8時間の作業が完了します)
  • N + 1日目:ストーリーAの再推定= 16時間(N日からストーリーAから1営業日を取り除いた)
  • N + 2日目:ストーリーAの再推定= 8時間(N + 1日目からストーリーAから1営業日を取り出した)
  • N + 3日目:ストーリーAはこれまでに完了する必要があります。しかし、そうではありません。開発者は、完了するまでにさらに3時間かかると考えています。ホワイトボードのストーリーを更新し、それに応じてバーンダウンします。
  • N + 4日目:ストーリーAは、わずか3時間ではなく終日かかりました!これで完了です。5時間という違いは、計画ではまったく考慮されていません。

ストーリーを毎日再評価する方法を教えてください。


フォーカスファクターを調整しようとしましたか?見積もりとの正確な相関関係はまだわかりませんでしたが、私が参加したスクラムプロジェクトでは、ほとんどの場合、見積もりの​​不足に対処するのに十分でした
-gnat

回答:


5

5hという違いは、計画ではまったく考慮されていません。

はい、次のタスクが遅延するため、暗黙的に説明されます。その開発者専用のバーンダウンチャートがある場合、開発者が別のタスクを引き受けるのに十分早く終了していれば、曲線は1日間「フラット」のままであることに気付くでしょう。

毎日のミーティング中に再推定する方法に問題はありません。再推定は、各タスクの正確な遅延を追跡することよりも、スプリントの終わりに間に合うかどうかを判断することの方が重要です。毎日計画を調整できるようにするためにスクラムで必要なのは、スプリントの進捗状況と、スプリントの目標をどの程度達成できるかを示すものです(通常、バーンダウンチャート)。


7

あなたが尋ねるべき質問は次のとおりです。

次の速度を計算するときは、アジャイルの「魔法」が反復で過小評価と過大評価のバランスをとるべきだと主張します(これが値を修正する唯一の理由です)。詳細については、Mike CohnのAgile Estimating and Planningを参照してください。

ただし、再評価する必要がある場合があります。仕事のカテゴリについて学んだことが、今後のすべての予測を調整する場合です。

例えば。データベースへの列の追加に1時間かかると推定されているが、だれも考慮ていない要因のために3時間かかることが判明し、データベースにフィールドを追加するたびにその要因が適用されるように見える場合次に、作業中のものを含め、その性質の作業のすべての見積もりを調整する必要があります。


3

私が最も効果的であることがわかったのは:

  • ストーリーのポイントサイズ(またはTシャツのサイズ)。
  • 製品バックログのストーリーをいつでも再評価します(特にスプリント計画の直前)。
  • このスプリントで予定されているストーリーを再評価しないでください-スタンドアップで懸念を持ち出すことは自由ですが、見積もりを変更しないでください。
  • 昨日の天気を使用してスプリントをスケジュールする

ストーリーが偽の推定値でスプリントに入る場合、スプリント前の計画の再推定により、問題になる前に修正できます。チームが楽観的すぎるためにストーリーが予想よりも長くかかっている場合は、昨日の天気が順調に進みます。

あなたの質問で説明したように、残っているものの毎日の再推定は完全に偽である傾向があります。完了/残りの作業は、「十分に」作業しているように見えるように設計された偽の数字です。はるかに良いのは、「いつ完了すると思いますか」と尋ね、ストーリーに問題がある場合、チームが支援のためにステップアップすることを明確にすることです。


仕事の残りの見積もりは、「いつ完了すると思いますか」とまったく同じではありませんか?作業が完了したら、あなたに同意しますが、「ストーリー/タスク完了/未完了」のバイナリ用語以外でそれを実際に測定する必要はありません。
-guillaume31

1

これは問題ではないと思います。むしろ、経験不足かもしれません。スクラムに従うほど、より正確な見積もりを提供するために開発者が慣れます。これは、5か月後にスクラムを実装した経験です。

ポーカーの計画セッションを、私たちの開発者は、非常に多様な各PBIのための推定と最初のスプリントの各タスクを示唆しました。しかし、今では、時間と見積もりはほぼ同じです。スクラムをどのくらい使用していますか?それほど多くない場合は、しばらくお待ちください。しかし、時間が長い場合は、@ pdrが示唆したように、リスクの高いタスクに余分なマージンを追加することを検討してください。たとえば、チームがUIクロスブラウザを作成するたびに、見積もりをパスします。したがって、クロスブラウザータスクの推定値に係数を常に掛けて、それをカバーできることを確認します。


1

スプリント中にコミットされたユーザーストーリーを再評価することは意味がありません。あなたの時間を無駄にするだけです。あなたはすでにコミットメントをしました、そしてあなたが再評価するかどうかは問題ではありません。

異なる状況は、現在のスプリントにコミットされていないユーザーストーリーです。場合によっては、再見積もりを行うことをお勧めします(計画前にスプリントごとに1回のみ)。再見積もりが合理的である理由は次のとおりです。

  • 製品所有者がユーザーストーリーを変更しました
  • プロダクトオーナーがユーザーストーリーを分割または統合する
  • 製品所有者がユーザーストーリーを追加
  • 最後のユーザーストーリーでは利用できなかった追加の知識があります
  • 一部のユーザーストーリーが関連しており、まだコミットされていない別のユーザーストーリーの一部を既に実行していることがわかりました

すべてのユーザーストーリーを必ずしも再評価する必要はありませんが、可能です。完全に再推定するためには、通常、何らかの高速な方法が必要です。ポーカーのプランニングは非常に遅く、非効率的で、退屈であり、10〜20ストーリー以上を見積もると不正確になることもあります。代替手段は、マジック推定です。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.