プラクティス名（別名）
スプリントバックログ （SBL）
プラクティスの目的・狙い
- スプリントゴールを達成するための実行計画を立てる
- スプリント中、日々の進捗を検査できるようにする
どんな時に使うか
- スクラムでは必須作成物（スプリントプランニングで作成）
- スプリントの見通しを立てたい時（作業の進め方、完了見込み）
実施手順（取り扱いルール）
SBLはDEVによる、DEVのための計画であり、DEVが主体的に管理する。
ただし認識共有のため作成はチーム全員で行うことが望ましい。
スプリントバックログには以下の３つが含まれること。
- 【Why】今回のスプリントゴール
- 【What】今回のスプリントで対象とするプロダクトバックログアイテム（PBI）
- 【How】PBIを実現するためにタスク分解された作業のリスト（SBI）
■計画時
- PBIを実現するためにDEVが実行可能な粒度までタスク分解する
- 実装作業だけでなく、あらゆる付帯作業をリストアップする（申請や調整など）
- タスク毎の所要時間を見積もり、チームのキャパ（リソース）と比較する
- SBIの優先順位を決める（PBIの優先度/タスクの依存関係/作業効率などを考慮）
■スプリント中
- 毎日タスク進捗状況を確認する（タスクボードやバーンダウンチャートなどで管理）
- 追加タスク/飛び込みタスクがあれば即時SBLに反映する
- キャパオーバーが見込まれる場合は、スプリントゴールに影響しない範囲でPOとスコープ調整する
作業担当者は日々の状況に応じて柔軟にサインアップすることが望ましいため、計画時は決めない方がよい
アレンジ例
- 計画時のタスク分解作業はペアワークなどで手分けして行い、事後その結果を全員で共有する
アンチパターン
- DEV以外の人がタスク分解したり、見積ったりしたSBIをそのままDEVに押し付ける
- 計画時に作業担当者が確定しており、計画した担当者ごとにタスクの粒度がバラバラ
SBIの適切な粒度はチームの成熟度によって異なります。SBIをより詳細に具体化すればDEV間の認識は揃いやすくなりますが、その分アイテム数が増え、管理の手間も増えます。粒度の目安としては1日以内に完了するサイズが良いとされていますが、もしもスプリント中にタスク個別の進捗率まで問われるようであれば、サイズが大きすぎることを意味しています。
参考情報
SBLのより詳しい説明としてはまずは定番のAgile Studioさんのサイトをおススメします。
タスク分解のコツについてはRyuzeeさんの記事が具体的で分かりやすいと思います。
こぼれ話（私的コメント）
SBL作成時によく取り扱いに困るのがPBIに紐づかないその他系タスク。例えば前回レトロで挙がった環境改善のためのアクションとか。個人的にはそういったタスクも全てSBIとして管理するのがシンプルで好きです。紐づくPBIが無いのが問題になるのであれば、PBIとしても追加しちゃおう、というのがSMとしての僕のスタンスです。が、POやDEVからするとそういったタスクにストーリーポイントを割り振るのって少し抵抗があったりするみたいで、チームによっても温度感が違うので匙加減が難しいです。見える化されていないタスクって知らず知らずのうちにUNDONEタスクとして積みあがってしまうリスクもあるので、そのあたりをきちんとPOと認識合わせできていると良いのかもしれませんね。