スクラムにおける Velocity

スクラムを始めると Velocity を計測すると思います。そのチームが 1 Sprint で何ポイントのバックログアイテムを完了できるか、という指標と解釈されると思います。

Velocity についてはいくつか重要なポイントがありますが、個人的には

相対的指標のため他チームと比較してはいけない
伸び続けることが重要ではない

と考えています。

しかし、なかなかスクラムやアジャイルが浸透していない（理解が浅い）組織では、

「あっちのチームは 20 pt なのにうちのチームは 10 pt なんだけど、どうにかならない？」
「ベロシティが 15pt で止まったままなんだけど上がらないの？」

などと上司に言われてしまうことは多々あるかなと思います。（私もスクラムマスター時はそうでした）

もちろん、Velocity とは？ を組織に正しくティーチングしていくこともスクラムマスターの重要な任務ですが、それでもなお改善されない状況だったり、そもそも Velocity しか指標がない場合、 Velocity = 生産性 と捉えられてしまう傾向にあるため、他の指標も観察することが重要です。

リードタイム
技術的負債の累積フロー図
バーンダウンチャート
まとめ

リードタイム

リードタイムは、ユーザーストーリーが提出されてから完成するまでの時間を示す指標です。スクラム開発においては、リードタイムを短縮することが重要とされています。なぜなら、リードタイムが長ければ、ユーザーストーリーを開発チームが確認し、修正や改善を行い、完成するまでの時間が長くなるため、プロジェクトの進捗に悪影響を与える可能性があるからです。

リードタイムを短縮するためには、開発チームがユーザーストーリーに関する詳細な情報を収集し、優先順位を設定することが重要です。ユーザーストーリーの収集には、顧客やステークホルダーとのコミュニケーションや、顧客のニーズに関する調査が必要です。

また、リードタイムを短縮するためには、ユーザーストーリーの開発とテストの並列化や、自動化されたテストの導入が有効です。これにより、開発チームはより効率的にユーザーストーリーを完成させることができます。

さらに、リードタイムを短縮するためには、開発プロセスの改善を継続的に行うことも重要です。スクラム開発では、スプリント終了後に振り返りを行い、開発プロセスの改善点を特定することが推奨されています。これにより、ユーザーストーリーの開発やテストにかかる時間を短縮するための改善策を導入することができます。

リードタイムを短縮することは、プロジェクトの成功に直結する重要な要素の1つです。スクラム開発においては、リードタイムを短縮するための様々な取り組みを行い、開発プロセスを改善することが求められます。

技術的負債の累積フロー図

技術的負債の累積にも注意が必要です。開発プロセス中に、修正されなかった問題や、後で取り組むべき問題を残すことがあります。これらの問題が負債として積み重なると、将来的に修正するための時間と労力が必要になります。そのため、技術的負債の総量を把握し、その解決策を検討することが重要です。

バーンダウンチャート

バーンダウンチャートは指標ではないように思うかもしれませんが、バーンダウンチャートからチームの活動状況を読み解くことができます。

例えば、バーンダウンチャートの理想線にほぼ沿っている実績線を描くようなチームは、本当に "理想的" な働き方をしているでしょうか？「理想線通りだからOK」と通り過ぎるのではなく、「残業して無理やり終わらせていないか？」「見積もりが過剰すぎるのではないか？」など疑ってみることも大切です。

この辺りは「バーンダウンチャート　解析」などで調べてみてください。より良い情報が見つかると思います。

まとめ

以上のように、ベロシティ以外の指標を観察することで、より正確なプロジェクトの進捗状況を把握することができます。ベロシティは有用な指標ではありますが、単一の指標に頼りすぎることなく、他の指標と組み合わせて観察することが望ましいでしょう。