スクラム指標

スクラムはアジャイル フレームワークであり、チームが複雑な問題に対処して目標に基づいてソリューションを繰り返し開発するために役立ちます。スクラムの作業方法にはスプリントという特徴があります。これは、スクラム チームが一定量の作業を完了するために従事した時間を測定したものです。

その適応性によって、スクラムなどのアジャイル フレームワークは技術指向のチームを越えて、サポート、設計、マーケティングなどにも普及しています。そのため、チームのパフォーマンスと効果を測定する上で、スクラム指標の重要性が高まっています。

スクラム指標は特定のデータ ポイントで、スクラム チームが効率と効果を向上させるために追跡して使用します。スクラム指標を定義、理解、実装すると、そこから得られるインサイトをチームのアジャイル化の指針として改善に役立てられます。

スクラム チームは指標を使用して意思決定を通知し、計画と実行の効率を高めます。また、現状のベースラインを確立して対象目標や改善計画を設定するためにも使用できます。その際、全員を今日と比較する業界標準の基準はありません。これは、コンテキストがない状態でデータ ポイントを比較することは、リンゴとアサリを比較するようなものだからです。チームはそれぞれ異なります。規模、使用するテクノロジー、実施する作業の種類などが異なります。

追跡する一連の指標について合意してその使用方法を定義するのは、各チームの責任です。これは個人の取り組みではなく、リーダーシップや経営陣がチームのために定義して実施できるものでもありません。

スクラム指標によって、チームがベンチマークを確立して作業の方向性を導けます。このため、スクラム指標は確立されたチームと新しいチームの両方にとって有用です。

また、スクラム指標の追跡によって、チームのベロシティ、キャパシティ、デリバリーの予測可能性、製品の品質など、チームの効果に関するさまざまな側面を可視化できます。主要な指標によってチームのパフォーマンスに対する意識を高めて、変化と改善に向けた行動を促せます。さらに、チームの幸福度と満足度を経時的に測定するためにすら役立ちます。

多くのアジャイル チームが、感覚や直感に頼ってチームのパフォーマンスを把握しがちです。この習慣の背後には多くの現実的な理由がありますが、それでも大きな機会を逃しています。

どちらとも言えません。スクラム指標は KPI (主要業績指標) の設定に使用できますが、作業の種類とスコープによって異なります。スクラム指標だけでは、顧客の価値を測定したり、チームが適切な成果を出したかどうかを示したりはできません。アジャイル チームにとって、KPI は最終的にチームが会社の優先事項にどの程度適切に貢献しているかを示す必要があります。

スクラム チームのパフォーマンスを測定する際は、次のようなスクラム以外の指標を考慮する必要があります。

• ビジネスに対する ROI (投資利益率) — 収益の増加、月間アクティブ ユーザー (MAU) など、企業は目的に応じてさまざまな方法でこれを測定します。
• 顧客満足度 — NPS (ネット プロモーター スコア) や CSAT (顧客満足度スコア) などの調査指標は、プロジェクトの成功を追跡する際に役立ちます。スクラム チームの価値を顧客に示すには、リリースごとに一貫した顧客満足度指標が重要です。
• チーム満足度 — プロジェクトに対するモチベーションのレベルとチームとの関わりについてチームに尋ねるだけで、離職率、消耗、開発者の不満などの問題を把握できます。

スプリント、スプリント計画、デイリー スクラム、スプリント レビュー、スプリントのふりかえりなど、アジャイル スクラムでは繰り返し発生するイベントがいくつか定義されていますが、これらは進捗や成功を保証するものではありません。ただし、こうしたイベントによって、チーム・メンバーは作業の進め方を検査して調整できます。

スプリント計画ミーティングはスプリントを開始するときに開催します。ここでチームは、ストーリーの説明を詳細なタスクに分解します。これによって、スプリント中に生み出される作業の見積もりが得られます。スプリントの目標、現在のチームのベロシティ、チームのキャパシティ、作業の種類など、チームのスプリント計画を効率化できるデータ ポイントがいくつかあります。スプリント計画ミーティング テンプレートを使用して、スプリント計画の指針として役立てます。

スプリントの目標によって、スプリントでチームが達成することを決定して項目をまとめ、優先度を設定するために役立ちます。多くの場合、スプリントの目標は、複数のスプリントで達成できるよりも大きい成果に貢献します。スプリントの目標の優先度は、この成果への影響に基づく必要があります。真に効果的なチームは目標とその優先度を定期的に見直して、エンジニアリング作業をどのように順序付けして分割するかについて戦略を立てます。

チームがスプリントにどれだけコミットできるかは、基本的にベロシティ (特定の時間内に達成できる作業量) とキャパシティ (どれだけの可用性があるか) によって決まります。Jira で使用しているようなベロシティ チャートは、スプリント中にデリバリーされた価値の量を示します。これによって、チームが今後のスプリントで実行できる作業量を予測できます。チームのベロシティは、チームとしていくつかのスプリントを一緒に実行して初めて理解できます。ベロシティは、チームが連携して作業することで時間の経過とともに安定します。これには、使用するテクノロジーを増やすだけでなく、お互いの専門知識を理解してチームとして作業する方法を学ぶことも含まれます。

次に示すベロシティ チャートの例には、(1) ストーリー ポイントに基づく見積もり統計、(2) コミットメント (スプリントにあるすべての課題の見積もり)、(3) 完了した見積もり、(4) 完了したスプリントが含まれています。

チームがスプリントで完了できる作業量がキャパシティと可用性に基づくことは当然です。チームの半分が休暇で不在の場合、安定したベロシティは何の意味もありません。キャパシティを計画する 1 つの方法は、いくつかのスプリントにおける各チーム メンバーの可用性を収集して合計を加算し、総キャパシティのパーセンテージを算出することです。土壇場の変更や緊急事態は誰にでも起こり得るため、過度なコミットメントや過少なデリバリーを避けるために、スプリントのコミットメントに 10% の余裕を確保することもお勧めします。

When your sprint backlog is a growing mix of feature work, bug fixes, and technical debt, it becomes tricky to see where your team is dedicating their time in the sprint. It’s easy for bugs or tech debts to sneak into your sprint, especially if the development team is passionate about quality. But if a team isn’t careful, it can end up after the sprint wondering why it didn’t ship enough customer values as planned.

スプリント計画中にさまざまな種類の作業の分割を見直して、チームがどのような作業に取り組んでいるか把握することを意識的に心がけましょう。この場合は、バックログに多くの技術的負債と質の高い仕事が見つかったとしても、技術的負債のスプリントをスケジュールするか QA の基準を引き上げることで戦略的に解決できます。

スタンドアップ (デイリー スクラム) は、チーム メンバーが自分の作業について確認する毎日の短いミーティングです。スクラム チームを効果的に運営するには、スタンドアップを To Do リストにある個人のアップデートに関する連絡以上のものにする必要があります。これは、チームのスプリントの進捗状況を確認して、スプリントの成果に大きな影響を与える可能性のある毎日の大小の意思決定を行うために優先順位を再調整する機会です。

このとき、次のデータと指標が役立ちます。