プロダクトバックログとリファインメントにおける27のアンチパターン

はじめに

スクラムは、プロダクトをつくるための戦術的なフレームワークですが、事前につくる価値のあるものが何かを確かにする必要があります。しかし、プロダクトのディスカバリーフェーズが成功したとしても、プロダクトバックログが適切な作業に適していなければ、適切な方法で適切なものをつくるのに苦労することがあります（ガベージイン、ガベージアウト）。以下、この記事では、スクラムチームの成功を阻んでいるプロダクトバックログのリファインメントのプロセスを含んだ27のよくあるアンチパターンを示します。

『スクラムガイド』によるプロダクトバックログ

まず、プロダクトバックログの目的について、最新のガイドを見てみましょう。

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

1 スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。プロダクトバックログアイテムがより⼩さく詳細になるように、分割および定義をする活動である。これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。多くの場合、属性は作業領域によって異なる。

作業を⾏う開発者は、その作業規模の評価に責任を持つ。開発者がトレードオフを理解して選択できるように、プロダクトオーナーが開発者を⽀援することもできる。

『スクラムガイド』（2020年11月）

スクラムは戦術的なフレームワークであり、検証された仮説を効果的に顧客の手に届け学習ループをまとめて、インクリメントをつくるための初期の仮説と決定プロセスを検査し、その後に次のスプリントの準備を適応させることに優れています。

スクラムは、仮説を立てて実験を行ったり、検証や反証をしたりする、つまり、プロダクトディスカバリーは得意ではありません。これは、戦術ではなくオペレーションの一部であり、スクラムチームを成功に導くためのものなのです。上のフロー図を見てください。スクラムの部分である戦術が右側にあります。プロダクトディスカバリーの部分であるオペレーションが左側にあります。 例えば、リーンスタートアップ、デザイン思考、デザインスプリント、リーンUX、デュアルトラックアジャイルなど、左側の部分を扱う機会は十分にあります。

スクラムチームは常に、プロダクトディスカバリーとプロダクトデリバリー（またはプロダクト開発）を同時かつ継続的に実践する必要があります。しかしながら、すべての作業アイテムをプロダクトバックログに押し込むことを義務付けているものではありません。逆に、私の経験上、スクラムチームがプロセスの両方の部分において2つの異なる作成物を厳密に維持しないならば、自分達の能力を発揮できません。

1. アイデア、仮説、実験、アウトカムを追跡するための透明性の高い作成物
   私は、その作成物の一部をアンチプロダクトバックログと呼んでいて、スクラムチームが追求しないと決めた課題の生のリポジトリなのです。
2. プロダクトバックログ
   効果的なスクラムチームは、この作成物を「実用的」に保つために多くの労力を払っています。実用的なプロダクトバックログは、スクラムチームが、プロダクトディスカバリー全般における継続的な労力が反映されたものです。つまり、どのアイデアが顧客にとって価値があるかという情報に基づいた意見を開拓し、それらの検証された仮説を適切なプロダクトバックログアイテム（PBI）に洗練させるのです。この時点で、スクラムチームの全員が、なぜ他のチームよりもこの機会を追求するのか、開発者は何をつくるのか、どのようにこれを達成するのか、そしておそらくこの段階ですでに誰がそれに取り組むのかを理解しています。通常、実用的なプロダクトバックログのサイズは、3〜6スプリント分の作業で構成され、プロダクトオーナーがPBIを価値によって並び替えすることを考えると、スクラムチームはいつこれに取り組むのかをよく理解しているのです。

よくあるプロダクトバックログのアンチパターン

プロダクトバックログを作成し、洗練させるプロセスは、比較的簡単であるのもかかわらず、よくさまざまなアンチパターンに悩まされます。私は。プロダクトバックログのアンチパターンを5つに分類しています。

全般的なプロダクトバックログ アンチパターン

1. 代理人による優先順位付

Prioritization by proxy
一人のステークホルダーまたは、ステークホルダーの委員会がプロダクトバックログの優先順位付を行なっていることです。

スクラムの強みは、プロダクトオーナーの確固たる立場の上に成り立っています。プロダクトオーナーは、どのタスクがPBIになるかを決定する唯一の人物なのです。したがって、プロダクトオーナーがプロダクトバックログの並び替えを判断するのです。その権限を取り上げてしまうと、スクラムはとても強力なウォーターフォール2.0というプロセスに変わり果てます。

2 .大きすぎるサイズ

Over-sized
プロダクトバックログには、スクラムチームが3〜6スプリント分提供できる以上のアイテムがあることです。

このようなやり方は、無駄な労力を使うことになる可能性がとても高いです。開発者がインクリメントにすることのない作業アイテムを洗練しなければならないことになるからです。
さらに、すべての労力を事前に投資することになるので、サンクコスト（埋没コスト）の誤謬に陥り、可能な限りの価値を提供できなくなる可能性があるのです。

3.古くなった課題たち

Outdated issues
プロダクトバックログに、数週間以上も触れられていないアイテムが含まれていることです。

数週間分とは通常、3〜4スプリントの長さ分に相当します。プロダクトオーナーがPBIを溜め込んでいると、古めのアイテムが古くなっていき、スクラムチームがそれまでに投資した作業が陳腐化していくリスクが生じます。

4. すべて詳細化され見積もられているアイテム

Everything is detailed and estimated
すべてのPBIが、完全に詳細化されて、見積もりもされていることです。

これは、事前の作業が長く、スクラムチームの時間配分を誤らせるリスクがあることを示しています。PBIのリファインメントは、スクラムチームがこれらのPBIをインクリメントに変えることに違和感を覚えなくなるまで行う継続的な活動なのです。

5. I.N.V.E.S.T.になっていないアイテム

INVEST?
スクラムチームが、PBIにINVERSTの原則を適用していないことです。

独立している価値のある小さな作業アイテムをつくれないと、スプリント中に実装が失敗するリスクがたかくなります。従って、スクラムチームは、作業を開始する前に、起こりうる問題に対処するために、適切なプロダクトバックログのリファインメントの実践に投資することを推奨します。

6. コンポーネントに基づいたアイテム

Component-based items
PBIがエンドツーエンドの機能に基づいて垂直方向にスライスされているのではなく、コンポーネントに基づいて水平方向にスライスされていることです。

これは、組織構造に起因するコンウェイの法則と呼ばれるものかもしれません。この場合、スクラムチームのデリバリー能力を向上させるために、機能横断チームに移行することで、この組織的負債を克服できます。そうでなければ、スクラムチームはより良いPBIを記述するためのワークショップに投資する必要があるでしょう。

7. 受け入れ基準が欠落しているアイテム

Missing acceptance criteria
PBIには受け入れ基準が必要ですが、それらがリストアップされていません。

リファインメントのサイクルの開始時にすべての受け入れ基準を用意する必要はありませんが、これによりタスクへのアクセスがずっとやりやすくなります。しかしながら、すべてのPBIは、完成の定義と、おそらく作業アイテムレベルの具体的な要件を満たす必要があるのです。完成の定義が後者を提供しない場合には、現在必要とされている受け入れ基準は、リファインメントの活動の結果として得られなければなりません。

8. 細かすぎる受け入れ基準

Too detailed acceptance criteria
PBIの中には、受け入れ基準のリストが充実しすぎている場合があることです。

これは、極端な話、プロダクトオーナーが開発者と交渉することなく、それぞれのエッジケースをカバーしているのです。通常は、3〜5つの受け入れ基準で十分すぎるほどです。さらに多くの基準が必要だと思われる場合は、作業アイテムがまだ大きすぎるため、分割する必要があることを示している可能性があります。

9. 100%の事前作業

100% in advance
スクラムチームが、リリース範囲が限定的であると捉えているため、プロジェクトやプロダクトの全体をカバーするプロダクトバックログを事前に作成しようとすることです。

複雑で適応性が求められる問題に取り組むときに、6ヶ月後に何を提供すべきかを今日確実に知るにはどうすればよでしょう。将来を予測できないことが、そもそもスクラムを採用する理由ではないでしょうか。

10. タイトルだけしかないアイテム

No more than a title
プロダクトバックログに、タイトル以上の意味を持っていないアイテムが含まれていることです。

バックログに多数の「リマインダー」を追加することによってノイズを発生させることになります。その結果、バックログが提供するべきシグナルが不明瞭になり、スクラムチームが顧客のために価値のあるインクリメントをつくる能力が低下してしまいます。アイデアは、プロダクトバックログに属するものではなく、プロダクトディスカバリーの仕組みの一部なのです。

11. 調査しない

No research
プロダクトバックログに、スパイクやタイムボックスの設定された調査用のタスクがほとんどないことです。

この効果は、スクラムチームが継続的なプロダクトバックログのリファインメントプロセスの一環として、スパイクを含めた将来の問題を調査するのではなく、将来の問題についての議論に多くの時間を費やしていることと、しばしば相関しています。

プロダクトオーナーのプロダクトバックログ アンチパターン

1. アイデアの保管場所になっている

Storage for ideas
プロダクトオーナーが、プロダクトバックログをアイデアと要求の保管場所として使っていることです。

大きなプロダクトバックログは、「良い」スクラムチームの証と考えられるでしょう。完全な透明性があり、組織にとって有用である証明としてです。しかしながら、「多忙」であることが、顧客や組織にとっての価値になるわけではありません。膨大な数の課題によってノイズが多くなり、価値のあるアイテムの検出を困難にさせることもあるのです。最後に、プロダクトバックログの大きさは、ステークホルダーが圧倒されたときに、クラウディングアウト効果（押し出し効果）をもたらしてしまう可能性があります。その結果、思いつきで膨らませたプロダクトバックログが、彼らとの重要なコミュニケーションを妨げてしまうかもしれません。

2. パートタイムなプロダクトオーナー

Part-time PO
プロダクトオーナーが、毎日プロダクトバックログに取り組んでいるわけではないことです。

プロダクトバックログは、開発者の時間を最も有効に活用できるものとして常に示す必要があります。例えば、プロダクトバックログの更新が、次のスプリントプランニングの直前など、たまにしか行われないとします。 リファインメントが不足しているため、多くの価値を取り残してしまう可能性がでてきます。プロダクトバックログの価値は、プロダクトオーナーと開発者のオープンな議論から生まれる部分が大きいのです。良いスクラムチームでは、開発者は提案されたPBIの価値について常にプロダクトオーナーに挑んでいきます。このチェックとバランスのアプローチは、プロダクトオーナーが確証バイアスに陥らないようにし、スクラムチームが次のスプリントプランニングで誤った投資決定をするリスクを軽減するのです。「解決策ではなく、顧客の問題を愛せよ」という格言があります。

3. コピペなプロダクトオーナー

Copy & paste PO
プロダクトオーナーが、ステークホルダーから受け取った要求文書をより小さな塊に分解することで、PBIを作ろうとすることです。

このシナリオは、プロダクトオーナーに「チケットモンキー（もぎりする猿）」というあだ名をつけることになります。PBIの洗練は、チームの活動であることを忘れないでください。さらに、ユーザーストーリーのテンプレートのようなプラクティスを用いることで、全員が「WHY（理由）」や「WHAT（内容）」、「HOW（やり方）」を理解することができるのです。Karl Popperの「誤解されないように話すことは不可能だということを忘れないでください。あなたを誤解する人は必ずいるはずです」という名言を忘れないでください。

4. 支配的なプロダクトオーナー

Dominant PO
プロダクトオーナーが、「WHY（理由）」だけでなく、「HOW（やり方）」や「WHAT（内容）」を提供することによってプロダクトバックログを作ろうとすることです。

『スクラムガイド』とそこに組み込まれたチェック＆バランスに従いましょう。開発者は、「HOW（どのように）」という質問（技術的な実装方法）に答えればよく、チームとプロダクトオーナーは、「WHAT（何を）」という質問（望ましい目的を達成するためのスコープ）に共に取り組むのです。

5. ユーザーストーリーの著者

User story author
プロダクトオーナーが、PBIを作成するために事前に多くの時間を投資していて、あまりにも詳細になりすぎていることです。

ある作業アイテムが十分に見える場合、開発者がさらなるリファインメントに関与する必要性を感じないかもしれません。このように「肥えた」PBIは、チームのエンゲージメントのレベルを低下させ、共通理解を生み出しづらくしてしまいます。ちなみに、インデックスカードを用いていた時代には、このようなことは起こりませんでした。物理的な制約があるかです。

6. 全知全能なプロダクトオーナー

The ‘I know it all’ PO
プロダクトオーナーが、リファインメントのプロセスにステークホルダーやSME（そのテーマの専門家）を関与させていないことです。

全知全能であると信じているプロダクトオーナーや、コミュニケーションのゲートウェイ（窓口）であるプロダクトオーナーは、スクラムチームの成功にとってリスクとなります。一般的に有能なスクラムチーム、特にプロダクトオーナーとは、目の前の問題をより良く理解するために、いつ他者に助けてもらうかを知っているのです。

ポートフォリオとプロダクトロードマップにおけるプロダクトバックログ アンチパターン

1. ロードマップ？なにそれ？

Roadmap?
プロダクトバックログが、プロダクトロードマップと同期していないということです。

プロダクトバックログは、現在のプロダクトゴールを達成するために十分に詳細なものでなければなりません。経験則では、この中間のプランニング目標の達成には、多くの場合、3〜4回分のスプリントが必要になります。その先のプロダクトバックログは、プロダクトロードマップのテーマを大まかに取り上げ、次のプロダクトゴールを示すべきですが、あまり具体的なものにはしません。この時点では、これらのテーマの実現リスクは高すぎるのです。その点において、プロダクトバックログには、その時々のプロダクトロードマップの「ローリング（修正や補完した）」サブセットが反映されます。

2. 年間のロードマップ

Annual roadmaps
組織のポートフォリオ計画や、リリース計画、または、プロダクトロードマップが、１年に１回前もって作成され、その間に再び変更されることがないことです。

プロダクトバックログがこれらの計画に沿っているままであれば、おそらく裏口からウォーターフォールのプランニングを導入している可能性があります。アジャイルのプランニングでは、常に「継続的」であり、古くなった計画に労力を誤って配分するリスクを軽減します。このような「ローリングプランニング」は、業界にも依りますが、少なくとも6〜12週間ごとに改訂することで効果を発揮するプロダクトロードマップにも適用できます。

3. 秘密のロードマップ

Roadmaps secrets
ポートフォリオ計画、リリース計画、または、プロダクトロードマップが、プロダクトインクリメントの開発に関係する全員に示されていないことです。

行き先がわからなければ、どんな道でも行くことができてしまいます。スクラムチームが成功するには、「全体像（Big Picture）」がとても重要になります。プロダクトの成功は、チームスポーツであり、すべてのチームメンバーやステイクホルダーのアイデアやインサイト、スキルに依存しているため、全体像を全員がわかっている必要があります。

4. できないことを目指している

China in your hands
ポートフォリオ計画、リリース計画、または、プロダクトロードマップが、それを提供することになっている人たちによって達成可能で信頼できるとは考えられていないことです。

これをプロダクトバックログに反映してしまうと、作業アイテムを洗練することが無駄になる可能性があります。

開発者のプロダクトバックログ アンチパターン

1. 従順なスクラムチーム

A submissive Scrum team
開発者が、プロダクトオーナーの要求にすべて従順にしたがっていることです。

プロダクトオーナーが選んだ作業アイテムが、開発者の時間の使い方として最適かどうか（「どうして我々がこれを行うのか？」）を問うことことは、チームメンバー全員のもっとも立派な義務なのです。スクラムは、フレームワークに組み込まれたチェック＆バランスに全員が応えなければ機能しないのです。顧客の真の問題に取り組むことよりも、「顧客の解決策」に惚れ込んでしまいがちです。もしプロダクトオーナーが「提案」したものを開発者がそのまま作れば、スクラムチームが生み出す全体的な価値が、その潜在的な能力を下回ってしまうことになります。したがって、チームには、傭兵だけでなく、宣教師も必要なのです。

2. 技術的負債ってなんのこと？

What technical debt?
開発者が、技術的負債やバグに対処し、プロダクトの品質標準を維持するために十分な時間を求めていない状況のことです。その代わりに、開発者が、「フィーチャーファクトリー（機能工場）」を完全に受け入れてしまい、新しいフィーチャーを次から次へと送り出している状態です。

私の経験則では、開発者は、自分達の時間の20％までをバグ改修やコードベースのリファクタリングに割り当てることを考えなければなりません。高品質な技術スタックが、スクラムチームとして、次のステップを教訓や最近のマーケットの傾向に適応させる中核となるのです。技術的な卓越性は、あらゆる形態のビジネスアジリティにおいても前提条件となります。この状況を維持することは、継続的なプロセスであり、安定してかつ、相当な投資を必要とします。

3. 余白時間がない

No slack time
開発者が、プロダクトオーナーに対して、ゆとりを生み出す余白時間や計画外キャパシティを求めていない状況のことです。

余白時間は、スプリントプランニングにおいて、スプリントゴールを作成し、チームの予測する能力とも重なるものです。しかしながら、早期に対策することはできないのです。チームのキャパシティが常に100%である場合、パフォーマンスは低下していきます。誰もが自分の作業を終わらせることに集中したいのです。チームメイトを手助けしたり、ペアを組んで取り組んだりする時間は少なくなります。些細なことでも、すぐに対応できなくなってきます。そして最終的には「私は忙しい」という態度が、チームメンバー全員の間での共通理解を生み出す機会を減少させることになります。

スクラムチームのプロダクトバックログ アンチパターン

1. スクラムチームと連携する理由がない

Involving the Scrum team—why?
プロダクトオーナーが、プロダクトバックログリファインメントのプロセスにスクラムチーム全体を巻き込まずに、単に「リードエンジニア」や「デザイナー」だけに頼ることです。さらに、開発者が、作る価値が何であるかを考えるよりも、より多くのコードを書くことができる方が満足できるので、このアプローチに賛同している状態のことです。

複雑な問題を解決しようとするときには、専門家がいないけれど、多くのアイデアが競合しています。したがって、リファインメント活動への積極的な参加者をスクラムチーム全体ではなく、少数のチームメンバーに限定することは、意見の多様性が人為的に制限されることになるため、確証バイアスに陥るリスクを高めることになります。

2. リファインメントの時間がない

No time for refinement
スクラムチームが、プロダクトバックログリファインメントセッションを十分に行っていないため、質の低いプロダクトバックログになっていることです。

『スクラムガイド』（2017年版）では、当初、スクラムチームの時間のうち、最大で10％をプロダクトバックログリファインメントに費やすことを推奨していました。これは、健全なビジネス上の判断です。不適切な設計による機能が、全くかほとんど価値を提供しないことほど高価なものはないのです。

3. リファインメントのやりすぎ

Too much refinement
スクラムチームが、リファインメントセッションが多すぎるため、プロダクトバックログが詳細になりすぎていることです。

リファインメントのやりすぎも健全とは言えません。追加的なリファインメントを重ねることで、限界的なリターンがゼロやマイナスになる瞬間があります。分析麻痺（analysis-paralysis）を考慮しましょう。新機能の基礎となる仮説のこれまでの検証が適切かどうかをスクラムチームが理解する唯一の方法は、これをビルドして提供することです。賭博台の上で延々と洗練と議論をしていても、問題が解決するわけではありません。

まとめ

次につくる価値のあるものを特定できたとしても、プロダクトバックログとプロダクトバックログリファインメントのプロセスには、改善の余地があります。余地があることをチームに伝え、次のレトロスペクティブで、考えられるプロダクトバックログのアンチパターンに対処してみてください。経験上、これがスクラムチームのパフォーマンスを向上させる最も簡単な方法であり、その結果として、ステークホルダーや顧客の間で、チームの地位を向上させることができるのです。

あなたが観察したプロダクトバックログのアンチパターンは何がありますか？ぜひ共有してください。

関連記事

• A Forensic Product Backlog Analysis — Making Your Scrum Work
• Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team
• Scrum: 20 Sprint Planning Anti-Patterns
• 21 Sprint Retrospective Anti-Patterns Impeding Scrum Teams
• Why Engineers Despise Agile
• Download the Scrum Anti-Patterns Guide for free.

ウェビナー

ウェビナーの動画をYouTubeでご覧いだけます。