スプリントバックログ
目的
何を含むか
スプリントゴール 達成のために開発チームが選んだ、取り組むプロダクトバックログアイテムのリスト
上述のプロダクトバックログアイテムを完了させるために必要な事柄のリスト
(optional) その他、開発チームがスプリント中に行う活動
人事部が設定する採用面接、人事評価の書類作成、経費精算など
チームが組織で活動するために必要なコストであることから「税」と例えたりする
チームが使える時間のキャパシティのうち、どの程度の時間が本質的なプロダクト開発に費やせているかを観測することができる
同様に、スプリント中に発生する突発的な対応の比率を出したり (次以降のスプリントで キャパシティのうちどの程度を突発対応のために確保すればよいかのベンチマークとする)
意図するべきこと
スプリントバックログアイテムのサイズ: 1つのSBIのサイズは1営業日で完了するものよりも小さくし、 #毎日動くカンバン を実現する。 そうすることで、連続する2回のデイリースクラムで1つのスプリントバックログが仕掛中であることは想定外であることを示す。
スプリントバックログは誰のためのものか?ステークホルダーやプロダクトオーナーに報告するためではなく、開発チームのためにのみ利用するもの。
どう間違ってもプロダクト開発の生産性をアセスメント用途で測ったり、マイクロマネジメントするための利用はしないこと
プロダクトバックログ完了のためのスプリントバックログアイテムは #完了の定義 に沿って書き出す。例えばテスト環境での動作確認、ドキュメントの整備までもれなく行われるようにする。プロダクトバックログの完了や受け入れ判断のタイミングで完了の定義を気にかける必要を排除する。 スプリントバックログのライフサイクルがスプリントをまたがないようにする。
スプリントバックログはスプリント中に完了させることに全力を尽くさせ、スプリント終了時にロールオーバーさせない。コミットメントの醸成、次のスプリントの計画をゼロベースで行う etc...
スプリントバックログ自体はスクラムチーム外に共有するものではない。スプリントを重ねるごとに改良する余地を残す。
スプリントのはじめに書き出したものをやりきることを第一義としない : デイリースクラムは進捗報告の場ではなくスプリントゴール達成のための再計画の場。スプリントバックログもデイリースクラムの中で見直す (もちろん、出した SBI はやり切るのが大前提だけど)
スプリントバックログの見積もり
絶対見積もり (時間) か、相対見積もり (ポイント制) か → SBL は絶対見積もり。なぜか
スプリントバックログのボリュームを見積もる目的は、期間が定められたスプリントにタスクが収まるかどうかを判断することが目的。
着手タイミング、アプローチの方法がわかっているので時間で見積もる難易度が低い。
プロダクトバックログアイテムの見積もりを相対で行う理由は方法不確実性が高いから。
パーキンソンの法則 を引き起こさないために no estimate というアプローチも選択肢?? 実装例
プロダクトバックログを管理するツール上での管理 ( #Jira の Story 配下のサブタスクなど) 「スプリント中に開発するソフトウェアのアーキテクチャをホワイトボードに書き出し、開発が完了した部分にマークを付けていく」みたいなことをやってるチームもあるらしい (本で読んだことがあるだけだよ)
完全に私見: スプリントバックログは正規化されすぎない方が良い
もちろん、メリットもあるのだけれど。以下、考えている理由。 (もちろんチームの状況によって、スイッチングコストとか慣れetcあるので、必ずこうしろ、みたいなことはやらないよ)
スプリントバックログのライフサイクルは1スプリントで収める。disposable である余地が、デジタルツールの導入で失われる
Disposable にすることで、スプリントを重ねるごとにスプリントバックログの構造の進化の余地がなくなる (進化? → 後述)
Issue Tracker に起票して翌スプリントにロールオーバーしても痛くも痒くもない状況があまり良いとは思わない
物理ホワイトボード上の付箋の場合、1週間使っていると汚くなってくる。汚くなった付箋がホワイトボードの上に残っていることが有益な情報となっている (滞留して手がつけられなくなっているから対策を考えよ、とか)
そもそも3スプリント前のスプリントバックログを振り返る必要に迫られたこと、ある?
スプリントバックログは, PBI と SBI の 1対N の関係だけで成り立つわけではないので、きれいなスイムレーンだけで成り立つ構造ではない。スプリントバックログ自体も進化させながら、チーム、状況に応じた最適な形を見つけるべき
PBI に紐付かないアイテムがたくさんある (税、レトロスペクティブで挙がったアイテム
複数の PBI の実現に必要なブロッカーになるタスクがスプリントバックログに現れたり
メリット
数値的な計測
各種インテグレーション=
過去に見てきた/やってきた、良いスプリントバックログの運用
ホワイトボードカンバンの余白に、デイリースクラムのパーキングロットやレトロスペクティブで話したいトピック、落書きなどのスペースを設ける
miro 上で、カンバンの周囲に毎スプリントのレトロスペクティブの議論ログを残す
miro 上で、カンバンの横にスプリントプランニングにて行った大枠の設計や議論のログを残す。
スプリント期間中に運用するカンバンとは別に、スプリント末に行うリリース作業の TODO リストをカンバン形式で起票しておく
毎スプリント、リリースした後のパッチ適用作業やテスト、デモリハーサルの内容が異なる中で、スプリント中に最後のリリース作業計画を育てていくイメージ