Definition of Ready

What's a Definition of Ready? 

Before we agree to take on new work, it's critical that we understand our customer's goal. A Definition of Ready is a check-list that reminds us what kinds of things to ask as we clarify the customer's expectations.  As noted by Roman Pichler, the Definition of Ready is not a new concept in the Agile space. It has been further popularized and generalized by Kanban under the name of Explicit Policies. These policies can be used before we begin the work (Definition of Ready/Entrance Policy), as we move the work from one state to another or from one team to another, or when we consider the work done (Definition of Done / Exit Policy).  These policies are often written at multiple levels; at varying levels of scope we have: Story, Iteration, Release. From a continuous improvement perspective, we have the policy we apply today, and the policy we aspire to reach some day. This may be represented as follows:

What's in a Definition of Ready?

We need a living document--something that is continuously updated as we learn better about our perimeter, that will prevent rework and unnecessary delays. While the list below is overkill for most teams, you may consider any of the following for your Definition of Ready:

• Is the story INVEST-worthy (independent, negotiable, valuable, estimable, small, testable)?
• Have we seen a demonstration of working code that proves any external components are complete and of high quality?
• Are there any external files, media, recordings, images needed to complete this work?
• Has the customer committed to time with us to explain the context and goals of the work?
• Have relevant external teams committed time to support this work? (e.g., database staff, developers of external components)
• Are we willing to defer elaboration of non-functional requirements, or do we have a clear idea of what they should be? (system load, multi-threading, permissions, robustness, etc.)
• Do we know: who requested the work? when is it needed? what's a barely sufficient implementation?
• Do we have the right skills to do this work?
• Who can we ask for help if something goes wrong?
• Are the acceptance criteria defined?
• Do we have an estimate for this work?
• Does the estimate match the customer's budget? Have we discussed the business value?
• Has this been ranked in comparison to other backlog items, in terms of urgency, priority, effort, and value?
• Do we have everything we'll need to meet the Definition of Done for this story if we complete it now?
• Have we considered the downstream effects of releasing or testing this story?
• Have we communicated about any ripple effects to other component teams?
• Have we informed marketing/sales/business folk we're about to start this work?
• Can we make these changes safely without breaking the current system? What if we have to abort this story early?
• Do we know how this work fits in the larger context of the release plan or future product versions?

See also Ken Power's excellent blog entry on the Definition of Ready.