Definition of Ready

What is the definition of Ready?

Definition of Ready is a set of agreements that tells you when something is ready to begin.

More correctly, “if something is good to begin”.

E.g., when a user story is ready to be taken into a sprint, or when all the conditions are right for a team to begin a sprint. Your ‘Ready’ story looks like this.

A ready story is a detailed user story Ready? that necessarily has-

    • A narrative

    • Acceptance criteria.

It should also be clear when there are any story-specific operational attributes like performance and the layout or appearance of the user interface design. A simple approach could be to capture the qualities of constraint cards and have a tentative design on a piece of paper.

Why do we have a Definition of Ready? A definition of ready deals with the user story, wherein the user story is ready to be taken into a sprint.

It doesn’t need to be “100 % defined” covering all the acceptance criteria. However, it should be “ready enough” only when the team is confident that they can successfully deliver the user story.

It will help in saving ample time if each user story meets the definition of ready before the sprint planning meeting. But it is also fine and acceptable to work on the user story during the sprint planning meeting and bring it to the ‘Ready’ status.

How to create Definition of Ready? The definition of ready has much to contribute to a good user story. It is also very much related to the concept of the INVEST matrix.

A team pushes back on a story when it doesn’t align with these criteria. But again, while these criteria are necessary for a story to be “Ready”, it is safe to say that they may not be sufficient. Several other factors are to be taken into consideration.

Each team will have its own definition of Ready. This largely depends on its personnel and the context.

An example will give you a clear picture.

    • The story should be written exactly in the ‘user story’ format. i.e As a <who> I want <what> so that <benefit>”

      • Role – The user should be an actual human who interacts with the system.

      • Action – The behavior of the system should be written as an action.

      • Benefits – The benefit should be a real-world result that is non-functional or external to the system.

      • e.g As <a recruiter> I can <post new jobs> so that <applicants can find those jobs via search>

    • Acceptance criteria must be understood by the team.

    • The Team needs to estimate the story. For a distributed team, it can be done using fire poker

    • The team should understand how to provide a demo of the features.

    • Performance criteria should be understood by the team.

The above items equip the team with the required information for a particular story. They also provide the opportunity to challenge the product owner in the absence of those items.

Steps in developing Definition of ReadyThe Definition of Ready should not stay fixed. Rather, it should grow and develop as the team evolves in terms of-

    • The working pace

    • The understanding of ‘what’ makes a good user story. You can input the same information into the product backlog via backlog grooming and planning sessions. The Definition of Ready will be updated through sprint retrospectives.

Examples of Definition of Ready: In this section, we shall show two separate instances of the Definition of Ready. This will help you develop an appropriate Definition of Ready as per the requirements.

    • Definition of Ready for a user story:

      • Well-defined User story

      • User story acceptance criteria defined

      • User story sized by the delivery team

      • Scrum team accepts user experience artifacts

      • Performance criteria identified

      • The Team is able to ‘demo’ the user story.

    • Definition of Ready for a sprint:

      • Prioritized sprint backlog

      • Defects, user stories and other work the team has committed to are contained in the sprint backlog

      • No hidden work

      • All team members have calculated their individual capacity for the sprint

      • Full Time on project=X hours per day.

      • All users stories meet the Definition of Ready.

The Product Owners can use the Definition of Ready as a guide when preparing for user stories for upcoming sprints. For a team, it is used as a checklist to make sure that there is an increased chance of success in delivering the completed user story, and that there are enough thoughts involved in building the user story before they start to deliver it. So finally, the Definition of Ready brings back the focus to backlog grooming meetings and lookahead planning activities.

Definition of Ready helps in minimizing the Rework on a user story.