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 me 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:

Differences between the Definition of Ready and Acceptance Criteria:

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 the 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 by the other.