Definition of Readyとは？スプリント開始前の品質基準を解説
Definition of Ready（DoR）は、バックログアイテムがスプリントに投入可能な状態かを判断する基準です。Definition of Doneとの違いや、チームでの運用方法を解説します。
Definition of Readyとは
Definition of Ready（DoR）とは、バックログアイテムがスプリントに投入できる状態にあるかを判断するための基準です。「準備完了の定義」とも訳されます。Definition of Done（DoD）が「完了の定義」であるのに対し、DoRは「着手可能の定義」にあたります。
DoRはスクラムガイドの公式な構成要素ではありませんが、多くの実践チームが「バックログリファインメントの品質チェックリスト」として採用しています。チームの成熟度に応じて導入・緩和を判断することが重要です。
DoRの目的は、不十分な状態のアイテムをスプリントに投入してしまうことを防ぐことです。曖昧な要件や未解決の依存関係を抱えたままスプリントを開始すると、開発中の手戻り、仕様確認の待ち時間、スプリントゴールの未達成につながります。
DoRはスクラムガイドの公式な要素ではありません。しかし多くのチームが実践的なツールとして採用しています。特にリファインメントのプロセスが十分に成熟していないチームにとって、DoRはアイテムの品質を担保する有効なチェックリストです。
構成要素
DoRは一般的に以下の観点で構成されます。
要件の明確性
ユーザーストーリーの記述が十分に具体的で、チーム全員が同じ理解を共有できる状態です。「誰が」「何を」「なぜ」が明確に記述されていることが基準となります。
受け入れ基準
テスト可能な受け入れ基準が定義されています。「Given-When-Then」形式やチェックリスト形式で、完了の判定基準が客観的に確認できる状態です。
見積もりの完了
チームがストーリーポイントまたは相対見積もりを実施済みです。見積もりが極端に大きい場合（13ポイント超等）は分割が必要です。
依存関係の解消
他チームや外部サービスへの依存関係が特定され、ブロッカーが解消済み、または解消の見通しが立っている状態です。
技術的な前提条件
必要なAPIの仕様、デザインモック、テストデータなどの技術的な前提条件が揃っている状態です。
| 観点 | 基準の例 |
|---|---|
| 要件 | ストーリーの記述が具体的で全員が理解している |
| 受け入れ基準 | テスト可能な形式で定義されている |
| 見積もり | チームが相対見積もりを完了している |
| 依存関係 | ブロッカーが解消または対処計画がある |
| 技術前提 | API仕様やデザインが準備されている |
実践的な使い方
ステップ1: チームでDoRを合意する
DoRの基準はチーム全員で議論して合意します。プロダクトオーナーと開発チームの双方の視点を反映し、現実的な基準を設定します。最初は5〜7項目程度に抑え、過度に厳格にならないよう注意してください。
ステップ2: リファインメントでDoRを適用する
バックログリファインメントの場で、各アイテムがDoRを満たしているかを確認します。満たしていない項目があれば、次のスプリントまでに解消すべきアクションを明確にします。
ステップ3: スプリントプランニングで最終確認する
スプリントプランニングの冒頭で、候補アイテムがDoRを満たしているかを確認します。DoRを満たしていないアイテムは原則としてスプリントに投入しません。
ステップ4: DoRの有効性を定期的に振り返る
レトロスペクティブでDoRの基準が適切かを振り返ります。基準が厳しすぎてスプリントへの投入が滞る場合は緩和し、不十分なアイテムが繰り返し問題を起こす場合は基準を追加します。
ステップ5: DoRの成熟に応じて段階的に緩和する
チームのリファインメント能力が向上し、自然にReadyな状態のアイテムが準備できるようになったら、DoRの形式的なチェックを段階的に緩和します。DoRは永続的なルールではなく、チームの成長を支える一時的なガイドレールです。
活用場面
新規結成チームの立ち上げでは、メンバー間の共通理解を醸成するためにDoRが特に有効です。要件の粒度や受け入れ基準の記述レベルについて、チーム内の期待値を揃えるツールとして機能します。
複数チーム間の連携では、チーム間で引き渡されるアイテムの品質基準としてDoRを活用します。依存関係のあるアイテムが適切な状態で引き渡されることを保証します。
外部ベンダーとの協業では、要件の記述レベルや前提条件の共有について、客観的な基準を設けることでコミュニケーションコストを削減します。
注意点
DoRを「着手を阻むゲート」として運用すると、リファインメントの停滞を招きます。あくまでチームの準備品質を高めるガイドレールとして位置づけてください。
ゲートキーピングの罠を避ける
DoRをゲートキーピングの手段として使ってはいけません。DoRの目的はアイテムの品質向上であり、作業の着手を遅延させることではありません。DoRを満たすための作業がボトルネックになっていないか注意してください。
DoRとDoDの混同を防ぐ
DoRとDoDを混同しないでください。DoRはスプリント開始前の「入口の基準」、DoDはスプリント完了時の「出口の基準」です。両者は補完関係にありますが、別のものとして管理します。
基準の固定化による成長阻害
DoRの基準を固定的に運用するとチームの成長を阻害します。チームの成熟度に応じて基準を定期的に見直し、不要になった基準は削除する柔軟性を持ってください。
まとめ
Definition of Readyは、バックログアイテムがスプリントに投入可能な状態かを判断するための基準です。要件の明確性、受け入れ基準、見積もり、依存関係の解消を確認することで、スプリント中の手戻りと遅延を防ぎます。チームの成熟度に応じて段階的に運用を調整し、自律的な準備ができるチームへの成長を支えるガイドレールとして活用してください。