プロダクトオーナー、要件の優先順位を付ける

スクラムでは、要件を整理をした一覧をProduct Backlog Item (PBI)と呼びますね。要件が複数あればProduct Backlog Itemsになります。で、前回のブログに書いたように業務要件を出して、それをリスト化したわけです。

要件は小分けにして早く使いたいから順番を付ける
要件を実現するにはしくみをシステム化しなくてはならないので、それを作るには要件が必要です。とは言っても、一度に「このリストの要件を全部を作って」、と言ってしまうと全部出来上がるまで待たなくはならないし、それに出来たときのものがいいのか悪いのかも届いて使ってみてからでないとさっぱりわかりません。

なので、PBIに実現したい要件はあるけれど、システムとして作る期間を短くしてその期間に出来そうな範囲までで要件を絞り込むことで先の出来るまで待たされる、全部出来ないといいものなのか期待外れとかにならないようにするのです。

優先順位を付けることは予想以上に難しい
で、優先順位を付けなければなりません。何せ、プロダクトオーナーは初めてですからねー。要領を得ません。そうは言っても順位を付けなければ進みませんから、順位を付けます。

兎にも角にも、一度優先順位をつけて見るとあれこれ考えてしまって意外とスパッと決まりません。それでもどうにかこうにか優先順位を付けてみました。

このシステムはいくつかの機能で構成するのですが、一度優先順位を付けた後に眺めると、1業務が1機能として見たときにやりたいことというか感覚的にやったほうがいい順で順番付をしてしまっていることがよくわかります。それでは作ってと頼んでも中途半端な機能や機能の単品の部品になってしまうことがわかり、順番を見直す羽目に。

初めてやることは試行錯誤をするつもりで予定を立てる
やっぱりと言うか想定のとおりというか。もともと見直しを2回くらいした方がよさそうだったので、そうした日程にしていた甲斐がありました。ま、ない方がいいに決まっているのですけど、まだまだ試行錯誤は必要なようです。

合わせて業務フローを作成していたのでそれと突き合わせてPBIのリストと紐付して、優先順位を付けた順番に作るとすると、その業務が離れ小島だらけにならないように、と注意をすることでだんだんと落ち着いてくるものです。

優先順位を付けることは、業務を分断して、再度、優先順位の順番に沿って再構成することになるわけです。その再構成して組み上げ直す範囲を意識て、今度はSprint Backlog Item(SBI)に分割していきます。