プラクティス名（別名）
バーンダウンチャート （スプリントバーンダウンチャート、リリースバーンダウンチャート）
プラクティスの目的・狙い
- 作業の進捗状況（タスク消化状況）を可視化し、対話を促す
- チームに進捗ズレを解消するためのアクションを促す
どんな時に使うか
- 朝会で「進捗は順調です」という言葉しか聞いたことがない時
- メンバーの現状認識がバラバラで、チームの足並みが揃わない時
- スプリント最終日に突然「間に合いませんでした」ということが繰り返される時
バーンダウンチャートには、主に１スプリント内のタスク進捗状況を示す「スプリントバーンダウン」と、リリースに向けた機能実装状況を示す「リリースバーンダウン」の２つがあります。どちらも期限に向けて進捗状況を右肩下がりのグラフで表現するもので、スケールが異なるだけで考え方自体は同じです。
実施手順
- バーンダウンチャートの縦軸/横軸を定め、表を作成する
※媒体は紙,Excel,ツールなど何でもよいが、全員が参照できることが必須条件 - 開始日から最終日に向けて目安となる理想線（均等に消化した場合の線）を引く
※なお途中でタスクの増減があると理想線も変わることがある - 残量線（実績）の更新タイミングを決める
※チーム内で統一する。理想は確認タイミングの直前。 - 表の確認タイミングを決める（関係者全員が集まる場であること）
- チャートをもとに、期限内に終わるかを会話し、必要ならアクションを決める
| 比較観点 | スプリントバーンダウン | リリースバーンダウン |
|---|---|---|
| 横軸 （時間軸） |
スプリント日数 | スプリント回数 |
| 縦軸 （残作業量） |
PBIのストーリーポイント タスク見積工数 タスク数 受入条件数 受入テスト数 など |
PBIのストーリーポイント PBIの数 理想作業時間（工数） など |
| 作成タイミング | スプリント計画時 | リリース計画時 |
| 更新タイミング | 1日の開始時 1日の終了時 デイリースクラム時 など |
各スプリントの最終日 |
| 確認タイミング | デイリースクラム時 | スプリントレビュー後 レトロスペクティブ スプリントプランニング など |
アレンジ例
- あえて手書き運用とし、チームボードに貼った表を朝会で皆で更新する
- スプリント最終日はレビューとレトロでほぼ作業できないという場合は、理想線の終着点を1日前に置く
- 遅延の許容限界線を書き加え、それを超えたらアクションするルールにする
アンチパターン
- 理想線と残量線が大きく乖離しているにも関わらず、誰からも声が上がらない
- チャートを描くことが目的になってしまい、その結果を分析していない
- いつもスプリント最終日になると奇跡が起きて一気に残量が0になる
- チーム外の人が監視ツールとして使用を強制する（→もちろんチームは「怒られない数字」を出してくる）
理想線/残量線を計画線/実績線と呼ぶ場合もありますが、「計画」「実績」というワードはズレ＝悪さと捉えてしまい、過度な計画遵守のプレッシャーを生んでしまうことがあるため要注意
参考情報
定番AgileStudioさんの解説
@o-yyu-oさんの記事。バーンダウンチャートのあるある事例と対策がまとまっていて大変参考になります。
こぼれ話（私的コメント）
個人的には進捗を実感できる手書きのチャートが好きです。ただ最近はオンラインメンバーも多く、手書きというわけにもいかず、なんならツールが自動でチャート化してくれる時代です。便利といえば便利なのですが、そうやって労力をかけずに出てきたものって結局スルーされがちなんですよね。
じゃあ、手間暇かけたら見るようになるのかというとそうとも限らず。以前、僕がいたプロジェクトで使われていたバーンダウンチャートは高機能なヤツで、ただその分、入力が面倒かつ難しくて、入力漏れや誤りが日常茶飯事でした。となると出てきたチャートも信頼性が低く、結局あまり活用されませんでした。
なので、バーンダウンチャートはシンプル・イズ・ベストで、一目瞭然の単純なものの方がオススメです。