目標ベロシティとベロシティのインフレ

みなさんこんにちは。@ryuzeeです。

現実から得られるベロシティの実績値をもとに、次のスプリントでそれよりも大きい目標ベロシティを設定することはおすすめしません。それは以下の理由からです。

そもそもチームの実績としての指標データであるベロシティが目標値として設定されることによって、チームがその目標に到達しなかった場合にチームに何か問題が発生しているようにとらえてしまう
もちろん継続的な改善によってチームのベロシティは一般的には初期のスプリントから中盤にかけては向上する傾向にはありますが、それはあくまで結果としての指標データです
目標ベロシティを決めて、かつ、それをコミットしてしまった場合、往々にして、数字を満たすために、テストの手抜きをしたりリファクタリングするのをやめて目先の数字を追ってしまうことが多々あります
いくつかのスプリントをこなせばチームとしての生産力は見えてくるので、数字をコミットさせるのではなく、チームの人数やリリース計画についての再検討を行っていくべきです（一般的には、チームの人数を増やしてもすぐに機能することはないので、できればスコープを見直したい）
おすすめは、スプリントにおけるベースとなるベロシティの値は、前のスプリントの結果と同じにするか、前の数スプリントの平均的な値を取ることです。もちろんチームの成長曲線もあるので、スプリントの期間を残してすべてのプロダクトバックログアイテムが完成することもあります。しかし、それはそれで十分で、チームの精神衛生的にも非常に良いことです。人間は通常追われるとプレッシャーを抱え、作業効率や品質が低下しやすい傾向にあります（まったく期日が設定されないのも作業効率があがらないですが……）。そして、余った時間でリファクタリングをしたり、過去の技術的負債を解消したり、次のスプリントで実施予定のプロダクトバックログアイテムのうち、残り期間で終わりそうなものに再度着手したりする（＝おかわり）のが良いでしょう

また往々にしてベロシティはインフレを起こします。これはどのチームでも起こる可能性があります。

インフレを起こす原因として、上記に書いたような目標ベロシティが設定されていて、それを成し遂げようとすること
チームは成功していると周りに思わせたい欲求があるので、達成したベロシティが水増しされやすい

ウォーターフォールがなぜ駄目なのか、というと、一番最初にたてた適当な計画が絶対的に正しいものとして扱われてしまうことです。たとえそれがとてつもなく無理な計画であっても、目標値として設定されます。目標として設定されてしまえば、後は数字を満たすためにはなんでもありの世界に突入してしまいます。ウォーターフォールでの失敗をアジャイルな開発に持ち込んではいけません。

透明性を保ち、常に評価、調整を繰り返すためには、ベロシティを目標にしてはいけません。目標にするのは顧客の価値を創出することです（価値を測定しましょう）。

それでは。