Voltaire famously stated that “perfection is the enemy of good.” Modern software development teams understand that “real artists ship” and innovation often happens in the iteration. 

For Agile teams, knowing when a product or project is “done” helps avoid never-ending loops of iterations that do more to muddy up and complicate a project than improve it. A lack of clear alignment on what defines “done” can breed crippling perfectionism—or worse, apathy. 

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. 

Because a DoD will need to be determined early on in a project, it’s also vital that it’s covered in the initial planning and brainstorming of a project. Let’s take a look at how a DoD helps project managers and Agile teams stay flexible, productive, and focused on the user experience and how you can establish a DoD. 

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.

Get helpful feedback for improvement

A DoD reflects the necessary steps to deliver on a sprint of increment. For Scrum and Agile teams, this benchmark provides an opportunity to test, iterate, learn, and improve the outcome of the next sprint. Each step of the DoD checklist offers the chance to receive feedback while still keeping the release plan on track. 

Improve planning

When a project is never “done,” there are likely to be many work-in-progress steps that can confuse and clutter future sprints and workflows. Never-ending product sprints often result in overcomplicated problems, and while quality and functionality is always the goal, there’s a lot of value in launching a minimum viable product and learning from user interactions. 

DoD helps Scrum and Agile teams truly break down product ships into definable increments, allowing better planning of upcoming sprints. Using DoD, development teams can ship, test, learn, iterate, repeat—all with forward-looking vision and progress. 

Visualize the status of projects over time

In addition to improved planning, DoD helps you quickly visualize the progress of a project, so you always have a clear vision of what’s been done, what’s next, and where product development is going. This level of transparency can also help ensure alignment across the organization—when directional conversations and product development work happen in silos, it doesn’t take long for strategic paths to diverge. 

What exactly does DoD look like? It can be reflected in many ways, but individual checkpoints are typically documented in a product roadmap or a Scrum board which clearly outline and visualize where a product sprint stands. 

Over time, DoD will contribute to a team’s velocity by ensuring work isn’t duplicative and the shippable state of the product or app environment meets user story demands and market expectations. 

Reflects the quality of an Agile project

Agile workflow methodologies are inherently flexible but also results-driven. Mature Scrum and Agile teams live by this flexible way of working but are also aligned on shared objectives and committed to delivering the best possible product as soon as possible. DoD supports and reflects this agility. 

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.