長すぎるプロダクトバックログをなんとかするTips

プロダクトバックログをMustとBetterで分ける

いくつかの対策をやったが、これが一番効果的だった。MustなプロダクトバックログとBetterなプロダクトバックログに分けてしまう。Mustに入れるものは本当に絞って、それ以外はBetterに入れる。自分の場合はなぜか100近いプロダクトバックログアイテム(PBI)があったが🤔、Mustが10~20くらいになればいいし、 20ちょいでもなんとか希望が持てた。

Mustの定義としては、社外のステークホルダーとはっきり約束したものとかそんな感じか。社内のステークホルダーと話がまとまる範囲で、上記の個数に収まるように定義できればいいと思う。

これが何の意味があるかというと、Mustに限った場合のバーンダウンを計測できる。ベロシティを計測してなくてもある程度スケジュールの想像がつく。明らかに完了できなさそうならチームサイズを見直すとか(人が増えればベロシティが上がるかというとそうでもないが、、)この量だと終わらないのでMustを削りましょうとか議論できる。そうするとスケジュールの不安なく開発を進められるようにはなる。

なぜこれを書いたか

最近ゾンビスクラムサバイバルガイドと言う本を読んでいる。スクラムがうまくいかなくなった状態をどうやって脱するのかを書いた本で、自分の現状にも一致していて参考になった。

スクラムとは何か、プロダクト開発はどうやるかという情報は十分にあるが、その辺の知識を持ってる人は多いと思う。一方で「なんちゃってスクラムをやってます」という自己紹介は多分よくあって、そのなんちゃってを本当に自信を持ってスクラムと言えるようにする方法の方が求められてるのではと思い、その地味な一歩を記せればということで書いた。