最新のアジャイルチームは、時間ベースの見積もりから、ストーリーポイントを使った相対的な見積もりに推移してきているが、我々はこれからも見積もりが必要なのだろうか？
Michael Dubakov氏は、 以下の理由から、なぜ我々がユーザーストーリーの見積もりを辞めるべきなのかを述べている。
- 見積もりに時間を浪費しないでください
- なぜ長～くかかったかを上位のマネージャーに説明するべきではありません
- 守ることが難しい約束をしないでください
- さらなるプレッシャーを開発チームに与えないでください
- 本当に重要なことに注力してください
Stephen Schwab氏は、見積もりがサイロでの結果とチームベースソリューションを阻害することを心配している。
プロジェクトのコストを決定するために、完全に見積もられたバックログを持つことを期待しているチームである組織を想像してみてください。一見すると、このアプローチはよいアイディアであるように見えます。作業する人は、見積もりを提示して、作業のコストについてよく知っていることが前提になります。
しかしプロジェクトの実際のコストについて本当に知っているでしょうか？すべてのなすべきことに対して、チームの賢いメンバーは問題の解決に動くでしょうか？数人のアナリストが問題を分析して、数週間以内に6ヶ月のプロジェクトの小さなストーリーカードを提示して、よい解決策をが作れるとは考えにくい。彼らは数週間で500のストーリーカードを作ることができるでしょうが、すべてが早期の想定に基づいているでしょう。もし数週間のうちに問題が解決できたとしたら、チーム全体に6ヶ月以上の支払いをする必要はないでしょう。
私には、より多くの将来を予測して、計画を立てて、計画を管理する試みであるように見える。
実際のところ、、完全なバックログの見積もりと（その詳細！）を求めて、規範的な行動を定めることは、アナリスト、ユーザーエクスペリエンス担当者、プロダクトオーナーからのインプットをもとに、ソリューションの構築をしているテクニカルチームメンバーを落胆させることになります。最終的な結果である「解決策」が期待よりも低かったとしても、驚くことはありません。チームは、よい仕事を邪魔されているのですから。
品質は誤った予測と引き替えに、製品に高い品質を期待しているステークホルダーからの要求が発生するごとにする可能性が高い。
コストの"計算"よりも重要なことは、なにか価値のあるものを構築することです。なにか使えるもので、最後にステークホルダーが、拡張や新しいアイディアを実現するときに、同じメンバーに戻ってきて欲しいと望まれるようにすることです。
Mike Cottmeyer氏は、見積もりを擁護する。
我々はマネージャが好きではないし、デスマーチも好きではない。我々は、ソフトウェアの開発は予測できないプロセスであり、見積もりは悪で、我々は見積もるべきではないと結論づけました。本当に見積もりの問題をなくすことはできるのでしょうか？悪い管理問題はあるのでしょうか？
私には見積もりをやめる理由が見つかりません。現実には、あなたのビジネスモデルが緊急を要するものでない限り、ビジネスはの結果は事前に定義した成果物に強く結びついています。あなたがなにかを顧客に売ったなら、約束したものをきちんと作る必要があります。
私たちは、このビジネスモデルについて一日中議論することができますが、もし現実的ならば見積もりが必要です。
見積もりは、レンジと確率を持つ必要があります。想定は、管理して、リスクを軽減する必要があります。我々は、見積もりがどれだけ間違っているかを計測することができ、どれだけ誤差があるかをを予測することができます。
私たちはデータが教えてくれることを無視します。私たちは、チームの実際のパフォーマンスも無視します。成果物に対する多くの競合からのプレッシャー、翌月末に販売する追加機能を追加するための大きなプレッシャー、販売チームが大きな契約を勝ち取るために納品するための大きなプレッシャー。現実を無視した多くのプレッシャー。
本当の問題は、組織の製造能力を過大に評価してしまうことです。本当の問題は、チームのテストされたソフトウェアを構築する確立したキャパシティを尊重するのではなく、「すべてのコストで開発しなくてはならない」という文化にあります。
悪い見積もりは問題を引き起こし、悪い管理は問題を引き起こします。成果物に対する変えられないプレッシャーに直面すると、根拠なき期待と柔軟性のないプロジェクトスケジュール、そしてコミットメントにぶつかります。
Bob Marshall氏は、同じ記事に彼のコメントを残している。
私は、定期的に「なぜ見積もるのか？」と尋ねずにはいられない。みんな共感するが、要件に対する見積もりは、(ほんとどの場合)暗黙的なソリューションである。どうして見積もりが価値を持っていると明確に言えるのか？
多くは、カンバンは見積もりから距離を取っていると信じられており、Karl Scotland氏はシチュエーションを明確にしている。
カンバンチームは、単純に大変だから、見積もりを避けています。いくつかのチームは、低いコストで同じ価値を実現できるため、見積もらない選択をしました。昔のジョークである（「ドクター、ドクター、こうすると痛いです」「もうしちゃいけません」）がいまだに当てはまります。もし見積もりがつらいのであれば、過去の能力から学び、将来の能力の予測をたて、チーム全体の対話と協力を促進する他の方法を見つけるべきです。一方で、見積もりが辛くないか、コストが甚大なのであれば、それをすることが正しい状況なのでしょう。
プランニングのときは、サイジングのためではなく、理解するために分解するべきです。
Jeff Anderson氏は、カンバンの見積もりにおける違いを提供している。
チームの進捗において、作業の種類をよりよく理解して、カテゴリ化することによって、ばらつきを減らすことができる。すなわち、チームAはJavaの拡張、致命的な障害、定型レポートの作業をするといった感じです。
見積もりの最も重要な部分は、作業を小さいピースに分けて、それを終えたとき小さなレンジの違いに気をつける唯一の理由は、議論を誘発することです。
見積もりのアウトプットは、おそらく疑わしく見え、見積もりの本当の価値は、途中で発生するチーム全体の対話である。どんな経験をしてきましたか？