During agile-based software development, a large software project is broken down into smaller user stories or tasks. These tasks/user stories are put on the Product Backlog, which is the overall to-do list for the whole project.
Now before each sprint, the development team, product owner, and scrum master meet and discuss which user stories are a target for development in the next sprint. But how do they know if a user story is ready for development? This is where a Definition of Ready (DoR) steps in.
Definition of Ready (DoR) Meaning.
Simply said, a definition of ready (DoR) outlines the conditions that each specific user story must before consideration for development. User stories, also called product backlog items (PBI), must these criteria in the definition of ready, before the development team, product owner, and scrum master even think of adding it onto a sprint backlog.
By doing so, an organization will avoid wasting resources on incomplete tasks whose requirements for completion are hard to meet.
Think of a definition of ready as a bouncer who vets you to see if you meet a certain standard. If you qualify, you can enter the club. If you don’t, well better luck next time. This is essentially what a definition of ready (DoR) does, except that the clubgoers are user stories, and the club is the upcoming sprint.
Although the definition of ready (DoR) is not as popularized as the definition of done (DoD), it still is a handy tool to filter which user stories go into development.
What’s inside a Definition of Ready?
The definition of ready is not the same for everyone, each organization/team is free to define their unique criteria for their DoR. However, there are a few rules to writing user stories that make it easier to use a definition of ready. An example is the INVEST mnemonic.
Independent: a backlog item should self-sufficient, self-contained, and stand-alone. This means the item’s production success or failure during a sprint should not rely on other backlog items. For instance, all the item’s dependencies should be part of it, and not on another backlog item. This way each item is developed and delivered separately.
Negotiable: User stories are not rigid; they are not a contract. The development team and the product owner (PO) should be able to discuss and negotiate the user story’s nature and scope. However, once a sprint starts, the PO can’t change the item’s acceptance criteria.
Valuable: Each item delivered must add value to your stakeholders (customers, purchasers, etc.). This means, if you can’t explain the value added by a backlog item, you should not do it. It should contribute a stand-alone vertical slice in a larger whole.
Estimable: You should be able to estimate the size of a PBI/user story, which is the time and resources needed to complete it. Story points are an effective way of sizing user stories.
Small: A product backlog item/user story should be small and easy to handle. Ideally, it should not take more than half a sprint or 40 hours to complete. If a user story doesn’t meet these criteria, it needs to be broken down further until it does.
Testable: You should be able to check/test whether you have successfully satisfied built the user story. The user story and acceptance criteria should have enough information to design tests. This again, touches on adding value, because if you can add value, you can test it. It’s not necessary to create the testing procedure/mechanism before a sprint, but it should be creatable nonetheless.
In addition, a ‘ready’ backlog item or user story must also be clear and feasible. This means that the whole team should have a common understanding of what a user story means or requires. Moreover, it must be completed in one sprint for it to be feasible.
As a team, create your definition of ready based on these guidelines and your unique needs. After, you fine-tune or review it at the Backlog Refinement or Sprint Planning Meeting. The team must agree to each update to the definition of ready (DoR).
Definition of Ready example
- User story must be clear
- User story must feasible
- User story is testable
- Acceptance criteria for user story must be defined
- User story dependencies must be identified
- User story must be sized by development team
- User story’s performance criteria must be defined and understood.
Definition of Ready (DoR) vs Definition of Done (DoD) vs Acceptance Criteria
Acceptance Criteria are the conditions that a user story must meet to be accepted by the product owner, user, or other stakeholders. They are user story/item-specific conditions that must be met before a user story can be considered finished. In Agile, the product owner usually defines the acceptance criteria, before the team proceeds to improve it at Backlog Refinement or S.P.M. Acceptance criteria for each user story are different.
On the other hand, the definition of ready can be thought of as the acceptance criteria for a user story to be pushed into development. It’s a set of statements or criteria that vet each user story’s readiness for development. A definition of ready is focused on each user story’s characteristics, instead of the overall scope.
Finally, the definition of done is the acceptance criteria for a sprint or release to be considered done. While the acceptance criteria and the definition of ready are focused on a user story level, the definition of done is focused on the overall completion of a sprint or release.
To summarize, a definition of ready is the entry criteria for a PBI (product backlog item) to move into the sprint backlog. The definition of done is the exit criteria for a sprint backlog to move towards an increment. While the acceptance criteria are the exit conditions for a user story to be considered addressed.