Most Agile practitioners would have heard about the Definition of Done or DoD. They will be very much familiar with the meaning of this term, and they will appreciate its value a lot as well. The reason is that it helps teams to remain transparent in their work. But, most Agile practitioners or at least prospective Agile practitioners would be less familiar with a similar term or concept called Definition of Ready or DoR. This concept aims to identify whether the work is ready to begin. DoR can be anything like a Product Backlog item or a User Story ready to be accepted into a Sprint. Teams can use this concept as a decision method to decide whether to begin their work on something.
Everyday Items Considered for DoR:
- Actionable: The teams would like to know whether the work is immediately doable. Can the team decide what they should do, and can it be done now? Also, they wish to know whether the item is free from external dependencies.
- Refined: The DoR lets the team know whether the item has passed through the refinement process before Sprint Planning. The team members wish to know whether there is a common understanding among all participants on the item and how they will implement it.
- Value: The DoR should also state the value of the item. In other words, the team members should know the value the item can bring to the end user. It should ensure that all project team members are aware of this value.
- Estimated: The DoR should also tell whether the team has estimated the item. It should reveal whether the item agreed to be of a particular size and whether the team will be comfortable completing the task within a Sprint.
- Acceptance Criteria: Has the item cleared the Acceptance Criteria?
- Demonstration: Do the team members know how they will demonstrate the item and whether they will discuss it on the Sprint Review once it is completed.
Like the DoD, the DoR should create collaboratively, and all project team members should agree. It should be possible for the project team to view this document as a living document. It should grow with the team when the project matures.
How Should Your DoR Look Like?
A ready story is a detailed User Story and necessarily will have a narrative and Acceptance Criteria. When there are any operational attributes specific to a story, the DoR should mention them. A DoR deals with the User Story, wherein the User Story is prepared to be taken into a Sprint. It need not have to be purely defined, covering all Acceptance Criteria. Instead, it should prepare only when the project team members are confident they can deliver the User Story successfully. It will be helpful to save a lot of time when every User Story meets the DoR before the Sprint Planning meeting. However, working on the User Story during Sprint Planning meetings is also acceptable to bring it to the "ready" status.
Creating a DoR:
The DoR can contribute too much to a good User Story. A good User Story would follow the INVEST Matrix. Each letter in the word Invest has a meaning as given below:
- Independent of all others
- Negotiable, which means that it is not an agreement for a particular feature
- Valuable
- Estimable to a decent proximity
- Testable even if the testing method is yet to discover.
Acceptance Criteria:
As we wish to understand the Definition of Ready vs. Acceptance Criteria, it is time to understand what is Acceptance Criteria all about:
Acceptance Criteria are responsible for detailing what should be done for the Product Backlog Item or PBI to be completed. Acceptance Criteria are created as essential components of User Stories and defined in particular to a User Story.
From Acceptance Criteria, it will be possible for the Developers to know the external quality features specified by the Product Owner from the business perspective. Further, from Acceptance Criteria, they can also get to know the exit criteria that the system or the components of this system must meet so that they can accept by customers, users, or other authorized authorities.
Why Should Acceptance Criteria Be Part of User Stories?
Acceptance Criteria should form an essential part when defining User Stories. The reason is that with Acceptance Criteria, it will be possible to ensure that the software developed meets the requirements of businesses. They provide the foundation for the definition of test cases that ensure achieving business objectives and the production of apps without any bugs.
Creating Acceptance Criteria is a win-win endeavor for Developers and Stakeholders in an organization. The great thing about Acceptance Criteria is that they will let teams know what expects of them. Further, it will keep the Stakeholders well informed of the development process. In short, Acceptance Criteria are used for:
- Ensuring accurate estimation and planning
- Serving as the basis for delivering tests
- Helping Developers understand when to stop adding more functionality to a story.
- Aiding team to reach consensus after gaining a shared understanding
- Helping Product Owners to define what they require for the specific User Story to add value
- Defining boundaries for User Stories.
How to Create Acceptance Criteria?
Software Developers and Product Managers often talk about the Definition of Done. But, in reality, they discuss Acceptance Criteria when discussing DoD. It is nothing but a checklist that comes as part of each User Story used to explain when the requirements specified in the User Story are met.
Developers, Stakeholders, and customers refer to the Acceptance Criteria of a project to identify what the project's outcome should look like.
Indeed, customers do not get involved in creating Acceptance Criteria for User Stories. Nevertheless, having the Acceptance Criteria will aid the Developers in paying attention to the crucial elements of User Stories. In turn, the Developers can assure customers that the development process will be focused and meet their requirements.
Some Product Managers run Acceptance Criteria by customers before deciding on them. They use Acceptance Criteria to show customers that the agreed work is completed to their utmost satisfaction. Even they do this to prevent scope creep. When creating Acceptance Criteria, here are some things to consider:
- Pay attention to outcomes: Acceptance Criteria creation should pay attention to results and not nitty-gritty details. So, when preparing Acceptance Criteria, the expected outcome should give the utmost focus.
- Engage in different perspectives: Further, when creating Acceptance Criteria, it is better to get inputs from different Stakeholders to avoid mismatches in the future.
- Derive from User Stories: Further, it should ensure that each User Story has at least a single Acceptance Criterion.
- Please keep away from Technical Jargon: When preparing Acceptance Criteria, one should remember that everyone should be able to understand them with ease. So, it is better to ensure that it does not include any technical jargon.
- Standalone testing: Also, when creating Acceptance Criteria for User Stories, it is better to make sure that it is verifiable and concrete.
- Adaption to your unique team: It is better to ensure that the Acceptance Criteria look different across various teams.
In most instances, Acceptance Criteria are written for Developers. They use them as a guide for creating the software. They pay attention to the project's requirements and crucial functions and prevent them from getting distracted by unwanted features.
Common Pitfalls to Avoid in Acceptance Criteria:
Acceptance Criteria should give a clear idea of what should be done for the work to be completed. But, the criteria should not tell how to do it. Also, it should not be prescriptive to get rid of creativity.
Key Differences Between DoR and Acceptance Criteria:
You intend to compare the Definition of Ready vs. Acceptance Criteria. So, the thing to remember here is that the Definition of Done applies to all User Stories the team works on. On the contrary, Acceptance Criteria are defined particularly for every User Story as needed by the Definition of Ready. So, the idea here is that Acceptance Criteria preparation is a part of the Definition of Ready. Acceptance Criteria define the desired behavior. Identifying whether a Product Backlog item has been developed successfully is helpful. On the other hand, DoR is a User Story or backlog item that is kept ready to be accepted into a Sprint.
References
- https://sensibleagility.com/2020/12/14/whats-the-difference-between-dor-dod-and-acceptance-criteria/
- https://www.scruminc.com/understanding-definition-of-ready-acceptance-criteria-and-definition-of-done/
- https://agility.im/frequent-agile-question/what-is-a-definition-of-ready/
- https://builtin.com/agile/acceptance-criteria
