ユーザストーリの完成と製品の提供準備完了をチェックする手段として，多くのチームが"Doneの定義(Definition of Done)"を使用している。しかし，プロダクトオーナから受け取るユーザストーリについてはどうだろう？ユーザストーリの品質をチェックするために，チームが利用できる手段が"Readyの定義(Definition of Ready)"だ。
Alan Bustamante氏は先日，"Defining Ready, an Essential Practice for Increasing Your Agile Team’s Planning Productivity"と題したブログ記事を書いた。その中で氏は，計画ゲームを始める前にユーザストーリの品質をチェックする方法として，Readyの定義を利用することに言及している。
Doneの定義(DoD)の価値やチームの作業規範(Team Working Agreement)はずっと以前から，熱心なアジャイルチームによって理解されてきました。しかし私の経験上，アジャイルチームが利用できるツールとしてさらに強力なReadyの定義(DoR)は，これまでほとんど利用されたことがありません。DoRはさまざまな成果物やアクティビティ(プロダクトバックログ，スプリントレビューなど)を対象としていますが，新たに導入するチームは，バックログ項目に対するReadyから始めるとよいでしょう。それを通じて，ワークストリームの重要部分である計画準備にDoRの概念を導入していくのです。
適切な構成のDoRは，チームにどのようなメリットをもたらすのだろうか？Alanは次のように列挙している。
- バックログ項目の"Ready"状況が判断できる
- プロダクトバックログ項目が”必要十分(just enough)”の方針で検討されていることの確証が得られる
- プロダクトオーナや他チームのメンバに圧倒されているチームを援護できる
- チーム間の責任意識を維持する
- ストーリが"Ready"になる前に見積をコミットするという，チームへの圧力を軽減する
- 開発中の"要件のぶれ"を軽減する
"Improve Sprint Throughput with 'Definition of Ready'"と題したブログ記事ではShrikant Vashishtha氏が，中途半端なストーリに取り組むチームの問題を解決する上で，Readyの定義をいかに利用すればよいかを説明している。氏によれば，
簡単に言えば，スプリントのバックログに追加されるユーザストーリはすべてREADY，スプリントの外に出されるユーザストーリはすべてDONEでなければなりません。
プロダクトオーナとチームは互いに協力して，まずユーザストーリを定義し，続いてその計画を立てる。
ユーザストーリが明確になり，チームの持つ未回答の質問や残っている障害の数が少なくなれば，そのストーリはREADYであると判断できます。そうなったら次に，ユーザストーリをストーリポイントで見積もります。このようなプロセスを他のストーリに対しても，セッションの全期間にわたって続けるのです。プロダクトオーナが未回答の質問として書き留めたストーリについては，さらなる分析を行うために留めておきます。
氏はReadyの定義によるメリットについて，次のように述べている。
"ストーリのReady化"に向けて作業することプロダクトオーナが自身の考えを整理する上で，素晴らしい支援の手段になります。同時に，チームメンバがスプリントの間，障害の解決を果てしなく待つ必要がなくなり，チームにとってもメリットがあります。
アジャイルは管理者と開発者が日々ともに協力し，可能な限り対面でコミュニケーションを取ることを意図している。Readyの定義はそれをサポートすると同時に，プロダクトオーナやチームに対して不要に多くのルールを課すこともないと，Stefan Roock氏は”Definition of Ready: A double edged sword”で説明している。
(...) Readyの定義はプロダクトオーナと開発チームのコラボレーションの障害となるような，過剰に管理されたプロセスの作成に使用される可能性もあります。プロダクトオーナと開発チームのコミュニケーションに問題があると，Readyの定義はそれらとは別のポリシによって拡大されてしまうのです。いくつかの"改善"の後，Readyの定義はプロダクトオーナに対して，個々の要求仕様を正確に定義して実行すること，曖昧さや詳細の不足を避けるために，他のプロダクトオーナやソフトウェアアーキテクトが定期的に事前チェックすることなどを要求するようになるでしょう。これはもう，スクラムでもアジャイルでもありません。
Readyの定義が重荷になって，コラボレーションやコミュニケーションの妨げに転じるようなことは避けなければならない。
Readyの定義について私が奨めたいのは，小さければ小さいほどよい，ということです。不完全な情報を処理するチームの能力が，それによってますます高まるからです。ですからReadyの定義は，時間とともに拡大するのではなく，縮小しなければなりません(Doneの定義が通常，チームの能力を向上させるのとは対照的です)。
Stefan Wunder氏はブログ記事”5 Tips on Getting Your Backlog Ready-Ready”で，次のような５つのティップスを提案している。
- チームやプロダクトオーナとともに，あなた自身の"Readyの定義"を定義してみましょう。ユーザストーリの理想である"Ready-Ready"とは，チームが中断することなくそれを実践できる，ということです。
- ユーザストーリが"Ready-Ready"であると言えるのは開発チームだけです。ですから，それぞれのユーザストーリがDoRの基準を満たしているかチェックするのは，開発チームの仕事なのです。
- ラベルや色，信号灯，接頭辞など，あなたの好みの方法で，バックログの中の"Ready-Ready"なユーザストーリを強調してください。バックログを見た人が一目で分かりさえすれば，フラグの付け方は問題ではありません。
- (ユーザストーリが"Ready-Ready"になることを妨げる)問題点はオープンにして，すべての人たちに見えるようにします (...) ユーザストーリが"Ready-Ready"になることを妨げるものは何であるか分かれば，最初に解決すべきことが何かが分かります。
- "Ready-Ready"なバックログのメリットが何なのか，プロダクトオーナと開発チームが理解しておくことが大切です。DoRがすべての人たちに浸透するまで，必要な限りのサポートをしてください。DoRな生活を！