User Tools

Site Tools


How Do We Use a Definition of Ready (DoR)?

The Definition of Ready (DoR) is part of a working agreement that specifies the conditions that need to be met for a Story before it can be accepted into an Iteration or Sprint. The DoR is typically based on the INVEST criteria for a Story.

The Definition of Ready is an analog to the Definition of Done (DoD), but is aimed at the earlier part of a story’s life cycle.

Why do we have a Definition of Ready?

“The secret of success is to be ready when your opportunity comes” - Benjamin Disraeli

Simply getting your stories ready will have an immediate and dramatic impact on the Team’s productivity; the data indicates at least a 2X improvement in Team performance. The reason for this improvement is:

  • Teams avoid beginning work on stories that do not have clearly defined completion criteria. Without a clear completion criteria Teams will waste time on costly back-and-forth discussions as work progresses or, worse, will result in significant rework when work does not meet actual need.
  • By having a DoR Teams are able to push back on starting work on ill-defined Stories.


The Product Owner is responsible for putting the features and stories in the backlog. The Team works with the Product Owner during Backlog Refinement to help Product Owners get the stories into actionable shape.

The Definition of Ready is usually based upon the INVEST Criteria:

  • Independent: As much as possible this Story can be worked on independently of other Stories and, if released, could produce incremental value on its own.
  • Negotiable: Leaves room to negotiate the method used to achieve the desired outcome.
  • Valuable: The value is clear for the end user.
  • Estimable: There is a Team developed estimate on the Story.
  • Small: Small enough to be completed in one Iteration (Sprint)
  • Testable: It is clear when the outcome has been achieved and the work is complete.

Backlog refinement is usually the first time that the Team can work though an understanding of dependencies associated with the work, be they internal (e.g. availability of specialists or systems) or external (e.g. need for something from a supplier).

The main thing to achieve is to ensure that we understand how the dependency lines up with Iteration (Sprint) timing. For example, if an external dependency with a supplier is expected to be resolved in 2 months time, then it probably doesn’t make sense to prioritize our work so that it would be scheduled for the upcoming iteration. You might as well wait until the value can be delivered and, in the meantime, deliver other valuable stuff (control WIP by “stop starting, start finishing”).

Tips and Traps

  • The Product Owner should work with the Agile Team to establish their initial Definition of Ready. This should be a collaborative effort.
  • The Backlog Refinement event is the main event to work stories to Definition of Ready
  • Think about creating a Ready (sub-)state on your Team Kanban board to reduce the amount of time you revisit items as part of refinement and visually see that there is sufficient backlog for the Team.
  • Define your exit criteria for the step before commitment to work based on your Definition of Ready
  • Ensure Teams and Product Owner regularly discuss their Definition of Ready. After all, this is a working agreement aimed at improving the flow of value and so will need revision as things change.
  • Use time-boxes to limit how much time is spent collaborating on a Story, and treat items with lots of unknowns as “homework”. For example, perhaps set up a Spike (Enabler) story if there is requirements or implementation uncertainty, and bring results back to the next Iteration Planning or Backlog Refinement event.
  • Sample DoR includes (assuming work is captured in a work management system):
    • Has a short, descriptive title - make it meaningful
    • Has a “user voice” form of the requirement (“As a <role> I want <capability> so that <I get this value>”)
    • Has acceptance criteria, where possible defined with examples (i.e. mostly written in Gherkin “Given <system is in this state> when <I take this action> then <I expect to see this result>”)
    • The issue type (story, defect, etc.) is correct for the work
    • Has an estimate (in story points) based on completing to Definition of Done
    • Are small enough to fit into an Iteration (estimate is typically sized below some threshold that means something to the Team e.g. 8's and below will fit into an Iteration)
    • Dependencies have been identified and priority aligns with Iteration (Sprint) timing
    • Items “expected” for the upcoming Iteration (Sprint) are prioritized appropriately, including improvement items from the Retrospective. In other words they are at the top of the Team Backlog

Definition of Success

  • There is a smooth flow of top priority (business perspective) Stories to the Teams
  • For each Team there is enough Ready backlog for at least 2-3 of Iterations (Sprints) at any given time.
  • Story is well understood by the Team and uses language everyone comprehends (e.g. avoid acronyms, jargon, and superfluous words)
  • Iteration (Sprint) planning results in a plan that seems relatively low-risk
  • Clear understanding of how the results can be demonstrated to customers and other stakeholders to solicit feedback during an Iteration (Sprint) Review.
    • NOTE: Think of the user voice format and acceptance criteria as the “script” that you will use when you demonstrate the story at the Iteration Demo.
  • Team is set up to up to quality Stories, with limited requirement defects


  • The Product Owner is expected to come up independently with Definition of Ready stories.
  • The Team is required to accept stories for work that do not meet Definition of Ready.
  • Too much time is spent on each Story to get it Ready.
  • The process becomes a “stage gate” whereby it literally gets in the way of the smooth flow value, or Teams use it as an excuse not to work on things. Remember, this is all about the smooth flow of value and collaboration!

Want to Know More?

/home/hpsamios/ · Last modified: 2020/11/02 12:47 by hans