ユーザーストーリーを再推定する必要がありますか？
私の現在のプロジェクトは、真ん中で分割された「ディスカッション」を持っています-"このストーリーは当初考えていたよりも複雑です。再推定する必要があります" vs " -見積もるだけで、決して下がらない」 "。
あなたが再推定する必要があるかどうかについて誰かが光を当てることはできますか？
私見私はあなたが新しい要件やストーリーのために完全に新しいカードを持ち出すことができると想像しますが、バックログ項目に戻って再推定すると、相対的なサイズ設定の概念を歪めているようで、バックログを「膨らませる」だけです。
私が取り組んだ1つのチームでストーリーを見積もる際の中心的な部分は、見積もるには大きすぎるストーリーのアイデアでした。つまり、ストーリーに含まれるワークロードは、単一のスプリントの範囲を超えていました。
より多くの情報が手に入るようになるか、チームが最初はストーリーの1つの獣のように見えたものをよりよく理解するようになると、ストーリーを再推定することがよくありました。ほとんどの場合、これには「大きすぎる」ストーリーをより小さな達成可能なストーリーに分割し、代わりにそれらを推定することが含まれる場合があります。
これらの「大きすぎる」ストーリーは、サイジングの数値やチャートを焼き尽くすことはありませんでした。
同様に、将来の話に戻る可能性があり、要件をよりよく理解すれば、再推定することができます。ストーリーが達成しやすくなったからといって、ストーリーを再推定してはなりません（たとえば、一連のフレームワークライブラリを構築した後、依存関係のある作業を達成しやすくなります）。チームはスプリントでより多くの成果を上げることができますが、ストーリーに対する理解が変わった場合、ストーリーを再推定することは確かに有効だと思います。
以下はコメントになりますが、私は夢中になりました...
見積もりでは、サイズと複雑さを区別することを忘れないでください。複雑さや難易度ではなく、サイズのみを見積もる必要があります。たとえば、画面にボタンを追加する場合は、常に「1」にする必要があります。これは、ユーザーに関する限り、ボタンを取得しているため、サイズが非常に小さいためです。実際にC＃（低複雑度、非常に簡単）またはアセンブリ（高複雑度、非常に困難）で実装するかどうかは関係ありません。ユーザーストーリーは同じサイズです。
したがって、変更を理解するときに再推定する価値があると私が言うとき、それは機能の実装方法の変更が変更されたということではなく、機能が何であるかについての理解です変更されました。
したがって、「ボタンが欲しい」は簡単ですが、後でユーザーが「クリック可能なボタンが欲しい緑色に変わりますおよびはユーザーにメッセージをポップアップします。これで、より複雑なストーリーになります。再推定する必要があります。
更新;要求に応じて、複雑さではなく「サイズ」で推定することで、私が何を意味するかを詳しく説明します。
この違いを新製品で考えるのが一番簡単だと思います。あなたのチームは、すべてが新しいマルチスクリーンシステムの構築を任されています。ユーザーストーリーの中には、次のような一連のストーリーがあります。
1）画面Aにボタンをクリックしたい。クリックすると、権限のないユーザーにエラーが表示される。 2）画面Bにボタンをクリックしたい。クリックすると、当日が週末の場合にメッセージが表示される。 3）画面Cにメニューを配置したい。クリックすると5分ごとに画面が点滅する。
チームがこれらのストーリーを推定するとき、彼らはそれらがすべてほぼ同じサイズであることに同意し、それぞれをスプリント速度スケールで5ポイントの価値がある「小さな」ストーリーとして推定します。
スプリントが始まり、最初のスプリントでは、プロジェクト、インフラストラクチャ、コアライブラリなどの設定にサイクル全体を費やしているため、チームはこれらのストーリーを達成できません。そして、チームにはまだ学習している新しい人がいます。
いくつかのスプリントが行われ、チームはストーリー＃1を満たすスクリーンを1つにまとめました-幸せな日々、彼らは5点の速度を達成しました。 （平均すると、最初のスプリントが非生産的であるため、スプリントごとに1ポイント）。
これで、次のスプリントのために、インフラストラクチャが整いました。チームには再利用するための画面テンプレートがあり、新しい人が頭を抱えています。このスプリントで、チームはストーリー＃2と＃3をノックオフします。
現在、彼らは1つのスプリントで平均10ポイントを達成しています。これは、チームの生産性が時間の経過とともに向上していることを示しています。これは、プロジェクトの進化、チームのスキルの向上、コアコードの再利用（書き直しではなく）に伴って完全に予想されます。
これは私にとって、理想です。十分に推定されたストーリーで、時間の経過とともに速度が急激に低下することを示します（新しいチームメンバーなどの大きな変更がない限り、最終的にはプラトーになります）。
一方、最初にチームがそれらのストーリーを見て、複雑さに基づいてそれらを推定した場合、彼らはすべての立ち上げ作業に加えてトレーニングが必要な新しい人。ストーリー＃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を掛けるだけです:-)
短い答え：製品の所有者は、チームがコミットするスプリントまで、ストーリーにやりたいことを何でもできます。
したがって、チームが将来のスプリントのためにストーリーを再推定したい場合は、頭がおかしくなります。
スプリントに入ると、作業（および見積もり）が修正されます。
私はこの方法で数多くのプロジェクトに取り組んできましたが、うまく機能します。製品バックログのバーンダウンを実行している場合は、見積もりをバックアップデートするか、少なくとも視覚的に、変更がバーンアップの場合ではないことを明確にしてください。
バックログ項目を上または下に再推定しても問題はありません。開発は学習プロセスであるため、過去のスプリントで得られた知識に応じて、将来のバックログ項目がより単純またはより複雑になることが予想されます。
多分「速度」（チーム/会社が指標として使用した場合）は、大規模な再推定の際に正確に測定できなかったかもしれませんが、最も重要なことは、再推定の演習でチーム自身の推定が急がれるということです未来。予測可能であることが重要なのは、初期の見積もりに制限されることなく、最新の情報を使用することです。
この場合、見積もりが大幅に間違っていた場合は、スプリントをキャンセルしてやり直すようです。もちろん、これはスクラムマスターとオーナーの責任です。見積もりに近い場所に提供する方法がない場合は、上司に正直に言って、決定を下すことができるようにすぐに伝える必要があります。