製品バックログアイテムの見積もり-チームの速度がなく、チームが新しい場合に、数時間で見積もりを回避する方法
これは事実です：
- 6人からなる新チーム。彼らは新しいチームなので、さらなるスプリント計画に使用できる速度はありません。
問題：
- プロジェクトマネージャーは、プロジェクトがいつ終了するかを知りたいと考えています。ユーザーストーリーが製品のバックログに積み重ねられているので、それらを見積もる必要があります。
私はそれらをストーリーポイントで推定し、スプリント全体でのチームのパフォーマンスを追跡したいと考えています。そうすれば、チームがプロジェクトを完了するときの明確なイメージを得ることができます。
プロジェクトマネージャーは、これらのユーザーストーリーを日/時間で推定したいと考えています。私はそれは良い考えではないと思います。
プロジェクトマネージャは、プロジェクトがいつ終了するかを知りたいと考えています。ユーザーストーリーは製品のバックログに積み上げられており、それらを見積もる必要があります。
プロジェクトは、次の2つのいずれかが発生すると終了します。 1つは、すべての作業が終了し、プロダクトバックログに他に何も残っていないことです。 2つ目は、動作するソフトウェアのデモンストレーションや配信に基づいており、さらに作業を行っても、別のSprintの実行コストを保証するのに十分な価値はありません。
Story PointsとVelocityを使用することは、プロジェクトがいつ完了するかを管理者が計画することではありません。彼らは、チーム外の人のためではありません。これらの概念は、チームが次のスプリントを計画し、適切な量の作業の完了を予測し、適切なスプリント目標にコミットしていることを合理的に検証するために存在します。長期的な予測には適していないか、有用ではありません。おそらく、追加のスプリントを1つか2つまで取得できます。これは非常に不安定であるためです。チームが良くなると、ストーリーポイントのベースラインが変化し進化します。そのため、速度を計算するために、複数のスプリントを振り返ることさえできません。
私のアドバイスは、アジャイルソフトウェア開発と従来のプロジェクト管理手法を混同しないようにすることです。経験主義、適応性、柔軟性、および変化する環境への応答性を受け入れます。価値の提供に集中し、コストが潜在的な残存価値を超える時期を知る。
私たちの世界は不確実性に満ちています。
ソフトウェアの開発またはプロジェクトの管理（好きな名前を付けてください）は、最終的には不確実性を確実性に変換するための集団的な努力にすぎません。
- 最初の不確実性：伝えられたがまだ語られていない期待/欲望、チームのダイナミクスと能力、顧客とのやり取り、技術的な課題、必要な時間などについての可能性があります。
- 最後の確実性：（うまくいけば）素晴らしい製品の前で幸せなユーザーです。この終わりは次のエピソードの始まりになることができます。
私たちは皆、この不確実性に対処しなければなりません。人によって方法は異なります。悪い点も良い点もありません。すべて自分の経験と実践に依存します。
自分のやり方に固執する
ストーリーポイントに慣れている場合は、アプローチに固執してください。現在のメンタルモデルがうまく機能している場合は、別の考え方を採用しないでください。理想的な日や実際の日で作業するには、非常に異なる考え方が必要になります。
チームがストーリーポイントと速度の履歴を推定すると、通常、将来の結果を予測するための信頼できる基盤が得られます。ストーリーポイントを期間中に変換します。それにもかかわらず、それは平均と集合的な経験に基づいた推定値にすぎません。クリスタルボウルでもありません。
特定の課題
特定のケースでは、新しいチームがあり、速度履歴がありません。
しかし、あなたには個人的な経験があります：
- 以前のチームで推定された数百のストーリーを見た場合は、新しいチームのストーリーポイントを、過去に使用された平均ストーリーポイントと相関させることができます。
- ベロシティがないため、新しいチームから期待できるベロシティと過去に経験した平均ベロシティを比較する以外に選択肢はありません。チームのダイナミクスがどのように機能し、サイズとスキルが異なる可能性があるかわからないため、これは難しい点です。しかし、試してみて、楽観的になりすぎないでください。
幸いにも、あなただけではありません。すべてのチームメンバーは、ストーリーポイントの見積もりと速度の両方と、以前のチームと今日のチームとの比較の両方で自分の経験を持っています。したがって、これを集合的な演習にすることができます。ストーリーをストーリーに向けてチームを「調整」した後、期待できる速度を集合的に評価してみてください。多分単一の数ではなく、単なる推定値であることを覚えておくための範囲です。
これに基づいて、最初の推測を行うことができます。ストーリーポイントの総数を速度で除算します。スプリントの数（またはより良い範囲）を使用し、いくつかの反復を追加して、必然的に発見される失われたストーリーに対処します。そして、ここにあなたのプロジェクトマネージャーと話し合う初めての地平があります。チーム期間です。ワークロードで換算するには、6を掛け、1日の労働時間数を掛けます。
仮定なしに予測を開示しない
予測される時間範囲に関連するすべてのやり取りでは、常に想定を思い出し（つまり、ストーリーが大幅に増えることはありません）、エクササイズが不安定になる可能性があることを思い出してください。また、これらの数値に固執するのではなく、信頼性の高い速度の数値が得られたら予測を再評価することを提案するように主張する必要もあります。
現在の時点（製品のバックログが満たされ、チームが組み立てられているが、これまでにスプリントが実行されていない）でも、プロジェクトが完了するまでにかかる時間を示すことができます。バックログに変更はありません。
- ストーリーポイントまたは「理想的な工数」のいずれかで、バックログ全体を推定することから始めます。
- その後、チームに、各スプリントで実行できるバックログの先頭からどれだけの作業ができるかという直感に基づいて、スプリントをいくつか計画するように依頼します。これは、チームが達成できると考える速度を把握するための演習であり、ストーリーの見積もりを合計した後、計画を破棄できます。
最低、最高、平均の「推定速度」に基づいて、完全なバックログを完了するために必要なスプリント数の間隔を計算できます。
たとえば、バックログに1000ポイントがあり、各スプリントで平均80ポイントで50から100ポイントを燃やすことができる場合、推定期間は10から20スプリントで、13のスプリントが最も可能性が高い。
この間隔をプロジェクトマネージャーに次のように提示しますプロジェクトに関する現在の理解、作業の見積もり、およびバックログに変更がないという想定に基づいて、プロジェクトはXとYのスプリントの間で行われ、Zスプリントで最も可能性の高い結果が得られると考えています。いくつかのスプリントを完了すると、結果が変わる可能性があります。
推定プロジェクト期間の間隔を提示することで、プロジェクトがいつ終了するかについて不確実性がどの程度あるかを明確に示すことができます。あなたの仮定（特に、バックログが変化しないという仮定は、ある程度の意味を持つ人なら誰でも知っているはずであるということを無効にする）を述べることでも、そこに役立ちます。