SAFeとScrumの文脈におけるバンダウンチャートの実践

この記事では、私たちがSAFeの方法論に沿って業務を進める中で、バンダウンチャートをどのように実践的に活用しているかをお話しする予定です

まずは一番興味深いところから始めましょう。つまり、このチャートをSAFeで使う場合、SCRUMで使う場合と比べて何ら特有の点があってはならない、ということです。それとも、あるべきなのでしょうか？

私たちのSAFeは、SCRUMには存在しない RTEという役割がある点で異なります。バンダウンチャートはスプリント内の作業量を追跡するツールであり、何よりもまずSCRUMチームのために必要なものであって、外部の誰かのためではないですよね？

というわけで、それでもなお、SAFeフレームワークの中にいながら、私たちがバンダウンチャートをどのように使っているかについて話を進めます。

私は Scrum Master の役割にあり、このチャートを毎日 Dev Team全体に向けて提示するように心がけています。私が使っている手段はチームチャットで、「@」でチーム全員にメンションし、チャートの現在の状態のスクリーンショットを添えるというものです。チーム全員へのメンションは非常に繊細なツールであり、できるだけ稀にしか使わないことが重要です（私たちスクラムマスターは、チームが快適に、そして可能な限り集中を乱されずに働けるよう支援すべきですよね？）

その結果、チームは毎日スプリントの現在の状態を目にし、以下の出来事を追跡できるようになります

• 計画外の作業の発生
• タスクが未完了ステータスのまま長時間滞留すること
• リスクの過剰な見積もり
• 作業が適切なペースで進んでいるかの把握

次に、これらの出来事のそれぞれを詳しく説明し、自分の実践から例を挙げていきます。

計画外の作業の発生

このチャートでは、新しい作業がどのように発生するかが非常によく分かります（2週間スプリントの第2火曜日）。

実践例：「アジャイルの原則を共有するスクラムチームの一員である開発者が、プロダクトオーナーと直接うまく連携しています。プロダクトオーナーは彼に、これはすぐに実装する必要がある、君も分かっているだろう、ここは速くてリスクも最小限だと言います。

その開発者は優秀で、アジャイルのことやビジネス価値の提供の重要性をすべて理解しており、バックログからストーリーをボードに投げ入れます。チームによる見積もりは6spです。

チームの残りのメンバー（開発者とプロダクトオーナー以外）は、朝のチャート更新でそれに気づきます。スタンドアップでチームはこの状況にどう対応するかを決定します。おそらくそのストーリーはスプリントから外され、チームはプロダクトオーナーと開発者にそうすべきではないと伝え、プロダクトオーナーは必要であればこのストーリーを次のスプリントに入れることができます。

もちろん、理想的にはチームはチャートがなくてもスタンドアップで新しい作業の発生に気づくべきです。しかしチャートは優れた指標であり、チーム全体にとって重要なこの変化に気づかないリスクを最小限に抑えます。

ここで重要なのは、このシナリオはチームのレベルに応じて異なる展開になり得たということです。優れたチームでは、プロダクトオーナーがそのようなことをする可能性は低く、仮にしたとしても「すぐに実装できるから」という理由ではなく、「今これを実装すれば来月の利益を20%増やせる可能性が55%あると見積もっている」とか、その他の測定可能な指標を根拠にしたでしょう。

タスクが未完了ステータスのまま長時間滞留すること

ここで、非常に長い間作業が部分的にも完了していないことがわかります。これは さまざまな問題を 示唆している可能性があります。そのいくつかを挙げます

• タスクの分解が不十分

  初心者チームは分解が不可能だとよく言います。彼らの場合、すべてが 最終日に 燃え尽き、作業が並列化されないなどです。もちろん、これには スクラムマスターが 取り組み、分解の価値をチームに説明する必要があります。

• 最適に定式化されていないDOD

  DOD（Definition of Done）は、スプリントにおけるユーザーストーリーの完了基準の記述です。 時には まったく存在しないか、非常に抽象的に記述されていることがあります。これは十分に問題となり得ることで、 当然ながら、スクラムマスターが解決を助けるべきです

リスクの過剰な見積もり

この場合、チームがリスクを見積もりすぎた状況が見られます。

おそらく、あるストーリーが 過大評価されていたのでしょう。あるいは、より体系的な問題であり、スプリント計画時に 作業量を増やす必要があるのかもしれません。 いずれにせよ、この状況は適切ではありません。なぜなら、ビジネス側は スプリントのタスクが まさにスプリント終了時までに実現されることを計画していたからです。依存関係がどのように計画されたかに応じて、 ここではおそらく期待値を調整するための会議を行う必要があるでしょう。

私の経験では、見積もり時に議論されたものよりも速い解決策が見つかった場合にこうなりました。 チーム全体でスプリント終了までにどのストーリーをクローズできるかを議論し、レトロスペクティブで グルーミング時にコードを見るようにしようと合意しました。コードをちょっと見るだけで、解決策がはるかに単純であることがわかるのに十分だったのです。

理解 - 作業が適切なペースで進んでいるか

ここで注目したいのは、Burn Down Chartのグラフ的に失敗した表示方法です

画像の上部は、以下に述べる2つの理由により、あまり成功していないグラフィック実装の例です。

• 新しいSPがスプリントに入ったことが目立たない

  ここでは、上の図では、計画外の作業が追加されたことがほとんどわかりません。下の図ではより明確です。

• 相対的な残作業量が正しく表示されていない

  上の図によると、あと3日作業が残っています。実際には2日で、 休日には 誰かが休む予定かもしれません。

もちろん、こうした些細なことは取るに足らないと感じる人もいるでしょう。しかし理解すべきは、チームの各 メンバーは この図をちらっと見るだけであり、この図は最大限の 有用な 情報を伝えるべきだということです。