イテレーティブ開発でのベロシティ推移をグラフ化する良し悪し

スクラムなどのイテレーティブな開発において、チームが各イテレーションでどのくらいの規模の開発をできるかという指標は、イテレーションの計画（スプリントプランニングなど）を円滑にする上でとても役立つ指標だと思います。そしてこの「チームが一つのイテレーションでどれだけの規模を開発できるか」の指標として、ベロシティというものがあります。具体的には、チームが取り組む各タスクのサイズを数値で定量化し、イテレーションで完了できたタスクの合計値をベロシティとして算出し過去数回のイテレーションとの平均値を取ることで、直近の自分達のチームだと一回のイテレーションでどれだけのタスクを完了することができるのか、という大まかな予測が立てられ、次のイテレーションの計画などに役立てることができます。

そしてこのベロシティはイテレーション毎に計測していくので、チームのログとしてベロシティの履歴は蓄積していきます。

すると、数値が並ぶとその推移をグラフ化して可視化したいというモチベーションが湧いてくることもあるかと思います。

ただ僕は、ベロシティ推移のグラフ化は使うべきシーンを選んだほうが良く、場合によってはグラフ化しないほうが良いシーンもあるのではないかと思います。

なお、今から書くのは僕自身が実際にグラフ化してみて経験したことではなく、あくまで「こうだろうな」と思っていることをまとめただけなので、机上の空論の可能性は大いにあります。

ベロシティ推移をグラフ化したほうが良いケース

数週間から数ヶ月かけて開発するようなプロジェクトをイテレーティブに回す場合、最初に全てのユースケースを一つ一つストーリーポイントを用いて見積もり、着地予測をするためにイテレーション毎のベロシティをバーンダウンで可視化することは、着地予測のズレを早期に検知し関係者との期待値調整ができるなどの効果があり有効だと思います。

ベロシティ推移をグラフ化しないほうが良いケース

そうではなく、例えば一つ一つの開発リクエストは独立しているが、チームの学習（レトロスペクティブ）やプロダクトへの学習（スプリントレビュー）のサイクルを仕組み化するためにイテレーティブな開発を導入している場合には、ベロシティ推移は敢えてグラフ化しないほうが良いケースもあると思います。

なぜならこの場合、ベロシティ推移の可視化の目的が「ベロシティを上げること」になってしまい、チームが「ベロシティを上げないと」というモチベーションになってしまうと、見積もりの時に多めのポイントにしたりと、自分たちを守るためのポイントをつけたくなってしまう力学が働いてしまう可能性があると思っているからです。

一方で、チームに「ベロシティを上げないと」というプレッシャーを与えず、純粋に「もっとアウトカムを増やすにはどうしたら良いだろう」という議論に繋がるようなチームの状態だったり、あるいは毎回グラフ化するのではなく、過去半年間などまとめて振り返る用途に使うとかであれば上手くワークするかもしれないですね。

ベロシティの可視化は何のため？

ということで、何のためにベロシティをグラフで可視化したいのかと、それがチームに与えうる効果を考えて使い分けると良いと思います。

とはいえ、冒頭でも述べたように、実は僕はベロシティをグラフ化したことがありません。単純に、使っているツールでいい感じかつ無料でグラフ化できるものがなく面倒だったためです。機会があれば、僕が所属するチームでもグラフ化してみてまた更新しようと思います。