DOD -Definition of Done

 

What is Definition of Done?

The definition of done (DoD) is a collection of deliverables within a project or contract that, when completed, will act as verifiable and demonstrable benchmarks for a project. In short, it’s a list of deliverables and a shared understanding of expectations on the requirements the team must meet before releasing a product to users. 

Why use DoD 

Experience is the best teacher—and the user experience is the best way to understand whether your product meets user needs. Of course, getting that insight requires a launched product. 

Establishing and working a DoD into your workflow process gets you to that launched product, or at least a minimal viable product, faster. From there, you can get the feedback you need to make better products, improve planning, and visualize and plan future projects. Let’s dive deeper into each of these benefits.

How to find your DoD

We spoke briefly of the risks of perfectionism and apathy. Both can result from failing to define DoD, and both result in a failure to launch. Various teams and stakeholders may have different ideas of what “done” looks like, but it’s important to collaborate and compromise to reach a consensus on acceptance criteria for each user story, feature, or issue and hold every team member accountable to those standards. These requirements must be clear, actionable, and always accessible.

Decide on your Definition of Done as a team

Establishing a DoD should be a cross-functional collaboration between product teams, project managers, quality control, and relevant stakeholders. Defining DoD depends on current user and business priorities but generally means that the developed code meets the objectives of the user story, feature, release, or issue and doesn’t cause any previous sprint of product development to break. 

At a more tactical, granular level, DoD checklists can look like: 

• Code is written
• Code is documented
• Code is reviewed
• Code or build is deployed in a testing environment 
• Code passes tests 

In addition to more traditional visualization and agile project management tools like product roadmaps and Scrum boards, visual collaboration tools like Lucidspark can also ensure there is transparency around DoD requirements for non-technical teams, that everyone involved has access to those requirements, and there is clear alignment on what’s required to move the feature forward—and what comes next. 

Create a checklist and specific requirements to fulfill DoD (acceptance criteria)

Simply put, acceptance criteria are the benchmarks required to meet your DoD. Once you have a DoD in place, it’s essential to create a checklist of rules that consider the larger whole and context of the current sprint and apply to every task within that sprint, whether it’s an entirely new app experience or a simple bug fix. The most important thing is consistency. 

Here’s a simple “done” acceptance criteria checklist. Note: These criteria can change over time as your DoD and product requirements and priorities change. 

• Unit test passed
• Code reviewed
• Acceptance criteria for each issue met
• Functional tests passed
• Non-functional requirements met
• The product owner accepts the user story

Once these items are checked off, you can consider a sprint “done,” then observe, test, and apply your learnings to ideate new product features, fix bigs, iterate and optimize current features, and plan your next sprint. The best thing about DoD? Your team is always moving forward and always learning. 

Make sure accountability is tied to action items

Alignment on acceptance criteria is key to keeping each team member accountable for each step. During your sprint planning process, individual team members will be responsible for different steps. Make sure that your acceptance criteria and checklists are available to view next to the work happening to maintain visibility and accountability through each stage of the development cycle. 

Ensure DoD works with organizational needs or contract objectives

To avoid work and sprints wasted, it’s important to occasionally check priorities and your DoD against larger organizational goals to ensure alignment and prevent any strategic blindspots. After all, a successful product ship is only as valuable as the goals it meets. Careful collaboration and alignment with key stakeholders and product owners will ensure every product sprint will benefit the company as a whole. 

For many quality-focused product development teams, it can be tempting to aim for perfection on every sprint and every version of an app. Teams that embrace DoD can move with agility, learn more about their users more quickly, and ultimately build better products.