Photo by Braden Collum on Unsplash

What is a “Definition of Ready”?

This describes the preconditions necessary for an agile issue — the collective noun for work items in agile management software — to be deemed ready before the issue can come into an iteration or sprint, thus enabling work to commence on that issue. It is a set of recommendations for the characteristics of a user story, while epics, tasks and sub-tasks may or may not require different criteria.

Personally I advocate applying these same characteristics to both user stories and epics. Why? When you’re faced with a wall of text in an epic’s description, it’s easy to overlook/misunderstand what it is that the customer actually wants or needs. Having the same format for both stories and epics helps everyone through using the same common language and phenomenology describing their needs in a succinct and standard format.

  1. there is a description (what needs to be done) using a “user story” format similar to
    As a [persona (and not as a developer or customer, think of “who” is asking for this work to be done/who will receive the benefit from it)],
    I want [specific action(s)],
    So that [specific benefit(s)]
  • The intended outcome is that there’s enough information in the issue for a colleague to be able to deliver the issue if needed (this is to address key person risk and ensure that the issue can progress if the assignee becomes unavailable at short notice – wins the “lottery” or “gets run over by a bus”)
  • Does our description fit into a greater plan for how we’ll complete the linked epic?
  1. there is an acceptance criteria (how do we know that this is complete?) using a format similar to
    Given [the context for why this issue is needed],
    When [specific action(s) is/are carried out – this may marry to the “I want” part of issue description],
    Then [a particular set of observable consequences will result]
    • The outcome is to ensure that we know when an issue can be marked as complete
  1. there is a story point estimate (how “big” is this issue to deliver?)
    • in story points (SP) – either relative or absolute, my preference is for relative SPs
    • this is an estimate, it isn’t a commitment or guarantee of effort
    • story points don’t indicate the duration, rather the relative size of this issue by comparison with a similar issue (relative SP) or in an “ideal person days” (absolute SP)
    • is the story small enough to fit inside one sprint, typically a maximum of one third the size of your Squad’s average sprint velocity – smaller is better though, ideally 1-3 SPs as a maximum
  1. if required, there is a due date (when does this need to complete by?)
    • helpful in cases where we have a commitment to deliver to another project’s timeline
    • valuable to know if another party can’t commence a subsequent activity until this issue has completed
    • due dates may be expressed at the epic level and or at the story or sub-task as necessary
    • how can we complete this story within the sprint?
  1. comments in your agile management software
    • these help others understand pertinent information that has shaped the issue, the context, how we will deliver it, what we’ve done (explored/considered) to get here etc.
    • allow for a timeline/record of information pertaining to the delivery of this issue, it may include the outcomes of key conversations, meetings etc
  1. for Jira use links, these are used to identify dependencies at the epic, story or sub-task by using
    • “Depends On”
    • “Is Depended By”
    • “is blocked by”
    • etc.
  1. wherever possible stories will meet INVEST principles:
    • “I” ndependent (of all others)
    • “N” egotiable (not a specific contract for features)
    • “V” aluable (or vertical)
    • “E” stimable (to a good approximation)
    • “S” mall (so as to fit within a single sprint)
    • “T” estable (in principle, even if there isn’t a test for it yet)
  1. Have we identified systems access/knowledge that we need to complete this issue, do we have it and/or a plan to resolve this?

  2. Have we identified knowledge uplift requirements or have a plan to do this for stories which have knowledge dependency (what do we need to “learn”/”know” to be able to complete this story)?
    • these may require a preceding “spike” story
  3. When accepting issues from another squad, is it crystal clear what needs to be done?
    • See description in #1 above. Clarity is required to ensure that we complete the issue and don’t, for example, gold plate the solution.
    • What is the magnitude of the issue in the number of  modules/lines of code/items that are involved? This can assist with prioritisation.
    • Do we know which stakeholders should be or will be involved in this issue? This is to ensure that we have access to the knowledge required to complete the issue.
    • Who is the “customer”, the impacted party who may be responsible for the “end customers” and/or a user of the impacted system(s), processes or products. This is to ensure that we know who has a “vote” vs a “voice” on completion of this issue.
    • When do we think that we might be able to start working on issue? To ensure that expectations and reality align.

Outcome: do we have enough information to be able to successfully deliver this story?

Specifically for products/processes etc being handed over to/from other squads (also see #10 above):

    • is the item of sufficient quality to be handed over – do we have a mandatory service transition check list?
    • is there sufficient documentation of what the item is and how it should operate?
    • is it clear who the customers (consumers) of this item are?

Further reading