プラクティス名
品質バックログ
プラクティスの目的・狙い
- プロダクトの品質確保に必要なタスクをあらかじめ盛り込む
どんな時に使うか
- 品質確保のためリリース前にはやっておきたい、と思っていたタスクが結局実施されない、といった事態が慢性的に続いている時
実施手順
- リファクタリングや高負荷テストといった品質を確保するためには欠かせないが、通常タスクのついでに行うには大きすぎる作業をDEVがPBIとして追加しておく（これを「品質バックログ」と呼ぶ）
- 何故その作業が必要なのかDEVやSMからPOに説明する
- 品質バックログのストーリーポイントは時期によって変わりやすいため、こまめに見直す
- 品質バックログの追加は品質状況に応じて適宜行うか、リリースプランを踏まえ先に追加しておく
アレンジ例
- スプリントN回おきに品質バックログを処理するための回を設ける、など周期化する
- 全部を一度にやろうとすると作業量が大きすぎる場合は範囲を限定してPBIも分割する
アンチパターン
- PBIは追加したが、POがその意義を理解していないため、優先順位が低いままで実行されない
- 品質バックログが逆に免罪符となってしまい、本来スプリント中に担保すべきことが行われなくなる
参考情報
「品質バックログ」の出典は以下の書籍です（ただし上記の説明は色々付け足しています）
こぼれ話（私的コメント）
アジャイル開発ってQA屋（品質保証）泣かせなんですよね。QA出身の僕が言うのだから間違いないです。既存のメトリクス（品質指標）は軒並み使えなくなるし、スクラムチームの外から第三者的に品質保証するというスタンスもイマイチ、ハマらないし・・・。なのでチームの中でしっかり品質確保してもらいたいところですが、そのための品質活動の痕跡がまた追いにくくて困ります。品質バックログがあればそのあたりが多少は見えるようになるかもしれません。
ピュアなアジャイラーの方には品質はスプリント内で担保すべきものであって、そもそもバックログ化すべきではない、とお𠮟りを受けそうなプラクティスではあります。