The Definition of Ready (DoR) and the Definition of Done (DoD) are checklists of the work that must be completed before a product backlog item (PBI) can be considered to ready for release.
The Definition of Ready (DoR) defines the ready state. In simple terms, a epic/user story needs to meet some criteria (or conditions) before it can be picked up for a release/sprint. The DoR collects all the conditions necessary for a user story/epic to be developed in the current sprint/release.
The PO/PM is accountable and responsible for the DoR that must have all details required by the organization, and description of the epic/story in consultation with the team.
A Definition of Ready (DoR) Defines Pre-Conditions.
A well defined and DoR compliant epic/story will help everybody associated with information that will be useful not just for the development team but also the stakeholders, marketing and sales people.
The stakeholders will benefit from the DoR by knowing the business value/ROI expected from the epic.
The sales people will be delighted to know the expected value/purpose for the customer. That will help them in their sales pitch.
Every required detail should be in the Epic/Story before the team can start grooming (not commit) the work item before they pull it up in sprint planning.
Focus on the description (canonical format), acceptance criteria, estimates, size, start date, due date and all other details that apply.
Backlog grooming: The focus here should be more on creating not only a strong backlog but also a healthy one. Hence, the DoR is important.
Grooming the product backlog should ensure that items at the top of the backlog are ready to be moved into a sprint so that the development team can confidently commit and complete them by the end of a sprint.
The backlog grooming focus should be more on the health of a strong backlog rather than the immediate next sprint.
What DOR means…Accountability
Product Owner/Product Manager
- Add a description – Description should be in the canonical format – Either, Given-When-Then, or As a Role-What-Result.
- For user story- It will be interesting to note that there are tools like cucumber, gherkins, etc. that can automate acceptance tests based on the canonical format. Hence, it is very important to follow the approach.
- Prioritize the Epic/Story – (use prioritization techniques like WSJF (weighted shortest job first), Customer demand, Ranking, MoSCoW, Five Why’s, KANO, etc.)
- Assign a high-level Size for the Epic. (the context of size here is to give it a number (Fibonacci series), or t-shirt size (S, M, L, XL, XXL) and not estimated effort, time)
- What value is it adding to the product –
- Is it an organisation initiative?
- What is the customer perceived value? – This information is important for the stake holders and sales people.
What DOR means…Consulted
Architect
- Scope and refine the epic/story based on technical investigation.
- Carry a feasibility study and document possible approaches to develop the epic/story (POC, Spike) Note: POC and Spike are not the same.
- Can assign a preliminary estimate to the Epic/Story. (the context of estimate here is to give it a number (Fibonacci series), or t-shirt size (S, M, L, XL, XXL) and not limited to the estimated effort, time). The development team has the final say on the effort estimate.
- Highlight any architectural risks/challenges.
What DOR means…Responsible
Development Team
- Understand the description, acceptance criteria and scope.
- Refine the preliminary estimate in consensus with PO and architect.
- Give an Estimate for the story (effort estimates should be based on– Complexity | Uncertainty | Dependency) . (The estimations can be done in the sprint planning, better if done during the backlog grooming)
- Assign an owner and commit. (Should be done in the sprint planning)
- Create tasks for each story. (Should be done on the first day of the sprint. If possible, do it during the sprint planning itself)
There are different thoughts on creating tasks. But, it has been proved in the product organizations that creating tasks will help in getting more clarity in the burn-down charts and thereby help in tracking the correct progress. However, there are other matrices to track the progress that should be considered once the team becomes mature with this process. There are more chances of team getting corrupted when they start understanding the system better and, over a period the velocity chart shouldn’t be the only data to rely for value output.
What DOR means…More details
Capture all engineering level discussions, constraints, dependencies, underlying assumptions & the finalized approach. Highlight any engineering level risks/challenges with other discussion points.
Tip for creating a healthy and strong backlog
Conduct JAD (Joint Application Design, or Joint Application Development) sessions, if needed.
- Simplify — consolidate months of meetings and phone calls into a structured workshop.
- Identify — issues and participants.
- Quantify — information and processing needs.
- Clarify — crystallize and clarify all requirements agreed upon in the session.
What is Definition of Ready DoR for an Epic/Story
Definition of Ready for an Epic
Detailed Appropriately
- Dependencies are identified and no external dependencies would block the PBI (Product Backlog Item) from being completed.
- Details are sufficiently understood by the development team so it can make an informed decision as to whether it can complete the PBI.
Emergent
- The feature shouldn’t be static. As the project progresses more information (description/user stories) can be added.
Estimable
- The items at the top of the backlog have more accurate estimates.
- The lower priority items are estimated at a high level and can be re-estimated as the team gets more information.
Note: Sizing – Not all XXL size will require the same effort. Similarly, not all S or M size will require any less effort. One size doesn’t fit all. Practice relative sizing.
Prioritized
- Business value is clearly articulated. •Performance criteria, if any, are defined and testable.
Definition of Ready for User Story
Independent
- The work item should be independent (self-contained and possible to bring it to progress without any dependency on other work items or external resources).
Negotiable
- Should have enough room for discussion regarding its optimal implementation
Valued
- What value it provides to the user, should be clear.
Estimated
- In story points (note the story points is a unit-less unit, i.e., it may not mean 1 point = 1 day, or a couple of hours).
Note: Estimation – Not all XXL stories will have higher story points, and not all S, M stories will have less story points. It is based on the level of Complexity, Uncertainty, Dependency
Small
- The PBI (Product backlog item) must be estimated and small enough to be completed in one sprint.
Note: Slicing – there are various techniques – Vertical, SPIDR (Spike, Path, Interface, Data, Rules) – whichever applies for the story can be used.
Testable
- Acceptance criteria are clear and testable.
We will discuss Definition of Done (DoD) in the next blog.
techritesolutions 