ベロシティを測ることの意味と見方の考察

はじめに

私が所属するチームではスクラム型のソフトウェア開発（アジャイル開発と呼ぶかもしれません）を行っています。具体的には、各スプリントを始める前に、作業チケットにストーリーポイントで見積もりをしてスプリント内で終わらせることができそうな範囲を見極めます。見極めのためには過去のベロシティが参考になります。なぜなら、チームがこれまでのスプリントでどの程度のストーリーポイントを消化できたのかを確認できるからです。さて、今回はそんな指標として用いられるベロシティや見積もりについての考え方や、チーム内で実践していること・工夫していることをまとめます。

この話は私が所属するチームにおける内容であり、一つの考え方・事例として参考にしてください。

ベロシティは実績である

そもそもベロシティとは何か？というと、スクラムチームが1回のスプリントでDone（完了）にしたストーリーポイントの合計値です。言い換えると、1回のスプリントで見積もりした作業がどのくらいできたかの実績をあらわします。そして、各スプリントごとのベロシティを見てみるとある程度の傾向が見えてきます。安定・上昇・下降・乱高下くらいのパターンに分かれるでしょうか。この数値や傾向を見ると何がわかるのでしょうか？

ベロシティを計測するワケは、不確実性の削減にある

ベロシティの見方を考える前に、ベロシティを測る意味について考えてみます。その答えはズバリ「未来の予測可能性を高めること」にあります。ある機能を追加するとき、それが1週間で終わるのか、1ヶ月で終わるのか、3ヶ月で終わるのかは誰もが知りたいことです。アジャイル開発では、ベロシティがその役割を担っています。例えば、過去のベロシティ平均が15だったチームでは、各スプリントで15ポイントのタスクを消化できるので、ある作業を見積もった時に30だったのであれば、おそらく2スプリントかかるだろうと予測できます。私のチームでは1スプリントが1週間なので、2週間かかることが推測できます。このようにして過去の経験から未来の不確実性を少しでも削減するためにベロシティを計測します。

この内容から以下のことがわかります。

ベロシティを計測するためには、見積もりが不可欠である

ベロシティ（平均）が安定していなければ意味がない

ベロシティが乱高下している場合、次のスプリントでどのくらいのポイントが消化できるかがわからない

ベロシティは価値提供の速度である

例えば以下のような原因が考えられます。

バグが多く、バグの調査や修正に時間がかかっている

→ アプリケーションの品質が下がっているなら、上げる工夫ができないか考える

→ 設計に問題があるなら、改善案について話し合う

→ 調査に必要なログ基盤が不完全なら、ログ基盤の強化について考える

リファクタリングや設計の見直しをするのに時間がかかっている

→ ベロシティを下げてもやることに理解が得られるように話し合う

見積もり以上に時間がかかっている

→ 実際にやってみないと（調査してみないと）わからない作業チケットについては調査自体を別チケットにして、解像度を上げてから再度チケット分割する

→ 影響範囲が見積もり時より広く時間がかかりそうな場合は、メンバーと共有した上でチケットの分割や再見積もりについて検討する

スプリント中に作業の差し込みが多すぎる

→ 作業の優先度に変更がないか確認する

→ 差し込み作業をやることでスプリントの目標が達成できない可能性が上がることについて確認する

→ スプリントを閉じて仕切り直しを検討する

→ スプリントの期間を短くしてみる

ベロシティからこのような問題点を発見し原因を追求して改善していくことによってベロシティの安定化（障害が取り除かれ、自然と緩やかに上昇することも良いでしょう）に繋がります。

終わりに

元々は社内向けにまとめていた記事を改めて整理して大幅に加筆しました。ベロシティを考える上では見積もりも重要なトピックなのですが、また機会があれば書いてみようと思います。まだまだ手探りな点もありますが、一つの考え方として参考にしていただければ幸いです。