Definition of Ready

“Definition of Ready” Is a term commonly used to define when a story can be put on the sprint backlog

It helps guide the breaking down and refinement of features

Before a story can be estimated by the team it needs to be defined in enough detail to enable the team
to understand it and to see how they could implement, the diagram below illustrates that a story might
go through two stages of preparation prior to being added to the sprint backlog. The team will agree
what preparation is needed to deem that is it "ready".
Checklists
Pre condition checklist to sprinting, Provides the team with the minimum input required for the team to
provide a commitment for sprint delivery (against DoD criteria) with a high degree of confidence.

Maturity Level 1
 Ways of working agreed and understood

 All User stories (/ Abuser stories*)….


 Are defined in Jira (As a … I want to … so that …)


 Are Independent, Negotiable, Valuable, Estimable, Small
and Testable – INVEST *
 
 Have Acceptance Criteria defined, in a BDD format
(given.. When.. Then)


 Have all significant architectural decisions made that the
User Story is dependent on
 UI Designs defined and signed off


 WireFrames and User Journeys defined

 Sprint Backlog..


 Prioritized


 Is sized by the Development Team, and can fit in the
sprint (typically < 13 SP)


 contains all defects, User Stories and other work that the
team is committing to


 Team know what and how demo will be  achieved


 All team members have calculated their capacity (team
availability) for the Sprint


 All team members are fulltime on the project

 Development / testing environments are set-up and

available

Maturity Level Full

 Ways of working agreed and understood
 All User stories (/ Abuser stories*)….
 Are defined in Jira (As a … I want to … so that …
 Are Independent, Negotiable, Valuable, Estimable, Small
and Testable – INVEST
 Have Acceptance Criteria defined, in a BDD format
(given.. When.. Then
  Have defined Quality Attributes (NFRs) (relevant for this
story
 Including all Operational NFR’
 Have dependencies identified
 Have all significant architectural decisions made that the
User Story is dependent o
 Have defined API ‘s and contract available for any
systems that the User Story needs to interface
 Has design sketches where there are cross system
impacts
 Have performance criteria identified, where appropriate
 WireFrames and User Journeys define
 Backlog..
 Prioritized
 Is sized by the Development Team, and can fit in the
sprint (typically < 13 SP)
 contains all defects, User Stories and other work that the
team is committing to
 Team know what and how demo will be  achieved
 All team members have calculated their capacity for the
Sprint
 All team members are fulltime on the project
 Development / testing environments are set-up and
available

Story Ready
 All User stories (/ Abuser stories*)….


 Product Owner - Are defined in Jira (As a … I want to … so
that …)


 Product Owner - Have Acceptance Criteria defined
 BDD format (Given.. When.. Then)
 Other formats available (by exception??)
 Have defined Quality Attributes (NFRs)


 Technical Product Owner - Have all significant
architectural decisions made that the User Story is
dependent on


 Technical Product Owner - Have defined Third Party API ‘s
and contract available for any systems that the User Story
needs to interface


 Technical Product Owner - Has (software) design sketches
where there are cross system impacts


 UX - Wireframes created & user journeys
 Visual Design - Designs created
 All - Are Independent, Negotiable, Valuable, Estimable,
Small and Testable – INVEST
 Must have enough detail to ensure the team can commit
to delivery within a sprint