ストーリポイントを使った見積が役に立っていないのではないか、と思ったあるチームが、#NoEstimateを試してみることにした。ストーリをより小さなタスクに細分化することで、ベロシティに対する洞察が生まれ、予測可能性を高くすることができる。プロセスに要する時間を低減して、価値の提供により多くの時間を費やすことも可能になる。
RuntasticのテクニカルプロダクトオーナであるソフトウェアエンジニアのAndre Schweighofer氏はLean Agile Exchange 2020で、自らのチームでストーリポイントを使用した経験と、#NoEstimatesを試行した成果について講演した。
それまでの見積プロセスは実際のユーザストーリとは関係のない時間とエネルギを要する上に、その結果はそれ程有用なものではなかった、とSchweighofer氏は言う。スプリントの計画日にはさまざまな問題が持ちあがり、有意な予測を立てるにはベロシティの粒度が不足しているような状況だった。このために、ストーリポイントやベロシティではなく、それぞれの直感に基づいたスプリントスコアに関する議論が、延々と続くことになっていたのだ。
レトロスペクティブでの議論をもとに、氏らのチームは#noestimateをトライすることにした。
まず最初に、ユーザストーリをもっと小さな、基本的に独立した実装ステップであるタスクに分割することで、実行する必要のある作業を明確化しました。
#noEstimatesによるメリットは、同じ結果を得るためのプロセスが少なくてすむことと、ユーザへの価値提供により多くの時間とエネルギを割り当てられることだ。
スループットによる予測に基づくようになったことで、作業を容易にすることが、予測可能性を高める上でも有効であることが分かりました。その最もよい例が、ストーリをタスクに細分化したことです。実装ストラテジ上の必要から実施したのですが、短期的な予測にはこれが理想的なベロシティになりました。これによって、作業がいつ終わるのかを予測するよりも、実際に作業を終わらせることに集中できるようになったのです。
見積を要求された場合には、データを取り出してデータ駆動の予測を立てることが可能である。その予測が有効でなければ、バックログの増加率、範囲の変更(descoping)、ベロシティ改善の方法などを議論すればよい、とSchweighofer氏は言う。
InfoQはAndre Schweighofer氏に、見積に関して氏らが抱えていた問題点、#NoEstimatesを試した感想、見積に使用するメトリクス、この経験から学んだこと、などについてインタビューした。
InfoQ: どのような方法で見積していて、どのような問題があったのか、説明して頂けますか？
<a0>Andre Schweighofer</a0>: どちらかといえば一般的なアプローチです — フィボナッチ数列でストーリポイントを使用して、バックログの詳細化ではプランニングポーカーを使って見積に合意していました。
理屈の上では、プランニングポーカーを使えば、ユーザストーリに関する有意義が議論ができるはずなのですが、実際には見積プロセスの方が話題になることが多かったのです。ストーリポイントとは正確には何なのか、なぜ、どのように使用するのか、という点についての共通理解を作り上げることが、特にチームが絶えず変化する状況においては、想像していた以上に難しい作業であることが分かりました。
ベロシティを追跡対象にすることには、チームの成果ではなく、チームのアウトプットが重視されるという問題もあります。ストーリポイントを消化して、ベロシティが向上するさまをバーンダウンチャートで見るのは気分がよいかも知れませんが、1,000ストーリポイントを消化してもユーザに何の価値も提供していない状況もあり得るのです。
InfoQ: #noEstimateを試してみようと思ったきっかけは何でしたか？
Schweighofer: 私たちは見積プロセスについて、レトロスペクティブで何度も議論してきました。ベロシティをもっと詳細にするために、より詳細な参照ストーリを見つけようとしたこともあるのですが、そうしてできた最小のストーリはもはやユーザストーリではなく、プロセス全体が不自然なものに感じられるようになったのです。ストーリを細かいチャンクにスライスすることも試したのですが、同じ問題に行き当たりました。
そのような中、あるレトロスペクティブで、チームメンバのNatraliaが#noEstimateの話題を持ち出したのです。見積プロセスに時間を要することがなくなる、という当然のメリットと合わせて、予測が不正確になるのではないかという懸念への対処についても議論しました。どちらにせよ、スプリントはうまくいったりいかなかったりしていたので、一度試してみよう！ということになったのです。
InfoQ: 実験はどうでしたか？
Schweighofer: 最初にほっとしたのは、これでもうプランニングポーカーをする必要はない、ということでした。会議にトランプを持っていったからといって、会議が楽しくなる訳ではないのです。それと同時に、これまでよりもユーザストーリに注意が集中するようになりました。要するに、難しい議論を先延ばしにして、代わりに見積プロセスについて話をすることがなくなったのです。
最も意外だったのは、予測可能性が実際に向上したという事実です！私たちはユーザストーリを、もっと細かなタスクに分割するようにしました。個々のタスクは、概ね独立的な実装ステップです。このタスクこそが、私たちの探し求めていたベロシティだったのです。これまでのベロシティよりも詳細であっただけでなく、さらに重要なこととして、タスクがベロシティのメトリクスを目的として分割したものではない、という点があります。あくまでも実施しなければならない作業を明確にする目的で、ストーリを分割したものがタスクなのです。この予測可能性は思わぬメリットになりました。
イメージ: プロジェクトの予測。青緑色(ターコイス)の線: 配信されるストーリ(6ストーリ/スプリント)。青色の線:プロジェクトスコープ(2ストーリ/スプリントの割合で増加)。赤色の線:当初のプロジェクトスコープ。バックログの増加率を考慮すれば、最初のスコープを提供し終えた時点で、プロジェクトは⅔しか進んでいないことが分かります。
この結果に驚いたので、同じアプローチをエピックのリリース期日の予測にも適用してみました。エピックでは、スプリント毎のユーザストーリの数をベロシティとしてチェックすると同時に、バックログの増加率を考慮した場合についても十分に正確な見積もりを行うことができました。スコープのクリープを視覚化し対処する上で有用であるため、バックログ増加率は重要なのです。
InfoQ: 現在の見積では、どのようなメトリクスを使用しているのでしょう？
Schweighofer: スプリントはまったく使用していません。現在はかんばんワークフローを使っています。これに伴って、スプリントの予測もまったく不要になりました。プロジェクトのリリース日のような長期的予測に関しては、週毎にデリバリするストーリ数の平均とバックログの増加率を使用しています。
最上位の計画についても、同じアプローチを適用しています。四半期に実行されるエピックの数をチェックして、これを次の四半期の予測に使用するのです。そしてこれが、ステークホルダに対するコミットメントの基本になっています。
InfoQ: どのようなことを学びましたか？
Schweighofer: 問題を見て見ぬふりをするのは簡単なのですが、今回私たちは、最も奥底にあった仮定に疑問を持ったことによって、繰り返し発生していた問題を乗り越えることができました。見積プロセスには常に問題意識を持っていたのですが、見積自体の必要性に疑問を持つには時間が必要だったのです。リリース期日を予測する最高かつ唯一の方法が見積なのだと、私たちは思い込んでいました。アジャイルチームはそうするものだ、と思っていたのです。しかしながら、レトロスペクティブを通じてこれに疑問を持ち始めたことから、素晴らしい結果を得ることができました。
人間である私たちには、未来を正確に予測することは不可能です。少しだけ正確な見積を行おうと努力するよりも、見積をまったく行わないことで、よりよい予測が可能になるのです。スループットに基づいた予測を使用すれば、人間による推測から事実や数字へのゲームチェンジが実現し、有意義な議論への肥沃な土壌となります。