プラクティス名（別名）
Readyの定義 （DoR、Definition of Ready、Entry Criteria、準備完了の定義、READY-read）
プラクティスの目的・狙い
- PBIがスプリント投入できる状態かどうかを判断する基準を明確にする
- PBIをスプリント投入できる状態にするための準備作業を明確にする
どんな時に使うか
- PBIをスプリントに投入したが、いざ取り掛かると準備不足で次スプリントに回す、といった事態が頻発する時
実施手順
- PBIをスプリントに投入可とする前提条件をチームで話し合って箇条書きにする
- スプリントプランニングでPBI選択する際、「Readyの定義」を満たしてることを確認する
- 近々投入予定のPBIは「Readyの定義」を満たせるように準備を進めておく
「Readyの定義」の記載例
- POがユーザストーリーの詳細をDEVに説明できる状態であること
- そのストーリーに価値があることが確認できていること
- ストーリーの記述が概ねINVEST原則に沿っていること
- ストーリーポイントの見積もりが最新化されていること
- 1スプリントに収まるサイズに細分化されていること
- ストーリーの受け入れ条件（AC）が明確化されていること
- テストやデモが実施可能であること
- 技術的に実現できることが検証済みであること
- 実装に必要な情報がドキュメント化されていること
- その機能やサービスの利用者が明確になっていること
- その機能に関係するステークホルダーがスプリントレビューに参加可能であること
- システム影響調査が済んでいること
- 連携が必要な他チームとの調整が済んでいること
- 今回のスプリントゴールと関係があること
アレンジ例
- PBL上で「Readyの定義」を満たしているものは行の色を変えるなど判別しやすくする
- SBL作成時に「Readyの定義」から導き出される準備作業をタスクに含める
アンチパターン
- 「Readyの定義」が多すぎて、それを満たすための準備作業の方がメインになってしまっている
- 厳密に運用しすぎて、逆にフロー効率を悪くしてしまう
参考情報
言わずと知れたryuzeeさんのブログです。いつも助けられております。（感謝）
こぼれ話（私的コメント）
ryuzeeさんの別の記事で「生煮えのPBIを食べる（＝スプリント投入する）と、消化不良（＝作り切れない）でおなかを壊す」という表現があり、分かりやすい例えだな、と思いました。
この記事を書くにあたり、「Readyの定義」の具体例を探しましたが全然出回ってなくて、このプラクティス自体、あまり採用されていないのかも、と思ってしまいました。個人的には「完成の定義」並みに有用なプラクティスだと思っているんですけどね。どうなんでしょう。
こうして記載例に書かれている項目を眺めていると、PO/SM/DEVそれぞれに準備すべきダンドリがあることが見えてきます。ただ記載例に挙げた項目を全て採用すると少し多すぎる気もするので本当に必要なものだけを取捨選択した方がよいと思います。また現場ごとに満たすべき条件は色々と変わってきそうです。
アンチパターンにも書きましたが、やりすぎると「勝てる試合しかしない」みたいなチームになってしまいそうなのでほどほどが良いかと。