先日の京アジャでプロダクトバックログ（PBL）にプロダクト以外のアイテムも入れるのかどうかについての議題がありました。僕は入れる派で今のチームでも入れていたのですが、これで良いのかどうかについては前から悩んでいました。
色々な意見や考え方を聞いて、考え直す良い機会なので改めて考えてみました。
注意：あくまで僕の意見や考え方なので、これが正解と言うわけではありません。
スクラムガイド的には入れない
スクラムで困ったときに見るドキュメントはスクラムガイドですね。PBLに関する部分では以下のように書かれています。
■プロダクトバックログ
プロダクトバックログは、プロダクトに必要だと把握しているものをすべて順番に並べた一覧である。
・・・中略・・・
プロダクトバックログは、今後のリリースで実装するプロダクトのフィーチャ・機能・要求・要望・修正をすべて一覧にしている。
・・・中略・・・
複数のスクラムチームが同じプロダクトの作業をすることがよくある。そうした場合、プロダクトの作業は 1 つのプロダクトバックログに記述する。また、アイテムを分類するための属性をプロダクトバックログに追加することもある。
プロダクトに必要なものは入れると書かれていますね。どういったものをプロダクトに必要なものと判断するかはチームによって異なると思いますが、プロダクトに関係ないものは入れないと読み取れます。
レトロスペクティブの結果を一つ以上PBLに入れるって記憶していたからプロダクトに関係ないアイテムも自信を持って入れていたのですが、スクラムガイドを見直すとプロダクトバックログではなくスプリントバックログの項目でした。
■スプリントバックログ
継続的改善を確実なものとするために、前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも 1 つは含めておく。
PBLとは別で見える化
プロダクトに関係ないアイテムはPBLに入れないことが分かりました。じゃあ、それらのアイテムはどうやって透明性を高めるのでしょうか。チームメンバーの誰かがプロダクトに関係ないけど、やらねばならない作業を抱えていた場合、共有したほうが良いと僕は思っています。スクラムの価値基準にも「公開」が含まれています。プロダクトに関係ないけど、チームメンバーに関係するアイテムは共有して、少しでも気持ちよく助け合えるほうが良いと思っています。
じゃあ、これからの作業を登録するならPBLだ！っと思って、一時期は全部PBLに入れてPOに優先順位を決めてもらっていました。しかし、POもすべてのアイテムを把握するのに時間がかかり、優先順位が正しく付けられなくなっていました。そこでプロダクトバックログとは別のバックログ（NPBL（NotPBL））を用意することにしました。NPBLはプロダクトに関係しない各個人が抱えるアイテムを入れておき、管理も各個人が行います。そして、スプリントプランニング時に、スプリントで作業したい旨を相談して、チームで合意がとれればスプリントバックログに追加します。NPBLに入っていることで、各個人がいつごろにどんな作業を抱えているか共有できるようになりましたし、POもPBLの優先順位がつけやすくなりました。
NPBLはチームのモチベーションも高める
好きな書籍 アジャイルコーチング の「4.4 チームをやる気にさせる」の項目に以下の記述があります。
開発者たちが延々と続くユーザーストーリーを処理しながら燃え尽きていることがあります。
プロダクトに必要なものだけ開発しているとモチベーションが下がるタイミングもあると思います。プロダクトに関係あるか分からなくても新しい技術にチャレンジすることは時に必要で、そういった状況を作る意味でもNPBLは役に立つと考えています。
さいごに
このやり方はまだ始めたばかりですが、以前と比べて優先順位をつけやすくなり、今のチームにはあっていそうです。
スクラムは細かい進め方の決まりはないので「あれ？この時どうするの？」って時はチームで考えて、自分たちのより良いやり方を見つけ出す必要があるので、これからも色々と考えていきたいなぁと思います。
