Definition of Ready Vs. Acceptance Criteria

Agile Methodology helps organizations develop and deliver products smoothly and aids them in building new-generation products that contribute to the growth of that industry. Often, Agile team members, stakeholders, users, and many others involved in the product development process may propose creative and unique ideas. Few ideas may seem that it is hypothetical and could not be achieved; few may seem vague, and few are very practical. As an Agile leader, it is important to consider every idea as anything could help the product grow in the market. However, Agile does not deal with ambiguity, it helps the team members and the organization to evaluate whether the ideas are achievable and deliverable effectively. A Product Backlog is not just a list of prioritized items, it consists of many other elements that make it more productive and attainable. 

Definition of Done, Definition of Ready, and Acceptance criteria are a few elements that contribute effectively to making the Product Backlog successful. High-performing companies know the actual importance of these items and utilize them maximally while organizing their Product Backlogs. These elements interplay with each other boost productivity and coordination, and minimize the effects of dependencies. In this article, we discuss the Definition of the Ready and Acceptance criteria and know the differences between the two. 

Definition of Ready

Definition of Ready is a set of agreements that tells the team whether a specific User Story is ready to begin, more accurately, whether that User Story consists of all necessary components that are essential to begin. The definition of Ready gives a sense of perspective as it is the specific portion of the language that helps the team understand if they can do that work. It is one thing to shape the idea in mind and think of ideas about the product feature; it is another thing to make that idea understood by the team and make them say it is achievable. Definition of Ready helps the team know the concept of the User Story better so that they can develop it during the Sprint and not be confused during the development process. DoR informs the team when all the conditions are right to begin the Sprint. 

A Definition of Ready consists of a narrative and acceptance criteria. The DoR should be clear if there are any specific operational attributes concerning the layout appearance of the user interface design or performance concerning a particular User Story. You could at least have a tentative design on a piece of paper or on a constraint card to have an idea about the specifications. 

What is the need for a Definition of Ready? 

A Definition of Ready assures that the User Story satisfies all the criteria and can be taken into a Sprint. You do not need to 100% define all the aspects of the acceptance criteria. Nevertheless, it should at least be ready enough for the team to be confident to deliver the User Story successfully. The team can save ample time if each User Stories meets the Definition of Ready. During the Sprint Planning meeting, they can also work on their User Story to bring it into the ‘Ready’ status.

How to design a Definition of Ready?

The INVEST matrix is the best way to design a Definition of Ready. This matrix is as follows:

I—Immediately actionable, the User Story should be such that the team can easily begin working on the item right away and does not have to wait for any other procedures to be completed. 

N- Negotiable: the team should be able to discuss the details of the items in the Product Backlog and how they could be achieved. 

V- Value, the User Story selected should produce value to the stakeholders and customers. 

E- Estimable: The user Story should be such that the team can estimate or approximate the amount of effort needed to accomplish it. 

S—Small. The tasks involved in the Product Backlog item should be small enough for the team to complete them in a single Sprint. 

T- Testable: the increment created by the Scrum Team could be easily tested. 

Each team has its Definition of Ready, which largely depends on the team and the Product Owner. Here are a few examples of ready Definitions that will give you a clearer idea. 

1. The User Story should be written according to the format of the ‘User Story.’
2. The team should estimate the story easily
3. The team needs to understand the acceptance criteria
4. The team should understand the performance criteria
5. The team should understand how to provide a demo of the features.

The definition of Ready should not stagnate; it should keep growing and developing as the team evolves regarding the working pace and the team's understanding of what makes a good User Story.

Definition of Ready Examples:

The examples of the Definition of ready could be divided into DoR for User Story and DoR for a Sprint. 

Definition of Ready for a User Story: 

• The team defines the size of the User Story
• The User Story should be well-defined
• The performance criteria should be identified. 
• The user experience artifacts should be accepted by the Scrum team
• The acceptance criteria of the User Story have to be defined 
• The team member accepting the User Story has to be selected
• The team should be able to give a demonstration of the User Story

Definition of Ready for a Sprint

• The Sprint Backlog should be prioritized
• All the work, such as developing User Stories or fixing defects should be contained within the Sprint Backlog
• There should not be any hidden work
• All the User Stories must meet the Definition of Ready
• All the team members should have calculated their capacity for the project.  

Acceptance Criteria

User Stories are the foundational artifacts of Agile development. User Stories can be large or small depending on what the team decides to build through the User Story. If a particular Product Backlog item is considered to be too large to fit in a Sprint, it will be broken down into many User Stories and numerous sub-tasks are assigned to them. All User Stories should have a Definition of Done and Acceptance Criteria. Hence, you could see that both of these co-exist in the Scrum development process. The User Story gives the context of the feature the team is supposed to build; the acceptance criteria guide the details of the functionality and how the customer will accept them. Few acceptance criteria would be decided during the Product Backlog refinement meeting before the Sprint begins, and others will be discussed after the Sprint Planning meeting. These are certain attributes of acceptance criteria:

• The term applies to an individual Product Backlog item or story
• This term is not defined in the Scrum Guide
• It is used to communicate to everyone involved in the project that all the requirements for a particular User Story have been satisfied. 
• It is also known as conditions of satisfaction, “test cases”, or acceptance tests. 

What are Acceptance Criteria?

Acceptance criteria is a list of activities that need to be completed so that the Product Backlog item could be considered done. This criterion helps the team to estimate, test, and accomplish the work. Although the terms “Acceptance criteria” and Definition of Done may sound similar, they are quite different. In simple words, the acceptance criteria is a list of things required to fulfill the customer's needs whereas the Definition of Done is things that the organization needs. Hence, with both of them on board during a Sprint Plan, a team gets a sense of direction and knows what to do so that their work is considered completed. For instance, let us take a healthcare company that has 10 teams who were not writing acceptance criteria. In their first few Sprints, they were not able to complete the work and were failing to complete their Sprint. The answer for why this was happening was that they did not know what needed to be done for them to know that the Product Backlog item was completed. 

Common Pitfalls in Acceptance Criteria

Acceptance criteria should have the ‘what’ element of the project and not the ‘how’ element. As in, it should only be clear about what needs to be done such that the work is considered as done. It should not dictate the techniques to be used to get that work done. When they know how things are supposed to be done, it eliminates creativity from the team and the potential of the team cannot be tapped. One good analogy of this could be that when you go bowling in a bowling alley, you know what you are supposed to do, but the techniques to knock the pins down could be different for each person. Everyone knows what needs to be done, but how they are supposed to do it is up to them. They can use their creativity and find out new techniques to knock the pins down and score points for their team. A similar thing is also true in the product development process, where developers know what they need to accomplish and take their path to complete it. 

Acceptance Criteria Goals

• To clarify the things the team needs to build before they begin working
• To ensure that everyone has a common understanding of the problem 
• To help the team members know that the Product Backlog item is complete
• To help the team verify stories through automated tests. 

Example of an Acceptance Criteria

User Story: As a user, I want to register online so that I can start shopping on the website.

Acceptance Criteria:

The user can only submit the form by filling in all the required fields. 

The email that the user provides must not be a free email

Submission from the same IP can only be made three times within 30 minutes

Users will receive a notification on the provided email ID after successfully registering.  

Conclusion

The definitions of Ready and Acceptance Criteria may seem similar, but as you have seen, they are quite distinct. Both are important for developing the User Story. Developers can effectively work on their product backlog items by understanding both terms' differences. If you are a new Agile team, explaining these terms to the Agile team becomes an important part of the introduction. Ensure your team members know the meaning and difference between these terms and efficiently work towards their Sprint and product goals. Simpliaxis offers comprehensive Agile and Scrum training courses to help teams master these principles and enhance their productivity in Agile environments.