nishida プロダクトバックログの粒度はどれくらいがいい？
新井：
スプリントを持ち越さないくらいの粒度に分けたいところですね。
1日〜2日くらいのスパンで転がっていくサイズがいいんじゃないかな。
転がっていきやすくした方が達成感も得られますし、みんなでハイタッチしたりして喜べるし（笑）。
Doingのところに滞留していると、進捗状況が本人にも周りにも見えづらくなっちゃいます。
中村：
1スプリントで完成できる大きさまで小さくすると、「スプリントレビューでうまく見せられない」と言われることがよくありますが、そこは見せ方を工夫できるといいですね。
スプリントレビューでは個々のバックログを独立して見せる必要はありません。
例えば、できた画面をパッと見てもらって、「見やすくなったね」ということであればそれでいいんですよ。
新井：
アクターによって分けるのもいいですね。
価値が見えやすくなりますし、機能ベースから価値ベースのバックログに転換しやすいと思います。
中村：
プロダクトバックログの分割については、いろんな識者が書籍やブログ、スライド等でヒントを出していますから、参考にされるといいですね。
本を読んで、うまくいかないと悩む人もいるかもしれませんが、今あるバックログに当てはめて、一旦やってみるといいと思うんです。
ホワイトボードの前に集まって、みんなで会話しながら取り組んでみれば、多少違和感はありつつも、前に進む感覚は得られるのではないでしょうか。
それをやらずにただ悩むのは、時間がもったいない気がします。
新井：
半分学び、半分実験。実用半分っていう感覚で、時間をとってみんなでやってみるといいですね。
中村：
アジャイルQA（Quality Assurance）の文脈では「実例マッピング」というプラクティスがあります。
要件をテストの観点から見える化していくんですけど、実は大きなバックログを整理するのにも使えるんですよ。
そういうこともやってみるといいかもしれませんね。
Message from coaches
- 1日〜2日くらいのスパンを目安に、１スプリントで完成できる粒度まで分割しよう。達成感が得られやすく、透明性を高められる。
- スプリントレビューに不安があるときは、価値が伝わるような見せ方を工夫してみよう。
- 機能を使うアクターによってプロダクトバックログを分割するのもおすすめ。
- 分割のヒントはたくさんある。識者による書籍やブログ、スライド等を参考に、まずはチームで会話しながら取り組んでみよう。
- はじめは多少の違和感があっても、前に進んでいる実感が得られることが大事。すぐに実用につながらなくても、まずは学んだことを実験的にやってみよう。
あふれかえるプロダクトバックログ、どうやって整理すればいい？
新井：
断捨離しましょう（笑）。
必要なものは後から絶対に復活しますから、まずは捨てることですね。
そうしないと無尽蔵に増えちゃいますし、1つのレーンを延々とスクロールしないと全部見られなくなってしまいます。
レーンの一覧性を上げることはすごく大事です。レーンを分けるのもいいですが、第一は捨てることですよね。
中村：
6ヶ月が経過したカードは自動的に消す、というルールを設けている現場もあります。6ヶ月経って何も変わらないようなら、恐らくもうやらないでしょう。
新井：
急に復活することはほぼないでしょうね。
中村：
復活したところで、新たに現状に合わせて考え直さなくてはならないことがほとんどですよね。消しても問題ないと思います。
新井：
あんまり数が多いと、いざ探しても見つからないですしね。
中村：
書いた人が既に当事者じゃなくなっていたりすることもありますし。
新井：
時間が経てば、その分だけ情報が増えて解像度が増すでしょうから、必要になった時点であらためて書き起こすのがいいんじゃないかな。
中村：
そもそも、プロダクトバックログが一夜にしてあふれかえる、なんていうことはないと思うんですよ。
プロダクトオーナーが定期的に不要なものを捨てたり、優先度を並び変えたり、そういう意思決定がうまくできていれば、あふれかえることはまずありません。
プロダクトバックログの価値をキープし続けつつ、インクリメントに変換していくのがプロダクトオーナーの仕事ですから、「あふれかえっている」ということは、恐らくプロダクトオーナーがきちんとメンテナンスできていないということなんですよね。うまく回っていないことを示すシグナルなわけです。
新井：
いつかはこの機能を作りたいな、って思うと捨てられないこともあるのかな。「もったいない」って思っちゃう。
クラウド系のタスク管理ツールなら履歴管理の機能が付いているものが多いですから、アーカイブしちゃえばいいと思いますよ。
Message from coaches
- まずは、思い切って断捨離しよう。本当に必要なら一度捨てても復活するはず。必要になった時点で、新たに得られた情報も加味しながら考え直せばOK。
- 6ヶ月経っても動きがないものは一旦消す、といったルールを設けるのもおすすめ。
- 定期的にバックログアイテムを見直して整理するのはプロダクトオーナーの仕事。プロダクトバックログがあふれかえっている状況は、うまく回っていないことを示すシグナルと捉えよう。
- レーンは一覧で見られるのが理想。長くなりすぎないよう、定期的にメンテナンスしよう。
- クラウド系の管理ツールなら、アーカイブすれば後から履歴として確認できる。思い切ってアーカイブしよう。
スプリント期間で完成できなかったプロダクトバックログアイテムはどうするのでしょうか？
新井：
これは、スクラムを始めたばかりの現場ではよく聞かれる質問ですね。
答えとしては「最新の状態にアップデートしましょう」ということでしょうか。
80%できていたとしても、自動的に次のスプリントに入れるのではなく、スプリント計画会議ではゼロベースで判断していけるといいですね。
その際、見積もりの数字が最初とは変わっていたりします。
とにかく透明性をあげるという意味でも、あらためて最新の状態にアップデートしましょう。
中村：
例えば５ポイントで見積もりを出していたものが、実際に途中までやってみたら５ポイントじゃなさそうだと分かった場合は、次のスプリントが始まる前にアップデートした方がいいと思います。
それ以外の場合は、あらためて見積もりをし直すということは私はあまりしないですね。
計算や管理が煩雑になりますし、次のスプリントで残りの分を消化すれば結果的には同じですもんね。
現場ごとのコンテキストに合ったやり方があるはずなので、ここでのお話が参考になればと思います。
Message from coaches
- 見積もりの数字を含め、スプリントが終わった時点で最新の状態にアップデートしておこう。
- 80%できていたとしても、自動的に次のスプリントに入れるのではなくゼロベースで判断しよう。
- 自分たちの現場に合ったやり方を見つけよう。
