Pivotal Tracker の効果的な運用についての考察
Published at: 2023/9/12
Pivotal Tracker でタスク管理をしていくと、やりたいことと、やるべきことを Backlog ないし Icebox に突っ込んでいくことになる。 そして、それを整理せずに放置していると、 Backlog は無限に伸びていくし、 Icebox は実質ゴミ箱みたいな扱いになっていく。
The Icebox is where stories go to die
thoughtbot.com
これはあまり効果的なタスク管理とは言えないので、整理していく方針について考察する。
Icebox に入れたくなるタスクの類型
上記 "The Icebox is where stories go to die" の記事において、 Icebox につっこまれる story としては、以下の2パターンがある、としている。
- まだ取り組むための準備が整っていないもの
- まだ取り組む準備ができておらず、 Sprint Item ととして実行できないもの
- low priority なもの
このうち、 low priority なものは Backlog でも、優先順位を下の方に移動させることで、表現ができる。 であるならば、優先順位が低いからといって、ゴミ箱的に放り込むべきではなく、基本的には Backlog 上での管理を行っていくべきである。
Pivotal Tracker では大きなタスクや複雑なタスクは管理すべきではない。
Pivotal Tracker のデフォルトのストーリーポイントの粒度は、 0, 1, 2, 3, 5, 8 である。 これは、ほぼほぼただのタスクに落ちた程度の TODO しか管理することができない。 そう考えると Pivotal Tracker はその設計として、タスクをスプリントに詰めていくことに特化したツールであると考えられる。
実行単位はタスクでしかないので、大きなタスクを考える場合、個人的には、それは別の機構で管理していった方が、いろいろやりやすい、という実感がある。
例えば、プロジェクト資料としては Notion に入れていき、細かいタスクに落ちたものたち、ないしスプリント管理の対象になったものたちを、 Pivotal Tracker に入れていくような運用である。
正直、 Epic と、 blocker 等のチケット間の関連機能のみからなる、チケット管理ツールとしての構造しか持たない Pivotal Tracker においては、複雑な手順を要するタスク(プロジェクト的なタスク)の管理は、向いていない。
Icebox の運用
Icebox には3種類のストーリーを入れるのが妥当である。
- Inbox として、優先的に整理を行っていく項目
- 実行要件が到来していない、しかし将来的には実行するべきタスク
- 粒度の大きい、スプリントでの実行がまだできないタスク
"Inbox", "Pending" のリリースを Icebox に配置し、それによって上記 3 レーンにストーリーを分離する。 "Inbox" と "Pending" は、例えば週次などで、 Backlog への移動など、適切な場所への移動を行っていく。 粒度の大きい unestimated なタスクは、随時 NextAction たちを Backlog に入れていき、完全にタスク分解できたタイミングで Backlog へ全移し、という運用ぐらいが丁度良い。
Backlog / Icebox の整理
Backlog も Icebox (の下の方の、粒度の大きいタスクたち)も、 Pivotal Tracker で管理する以上は、優先順位によって常にその上下の位置を管理できる状態になっているべきである。 Backlog と Icebox のアイテムの量が増えてくると、その優先順位の管理だけで、コストが重んでしまうことになる。
整理整頓の考え方や、ドラッカーの体系的廃棄の考えのもと、実質、もう取り組む可能性が低いタスクについては、 Backlog / Icebox から削除していくべきである。
時間は有限であり、それをスプリントで表現し、それを有効活用していくのがスクラム / スプリントの考え方である以上、 Backlog に登録される Item は、その貴重な枠を消費するのに足るタスクかどうかを峻厳に考えるべきである。
バックログの長さは最短 2 スプリント分だけあればスプリントを回していくことはでき、最長は、タスクの流入量のばらつきを踏まえて、実行するべきタスクがなくならない程度の枠があれば良くなる。 それを超えた量のタスクたちについては、むしろ延々に実行される未来は来ない、という結論すらありうる。 ある一定の未来以上に積まれることになったタスクは、機械的に削除、でも問題なさそうではある。
また同様に、着手されていく可能性が低い Icebox の項目についても、整理の文脈で削除していった方がよい。
このような形でスリムに Backlog と Icebox を整理整頓していくことで、スプリントを回す際の管理コストを可能な限り減らしていき、この仕組みの本来的な目的である、価値あるタスクの実行効率の最大化が、実現されていくのではないか、と考えている。