RSGT2022で 「プロダクトバックログ Deep Dive」 というセッションに参加し、いかに今まで自分がプロダクトバックログを意識できていなかったかということに気がつきました。学習したこととチームの現状をまとめ、今後にいかせるようにメモにしていきます。
「プロダクトバックログ Deep Dive」 の資料は発表者の吉羽さんのブログにて公開されています。ぜひご覧になってみてください。
【資料公開】プロダクトバックログ Deep Dive | Ryuzee.com
そもそもプロダクトバックログとはなにか
初心者スクラム実践者の自分にはうまい説明ができそうにないので、 スクラムマスター ザ・ブック から引用します。
プロダクトバックログは、これから開発チームが作業を行っていく製品の要求についての、優先順位付けされたリストです。(~中略~) 各項目の規模は開発チームが見積もりを行います。直近数スプリントの作業実績から、ベロシティの平均値を算出します。
本当にざっくり説明すると、プロダクトバックログはチームのための上から行うTODOリストのようなものです。
順番は流動的で、時と場合によってプロダクトバックログに入っているアイテムの順番を上下したり分割したりして、チームが次のスプリントで何を行うか明瞭化しなければなりません。それをすることをプロダクトバックログリファインメントと呼びます。
より良いプロダクトバックログ作り
セッションの内容をそのままなぞるのではなく、現状、私たちのチームがどの程度バックログに意識を払っていたか、どうすればもっとよくなるかをまとめます。
プロダクトバックログアイテムの分割を行う
大きすぎるプロダクトバックログアイテムはスプリントに投入することができません。適切なサイズに分割する必要があります。
アイテムの分割にはさまざまな方法があります。例えばワークフローのステップであったり、ビジネスルールであったり…。そのチームにあった方法を選択するのが良さそうです。一方で、やってはいけない分割方法は明示的に示されています。作業工程面や技術面での分割を行うことです。
例えば「◯◯機能の設計を行う」「××機能のDB実装」などの技術面で分割されたアイテムをスプリントに投入すると、後続のスプリントでやらなければいけないことが自動で決まってしまい、変化に弱いスプリントになってしまいます。
これらは理屈ではわかっていたことですが、実際私が行うと実装や設計と行った技術面で単位で分割したり、投入段階で適当に分割をしたりしていました。今後は、分割手法を意識しながら定期的に分割を行う時間を作るなどを試して改善していきたいと思います。
準備ができているアイテムだけを入れる
セッションの中で、大原則として紹介されていたのが「準備ができているアイテムだけを入れる」ということです。準備ができていないアイテムをスプリントに投入すると、下記のような弊害が発生し、スプリント終了時にプロダクトバックログアイテムが完成しない確率が高まります。
- スプリント中に何度もプロダクトオーナーと使用を確認することになる
- 着手した後に、想像以上に規模が大きいことがわかる
- プロダクトオーナーに完成確認した時に、認識の相違が見つかる
では、「準備ができているアイテム」とはどういう定義でしょうか。これはチームごとに適切な範囲が異なると紹介されています。
私たちのチームでは、基本的に一つのプロダクトバックログアイテムに一つの仕様書がある状態で実装を進めていました。この方法では、仕様書から実装に必要なリソースをある程度見積もることができるというメリットがありますが、必須要件と希望要件が一つの仕様書に混在しているため、そのスプリントで作業するべき最優先のアイテムが見えていない状態に陥るというデメリットも感じていました。
仕様書の単位で実装を進めると、期限に間に合わないことがわかった段階で機能をオミットするための調整が必要になったり、そもそもスプリントでアイテムを実装できなかったりします。
今後は、仕様書を元にアイテムを分解し、優先順位を持ったバックログを作成していきたいと思っています。アイテムの分解は仕様書が完成した段階で随時取り入れ、プロダクトバックログリファインメントを同時に行っても良いのかな、と思っています。
並べ替えを行う
並び替えもより良いプロダクトバックログ作りには欠かせない要素です。開発チームは基本的にプロダクトバックログを参照し、上からタスクを行っていくことが望ましいからです。
並び替えは価値の高い物や実装にかかるコストなど、アイテム間のさまざまな要素から行っていきます。詳しくは冒頭の資料を参照してみてください。
前述の「準備ができているアイテムだけを入れる」でも紹介しましたが、私たちが今まで使用してきたバックログは仕様書ベースだったため、この並び替えが上手く機能していませんでした。
まずは前述の準備と分割を徹底し、その後に並べ替えを実践していきたいと思っています。
小さく始める
このセッションでは理想的なプロダクトバックログを作るための知見がたくさん共有されていましたが、この記事では明日から試せそうなことを抜き出してみました。
セッションに限らず、RSGT2022ではさまざまな知見を得ることができ、どういう状態であれば理想的なのかというイメージをつかむことができました。今後はそれを自身の置かれている環境に少しづつ還元していければ良いかなと思っています。