プロダクトバックログ項目はReadyなものだけスプリントに投入するべきという話

 2016/11/03

Follow @ryuzee

みなさんこんにちは。@ryuzeeです。

プロダクトバックログはスクラムにおける生命線の1つです。 プロダクトバックログが良くないとプロダクトの価値がでなかったり、そもそもスクラムチームとして安定したデリバリーを行えません。

プロダクトバックログでよく起こる問題

プロダクトバックログを管理する上でみなさんがよく知っているのは、並び替えをする、という点ですが、これだけではまったく不十分です。

単に並び替えだけをしたプロダクトバックログで、スプリントを始めてしまうと以下のようなことが起こります。

• 選択したバックログ項目の中身に対してプロダクトオーナーと開発チームの理解が違ってしまう
• そのためスプリントを開始した後に頻繁にプロダクトオーナーと会話をする必要が出てきてしまい、場合によっては本来の要求が別のものであることが判明する
• もしくは色々会話をしていたら、当初の想定以上に規模が大きいことが分かり、スプリント中で完成しない
• 会話や決定までの待ち時間を惜しんで複数のプロダクトバックログ項目に同時に着手してしまう
• 結果として、複数のプロダクトバックログ項目で同じことが起こり、同時に頑張って進めたものの結果として何一つ完成しない
• そもそもプロダクトオーナーが会話する時間を取れなかったり、開発チームが勝手に想像して実装を進めた結果、プロダクトオーナーの受け入れ確認で拒否される
• これらの結果、各スプリントの実績（ベロシティ）のバラつきが多く、今後を予測できない

このような問題を防ぐためには、スプリントに投入するプロダクトバックログ項目はReady（準備完了）になっているものだけを投入しないといけません。

Readyとはなんだろう？

さきほど見てきた問題を流れの観点から見ると、「要求 → 開発」の流れにおいて、逆流が起こっていることを意味します。 このような逆流が起こってしまうと、完成までに余計に長い時間がかかったり、混乱したりします。これらを避ける必要があります。

プロダクトバックログの責任者はプロダクトオーナーですが、開発チームにプロダクトバックログ項目を引き渡す（開発を始める）にあたっては、

• 開発チームとして必要な情報が揃っている
• 開発チームとして受け入れ可能な品質

のプロダクトバックログ項目を渡さないといけないのです。 そしてプロダクトバックログ項目がそのような状態になっていることをReady（準備完了）といいます。

なお、プロダクトオーナーはプロダクトオーナーの並べ替えの責任や最終的な意思決定の責任はありますが、プロダクトバックログを全て自分で用意しないといけない責任があるわけではありません（できるのならもちろん良い）。プロダクトバックログを作ったりメンテナンスする作業は開発チームも協力して行えば良いでしょう。

Readyの具体的な状態

それでは、開発チームとして必要な情報が揃っている、受け入れ可能な品質のプロダクトバックログ項目とはどのようなものでしょうか。

まずプロダクトバックログ全体としては、以下が必要です。

• 各項目がプロダクトオーナーによって並べ替えられている（言うまでもないですが）
• 各項目は開発チームによって見積もられている（並びが下の方はどちらでも構いません）
• 各項目はプロダクトに関係がある

またプロダクトバックログの項目としては、以下のような項目が挙げられます。

• 上位の項目については、具体的である（要望ではなく要求でないといけない）
• 上位の項目については、達成可能である（技術的に不可能なものではないことが明確）
• 上位の項目については、何をもって完成したのかを判断する基準が明確である。すなわち受け入れ基準やデモのシナリオ、求められる結果が明らかである（これがあればスプリント冒頭で受け入れテストを自動化できる）
• 上位の項目は開発チームが1スプリント内で完成できるサイズになっている（すなわち継続的に見積りの見直しを行って、過去のベロシティから1スプリントに入らないことが明確であれば、事前にプロダクトバックログ項目を分割しておく必要がある）

これらを満たすプロダクトバックログを維持するためには、バックロググルーミング（リファインメント）のイベントなどを使って、継続的にプロダクトバックログをメンテナンスし続けるようにしてください。

なお、これらすべてを100%完璧な状態にしようとはしないでください。 目的は開発チームとして安定的な成果を出すためであり、開発チームが十分と思える度合いになればそれで良いのです。したがってガイドラインとして扱うのが望ましいと言えます。

Readyの定義を見える化しておく

ここまでの話は、慣れているスクラムチームであればやっている話ですが、最初のうちはReadyの定義を作ってチェックするようにしておいても良いでしょう。 いくつか、ネット上で公開されているものを抜粋して紹介します。

• プロダクトバックログ項目が必要な場所に書かれている
• 受け入れ基準が定義されている
• ほかのプロダクトバックログ項目との依存関係が明らかになっている
• プロダクトバックログ項目は開発チームによって見積もられている
• 開発するのに必要な上流や外部から提供される部品が手に入っている
• 必要な場合は、非機能要件（性能やセキュリティ）が定義されている
• デモの手順がわかる
• 開発を進める上で大きな疑問は残っていない
• なぜそのプロダクトバックログ項目が必要なのかの価値が明確化されている

これがすべてでもなく絶対というわけではないので、ふりかえりの中で出てきた知見を反映していくのがお勧めです。 もちろん言わなくても守れるような定義はリストから外していってください。

それでは。

 2016/11/03

Follow @ryuzee