プロダクトバックログを一列に並べたらシンプルになった

「自分たちのプロダクトバックログが複雑すぎてわからん」という問題を改善しました。

改善前

今まで使っていたプロダクトバックログには、次のような9つの状態（以下、status と呼びます）がありました。基本的には、この順序で status が進んでいきます。

1. Draft：下書き
2. UI required：デザイン待ち
3. Backlog：要件とデザインが確定した
4. Waiting for refinement：リファインメント待ち
5. In refining：リファインメント中
6. Refined：リファインメント済み
7. Ready：次のスプリントで着手するつもり
8. In progress：このスプリントで着手中
9. Done：完了

この構成は、以下の事情を反映したものでした。

• リファインメントの前に、デザインがある程度固まっていてほしい
• デザインチームはスクラムのチームの外に存在している

そして、カンバン形式のビューをメインで使っていました。status ごとのカラムが並んでいて、左（Draft）から右（Done）へとプロダクトバックログアイテムが流れていきます。

カンバン形式のビューの全体像（中身はダミー）

しかし、この方法には以下のような問題がありました。

• status が多くて管理が煩雑
• プロダクトバックログアイテムに取り組む順番^[1]が分かりづらい
• 特別な事情でプロダクトバックログアイテムを急ぎで割り込ませるときに、管理が難しい
• カンバン形式のビューだと見通しが悪いため、リファインメントやスプリントプランニングでは、それぞれ別のビューが必要

2番目の「プロダクトバックログアイテムに取り組む順番が分かりづらい」について、もう少し補足しておきます。まず、各 status のカラム内では、取り組む順番にプロダクトバックログアイテムを並べています。これは簡単ですね。

各 status 内では取り組む順番に並べている

しかし、このプロダクトバックログでは、status を跨いだプロダクトバックログアイテム同士の順番を示すことができません^[2]。たとえば、Waiting for refinement の一番上にある「Slack 連携機能の追加」と、Refined の中ほどにある「チャット機能のリアルタイム通知」とでは、どちらが先なのか示されていません。

status を跨いだ順番の関係は示せない

status の流れからすると、より右にある「チャット機能のリアルタイム通知」が先であるかのように思えます。しかし、「『チャット機能のリアルタイム通知』のリファインメントを済ませて Refined になったものの、結局そこまでニーズがないことが分かり、ずっと Refined に残っている」という状況なのかもしれません。あるいは別の可能性として、「緊急で対応したい『Slack 連携機能の追加』が、猛烈なスピードで左から右へと進んでいっている最中」という状況も考えられます。

……このようにいろいろな可能性が考えられますが、結局順番が示されていないので、プロダクトオーナーにいちいち「これってどういう順番なんですか？」と聞かなければ分かりません。問題点の 3 番目に挙げた「特別な事情でプロダクトバックログアイテムを急ぎで割り込ませるときに、管理が難しい」にも繋がります。

複雑ですね。

半年ほど前にプロダクトオーナーが交代になり、新しいプロダクトオーナーに対して「わたしたちのプロダクトバックログはこうなってます！」と説明しました。が、自分でしゃべっていても複雑です。新しいプロダクトオーナーの横で運用のサポートもしたんですが、やってみるとこれまた難しい。仮にわたしがプロダクトオーナーだったとしても、これを運用できる自信はちょっとありません。

改善後

そこで、以下のように見直しました。プロダクトバックログアイテムをただ一列に並べるだけです。スクラムガイドに以下のように書かれているとおりの、基本スタイルそのまんまですが。

プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの⼀覧である。これは、スクラムチームが⾏う作業の唯⼀の情報源である。（強調は筆者）

すべてのプロダクトバックログを一列に並べる

この並び順は、プロダクトバックログアイテムに実際に取り組む順番です。最低限この順番だけ見ておけば、現時点での予定が誰でもざっくり掴めます。また、先ほど「『Slack 連携機能の追加』と『チャット機能のリアルタイム通知』は、改善前のプロダクトバックログだとどっちが先だか分からない」という例を挙げましたが、改善後のプロダクトバックログであれば、一目瞭然です。

「Slack連携機能の追加」の方が先だった

さらに、「特別な事情でプロダクトバックログアイテムを急ぎで割り込ませるときに、管理が難しい」という問題も解決しました。たとえば、「この機能はニーズが多いことが分かったので急ぎでやりたい」となれば、順番をグッと上の方に動かすだけです。上の画像では、Draft 状態の「利用統計のグラフ表示」が 11 番目に置かれていますが、ここから「わりと重要な機能なので、早めに要件を固めてデザインやリファインメントに進む必要があるんだな」ということが分かります。

「デザインが完了したか」「リファインメントが完了したか」については、status ではなく、別々の属性として管理することにしました。こうすることで、status の状態数が減ってシンプルになります。9状態から4状態に圧縮できました。

1. Draft：下書き
2. Backlog：要件が確定したプロダクトバックログアイテム
3. In progress：このスプリントで着手中
4. Done：完了

status を分解してシンプルにした
改善前と比較しやすいように、「9 状態の status」も参考として表示しているが、実際の運用では不要。

その上、デザインやリファインメントにおいても、どのプロダクトバックログアイテムから着手すべきかひと目で分かります。

• 「デザインが完了したか」属性の列を見て、完了していないものを上からデザインしていけば OK
• 「リファインメントが完了したか」属性の列を見て、完了していないものを上からリファインメントしていけば OK

デザインやリファインメントに着手すべき順序

また、「リファインメントが先に完了しているけど、細部のデザインはまだ調整中」のような状態も、素直に表現できます。改善前のバックログでは、運用でカバーするしかありませんでした。

リファインメントが先に完了しているけど、細部のデザインはまだ調整中

単純ですね。

さらにおまけで、「リファインメント待ちのムダが可視化された」という思わぬ効果もありました。一列に並べた表にしたことで、「デザインは完了しているがリファインメントがまだ」なプロダクトバックログアイテムの多さが、ひと目で分かるようになりました。

デザインは完了しているものの、それからの待ちが長くて無駄になってしまっている

改善前のカンバン形式では表示が見切れてしまい、その量が直感的に掴めていなかったのです。

これらのプロダクトバックログアイテムは、「せっかくデザインしたけど、まだまだ日の目を見ない」という状況なわけです。仕掛りのような状態で、プロダクトとしてはまだ価値を生み出していません。また、リファインメントを経て着手するまでの間に状況が変わったり、そもそもプロダクトバックログアイテムが不要になるかもしれません。このようなプロダクトバックログアイテムを増やさないように留意すれば、デザインチームのリソースをより有効に使えそうです。

おわりに

積み重なったカスタマイズによってプロダクトバックログの運用がややこしくなっていましたが、一旦基本に立ち返ったことで、かなりシンプルになりました。これで透明化が進み、チーム内外のコミュニケーションもしやすくなりそうです 🙌

裏では「そもそもプロダクトバックログアイテムが多すぎてわからん」という問題もあるのですが、それはまた別のお話……。

脚注

1. 雑に言ってしまえば「優先順位」のようなものですが、優先順位との違いについては プロダクトバックログにおける優先順位と順番の違いは何ですか？ | Ryuzee.com が参考になります。

2. 要は半順序集合になっているわけですね。プロダクトバックログは、本当は全順序集合であってほしいのに。