ScrumとSAFeの文脈におけるCumulative Flowの実践

この記事では、私たちがフレームワークでの作業プロセスにおいてScrumで Cumulative Flow Chartをどのように実践的に適用しているかについてお話しする予定です。 SAFe

まずは、 こちらの 記事 へのリンクから始めましょう。ここでは、標準的な形でのその目的がよく説明されていると私には思われるので、私の記事を読む前に目を通すことをお勧めします。以下では、私たちがそれをScrumプロセス向けにどのように適応させたか（もともとは Kanbanで使われているものです）、そしてスプリントでの作業においてどのような問題の解決に役立っているかを説明します。

以前に、 Burn Down Chartsに関する 記事 で、そこでは新しい作業の出現と古い作業の燃焼が見えるとすでに述べました。 Burn Down Chartの問題は、Cumulative Flow Chartとは異なり、ユーザーストーリーのステータス間の移動が見えないことです。Cumulative Flow Chartでステータス間の移動を観察し始めると、日々の変化が見えるようになり（Burn Down Chartは数日間変化しないこともあり、 一部の 文脈ではそれはまったく正常な場合もあります）、より微妙な問題に気づくことができます。

これが動的な様子です（画像は実際のデータに基づいて作成された図です）。

この例では次のことがわかります

• スプリントの最初の7日間、テスト工程にある作業量はごくわずかで、変化していません
• DOR（ここではドラフト）から作業へとユーザーストーリーはかなり均等に移行しています - これは良いことです。
• Burn Downと同様に、傾向によればユーザーストーリーはスプリント終了までに 完了しないことがわかります

これら3つの観察を総合すると、次の結論に至ります。ここでは明らかに、まだ早い段階（スプリントの 2〜3日目あたり）で、スクラムマスターが「テスト」レイヤーに注目すべきでした。このレイヤーは 少なすぎ、かなり長い間変化していないのです（原因を確認する必要があります）。テスト準備ができた 作業量が何らかの事情でテストできないと推測することもできますが、そうなるとテスターが 遊んでいることになるので、少なくとも次のスタンドアップで彼らの話をもっと注意深く聞くべきです。

実践の適用について言えば、例えば私は毎日、スタンドアップ前にチームチャットでチーム全員にメンションしてすべてのメトリクスを公開しています。

全体として、メトリクスはやはり正しく解釈する必要があることを忘れないでください。本当に システム的な問題があればそれを見抜けるようにし、あなたの文脈ではむしろ 肯定的な兆候であるかもしれないものを問題と受け取らないようにしましょう