優先度付けや製品のリリース計画のためにアジャイルチームやプロダクトオーナーは見積もりを行う。
long-range planning with user storiesと題した記事で、George Dinwiddie氏はアジャイルを使った予測について書いている。氏はユーザストーリーはチームが仕事をするのに役に立つが、ユーザストーリーを使ったリリース計画はチームにとって労力がかかりすぎると主張する。
3ヶ月(週5日で13週間)をひとつで2日かかるユーザストーリーに分割すると32ストーリーになります。たくさんのストーリーになってしまいますが、同時に複数のストーリーを実装したり、同じようなストーリーが複数あったりすると、さらに大変です。チームの半数がそれぞれのストーリーの実装に関わり、半数のストーリーに1日だけ必要な場合、ストーリーの数は96に増えます。プロジェクトのはじめに96のストーリーを確認して、何が3ヶ月にフィットするか、実現にどのくらいかかるかを考えるのはとても大変です。
氏はかわりに、リリースの見積もりをするためにフィーチャーを使うことを提案する。
フィーチャー(ビックストーリー、エピックと呼ぶ人もいます)をリストにして、おおよその大きさ順に並び替え、経験をもとにして見積もりをします。そして、はじめのフィーチャーを実装しているときに、自分の見積もりが正しかったかどうか確認して、自分の予測を実際の結果に向けて調整します。作業が進めば進むほど、自分の予測を高めることができます。また、まだたくさんの労力を投資していないので、本当に必要な機能についての考えを変える準備ができます。
では、なぜ見積もりが難しいのか、簡単にするにはどうすればいいのか。氏はいくつかアドバイスしている。
フィーチャーのような大きな固まりを見積もるのは、ユーザストーリーのような小さな作業を見積もることと違います。私たち人間は幅広い大きさの物事を一貫して見積もる能力が優れていません。あるフィーチャーを実装するためのユーザストーリーの見積もりの合計が、そのフィーチャーの見積もりと関連を持っている例に遭遇したことがありません。私はいくつかの理由でふたつを別々に考えています。私はいつもフィーチャーの大きさをTシャツのサイズで表現します。フィーチャーについてほとんどわかっていないため、数字では正確に見積もれないからです。ストーリーについては数を数えるだけにとどめます。もちろん、大きさはさまざまです。けれども、問題になるほど大きさがばらついているのではありません。私の経験では、数値的な一貫性を持って見積もりをするより、受け入れシナリオを検証しながら、大きさをそろえる方が簡単です。
Mike Cohn氏はassigning story points at the right time—or not at allというブログ記事で、プロダクトバックログの見積もりにはふたつの理由がある、と書いている。
まず、プロダクトバックログのアイテムを見積もると、プロダクトオーナはバックログに優先順位をつけることができます。見積もりはアイテムのコストを表しています。コストがわからないと、正確に優先順位をつけられません。
見積もりのふたつ目の理由は、プロジェクトの長期的な展開を作るためです。ボスや顧客、クライアントがいつバックログのアイテムが完了するかを知りたい場合、見積もりをしておかなければなりません。同様に、ボスや顧客、クライアントが3ヶ月でどのくらいのバックログを実現できるか知りたい場合も、3ヶ月分に相当するアイテムを見積もっておく必要があります。
プランニングゲームで見積もりするには遅すぎると氏はいう。
プロダクトバックログを見積もるとよくある問題も一緒に解決できる理由もしっておくといいでしょう。正しいタイミングで見積もりができるからです。プロダクトバックログは十分早い段階で見積もることで、プロダクトオーナーが優先順位をつけたり、いつ頃、どのように完了するかを答えられるようになります。
スプリントのプランニング中にストーリーポイントをバックログのアイテムの上に置くのも遅すぎます。ストーリーポイントをスプリントプランニングの最中に割り当てるのには別の問題もあります。しかし、後から割り当てても、プロダクトオーナはスプリントの計画に新しい情報を役立てることができません。
ACMの記事user stories don’t help usersでは、William Hudson氏がリリースの計画がユーザストーリーだけに基づいている場合の問題点を指摘している。
XPでは、ユーザストーリーはプランニングゲームに組み込まれます。(…)しかし、チームがユーザストーリーをもとにして見積もりと計画を作成するつもりの場合、最低でも何をする必要があるか、そしておおよそどのようにやればいいのかを把握しておく必要があります。特に、新しいシステムの場合はそうです。確立されたやり方がないからです。つまり、ユーザストーリーを書く前にシステムの目的や形、大きさなどを念頭においておく必要があるのです。残念ながら、多くのアジャイルの実践では、設計は悪と考えていますアジャイルマニュフェストや“アジャイルソフトウェアの12の原則”ではどのようなことはいっていない(事前の“大きな設計”がよくなく、ざっくりとした設計については悪いとはいっていない)にも関わらずです。まだ成熟していないユーザストーリーに基づく見積もりや計画には信頼性が足りないのはいわずもがなです。
Steve Povilaitis氏はフィーチャーを使った大規模なアジャイルプロジェクトの管理方法について書いている。氏はフィーチャーを使ったリリースプランニングの利点について説明している。
フィーチャーには拡張性が必要です。大きな問題をユーザストーリーだけで対処するのは難しいからです。作るものを表現する中間層のフィーチャーがないとリリースプランニングはとても細かくなってしまいます。フィーチャーがなければ、チーム全体を効率的に動かすことができなくなり、高いレベルの価値や目的についての十分な文脈が得られません。プロダクトを定義し、作ろうとしているものをチームレベルで計画するためにはフィーチャーが必要です。
Michael Carew氏はagile estimating – if the T-shirt fits . . .というブログ記事で、テーマ、エピック、ユーザストーリーの見積もりについて書いている。氏は初期の探索の段階で可能なふたつの方法について説明している。ひとつはTシャツのサイズで見積もる方法、もう1つはAgile Development Unitと呼ばれる単位で見積もる方法だ。
[Agile Development Unit (ADU)]はひとつのスプリントのためのひとつのスクラムチームであり、サポートがつきます。これは必要なリソースの量を把握し始めるのに使われます。また、ADUを買ってきて必要な大きさに調整される場合があります。ちょうど、着ているに従ってコートを切るようにです。
Tシャツの大きさやADUを使った見積もりは作業期間ではなく作業の大きさを示す。これらの見積もりはリリースプランニングの最中にビジネス上の意思決定で活用される。
この時点では膨大な調査に基づいた見積もりはありません。以前の経験から算出した相対的な大きさです。これによって最小限の労力でリリースプランを更新できます。ビジネスに基づいてプロダクトオーナーが決めた優先順位によって、テーマとエピックをユーザストーリーに落とし込み始めます。
ユーザストーリーはストーリーポイントを使って見積もられる。氏は以前に行った見積もりと比較して見積もりのチェックを行うことを推奨する。例えば、Tシャツのサイズとストーリーポイントのサイズのテーブルを使う方法だ。
あるストーリーに対するさまざまな見積もりの中に予期していなかった関係があるかどうか調べるためにテーブルを使います。こうすることで誤解が見つかります。(…) このレベルで誤解が見つかると、理解の相違がはっきりします。次のステップで相違について議論します。
最後に時間を見積もる。
スプリントプランニングの最中にストーリーポイントから時間へ意向します。そこで、実際の時間を使うか、理想的な時間を使うかを決めます。普通は、理想的な時間を使って見積もり、変換要素を使って実際の時間に変換します。この要素を計算するため、スプリントが進んでいる間、計画した時間と実際の時間を比較します。
あなたはどうやってリリースプランニングをしているだろうか。