ユーザーストーリーを再推定する必要がありますか？

私の現在のプロジェクトは、途中で分割された「ディスカッション」を持っています- 「このストーリーは当初考えていたよりも複雑です。再推定する必要があります」対「決して再推定する必要はありません。 "。

あなたが再推定する必要があるかどうかについて誰かが光を当てることはできますか？

私見私はあなたが新しい要件やストーリーのために完全に新しいカードを持ち出すことができると想像しますが、戻ってバックログアイテムを再推定することは相対的なサイジングの概念を歪めているようで、バックログを「膨らませる」だけです。

私が取り組んだ1つのチームでストーリーを見積もる際の中心的な部分は、見積もるには大きすぎるストーリーのアイデアでした。つまり、ストーリーに含まれるワークロードは、単一のスプリントの範囲を超えていました。

より多くの情報が手に入るようになるか、チームが最初にストーリーの1つの獣のように見えたものをよりよく理解するようになると、ストーリーを再推定することがよくありました。ほとんどの場合、これには「大きすぎる」ストーリーをより小さな達成可能なストーリーに分割し、代わりにそれらを推定することが含まれます。

これらの「大きすぎる」ストーリーは、サイジングの数値に含まれたり、グラフを焼き尽くしたりすることはありません。

同様に、将来の話に戻る可能性があり、要件をよりよく理解すれば、再推定することができます。ストーリーが達成しやすくなったからといって、ストーリーを再推定するべきではありません（たとえば、一連のフレームワークライブラリを構築した後、依存する作業を簡単に達成できるようになります）。チームはスプリントでより多くの成果を上げることができますが、ストーリーの理解が変わった場合は、ストーリーを再推定することは確かに有効だと思います。

以下はコメントになる予定ですが、私は夢中になりました...

見積もりでは、サイズと複雑さを区別することを忘れないでください。複雑さや難易度ではなく、サイズのみを見積もる必要があります。たとえば、画面にボタンを追加する場合は、常に「1」にする必要があります。つまり、ユーザーに関する限り、ユーザーはボタンを取得しています-サイズは非常に小さいです。実際にC＃（低複雑度、非常に簡単）またはアセンブリ（高複雑度、非常に困難）で実装するかどうかは関係ありません。ユーザーストーリーは同じサイズです。

だから、私はそれがときに理解の変更の再推定する価値があると言うとき、それは機能を実装する方法のご理解が変わったことはありませんが、それは機能が内容をご理解のだで変更されました。

したがって、「ボタンが欲しい」は簡単ですが、後でユーザーが「緑色に変わり、ユーザーにメッセージをポップアップするクリック可能なボタンが欲しい」を意味することに気付くと、より複雑なストーリーになり、再作成する必要があります。推定。

更新 ; 必要に応じて、複雑さではなく「サイズ」で推定することで、私が何を意味するかを詳しく説明します。

この違いを新製品で考えるのが一番簡単だと思います。あなたのチームは、すべてが新しいマルチスクリーンシステムの構築を任されています。ユーザーストーリーの中には、次のような一連のストーリーがあります。

1）画面Aにボタンが必要です。クリックすると、権限のないユーザーにエラーが表示されます。2）画面Bにボタンをクリックしたい。クリックすると、当日が週末の場合にメッセージが表示される。3）画面Cにメニューをクリックします。クリックすると、5分ごとに画面が点滅します。

チームがこれらのストーリーを推定するとき、彼らはそれらがすべてほぼ同じサイズであることに同意し、それぞれをスプリント速度スケールで5ポイントの価値がある「小さな」ストーリーとして推定します。

スプリントが開始され、最初のスプリントでは、プロジェクト、インフラストラクチャ、コアライブラリなどの設定にサイクル全体を費やしているため、チームはこれらのストーリーのいずれも達成しません。さらに、チームにはまだ学習している新しい人がいます。

いくつかのスプリントが行われ、チームはストーリー＃1を満たすスクリーンを1つにまとめました-幸せな日、彼らは5点の速度を達成しました。（平均すると、最初のスプリントが非生産的であるため、スプリントごとに1ポイント）。

これで、次のスプリントのために、インフラストラクチャが整いました。チームには再利用するための画面テンプレートがあり、新しい人が物事に頭を抱えています。このスプリントで、チームはストーリー＃2と＃3をノックオフします。

現在、彼らは1つのスプリントで10ポイントを達成しており、1スプリントあたり平均約4ポイントです。これは、チームの生産性が時間の経過とともに向上していることを示しています。これは、プロジェクトの進化、チームのスキルの向上、コアコードの再利用（書き直しではない）に伴って完全に予想されます。

これは私にとって理想的です。時間の経過とともに速度が急激に低下することを示す、十分に推定されたストーリー（新しいチームメンバーなどの大きな変更がない限り、最終的にはプラトーになります）。

一方、最初にチームがそれらのストーリーを見て、複雑さに基づいてそれらを推定した場合、彼らはすべての立ち上げ作業に加えて、ストーリー＃1が大きなストーリーであることに気づくでしょう。トレーニングが必要な新しい人。ストーリー＃2は中程度です。なぜなら、彼らは少なくともそれまでに途中であり、より簡単であるはずだと考えているからです。そして最後に、ストーリー＃3は小さいです。なぜなら、＃1と＃2が完了したら簡単になるからです。

さて、このモデルで最終的に得られたのは、単に難読化されたTIMEの見積もりです。見積もりは、それがどれほど難しくなるか、および作業を完了するのにかかる時間を考慮に入れており、私たちが知っているように、これはせいぜい困難です。このモデルでは、ベロシティは最初から均一化されており、チームのパフォーマンスの向上を実証することはできません。時間どおりに見積もると、1週間で40時間の作業しか達成できません。そして、あなたは多かれ少なかれ仕事でスプリントを計画するのはばかげているでしょう。チームの能力が向上した場合でも、予約できるのは40時間の作業のみです。あなたは40時間の仕事を達成するだけです。

したがって、C＃でのジョブはアセンブリでのジョブよりも簡単である（複雑さは少ない）が、タスクの「サイズ」は同等に見積もる必要があると指摘した理由。このように、言語を移動する選択、機能の改善（または他のチームダイナミックへの調整）が速度に直接影響することがわかります。

[ 別の更新：優先順位付けへの対処 ]

優先順位付けに関しては、これはサイジング/推定とは別の議論だと思います。単にストーリーの見積もりに基づいてキューを優先するのではなく、さもなければ私たちは小さな仕事をするだけで、より大きく、おそらくはより重要な仕事は決してしません。私が率いるチームでは、スプリントキューを管理する際に複雑さについて日常的に会話しました。POは、一部のタスクが（ストーリーポイントで）「小さい」タスクである一方で、X、Y、Zのために達成するのが難しい場合があることを理解するために与えられます。時々、これらのより複雑なストーリーのいくつかを実装するために、チームの速度が打撃を受けることがあります。他の場合には、POは「まあ、私はむしろこのスプリントに他に5つのものを持っているので、より複雑な仕事を先送りします」と言うでしょう。

難易度の高いストーリーを単純に見積もると、速度が隠されてしまいます。速度の平均を出すために、困難または時間のかかるタスクには常により多くの重みが与えられます。前に述べたように、これは時間推定の別の形式であり、これが推定方法である場合、ポイントトラッキング速度はありません。これは、スプリントの継続時間が常に固定されているため、「速度」は、誤って見積もられた（たとえば、8時間のタスクに1時間かかった）。

それがliitleをクリアすることを願っていますか？

私が再指摘しない主な理由は、それがベロシティの有用性を破壊することです。すべてのストーリーを1ポイントと推定する架空のスクラムチームについて考えます。彼らは毎回約10ストーリーを完了し、平均速度は10です。

振り返ってみると、チームメンバーは、振り返ってみると、ほぼすべての反復を振り返ると、ストーリーの1つが5ポインターであったはずなので、速度を「修正」するようにポイントを変更する必要があると主張します。これにより、速度が最大14になります。

次の計画では、ベロシティは、さらに4つのストーリーを引き受けることができることを示唆しています。彼らが見積もった未来の話の1つが本当に5ポインタである可能性が高いので、彼らはそれが正しくないことをかなり確信しています。残念ながら、彼らはどちらがどれか分かりません。突然、それらは計画には全く役に立たない速度図を持っています。

問題は、速度を10に保っていた場合、推定スキルを考慮に入れることです。以前の反復でのストーリーの10％が実際に5つのポインターであった場合、オッズは将来の反復でのストーリーの10％も同様に過小評価されます。長期間に渡って、すべてが洗い物に出てきます。

速度には単位がないことに注意してください。数値が大きいほど、正確で有用な値よりも優れているわけではありません。自慢する権利が必要な場合は、すべてに1000を掛けるだけです:-)

短い答え：製品の所有者は、チームがコミットするスプリントまで、ストーリーにやりたいことを何でもできます。

したがって、チームが将来のスプリントのためにストーリーを再推定したい場合は、頭がおかしくなります。

スプリントに入ると、作業（および見積もり）が修正されます。

私はこの方法で数多くのプロジェクトに取り組んできましたが、うまく機能します。製品バックログのバーンダウンを実行している場合は、見積もりをバックアップデートするか、少なくとも視覚的に、変更がバーンアップのケースではないことを明確にしてください。

この場合、見積もりが大幅に間違っていた場合は、スプリントをキャンセルしてやり直すようです。もちろん、これはスクラムマスターとオーナーの責任です。見積もりに近い場所に提供する方法がない場合は、上司に正直に言って、決定を下すことができるようにすぐに伝える必要があります。

バックログアイテムを上または下に再推定しても問題はありません。開発は学習プロセスであるため、過去のスプリントで得られた知識に応じて、将来のバックログ項目がより単純またはより複雑になることが予想されます。

多分「速度」（チーム/会社がメトリックとして使用した場合）は、大規模な再推定のイベントでは正確に測定できなかったかもしれませんが、最も重要なことは、再推定演習が未来。予測可能であることが重要なのは、初期の見積もりに制限されるのではなく、最新の情報を使用することです。