錯覚とかじゃなくて多分真実。
PBI＝プロダクトバックログアイテムは小さい方が良い！
最近「PBIはできるだけ小さくした方がいい」と言いかけて、「あれ、そうだよね？なんでだっけ？」となったので頭を整理することにしました。
優先順位がつけやすい
優先順位が付け難いバックログアイテムが複数あったときに、大きなPBIを分割してみるとスポッといい感じにハマることがある。
「この改修A早くやりたいけど重たいな」「Bのバグは緊急性高いぞ」って時に、「Aって別にまとめてやる必要ないやん！A-1だけ先にやっとこ！」っていうのを見つけられるととても気持ちがいい。
常に小さくしとけば柔軟に決められるし、そうでなくても悩んだときに「小さく切れないか」って選択肢を最初に出せるとスピード感保てる。
結果が出せないリスクが抑えられる
スプリントで成果＝アウトプットが出せるかということ。アウトカムでもいいけど。
スプリントで取ったバックログアイテムは確実に終わらせる、というのは大前提としても、実際には割り込みやら見積りが甘いやらで終わらないこともあるよ。
それは仕掛かりとして次のスプリントでってなるのが多そうだけど、仕掛かりが残るってことはその分スプリントで期待していた進捗が出ていないワケで、これがでかいPBIだと割と悲惨だと思う。
スプリントの８割をしめるPBIが最後の最後でバグ出ちゃって収束しませんでした、とか最大でも期待の２割しか出せてないし、これが特大PBI一つをスプリントかけてやりますとかだと、何も出せなくて「今週何してたの？」ってことになりかねない。
同じことやるのでも細かくしておけば「予定の８割出せました」と言えるので多少は心が穏やかでいられる。
細かくリリースできる
細かくリリースできるってことは、それだけプロダクトを最新（最善？）の状態に保てるということ。
スクラムみたいな繰り返し開発するスタイルでビッグバンリリースということはないだろうけど、小さめのビッグバン、言わばミニビッグバンを隔週くらいで出すケースは結構あるんじゃないかと。
それよりか、分けれるなら分けて小出しした方がリスクも少ないし着実に進められる。
施策と結果の関係がわかりやすい
PBIが大きい時って、「あれもこれも」を一つのアイテムで実現しようとしていることが多いと思う。
複数の目的を一つで達成しようとしてまとめているけど、実は目的ごとに独立したPBIに分けられたりする。
「この機能改修でこんなフィードバックがきた」と言えればわかりやすいけど、「アレとコレとソレやったらこんなフィードバックがきた」ってなっちゃうと結局どの対応が響いてたの？ってことになってしまう。
仮説に対する検証がちゃんとできる状態にはしておきたいし、いろいろ講じてからではなくてフィードバック踏まえて次を決めたい。
でかいと複雑化しやすい
まとめる必要のないものがまとめられた結果、要らぬところに依存関係が生まれてしまったり、スマートに考えにくくなってしまうことがある。
must haveとmust haveをnice to haveで繋げて大きなPBIを作っていたりするととても複雑に見えてしまうけど、一旦nice to haveを忘れてmust have単体で見たら単純、みたいな。
作業ボリュームにしても、あれやらなきゃこれやらなきゃって気になって目移りしてしまうよりか、一つのPBIに集中した方が捗ると思う。
なんか他にもあるかな。
あったら教えて欲しいです！
とにかくPBIは小さくできるなら小さくしときたいんだけど、これが案外むずい！
「コレ必要だ」と思った時点ではまとめて一個なのよね。
まとめてやったほうが効率が良いとか、効果が高いとか、そういうのはあると思うけど、それは小さく分けた後に考えた方が構造がしっかり見えて好きだなぁと思いました。
コメント