イテレーション0のすべてのユーザーストーリーを推定しますか？
製品バックログが作成され、優先順位が付けられた後、製品バックログのすべてのストーリーを簡単に見積もるつもりですか？製品のバーンダウンチャートを作成するためにはそれらが必要であると思いますが、ストーリーが多い場合、最初は長い時間がかかる可能性があります。
さらに、ユーザーストーリーは、バックログに追加されるときに承認基準を持つ必要がありますか、それとも、ストーリーが製品バックログからスプリントバックログに転送されるときに追加される基準ですか？それらなしで推定することは難しいでしょう。
製品バックログ全体を推定する人を見たことがありません。通常、何が起こるかは、製品のバックログが製品所有者によって継続的に優先されることです。スクラムには、Backlog Refinementと呼ばれる進行中のアクティビティがあり、製品所有者と開発チームが製品バックログ項目を確認し、必要に応じて項目、見積もり、および再注文を実装するための十分な詳細を追加します（おそらく、複雑さまたは技術的な依存関係の理解が深まるためです）。 。スプリント計画によって、かなりの数の製品バックログ項目が絞り込まれ、チームは製品バックログでの優先度に基づいて、十分な数をスプリントに取り込みます。
受け入れ基準は、推定の前に製品所有者が追加する必要があります。受け入れ基準はビジネスニーズ（製品バックログアイテムに関連付けられた機能的ニーズと非機能的または品質属性の両方）に基づいているため、製品所有者はこれらのニーズを各製品バックログアイテムに関連付ける適切な立場にあります。チームがアイテムを正常に完了するために必要だと感じる追加作業がある場合は、見積もりのディスカッション中に追加して、必要なすべての作業が文書化され、見積もりに含まれるようにします。チームは、完了に必要な作業を含めるだけでなく、アイテムの完了を検証および検証して見積もりに含めることができます。
また、「製品バーンダウンチャート」を見たことがない。バーンダウンチャートは通常、プロジェクト全体ではなく、個々のスプリント用です。スプリントの1日目のバーンダウンチャートは、スプリントに持ち込まれた値を反映しています。スプリントバックログのアイテムを実装すると、チャートが更新されて、スプリントに実装する残りの値が反映されます。洗練されたプロダクトバックログアイテムに基づいてプロダクトバーンダウンチャートを作成できない理由はわかりませんが、プロダクトバックログアイテムが追加、洗練、および削除されると、チャートが変動します-これは、スコープを変更するよりもはるかに定期的に行われるはずですスプリントバックログで定義されています。
Thomas Owensの回答に対するあなたのコメントに基づいて、いくつかのポイントを追加したいと思います。私は彼の答えに同意します！
最初の（数少ない）スプリントでは、プロジェクト時間を適切に見積もることができません。多分あなたは 不確かさの円錐 を知っていますか？それは言う：
プロジェクトの最初は、製品や作業の結果についてはほとんどわかっていないため、見積もりは大きな不確実性の影響を受けます。
特にスクラムでは、プロジェクトの実行中に詳細に指定される非常に大きく曖昧な目標/タスク/要件があります。
あなたはおそらく4つのキーワードも知っています：価格、品質、時間と機能。標準プロジェクトは、価格、時間、機能を固定しようとします。品質はこのように影響を受ける可能性が最も高いです。スクラムは、変数をフィーチャーに渡すことにより、品質を固定しようとします。各スプリントの後に製品を出荷できる可能性があるため、機能は（顧客の観点から）他のより重要な機能のために削除または延期される可能性があります。
次に、プロジェクト時間の見積もりについて説明します。 Thomas Owensが述べたように見積もることができます-おそらく、スプリントで終了することを期待するよりも少し多いでしょう。これで、ストーリーの平均的なストーリーポイントを取得するだけで、残りの作業を「推測」できます。ストーリーポイントの総量は非常に信頼できませんが、最初の「推測」があります。
次のスプリントが始まるとき、あなたは別のストーリーのセットを推定しました。少ない（または多分多い）タスクが製品バックログに含まれるようになりました。たぶん、あなたはすでに平均的な話が何をするかについてのより良い考えを持っています。今すぐ見積もりを更新できます。製品変更のストーリーポイントの合計量。そして、おそらく3回目のスプリントの後、あなたはそれが実際にどれだけかかるかについての良い考えを得ます。少なくとも、現在の設定（速度に基づく）ですべての機能を完了することが可能であれば、表示されます。
編集：言及するのを忘れました：製品リリースチャートを BurnUp チャートにすることをお勧めします。
バックログ全体を見積もる必要はありません。最初のストーリーを推定できるように注文されています。
リリース計画とそのチャートを作成する必要がある場合、それをカバーするのに十分なストーリーを見積もる必要があります。したがって、3か月先の計画を立てる場合は、少なくとも3か月分のストーリーを見積もる必要があります。
管理者がリリースレベルで計画できることは非常に重要です。
ストーリーの見積もりは、一般にリリース計画の見積もりよりも速く、いつでも行うことができます。
これらの提案はすべて、かなり大きな想定をしているようです。つまり、ユーザーストーリーは見積もりなしで優先順位を付けることができるということです。私はそれが可能な環境で働いたことはありません-たぶん莫大なお金を持っている巨大な会社です。私にとって、それはVCお金を燃やすための最も速い方法のようです...いくつかのトリクルに役立ついくつかの簡単な果物を構築することなく、最初に最も重要な/不可能なものを構築しようとしていますお金。
次の方法を使用します。
知っていることを推定する
あなたがそうでないものを推定することを拒否し、それをスパイクと呼びます
少なくとも1つのスパイクを実行する必要があることを経営陣に伝えます。スパイクの結果/成果物は、スパイクが作成された1つまたは複数のストーリーの推定値、または学習したレッスンと次のスパイクの推奨される次のステップを示す何らかのメール、ドキュメント、パワーポイントなどです。
ビジネス要件が2、3、またはそれ以上急増した後、チーム全体と経営陣は、これが不確実性に満ちた危険な領域であることをすぐに明らかにします。また、経営陣は見積もりのないものを好まないため、急上昇を優先する傾向があります...彼らは見積もりを求めています。どちらの方法でもうまくいきます。リスクの高い、不確実なストーリーはすべて、リリースの初めに向かって泡立ち始めます。そのため、現実的なものとそうでないものについて、早い段階で誰もがより明確な状況を把握できます。
さらに優れているのは、スパイクは推定値ではなく、私たちのチームが推定されていないものにコミットしないため、スパイクはコミットメントではないことをリーダーシップがすばやく学習することです。
最後のステップ-アプリケーションのさまざまなコンポーネント（UI、データベース、サービスなど）のクリティカルパス...これはスパイクとストーリーを意味します。私はこれが滝のように見えるかもしれないことを知っており、完全なシステムエンジニアリングのクリティカルパスを実行する必要はありませんが、ただ「これにより、これが機能しないようにするか、ブロックします」。並行して実行できること、ブロックされていることなどをすばやく特定する必要があります。これは、リリース計画、スプリントテーマ、マイルストーンを定義するのに役立ちます。
また、バックログ全体を見積もるべきではない、またはどのように誤解を招く可能性があるかについて、ここで共有されている感情に同意する傾向があります。
私の経験では、バックログ全体の見積もりが雑用または誤解を招くものである場合、バックログが大きすぎるか、チームが見積もりに長けていないか、チームが知らないか、リリースが野心的すぎるなどです。月次リリース（6スプリント）。
また、doneには2つの定義があります。ほとんどの人が精通しているものと、「doneの有効な定義」です。皆さんがおそらくおなじみの1人は、私たちにとってかなり緩いです。私たちは、それを発表し、フィードバックを得て、そこから学ぶのに十分なだけの何かが必要です。通常、これはストーリーを「受け入れる」製品所有者です。ただし、製品の所有者がユーザーのプロキシを貧弱にすることは非常に早い段階でわかりました。そのため、実際のエンドユーザーのテストが行われるまで、ストーリーを「検証」しません。快適であると感じ、目立つ否定的なフィードバックを受け取っていないか、いくつかのユーザビリティテストを実施していない場合は、「検証済み」とマークします。検証されたら、これは、自動UIテスト、品質管理などで強化する必要があることを意味します。このユーザーストーリーを具体化したいと考えています。製品の所有者は、ビジネス要件を満たし、ユーザーに問題はないと述べていますそれも。
ユーザーが問題を抱えていなくても検証されない可能性があるため、実際には「スクラップされたコード」リポジトリに配置されるという他の事例を聞いたことがあります。それがアプリの販売に役立たない場合、ユーザーはそれを使用することはありません、ユーザーは必ずしもそれを愛するわけではありません...なぜそれを補強し、維持するためにリソースを費やすのかなど。
バックログ全体を見積もるのは、すべての機能の完了を見積もる必要がある場合のみです。これは、SCRUMを、プロジェクト全体の「終了」日を必要とするプロジェクトと統合しようとしたときに発生します。
バックログ全体に「完了」日は必要ないと仮定すると、次の1〜2回の反復の内容を詳細に見積もり、開発を続行します。バックログを優先するので、それ以上は必要ありません。
製品バックログを優先した後、私は常にすべてのユーザーストーリーをSprint 0のスプリント計画セッションの一部として推定しようとします。1つのスプリント計画セッションでこれを実行するには、ストーリーが多すぎるため、プロジェクトは2、3しかありませんでした。 。これが発生したとき、私たちはストーリーを優先度の順に見積もっていたので、時間がなくなったとき、最初のスプリントで作業するつもりがなかった、優先度の低いストーリーのみを見積もることなく残しました。その後、次のスプリントの計画セッションで残りのストーリーの見積もりを完了することができました。見積もりに貴重な開発時間を無駄にせず、タイムボックス化されたスプリント計画セッションに限定してください。
私たちは、Planning Pokerを通じて到達したストーリーポイントで相対推定を使用します。これにより、プロセス全体が迅速かつ簡単になり、プロジェクトの最初に製品バックログ全体を見積もることがほとんどの場合達成可能になります。
2番目の質問に答えて;ユーザーストーリーに特定の受け入れ基準がある場合、はい、ストーリーの作成時にこれらを追加する必要があります。そうでなければ、あなたが識別したように、正しく実装するのが難しいことは言うまでもなく推定することは難しいでしょう！すべてのストーリーに適用される一般的な承認基準（おそらく、トランザクションの最大応答時間または最小のコードカバレッジ）がある場合、これらは定義の定義で定義する必要があります。これは、各チームメンバーがストーリーの完了を宣言する前に達成する必要がある一連の品質基準を形成します。
個人的には、それが表すデータが誤解を招く可能性があるため、全体的な製品バックログを作成しないことを好みます。新しいユーザーストーリーは常に表示されているはずなので、バックログを完全に焼き払う一方で、バックログにさらに追加することがよくあります。時間の経過に伴う不完全なユーザーストーリーの数または不完全なストーリーポイントの合計を表示することは、必ずしもプロジェクトの進捗状況を正しく表すものではありません。