(この記事は2022年に取り組んでたプロジェクトで自身の経験の話です)
Product Backlog (PBL) はこれから開発する成果物に必要な機能のリストである。Product Owner (PO) は最新のユーザーの要求を拾い上げ、PBLを最新の状態にアップデートする責務を負っている。毎週の PBR でタスクの優先順位付けを実施し、Sprint Planningでは高優先順位のものからSprint Backlogに取り込んでいく。
これを毎週繰り返すと、以下のような事象が発生する。
この事象が発生すると以下のような問題が生じる。
- 起票したときのことを忘れ、積んだときの背景や前提条件が不明になったアイテムが放置される
- ユーザーがその機能を欲する気持ちが以前より弱くなったアイテムが放置される
- 例:ユーザー的に あったらいいよね ≒ なくてもいいよね になっているアイテムが存在する
- 実装以前にタスクの具体化等の議論が必要なアイテムだと、Low程度のタスクだとコストが大きすぎて放置される
- エンジニアがSprint Planningでアサインされたアイテム以外で、隙間時間等で自発的に着手したいアイテムを探すとき(例:SP 1で依存がないアイテムなど)にLowの中でどれをやれば良いかわからない(前提:SPが低いアイテムの割合がLowに比較的多い)
対策案としてPriorityにICEBOXを追加する案を考えてみた。
優先順位のLOWより下に、ICEBOXを作る。ICEBOXに送られたアイテムはSprint Planningでピックアップ対象から外し、かつエンジニアが自発的にアイテムを取る際もここからは取らない。
作成日時から3ヶ月経過しなおかつ更新もないアイテムは、自動的にICEBOXに送る。
1ヶ月に一回くらい、ICEBOXから復活させるかアイテムを削除するかを審議する、ICEBOX Refinementをする。
結果、上に挙げた問題が解決された。また時間の経過につれて現状と乖離したPBIの情報を、無理に労力をかけて修正せず、実態に合わせて起票し直すことで、よりローコストにPBLをメンテナンスできた。