Software Development Lifecycle
Definition of Ready (DoR) vs. Definition of Done (DoD)
One of the key artifacts of Agile / Scrum is the idea of backlogs – both at the Product level as well as at the Sprint level.
The Product Backlog is essentially the project’s To-Do list, or requirements repository.
All items that are deemed in scope for the project, regardless of level of detail, are in the Product Backlog, and they are ordered, not just prioritized – meaning the one on top is more important than the one in 5th position, which is more important than the one in 23rd position. Order is decided by the Product Owner and usually driven by business value – in consultation with the Development Team.
What is known of the projects scope, is written down and documented in the form of user stories, with the expectation that discovery will lead to change. The Product Backlog is a living document (or repository) and is owned by the Product Owner.
The Product Backlog is the source for the Sprint Backlog. Whereas the Product Backlog represents the requirements repository for the project, the Sprint Backlog is the agreed upon scope for the next upcoming sprint and as such represents the Development Team’s deliverable commitment.
Once agreed upon and committed to, the Sprint Backlog usually does not change in order to ensure the Development Team can deliver against their commitment.
The Development Team works through the Sprint Backlog top to bottom (most important to least important) and if it runs out of work would usually look at the Product Backlogs’ top items in order to pull additional work into the current sprint.
If items are not finished during the current sprint, then they revert back to the Product Backlog to be reconsidered for the next sprint in the upcoming Sprint Planning Meeting.
Newly discovered requirements are added to the Product Backlog in the form of user stories, to be considered for future sprints.
A sprint is a time-boxed development cycle that takes high-priority items off the Sprint Backlog and turns them into a product increment. However, in order to successfully pull items into the current sprint, it is important that the defined user stories are “ready” – pulling unfinished or unrefined user stories into a sprint causes problems during the implementation cycle, as it follows the old principle of “garbage in, garbage out”. If developers work off of insufficiently detailed or defined user stories, they are unlike to produce high quality code.
A “ready” backlog item needs to be clear, feasible and testable:
Simply stated, the Definition of Ready defines the criteria that a specific user story has to meet before being considered for estimation or inclusion into a sprint.
Whereas a Definition of Ready is focused on user story level characteristics, the Definition of Done is focused on the sprint or release level. Essentially, a DoD represents the acceptance criteria for a sprint or release. It spells out what the Development Team has to cover in order for the product increment to be considered “done”.
The Definition of Done is an agreement between Development Team and the Product Owner on what needs to be completed for each user story – and it is often standardized across the company in order to guarantee consistent delivery of quality.
Things that commonly addressed in the Definition of Done are:
Essentially the Definition of Done are the agreed upon acceptance criteria that the Product Owner will use to accept the product increment at the end of the sprint.
Please note that the DoD may be different for sprints vs. releases, meaning intermediate sprints might have a less stringent DoD than the final couple of sprints before you are planning to release to market.
The original intent of DoR and DoD was to create brief documents representing internal agreements between the projects’ stakeholders, the Product Owner, and the Development Team.
However, with more development work being outsourced or subcontracted, the DoR and DoD are now used more and more in contract agreements and statements of work, spelling out exact expectations as to what needs to be done.
These are useful tools for negotiating project scope as they define expectations and hold both parties accountable; the DoR helps the customer for producing well written user stories that are ready to be consumed by the Development Team, and the DoD helps the implementation partner for producing working product increments according to all project requirements, not just the specific user story functionality.