5 つの役立つアジャイル指標

Stats and charts are powerful tools. Use them for good, dear agilists... use them for good. 

Dan Radigan Dan Radigan

指標には慎重な扱いが必要です。

かつてのようにプロジェクトで一切のデータを追跡しなければ、リリースに向けて順調に進んでいるのか、または効率が向上しているのかを知ることは困難です。反対に、統計を武器にチームを競争させたり週末の労働を正当化したりするようなプロジェクトの苦しさも、多くの人が経験しています。ほとんどのチームと指標が愛憎関係にあるのも無理はありません。

しかし、指標をうまく活用する方法があります。 アジャイル指標を追跡し共有することで、混乱を減らし、開発サイクル全体でチームの進捗 (や後退) を把握することができます。次に、その方法を説明します。

ビジネスを理解する

"Done" only tells half the story. It's about building the right product, at the right time, for the right market. Staying on track throughout the program means collecting and analysing some data along the way. In any agile program, it's important to track both business metrics and agile metrics. Business metrics focus on whether the solution is meeting the market need, and agile metrics measure aspects of the development process.

プログラムのビジネス指標はロードマップに根差したものであるべきだ。

For each initiative on the roadmap, include several key performance indicators (KPIs) that map to the program's goals. In addition, include success criteria for each product requirement such as adoption rate by end-users or percentage of code covered by automated tests. These success criteria feed into the program's agile metrics. And the more teams learn, the better they can adapt and evolve. 

アジャイル指標を使用してデリバリーを最適化する方法

The agile metrics discussed below focus on the delivery of software. Whether you are a scrum or kanban team, each of these agile metrics will help the team better understand their development process, making releasing software easier.

Sprint burndown

Scrum teams organize development into time-boxed sprints. At the outset of the sprint, the team forecasts how much work they can complete during a sprint. A sprint burndown report then tracks the completion of work throughout the sprint. The x-axis represents time, and the y-axis refers to the amount of work left to complete, measured in either story points or hours. The goal is to have all the forecasted work completed by the end of the sprint.

社内では、常に予測どおりに活動しているチームがアジャイルのお手本となります。ただし、実際にはまだ完了していない項目を数に入れて数字をごまかさないように注意しましょう。短期的にはうまくいっているように見えますが、長い目で見れば学習と改善の妨げとなります。  

注意すべきアンチパターン
  • チームがスプリントを次々と早期終了するのは、十分な作業を行っていないから。 
  • チームのスプリントの予測が外れ続けるのは、作業が多すぎるから。 
  • バーンダウンラインが徐々に低下するのではなく急低下するのは、作業を細かく分割していないから。
  • プロダクトオーナーがスプリントの途中でスコープを追加または変更してしまう。

Epic and release burndown

Epic and release (or version) burndown charts track the progress of development over a larger body of work than the sprint burndown, and guide development for both scrum and kanban teams. Since a sprint (for scrum teams) may contain work from several epics and versions, it's important to track both the progress of individual sprints as well as epics and versions.

"Scope creep" is the injection of more requirements into a previously-defined project. For example, if the team is delivering a new website for the company, scope creep would be asking for new features after the initial requirements had been sketched out. While tolerating scope creep during a sprint is bad practice, scope change within epics and versions is a natural consequence of agile development. As the team moves through the project, the product owner may decide to take on or remove work based on what they're learning. The epic and release burn down charts keep everyone aware of the ebb and flow of work inside the epic and version. 

注意すべきアンチパターン
  • 作業に変更が生じても、エピックおよびリリース予測が更新されない。
  • 複数のイテレーション期間にわたって進行がない。 
  • Chronic scope creep, which may be a sign that the product owner doesn't fully understand the problem that body of work is trying to solve.
  • スコープの成長にチームの対応が追いついていない。
  • チームがエピックの開発全体を通して増分リリースを出荷していない。

ベロシティ

Velocity is the average amount of work a scrum team completes during a sprint, measured in either story points or hours, and is very useful for forecasting. The product owner can use velocity to predict how quickly a team can work through the backlog, because the report tracks the forecasted and completed work over several iterations–the more iterations, the more accurate the forecast.

例えば、プロダクトオーナーがバックログで 500 のストーリーポイントを完了したがっているとします。開発チームは一般的にイテレーションごとに 50 のストーリーポイントを完了することがわかっています。したがって、プロダクトオーナーは目的の作業に 10 のイテレーションが必要と考えるのが合理的です。

時間とともにベロシティがどのように進化するかを監視することが重要です。新規チームでは、関係や作業プロセスの最適化に伴い、ベロシティの向上が期待できます。既存チームでは、ベロシティの追跡によって常に一貫したパフォーマンスを確保するとともに、特定のプロセスの変更が向上につながるかどうかを確かめることができます。平均ベロシティが低下する場合、通常はチームの開発プロセスの中に非効率的な部分があることを示しており、次のふりかえりで課題として挙げる必要があります。

注意すべきアンチパターン

長期にわたってベロシティが一定しない場合、必ずチームの見積もりを再度行ってください。チームのふりかえりで、次の質問をします。

  • この作業の見積もり段階で考慮に入れなかった、予想外の開発上の課題はあったか? これらの課題を発見するために、作業をより適切に分割するにはどうすればよいか?
  • チームに無理を強いるような外部からの業務上の圧力があるか? 開発ベストプラクティスを遵守することが結果として困難になっているか?
  • チームとして、スプリントの予測に力を入れすぎているか? 

Each team’s velocity is unique. If team A has a velocity of 50 and team B has a velocity of 75, it doesn't mean that team B has higher throughput. Since each team's estimation culture is unique, their velocity will be as well. Resist the temptation to compare velocity across teams. Measure the level of effort and output of work based on each team's unique interpretation of story points. 

管理図

Control charts focus on the cycle time of individual issues–the total time from "in progress" to "done". Teams with shorter cycle times are likely to have higher throughput, and teams with consistent cycle times across many issues are more predictable in delivering work. While cycle time is a primary metric for kanban teams, scrum teams can benefit from optimized cycle time as well.

Measuring cycle time is an efficient and flexible way to improve a team's processes because the results of changes are discernable almost immediately, allowing them to make any further adjustments right away. The end goal is to have a consistent and short cycle time, regardless of the type of work (new feature, technical debt, etc.).

注意すべきアンチパターン

管理図は最初は無秩序に見えます。外れ値はそれほど気にする必要がありません。読み取るべきものはトレンドです。次の 2 つに注意しましょう。

  • Increasing cycle time -Increasing cycle time saps the team of it's hard-earned agility. In the team's retrospective take time to understand an increase. One exception: if the team's definition of done has expanded, cycle time will probably expand too.
  • Erratic cycle time – The goal is to have consistent cycle time for work items which have similar story point values. Filter the control chart for each story point value to check for consistency. If cycle time is erratic on small and large story point values, spend time in the retrospective examining the misses and improving future estimation. 

累積フロー図

The cumulative flow diagram is a key resource for kanban teams, helping them ensure the flow of work across the team is consistent. With number of issues on the Y axis, time on the X axis, and colors to indicate the various workflow states, it visually points out shortages and bottlenecks and works in conjunction with WIP limits.

累積フロー図は左から右まで平坦な状態が理想です。任意の色の逸脱や差は不足やボトルネックがあることを示しているため、図全体で色付きの部分を平坦にする方法を考えましょう。

注意すべきアンチパターン
  • 障害となる課題があると、プロセスの部分によって大規模な余剰や不足が生じます。
  • 未チェックのバックログの増加。これは、古い、または優先順位が低い課題をプロダクトオーナーがクローズしない場合に発生します。 

Even more metrics

有用な指標はここで挙げたものに限りません。例えば、品質はアジャイルチームにとって重要な指標です。アジャイル開発に適用できる従来の指標は多くあります。

  • 見つかった不具合の数
    • 開発中
    • 顧客へのリリース後
    • チーム以外から
  • 将来のリリースまで先延ばしにされた不具合の数
  • カスタマーサポートの依頼件数
  • 自動化テストのカバー率

アジャイルチームはリリース頻度やデリバリー速度にも着目する必要があります。各スプリントの終了時には、ソフトウェアを本番にリリースする必要があります。実際にはどれくらいの頻度で行っているでしょうか?ほとんどのリリースのビルドが出荷されていますか?また、緊急の修正を本番にリリースするのにどれくらいの時間がかかりますか?リリースは容易ですか、それとも苦労を伴いますか?

Metrics are just one part in building a team's culture. They give quantitative insight into the team's performance and provide measurable goals for the team. While they're important, don't get obsessed. Listening to the team's feedback during retrospectives is equally important in growing trust across the team, quality in the product, and development speed through the release process. Use both the quantitative andqualitative feedback to drive change. 

次の記事
優位性