Your development team isn’t ready to start building things until they align on the definitions of two words, ‘ready’ and  ‘done’. Think of these as the most important quality gates that you and your team can invest in that will quickly improve Sprint predictability, and overall product quality.

Definition of Done (DoD) is a contract between developers and business and quality stakeholders, indicating what metrics or milestones must be met for a story or release to be considered ‘done’ and thereby ready for the masses in an imminent release. Many teams have a good intuition about their ‘Definition of Done’, since it determines when the development team can stop working on a story or a release. Which is important, because a working development team is expensive and we have a lot of new experiments to run. 

The Definition of Ready (DoR) is a commitment that your team makes and satisfies before a sprint is started. For a story or a sprint, it’s the set of conditions for developers to begin work. Many teams find this more challenging: anything that keeps developers from building feels like pain. But in the end, DoR is at least as important as DoD for efficiently creating value. If a developer takes a ticket only to find that they don’t have a decision or text from the legal department, then the time spent on planning and playing and waiting during the Sprint is literally over-production on things that don’t immediately generate value.

Work that is well specified and of the right granularity can be delivered with higher quality and predictability. Make your Sprints ready like well-placed dominoes, with smallish tickets that are clear and actionable so that your team can get to done as fast as possible.  

At Lab Zero we write new DoRs and DoDs (DoR/Ds) whenever we form a new team or specify new features. This idea of being clear about ready and done works for overarching norms across your tech org as well as per feature, story or release. We often work side-by-side with developers who have either never used rigorous DoR/Ds, or have used different ones. Also, with most clients, we are helping them to implement a new delivery pipeline, and many of the items in DoD depend on the configuration of the pipeline and accompanying processes. And so we take a morning or afternoon to spell out DoR/Ds. The time spent with the whole team agreeing on DoR/D helps everyone understand those working agreements, how they help us avoid waste and prepare to meet each other with the right deliverables at the right time.

Some examples of DoR/D we’ve used.

Definition of Ready

DoR can vary from scene to scene, but they always boil down to three basic attributes: a user story is ready when it’s clear, feasible and testable. Each new team needs to dial up precision on these attributes to build a more concrete set of conditions for story and sprint.

Stories are ready when:

• The title takes the form of a User-centered sentence: <Actor><Verb><Subject><Context> e.g. Approver uploads authorization documents on the request detail page 
• Acceptance criteria are listed and are objective and measurable
• All copy or assets to be used in the story are attached or linked to the story
• Developers agree how the story will be demoed
• Stakeholders have reviewed the design and approved the content
• The story is reviewed, understood and estimated by the development team 
• Developers agree that the story can be reasonably completed within one sprint
• Dependencies are understood, and none block the work of the story

A sprint is ready when:

• The sprint backlog is ordered according to priority 
• Any other work the team has committed to--including the bugs and user stories--are contained in the sprint backlog (there is no hidden work)
• All team members have calculated their individual capacity for the sprint (full time on project=X hours per day)
• All user stories meet the definition of Ready
• The total number of story points in the sprint is appropriate given the team’s current capacity and historical velocity

See our Definition of Ready guide. 

Definition of Done

DoD also varies from team to team, but we focus on attributes tied to acceptance criteria from DoR, as well as automated and manual tests and approvals.

A story is done when

• Unit tests are written and are green
• Acceptance tests written for common cases and run in continuous integration environment
• Final art and content is placed in the product
• Peer review comments all resolved, code adheres to style and security best practices
• Security automation scan finds no high or medium vulnerabilities
• Story is accepted by the designated accepter, using the specified acceptance criteria
• The feature set taken as a whole is a usable product, and there are no new loose ends as a result of the way the feature was implemented
• Features are manually tested and accepted in the QA environment

See our Definition of Done guide. 

Are we overdoing it?

At some time or another, during a sprint retrospective, somebody is going to express doubt that your DoR/Ds are serving you well. One member of the team says that DoR is keeping you from starting too much important work. Another team member feels that DoD is not sufficient to keep buggy code from making it to production. Here are some signs that you’re overdoing (or underdoing) it.

Definition of Ready should de-risk Sprint Planning. If you’re never hitting your sprint goal, then you probably aren’t estimating well, which could mean that you’re taking on stories that are not ready, or that your definition of ready isn’t sufficiently clear.

Definition of Done should de-risk Release. If bugs (or features) are making it into production that impair user experience or value, then your DoD is either not rigorous enough or it’s not being followed.

Both DoR and DoD should contribute to users getting more value, earlier. If you have high quality and you’re always hitting your sprint goals, but users are flocking to your competitors, then you probably are focused too much on process and not enough on delivering value. On the other hand, if corner-cutting is leaving you with piles of technical debt, then you should pay more of that debt down during the sprint through a more rigorous DoD.

Don't Start Without These

You're not ready to start development until you adopt these essential working agreements. In your first sprints, you'll likely refine them, but starting with DoR and DoD written down and agreed by the entire delivery team is an essential first step. Here's a starting point for how a team might write down their definition of done and definition of ready on our guides website.

If you've already gotten started it's not too late, make time for your team to create these as soon as you can.

Please let me know how it goes on your team, I'd love to hear from you.