Definition of Ready Vs. Acceptance Criteria

One of the most popular questions among Scrum Teams is the difference between the Definition of Ready and Acceptance Criteria and how they tend to affect the User Stories. Even though Acceptance Criteria can be related more to software development, the Definition of Ready is unique to Scrum.

More often than not, people tend to mix up the two terms mentioned above. However, the two have some similarities and differences, and knowing them in detail will help learn each of their practical applications.

What is the Definition of Ready (DoR)?

In simple terms, a Definition of Ready is used to know whether a task or work (generally a User Story) is ready to begin working on it. Therefore, before a team can assign a specific User Story or a task in a particular Sprint, the same must be adequately described and understood by the team members so that the task or work is actionable.

Additionally, the team members should also provide an estimation for completion and allocate essential resources to meet the goals.

The Definition of Ready can also be described as a checklist of criteria that can help facilitate a team’s decision to start working on a specific work or task. It should be known that the Definition of Ready differs from the Definition of Done (DoD).

What are Acceptance Criteria (AC)?

Acceptance Criteria are defined as the predetermined requirements or conditions that must be completed or met to ensure that a User Story has been completed and it’s viable enough to be accepted by the customer, user, or any other system.

If the Acceptance Criteria are well-written, unexpected results can be avoided at the end of a product or software development stage.

Moreover, it also ensures that all users or Stakeholders are satisfied with the outcome.

Acceptance Criteria must be defined before the team starts working on a particular User Story. Otherwise, it will be challenging for the team to meet the expectations and needs of the client.

Thus, to learn the differences between the Definition of Ready vs. Acceptance Criteria, it’s crucial to know the significance of each concept.

Similarities between the Definition of Ready and Acceptance Criteria:

 

Acceptance Criteria

Definition of Ready

Feature scope

Acceptance Criteria help in defining the boundaries of User Stories. Precise details are provided on the functionality that allows the team to understand whether a particular story is completed accurately and also works in the expected procedure. 

Similar to Acceptance Criteria, the Definition of Ready also helps in ensuring that the User Story is well-defined so that the Scrum Team can work towards the goal without any difficulties. If the Definition of Ready is not clearly defined for the User Stories, then it will lead to a random selection of tasks. As a result, the Scrum Team will realise that what they’re working on will fall short of the desired outcome and therefore have to compensate for the mistake with half-baked User Stories that will work properly. 

Resource utilisation

With the help of Acceptance Criteria, acceptance testing can be streamlined. Each Acceptance Criterion is independently tested and based on whether the tests pass or fail, the fate of the User Story will be decided. 

Since the objective of project management is to meet the targets within the allocated time and budget, having a proper Definition of Ready is crucial. Once the Scrum Team has the necessary information relating to the User Story that they have to work upon, so that it turns into a product feature, proper clarity can be injected into the delivery procedure. As a result, the Scrum Team can coordinate their resources, so that the process can be completed seamlessly. 

Communication

Using Acceptance Criteria, the visions of the Scrum Team as well as the client is synchronised. As a result, it is ensured that everyone in the team has a proper understanding of the needs and the outcome. 

Just like Acceptance Criteria, the Definition of Ready also makes sure that the described requirements for a user to move from the backlog to development, are adequately communicated to the team members. 

Burnouts

As Acceptance Criteria already define the scope and requirements for a User Story to be marked as complete, it prevents overworking of the Scrum Team, which helps in preventing burnout. 

Similarly, the Definition of Ready also prevents burnout among team members by defining the amount of work that is to be done for a User Story to be marked as completed. 

Differences between the Definition of Ready and Acceptance Criteria:

 

Acceptance Criteria

Definition of Ready

Usability

Acceptance Criteria is a concept that is followed when all the necessary work on the User Story has been completed and the same is ready to be tested for acceptance by customers or users (based on whether the set conditions are met). Thus, it can be concluded that Acceptance Criteria come at the penultimate stage and therefore succeeds Definition of Ready. 

Definition of Ready is a concept that is followed before the start of work on any User Story begins. Thus, it precedes Acceptance Criteria and is responsible for determining whether work should be started on a User Story. 

Concept

Acceptance Criteria depend on the Definition of Ready for it to be applicable. Hence, it’s a smaller concept than the Definition of Ready. 

Definition of Ready is a larger concept than Acceptance Criteria and doesn’t depend on Acceptance Criteria for applicable. However, Acceptance Criteria are necessary to ensure that the task or work (at hand) ends up being successful. 

Factors to consider when outlining the Definition of Ready:

1.Independency of the User Story

The User Story should have as much as little to no dependence on other User Stories. Such a feature will ensure that the Sprint will not stop, which can force the Scrum Team to deviate all their attention to other tasks that are not part of the current ongoing procedure.

2.User Story should be flexible

No User Story should be non-negotiable or set in stone. There should be enough flexibility allowed for additional considerations to be made.

3.User Story should add value to the product

Before pushing a User Story to the Sprint, it must be judged whether the User Story will add proper value to the product as well as the end-users. Suppose the User Story cannot provide sufficient value. In that case, there’s no reason for the User Story to be moved from the backlog to the development stage.

4.User Story must be measurable

The User Story should be measurable for the Scrum Team to learn about their progress. In case the User Story is not measurable, then approximate data that applies to the User Story must be estimated.

5.User Story should be manageable & testable

A User Story must be small enough to fit in a single Sprint duration so that the team doesn’t have to worry about burnout. Besides, the User Story should also have the capability to be tested so that the Scrum Team can learn whether they have met their targets.

Factors to consider when outlining Acceptance Criteria

1.Acceptance Criteria must be created from a user’s perspective

When a Product Manager or Product Owner writes an Acceptance Criterion, the same should be written from a user’s perspective. Moreover, the Acceptance Criteria should be written before the User Story is ready to enter the Sprint Planning. Everyone on the team should review the same to confirm that they agree and understand each other.

2.Acceptance Criteria should have a shared understanding

It should be known that Acceptance Criteria are responsible for synchronizing the visions of the Stakeholder along with the Scrum Team. This is to ensure that all the parties have a common understanding of the needs.

3.Acceptance Criteria should have clarity

The Acceptance Criteria must be concise and clear. It must be expressed in such a manner that the Stakeholders can understand. Any unwanted details must be removed.

4.Acceptance Criteria must be testable, achievable and measurable

Using Acceptance Criteria, a User Story should be accurately planned and estimated. Each criterion must be independently tested with a pass or failure scenario.

5.Acceptance Criteria should be written in specific formats

There are three main formats in which Acceptance Criteria can be written:

  • Custom formats
  • Rule-oriented formats (checklist)
  • Scenario-oriented formats

We suggest using rule-oriented formats.

Conclusion

At the end of the heyday, Acceptance Criteria and Definition of Ready serve two different purposes. On the one hand, the Definition of Ready focuses on whether work or task is ready to begin. On the other hand, Acceptance Criteria focus on the completeness of the said work or task and whether a user or customer can accept the same. Thus, both concepts should be utilized in tandem with each other and not be replaced with the other.