プロダクトバックログリファインメントの5つの戦略

はじめに

スクラムチームは、常にプロダクトバックログリファインメントを行っています。スプリントレビュー中でも、デイリースクラムの後でも、スプリントプランニング中でも、そして、開発の一環としても行われています。スクラムチームは、今後の作業についての話し合いを行い、共通理解を得るのです。この話し合いには、以下のようなものが含まれます。

• 作業から得られる成果物の明確化
• 完成したときに個別のピースが価値を持つような作業への分割
• スクラムチームと組織のゴールが最善に達成できるようにするためのプロダクトバックログにある作業の並び替え
• プロダクト必要な新たな作業の追加、冗長な作業の削除
• 作業にある依存関係の解消
• 作業の規模と価値の見積もり
• 作業における前提条件を理解

つまり、そのプロダクトバックログにおいて、プロダクトバックログアイテム（以下、PBI）として表現されている将来の作業のすべてです。Barry Overeem は、これらの PBI を「将来必要になる会話を思い出させるもの」と呼んでいます。リファインメントとは、単にこれらの会話を行う継続的な活動であり、プロダクトマネジメントには欠かせない活動なのです。

プロダクトバックログリファインメントが必要なのはなぜか？

リファインメントでは、PBI について共通の理解が得られるまで話し合います。PBI は、開発者がスプリント内で完成できると確信できるまで分割されていきます。これにより、プロダクトバックログは、リスクを軽減できる透明性が高まります。リスクは、スプリント内で PBI が完成しないことで露呈します。それは、組織のために価値を生み出す機会を手放すことになります。だからこそ、リファインメントは、成功するスクラムチームが習得しなければならない必須のプロダクトマネジメント活動なのです。

スクラムチームは、プロダクトバックログの最上位の PBI だけを洗練することが時間的に効率的であることをわかっています。なぜなら、スクラムチームは、必然的に PBI の見方を下方に変更したり、冗長にしたりすることから新たな学びを得ます。そのため、スクラムチームは、プロダクトバックログの上の方にある PBI だけを洗練させていきます。前もって多くのものを洗練させることを防ぐため、開発者は、自分たちの時間の10%だけを費やすようにすべきです。

訳註: 『スクラムガイド 2020年版』からは、「10%」ではなく、「必要な時間を割く」といったような表現に変更されています。

5つのプロダクトバックログリファインメント戦略

プロダクトマネジメントにおいてリファインメントは不可欠な活動ですが、『ゾンビスクラムサバイバルガイド』によると、スクラムチームの43%は現在のスプリントにおいて、次のスプリントのための作業を洗練させるために時間を割いていません。スクラムチームがプロダクトバックログを洗練するための5つの戦略を紹介します。

• インサイトを得る
• プロダクトバックログを並べ替える
• PBI を見積もる
• PBI を分割する
• 依存関係を解消する

これらひとつひとつの戦略は、スクラムチームとステークホルダーが今後の作業について会話を行い、プロダクトバックログにある PBI を明確にするのに役に立ちます。

インサイトを得る

スクラムチームとステークホルダーが協働でインサイトを発見することで、作業に対する共通理解が確立されます。「仮説キャンバス」や「UX フィッシュボウル（経験共有金魚鉢）」は、この発見を促進するためのツールです。

仮説キャンバス

プロダクト開発においては、わかっていること（既知）よりもわかっていないこと（未知）の方が多いものです。顧客の考えは変わり、テクノロジーも変化し続けます。残念ながら、この複雑さに対して固定化した予測可能性と詳細な計画で管理しようとする習慣は、スクラムを用いている組織でさえ、まだ多くの残っているのです。スクラムチームは、プロダクトのニーズや、顧客の振る舞い、そして、プロダクトマーケットフィット（プロダクトと市場の適合性）を推測するように求められると、多くの場合は、失敗する運命にあります。組織は、スクラムチームを「フィーチャーデリバリー工場」ではなく、「問題解決チーム」として強化することで、これを変えることができるのです。

成功するスクラムチームは、フィーチャーを実装することから始めることはありません。まず、顧客の問題について考え、考えられる解決策について仮説を立てるところから始めます。Jeff Gothelf 氏の「Lean UX Canvas」をベースにした「仮説キャンバス」は、スクラムチームが創造的に問題を探求することを促進します。

わたしたちは、［ユーザー］が［フィーチャー］に使うことによって［アウトカム（成果）］を達成すれば、［プロダクトゴール］に向けて前進できていると考えています。

仮説キャンバスは、スクラムチームとステークホルダーが、PBI を固定された要件としてではなく、価値を提供する上での最善の推測として捉えるのに役立ちます。成功の基準を明確にし、ユーザーがそのフィーチャーでどのようなアウトカム（成果）を得るべきか、またフィーチャーの利用によってプロダクトゴールの達成にどのような影響があるのかをスクラムチームに伝えることになります。

リファインメントでは、スクラムチームは、ステークホルダーと協力してこれらの仮説を育てていきます。

UX フィッシュボウル（体験共有金魚鉢）

ユーザーエクスペリエンス（UX）のフィッシュボウル（UX Fishbowl; 体験共有金魚鉢）は、PBI の実装がステークホルダーの視点からどのように見えるのか、それによって何が可能になるのか、スクラムチームが探ることができるリベレイティングストラクチャ（LS）です。

UX フィッシュボウルは、2つのグループと2つのステップで構成されています。1つのグループは、ステークホルダーです。もう1つのグループは、スクラムチームです。ステップは、順番に、必要に応じで何度でも実施します。

1. ステークホルダーは、次の質問について議論するために招待される。
   「このフィーチャが既にプロダクトに搭載されていると想像してください。どのように、いつ、なんのためにこのフィーチャーを使いますか？どのような手順で使いますか？何があなたのとって便利ですか？何があなたを妨げていますか？」
   スクラムチームは、注意深く耳を傾けて、本質的なインサイトを書き留めていく。
2. スクラムチームは集まり、聞いたことに基づいてフォローアップの質問を作成する。これらの質問は次のラウンドのための質問となる。

この UX フィッシュボウルによって、スクラムチームは大きな PBI を、ステークホルダーにとって価値のある小さな PBI に分割する機会を得ることができます。

プロダクトバックログを並べ替える

プロダクトオーナーは、プロダクトバックログの並べ替えをプロダクトオーナーひとりで行うべきではないことを知っています。スクラムチームが、プロダクトバックログをステークホルダーと協力して並べ替えすることにより、プロダクトにとって価値があるものについての新たなインサイトが得ることができるのです。「Buy a Feature」や「20/20 ビジョン」は、スクラムチームがプロダクトバックログを並べ替える際に役に立ちます。

Buy a Feature

スクラムチームは、PBI の潜在的なユーザーを巻き込んで、どの PBI が重要であるかは判断します。「Buy a Feature」（Innovation Games より）は、次のようにしてこれを可能にします。

訳註: 現在上記の Buy a Feature のリンク先は、SAFe にリダイレクトとなっているようです。Buy a Feature については、こちら がわかりやすかったです。

1. 購入可能な PBI には、価格が設定され、リストアップできる
2. 資金は、ステークホルダーたちに平等に分配する
3. ステークホルダーたちは、自分にとって最も重要な PBI を購入する。各 PBI は1度しか購入できない。ステークホルダーたちは、購入時に自分たちの資金を組み合わせること（訳註: 共同購入）もできる。
4. すべての資金を費やしたときに、リストの中で購入された PBI は、ステークホルダーにとって重要な PBI がまとまっていることになる

ステークホルダーたちの協力を促すために、ひとりのステークホルダーでは購入できないような高額な PBI を用意しておきます。ステークホルダーたちの総資金では、半分の PBI しか購入できないようにしておきます。

20/20 Vision

20/20 Vision を持つということは、メガネやコンタクトレンズをつけなくても完璧に見えているということを意味しています。スクラムチームは、以下の手順により、ステークホルダーの目を通してプロダクトバックログの順番を完璧に見ることができるようになります。

訳註: 現在上記の 20/20 Vision のリンク先は、SAFe にリダイレクトとなっているようです。20/20 Vision については、こちら がわかりやすかったです。

1. PBI をそれぞれ独立したカードにわける
2. カードをシャッフルして、伏せた山を作る
3. 一番上のカードを山の横に表にして置く。このカードは参考基準として使う。
4. 次のカードをめくり、ステークホルダーがそのカードが自分たちにとって重要かどうかを判断し、参考基準のカードの上か下に配置する。
5. 山のカードがなくなるまで、繰り返すことで、カードをグループ化する。プロダクトバックログの順番に関する 20/20 Vision が作られ、ステークホルダーにとって何が重要であるかが示される。

プロダクトバックログアイテム (PBI) を見積もる

見積もりの目的は、プロダクトバックログでの作業についての共通理解を得ることであり、関連する実装についての絶対的な確実性を得ることではありません。スクラムチームは、 PBI のサイズを開発者に割り当ててももらうことで、PBI を見積もります。サイズは、PBI の絶対的な大きさではなく、他の PBI との相対的なサイズを表します。スクラムチームが相対的なサイズを用いるのは、人々が関連をより簡潔に判断できるからです。

「マジック見積もり（Magic Estimation）」と「プランニングポーカー」は、相対的なサイジングに基づいた見積もり方法です。

マジック見積もり

マジック見積もりを使えば、スクラムチームがまるでマジックのように短時間でプロダクトバックログを見積もることができます。次の手順で実施します。

1. サイズの候補は、21までのフィボナッチ数列と「？」（1, 2, 3, 5, 8, 13, 21, ?）とする。
2. ある PBI にあるサイズを共同で割り当てる。残りの PBI へのサイズの割り当ての参考にする。
3. 残りの PBI を開発者に分配する。
4. 開発者は、参考となる PBI と関連するそれぞれの PBI にサイズを割り当てる。PBI を理解できていない場合は、「？」を割り当てる。割り当ての作業は、黙って行う。
5. すべての PBI にサイズが割り当てられた後、開発者は他の人が行ったサイズの割り当てを検査する。PBI の現行のサイズに同意できない場合、新しいサイズを割り当てる。
6. PBI に一意のサイズを割り当てられない場合、2つの値の間のサイズを割り当てる。PBI に「？」が割り当てられている場合、一意のサイズを割り当てることができるまで、プロダクトオーナーの協力を得てさらに明確化していく。

結果として、参考となる PBI と関連するプロダクトバックログの見積もりが得られます。

プランニングポーカー

プランニングポーカーは、James Grenning から始まり、スクラムチームが PBI を理解し、そのサイズについての共通理解を得るのに役立ちます。その見積もり技法のモデルは、ポーカーゲームです。その手順は、次のようになります。

1. 見積もり対象となる PBI についてプロダクトオーナーが説明する。
2. それぞれの開発者は、PBI のサイズを個別に見積もる。全員が PBI を見積もるまで伏せておく。その後、開発者同士で自分たちの選択した見積もりを比較する。
3. サイズについて合意が得られない場合、開発者は相違点について話し合いを行い、再度見積もるを行う（ステップ2をもう一度行う）。
   このサイクルは、合意が得られるまで繰り返す。この合意は、PBI についての共通理解として反映するため。

サイズの値としては、指で数を示してもいいし、Gummy Bears の数でもいいし、Tシャツサイズ（訳註: S, M, L, XL）などが考えられます。

プロダクトバックログアイテム（PBI）を分割する

スクラムチームは、各 PBI の実装してすぐに使えるように分割します。この垂直方向の分割によって、ユーザーにとっての価値を確実します。PBI の水平方向の分割は、スプリントプランニング中に、次のスプリントのプランが作成されるときにのみ行われます。

PBI をワークフローのステップごとに分割

PBI にワークフローが含まれている場合は、ここのステップに分割することができます。「顧客がショッピングカード内の商品の代金を支払うことができる」という PBI は，次のように分割することができます。

• 顧客として、自分のアカウントでログインすることができる
• 顧客として、自分の注文に対して支払いを行うことができる
• 顧客として、自分の注文の確認メールを受信することができる

PBI をハッピーパスとアンハッピーパスに分けて分割

機能には、ハッピーパスとアンハッピーパスがあることが多いです。ハッピーパスは、すべてが希望通りに進んだ場合に、その機能がどのように動作するかを示しています。逸脱や例外、その他の問題が発生した場合は、アンハッピーパスが発動されます。

顧客が自分のアカウントでログインできることを記述している PBI は、さらに2つの部分に分けることができます。

• 顧客として、自分のアカウントでログインすることができる（ハッピーパス）
• 顧客として、ログインに失敗した場合、自分のパスワードをリセットすることができる（アンハッピーパス）

PBI の分割方法の戦略については、こちら を見てみてください。

依存関係を解消する

スクラムチームは機能横断的ですが、複雑な環境下で仕事をしています。そのため、予期せぬ依存関係が生じる可能性があります。依存関係は、プロダクトオーナーがプロダクトバックログの並べ替え、価値を最大化する際の妨げとなります。依存関係は、遅延によるリスクを高め、スクラムチームが、スプリントの終盤までに使用可能なインクリメントを作成するのを妨げます。

依存関係には、さまざまなものがあります。

• 内部依存関係: PBI が互いに依存していること。
  例）ワークフローのステップがそれぞれに実装されている場合や、特定の PBI がリリースに含まれていなければならない場合、PBI がまとまっていることでより大きな価値を提供する場合、など。
• 外部依存関係: PBIが、外部要因に依存していること。
  例）PBI がリリースプロセスや購買プロセスなどのビジネスプロセスに依存する場合、サードパーティシステムに依存している場合、作業にスクラムチームがコントロールできないシステムの領域における技術的な変更が必要な場合。PBI の完成に専門知識や特定の知識を持つ人のサポートが必要な場合、など。

スクラムチームは、プロダクトバックログにおいて、依存関係を可視化することで、早期に依存関係を解消できるようにします。依存関係を可視化するためには、次の手順を行います。

1. プロダクトバックログにおける依存関係を特定する。
2. 依存関係を矢印で強調することで PBI が互いにもしくは、外部要因にどのように依存しているかを明確にする。
3. すべての PBI をノードとし、依存関係を示す矢印をエッジとするグラフを作成する。

結果として得られるグラフは、スクラムチームが依存関係を解消するためのインサイトとなります。依存関係の解消方法としては、PBI の分割、プロダクトバックログの再度の並べ替え、外部システムを必要としない新たな技術的ソリューションの発見、他のチームとの事前の連携、チーム内での不足している知識の習得などが考えられます。

プロダクトバックログリファインメントは必須

今後の作業について、インサイトを得て、プロダクトバックログの並べ替えを行い、見積もり、分割し、既存の依存関係を解消することで、スクラムチームとそのステークホルダーが作業を洗練させ、共通理解を確立することができます。スクラムでは、このプロダクトマネジメント活動を「プロダクトバックログリファインメント」と呼んでいます。スプリントの作業が完了しないというリスクを軽減するために必要不可欠な活動なのです。

関連記事

おすすめ記事

スクラムをスケーリングする Nexus フレームワークの概要 | サーバントワークス株式会社

翻訳記事 この記事は、Simon Flossmann さんの「Overview of the Nexus Framework for scaling Scr…

サーバントワークス株式会社

おすすめ記事

依存関係のマネジメント 〜 良い依存関係・悪い依存関係・酷い依存関係 | サーバントワークス株式会社

アジャイル開発での重要課題としてチームとプロダクトに関する依存関係があります。この翻訳記事では、なかなか取り扱われない依存関係の性質、改善へのコツを解説して…

サーバントワークス株式会社