スクラムにおけるベロシティ:パフォーマンスの測定と改善方法

Atlassian 作成者 Atlassian
トピック一覧

スクラム・チームが実際にどれくらいの速度で進められるか知りたいですか?ベロシティはアジャイル・プロジェクトのスピードメーターであり、チームの作業能力に関する比類のないインサイトを提供します。このガイドでは、スクラムにおけるベロシティの秘密を解明し、その計算方法を説明し、この強力な指標を使ってチームの将来のパフォーマンスを予測する方法を紹介します。

スクラムにおけるベロシティとは

スクラムやその他のアジャイル・プロジェクト管理フレームワークでは、ベロシティはスクラム・チームが特定の時間枠(通常は 1 スプリント)内に完了できる作業を見積もるアジャイル指標として機能します。

ベロシティはストーリー・ポイントで表せることができます。ストーリー・ポイントは、複雑さ、リスク、不確実性の観点からユーザー・ストーリーやタスクのサイズを決定するための測定単位です。ストーリー・ポイントは、時間や日数などの時間ベースの指標よりも、より繊細な方法で作業を見積もります。

たとえば、アプリのログイン画面を開発するためのユーザー・ストーリーを考えてみましょう。チームは、認識された複雑さと、タスクを完了するための労力に基づいて、このタスクにストーリー・ポイント値 3 を割り当てることができました。複雑な決済ゲートウェイを統合することで、より複雑になり潜在的なリスクが生じるため、この値が 8 となる可能性がありました。

各チーム・メンバーが 2 週間のスプリント中に完了できるストーリー・ポイントの数には、個人の経験、タスクの複雑さ、チームの作業ダイナミクスなど、多くの要因が影響します。新しいスクラム・チームは通常、2 週間のスプリントごとに 1 人あたり平均 5 から 10 のストーリー・ポイントを獲得します。

チームのベロシティを理解すると、チームが今後のスプリントを予測したり、現実的な目標を計画して設定したりできるため、継続的に改善するために有益です。この指標は、チームが安定した作業リズムを策定し、プロジェクトのタイムラインを予測し、関係者の期待を管理するのに役立ちます。

スクラムにおけるベロシティの計算方法

通常、各スプリントの終了時に、完全に完了したすべてのユーザー・ストーリーのストーリー・ポイントまたはその他の測定単位を合計してベロシティを計算します。

スクラムにおけるベロシティを計算する方法の段階的なプロセスは次のとおりです。

1. スプリントを計画する

スプリントを始める前に、製品バックログ内のすべてのユーザー・ストーリーに概要を説明し、ポイントを割り当てます。以下に例を挙げます。

  • ユーザー認証の割り当て:5 ポイント
  • 決済ゲートウェイ統合の追加:8 ポイント
  • 検索機能の実装:3 ポイント
  • ユーザー・プロファイル・ページの作成:13 ポイント
  • 電子メール通知の実装:2 ポイント
  • データベース・クエリの最適化:21 ポイント
  • 管理者ダッシュボードの作成:5 ポイント

チームは、以前のスプリントからの平均ベロシティと、休日や外部依存関係などの他の要因に基づいて、次のスプリントでユーザー・ストーリーを完成することをコミットする必要があります。たとえば、休日や外部依存関係がない場合に平均ベロシティが 15 ポイントであれば、チームは次のスプリントで合計 15 ポイント程度のユーザー・ストーリーをコミットできます。

2. 完了したユーザー・ストーリーを一覧表示する

各スプリントの終了時に、完了したすべてのユーザー・ストーリーのリストを作成します。これらは、受け入れ基準を満たし、スクラム・マスターと製品所有者が承認したストーリーでなければなりません。

ユーザー・ストーリーが 90% 完成したとしても、それは完全に完成した作品ではありません。チームはそれを次のスプリントに移動し、残りのタスクに基づいてポイントを再評価する必要があります。

3. チェック・ポイント

チームはすでに、完成した各ユーザー・ストーリーにストーリー・ポイントを割り当てているはずです。何らかの理由で、ストーリー・ポイントを再評価する必要がある場合は、再評価を行います。

たとえば、チームが現在スプリントでユーザー認証の割り当て、支払いゲートウェイ統合の追加、検索機能の実装という 3 つのユーザー・ストーリーを完了したとします。これらのタスクには、次のストーリー・ポイントを割り当てることができます。

  • ユーザー認証の割り当て:5 ポイント
  • 決済ゲートウェイ統合の追加:8 ポイント
  • 検索機能の実装:3 ポイント

4. ポイントを合計してベロシティを求める

次に、完成したすべてのユーザー・ストーリーのストーリー・ポイントを合計する必要があります。ストーリー・ポイントの合計がスプリントのベロシティを表します。

上記のシナリオでは、合計は 5 ポイント + 8 ポイント + 3 ポイント = 16 ポイントになります。つまり、このスプリントのベロシティは 16 ポイントになります。

5. 平均ベロシティ

チームが完了するスプリント数の平均ベロシティを計算すると、将来のスプリントについてより信頼性の高い測定値を得られます。この測定値は、新しく結成されたチームや、規模や構造が変わったチームに特に役立ちます。

たとえば、過去 3 回のスプリントのベロシティが 14、16、15 の場合、平均ベロシティは (14 + 16 + 15)/3 = 15 ポイントになります。

スクラムにおけるベロシティに影響を与える可能性のある要因

さまざまな要因がスクラムの指標やベロシティに影響を与える可能性があります。これらを理解することは、チームのパフォーマンスを計画し、継続的に改善させるのに役立ちます。

チームの規模とスキル・レベル

チーム内の人数とそれぞれのスキル・レベルは、チームがスプリント中に完了できる作業に影響する可能性があります。大人数のチームであれば、1 スプリントでより多くのストーリー・ポイントを獲得できる可能性があります。しかし、人が増えると、コミュニケーションのオーバーヘッドが高くなり、調整が困難になる可能性があります。

逆に、小規模でスキルの高いチームは、複雑なタスクを効率的に処理することで、大規模でスキルの低いチームよりも優れたパフォーマンスを発揮できる可能性があります。

チームの安定と経験

スクラム・チームのメンバーが協力して複数のスプリントを行うと、新しいチームの妨げとなる多くの問題が解決される可能性があります。彼らはコミュニケーション・パターンを確立していて、誰が何を得意にしているかも把握しています。

これらのチームは、問題が発生したときに活用できる経験を共有しています。経験があることで、ベロシティを大幅に向上させる場合があります。

ユーザー・ストーリーの複雑さ

複雑なストーリーが詰まったスプリントは、通常、ベロシティが低くなります。複雑さが割り当てられたストーリー・ポイントを正確に反映していない場合、ベロシティの数値は誤解を招く恐れがあります。

ベロシティを一定に保つために、一部のチームはスプリント内で「即効性のある」タスクとより複雑なタスクのバランスを取ることを目指しています。

外部依存関係と制約

チームがデータベースの更新や API の統合を完了するために他のチームに依存しており、そのチームの作業が遅れた場合、チームのベロシティが直接低下する可能性があります。これらの依存関係を認識し、チーム間の効果的なコミュニケーションを通じて計画を立てると、ベロシティへの悪影響を軽減できます。

同様に、祝祭日や社内のイベントは、それによって作業できる時間が短くなるため、スプリント計画に組み込みます。

スクラムにおけるベロシティの使い方

チームのベロシティが理解できれば、次のようなスプリント計画やプロジェクト管理のさまざまな側面で強力なツールになります。

将来のスプリントの見積もり

チームの平均ベロシティを知ることは、当て推量を排除するに役立ちます。チームの過去 3 回のスプリントの平均ベロシティが 50 ストーリー・ポイントであれば、次のスプリントを計画するためのデータに裏付けられたベースラインができます。次のスプリント・バックログに約 50 ストーリー・ポイントがある場合は、妥当なコミットメントをしていることになります。

プロジェクト・タイムラインの予測

関係者は、推測や希望的思考よりもデータに基づいた見積もりを頼りにします。たとえば、プロジェクトのバックログに 200 ストーリー・ポイントがあり、チームの平均ベロシティが 1 スプリントあたり 50 ストーリー・ポイントの場合、プロジェクトを完了するためにチームはさらに約 4 回のスプリントが必要になる可能性があると確信を持って予測できます。

オーバーコミットメントとアンダー・コミットメントの特定

チームのベロシティが突然 30 ストーリー・ポイントに低下したり、70 ストーリー・ポイントに急上昇したりした場合は危険です。一貫して低下している場合は、チームが圧倒されていると感じている可能性があり、上昇している場合は、チーム・メンバーがチャレンジ不足である可能性があります。この知識により、タスクの再割り当てやスプリント目標の再検討など、リアルタイムの調整が可能になります。

改善と反復的な進捗の追跡

時間の経過とともにベロシティを追跡することで、チームの効率が向上しているのか、それとも進行中の課題に注意が必要なのかを理解するのに役立ちます。数回のスプリントでベロシティが 40 から 60 に上昇した場合、プロセスの改善が成果を上げていることを示しています。

Jira でベロシティを追跡する

Jira にはその他の多様なアジャイル・レポートに加え、チームの過去のベロシティを示すベロシティ・チャートが用意されているため、ソフトウェア・チームによるベロシティの追跡、将来のパフォーマンスの予測、スプリント計画が容易になります。これはチームが処理できる作業量を視覚化するワンストップ・ツールであり、今後のスプリント目標をより正確に設定できます。

さらに、Jira はチームが計画とパフォーマンスを次のレベルに引き上げるために必要な、その他すべてのアジャイル指標、コンテキストに応じたインサイト、レポート、およびプロジェクト管理機能も提供します。

スクラムにおけるベロシティ:よくある質問

スクラムにおけるベロシティは生産性と同じですか?

いいえ、スクラムにおけるベロシティは生産性と同じではありません。ベロシティは主に、チームが将来のスプリントで処理できる作業量を計画し、見積もるための指標です。

生産性は通常、仕事の質、プロセスの効率、ビジネスにとっての価値などの要素を含む、より広範な尺度です。

チームはどのような方法でベロシティを向上させることができますか?

チームは定期的にふりかえりミーティングを開き、うまくいったこと、うまくいかなかったことを話し合い、次のスプリントの改善を計画することで、ベロシティを向上させられます。コンテキストの切り替えを最小限に抑える、つまりさまざまなタスクやプロジェクト間の頻繁な切り替えを減らすことで、より速く、より一貫したベロシティを実現できます。

スクラムでベロシティを使用する場合にはどのような限度がありますか?

ベロシティは便利な計画ツールではあるものの限界があり、チームを評価するための唯一のパフォーマンス指標とすべきではありません。チームのパフォーマンスをより包括的に把握するには、その他のアジャイル指標を追跡することを検討してください。

1 つの重要な限度は、ベロシティは作業の質や提供するビジネス価値を測るものではないということです。これは、個々のユーザー・ストーリーの複雑さの質的側面を考慮しない定量的指標です。

ベロシティはチーム固有のものであり、さまざまなチームのパフォーマンスを比較するための指標ではありません。チーム内の各グループの作業は異なる場合があり、その結果、ベロシティも異なる可能性があります。全体的なベロシティが低いからといって、そのチームが別のチームより成功していないとは限りません。