スクラムチームに「No-Estimates」を導入してみた感想

はじめに

22年の11月から新スクラムチームのスクラムマスター(SM)を務めることになり、スクラムで開発を進めていくために様々な準備を行ってきました。
その中で個人として取り組もうと事前に決めていたのが「No-Estimates」の導入でした。
念のため先に断っておきますが、本記事ではストーリーポイント(SP)やそれによる見積りやベロシティ測定を否定するものではありません。私のこれまでの経験に基づき、一つのチャレンジとして取り組んだ内容とその感想をお伝えする記事です。

「No-Estimates」を導入することにしたきっかけ

開発者として複数のスクラムチームを経験した上で、「No-Estimates」を導入したいと感じるポイントがいくつかあったので、ポイントごとに書いていこうと思います。

チームの目的がベロシティ向上になってしまっていること

開発者として携わったどのチームもSPによるベロシティ測定を実施していました。その中で個人的に気になっていたのは、チームが開発を進めるにつれてベロシティを向上させることが目的になっていることでした。
ベロシティを向上させることはもちろんいけないことではありませんし、目指すことの一つではあると思います。しかし、スクラムチーム最大の目的はプロダクトゴールを達成することであり、ユーザーに届ける価値を最大化することです。

ベロシティの存在によりチームがその数値で評価されてしまうこと

上記に付随して問題と感じていたのは、SPによるベロシティの存在によりスプリントごとにチームが評価がされてしまうことに違和感がありました。
そのスプリントでベロシティよりも多くSPを消化した時は成功とみなされ、逆に少ないSPの消化だったスプリントは失敗のように扱われることにモヤモヤしていました。その失敗と見なされたスプリントのレトロスペクティブで消化したSPが少なかった原因を追究するための「反省会」が開かれると開発者としては更にテンションが下がります。
ましてや多くの残業時間を費やして多くのSPを消化したスプリントであっても、それで成功とみなされることに最も違和感がありました。スプリントのタイムボックスが固定化されていない状態でのSP消化数とベロシティの比較など意味をなしていないはずです。
またベロシティによってチームが評価される場合、開発者は想定よりも大きなSPを出してしまうはずです。そうし始めた瞬間に見積もりとしてのSPの機能は破綻してしまいます。

大きいSPのアイテムほどチーム内で認識齟齬が起こりやすいこと

プロダクトバックログアイテム(PBI)によっては、要件の大きさからSPが膨れ上がるアイテムがあります。SPが大きいアイテムほど要件が固まりきれていなかったり、新たに仕様確認が必要なものが出てきて、開発の手を止めてプロダクトオーナー(PO)とのコミュニケーションが必要になってくるタイミングが多く発生します。
POが常に開発者たちと同じ場で仕事をしてくれ、いつでもコミュニケーションが取れる状態であれば問題ないかもしれません。しかし、私の経験上でもそうですが大いにしてPOの方はお忙しく、コミュニケーションを取るにあたりある程度の時間を要します。
その確認を待っている間、開発者が手隙になってしまい、別のPBIに着手し始め、結果として仕掛中のPBIが増えるといった悪循環が生まれることがあります。

導入に向けて取り組んだこと

「No-Estimates」の目的と考え方のインプット

まずはSPで見積りをしないことに理解をしてもらうことでした。今回SMを務めるチームには、スクラム経験者が2名、未経験者が2名の開発者たちとアジャイルでの開発経験を持つPOによるチームでした。特にスクラム経験者たちはこれまでSPでの見積もりを経験してきていたため、これまでとの見積り方法にとまどいを感じたと思います。
そのため、まずは前述の私が問題に感じているポイントと、「No-Estimates」を導入する際の基本的な考えを伝えました。
自分自身の言葉だけではメンバーに対して完全な納得感を生み出す自信が無かったので、以下のサイトを共有することでより納得感を得てもらうようにしました。

Agileの“No-Estimates”を考える

PBIのサイズを(できるだけ)小さく均等にする

前述の添付記事にも記載がありましたが、「No-Estimates」は見積もりをしない訳ではありません。

“No-Estimates”の文脈は「見積もりをするな」ということではなく「見積もりに踊らされるな」

「Agileの“No-Estimates”を考える」より

SPで見積りをしないだけであって、このスプリントでどれくらいできそうか？を見積もるのは必要だと思います。
「No-Estimates」の導入にあたっては、SPを使わない代わりにPBIの数で見積りを行います。
PBIの数で見積もるために2つのポイントが重要だと思います。それは「PBIのサイズを小さくする」ことと「各PBIのサイズを均等にする」ことです。

チーム全体でアイテムのサイズの共通認識を合わせるためにPBIのサイズを小さくします。どうしても要件や仕様が複雑でPBIのサイズが大きいものはチーム内でもサイズに対する認識がブレてきます。それを避けて共通認識を図りやすくするという意味でPBIのサイズは小さくします。

またアイテム数でベロシティを出すために各PBIのサイズを均等にすることも大事になってきます。先ほどのサイズを小さくする話も含めて、極端に言えば1受入条件 = 1PBI くらいのイメージで分割していきましょうと伝えました。ですが、厳密にそうしているわけでは無く、要件・仕様の内容や開発者の開発効率等を鑑みてPBIのストーリーと受入条件を決めるため、PBIのサイズのブレは若干あります。ですが、PBIのサイズを小さくシンプルにという考えはチームの共通認識としてあるため、大きなサイズのPBIが生まれることはありません。

PBIのサイズを小さくすることに対してもう一つ狙いがあります。それは必要な要件・仕様に対して優先度をよりつけやすくすることです。画面や機能単位でPBIを作ってしまうとその中の要件で優先度がつけづらくなり、結果としてプロダクトバックログの優先度をが画面や機能単位でしかつけれなくなります。
しかし、その画面・機能の中でも優先的に開発してスプリントレビューで検査したい項目とすぐに検査しなくてもいい優先度の低い項目があるはずです。そうしたときにPBIのサイズを小さくすることで他画面・機能の要件とのトレードオフがしやすくなります。

導入してみてどうだったか

チーム全体のPBIに対する共通認識が取りやすくなった

1つ1つのPBIがシンプルになったことによりストーリーと受入条件の共通認識が取りやすくなりました。
画面や機能全体を見ても考慮しなければいけない点が分かりやすくなり、全体像が分かりやすくなったという利点がありました。

プランニングの時間が短くなった

プランニングポーカーによるSPの同期取りが無くなったため、プランニングの時間が今まで経験してきたプランニングの時間よりも短くなりました。こちらもPBIのサイズが小さくなったことにより、内容についての同期がとりやすくなったことが時間短縮の要因だと思います。

ベロシティ向上がチームの最大目的でなくなった(ゴール達成が最大の目的になった)

「No-Estimates」だけの恩恵ではありませんが、SP上のベロシティが無くなったことによって、見積もり時にSPを盛ったりする必要がなくなったことでベロシティ向上を無駄に意識する必要がなくなったと感じてます。
実際はアイテム数によってベロシティ測定ができてしまいますが、チームにはとにかくスプリントゴールの達成とその先にあるプロダクトゴールの達成に目を向けさせるように、何度も繰り返しそのメッセージを伝え続けました。その2つの作用によってチームがゴール達成に目的意識を向かせることができたと感じています。

まとめ

結果として「No-Estimates」の導入はチームにとって非常にうまくいったと思います。開発者からもPBIに対する共通認識の図りやすさや、要件・仕様に対する理解がしやすくなったとポジティブな声を聞くことができました。
初めにお伝えした通り、SPによるベロシティ測定を否定するつもりは一切ありません。しかし、自分の意図しない形でSPによるベロシティが受け取られることでチームにとって良くない状況が発生してしまうのも事実なので、それを避けるためにも「No-Estimates」の導入を一つ考えてみるのはいいのではないかなと思っています。