顧客からよく尋ねられる質問のひとつに、納品までに要する時間のラフな見積りがある。これはアジャイルチームにとって心地よいものではない。実作業に着手しないうちに製品機能全体を見積もると、間違いが頻発することになる。しかし、たいていの場合、チームはこの問題を避けて通ることはできない。
Jarrod Roberson氏はこう語る。ひとりでプロジェクト全体を見積もってはいけない、それはアジャイルの哲学に完全に反しているためだ。せいぜい言えるのは、チームはコストなどの制約から期日を設定すべきであり、プロダクトオーナーはその日までに何を達成する必要があるか決めるべきである、ということだ。Pascal Thivent氏はこう付け加える。事前に見積るとスコープを固定することになる。これはアジャイルに反している。極端に言うと、アジャイルチームは事前に見積りが必要なプロジェクトに関わるべきではない。
しかし、現実世界はどうだろうか？
アジャイルチームはたいてい、さまざまな意思決定のためにクライアントからラフな見積りを要求されている。Hugo Palma氏はこう話している。
クライアントはみな、ある数のフィーチャーの実装がどれくらいのコストになるのか、少なくとも見積りを求めています。アジャイルに仕事をしているので見積もれない、という意見には賛同できません。そのプロジェクトにどれだけお金がかかるのか、クライアントは大雑把にでも知りたいのです。アジャイルなら、こうした現実世界に適応できるはずです。
Mike Cohn氏も、プロダクトを納品するのにどれくらいの時間が必要なのか、見積りを聞かれるのが普通だと語る。一番のおすすめは、過去のデータが十分そろうまで、少なくともスプリント計画ミーティングで合意されたことがある程度達成できるまでは、見積りを先延ばしにすることだ。そうは言っても、ラフな見積りを要求される場合もある。そこでMike氏はバックログのサンプルを使うというテクニックを提案する。あるサイズのストーリーにかかった平均時間を見つけるのだ。
自分の思う1ポイントのストーリーの平均値を求めると、1ポイント当たり3.2時間でした。タスクに分割される2ポイントのストーリーは1ポイント当たり4.3時間、3ポイントのストーリーは4.1時間、といった具合でした。
これがわかると、プロダクトバックログにある各サイズのストーリーの数にその平均時間を掛ければよいのです。
このテクニックはタスクの特定と見積りで取り込まれた欠陥をすべて引き継ぐことになるので注意するようMike氏は言い添えた。Rob Bowley氏はこうコメントした。ソフトウェア開発は予測不可能で、完了するのに必要な作業量を低く見積もってしまうものなので、サンプルバックログというテクニックはうまくいかないだろう。
このようなことを正当化してはいけません。間違いなく、作業量を大幅に低く見積もって、ソフトウェア開発にかかる費用を低く考えてしまうでしょう。これは組織に金銭上の損害を与えたり、だれかのキャリアを壊すことになります。
Matteo Vaccari氏はこう語る。サンプルバックログによる見積りは数値的に役に立つかもしれないが、結局のところ、チーム成熟度、一緒に仕事をした経験、完了の定義といった、この見積りを役に立たなくする未知の要素が複数あり続けるだろう。
こういう状況について、Martin Fowler氏が提案するような柔軟なスコープ(Scope Limbering)にするという意見もある。このアイデアは、固定スコープでの契約から始めて、徐々にクライアントにアジャイルのメリットを理解してもらい、固定スコープの幻想 (FixedScopeMirage)を打ち砕く手助けをするというものだ。Rob Thomsett氏も倍加ゲームを提案しており、これはMartin氏が説明したものによく似ている。
このように、本当の意味で完全なテクニックはないようだ。いずれも主観的要素や欠点がある。しかし、ラフな見積りが要求されている場面で適用すれば、ステークホルダーは多少なりとも情報を得ることができて、判断を下すのに役立つかもしれない。