What is a “Definition of Done” in software and why you need it for alignment

It’s not hard to be on the same page when just three people work in the same room. But as you grow, how do you maintain that alignment, continue to “speak the same language,” and ensure that information isn’t heavily centralized or siloed?

At Allstacks, we’ve repeatedly proved that you’re less likely to have miscommunications if everyone has the same information at the same time. Even though we’re very distributed, we still need to operate as if we’re all in the same room.

Part of this is to collectively understand what it means to be “done” with a task or initiative. Often product managers will report that something is ready for delivery when in reality it’s “Dev done” and not “QA done” or “the code’s been written, but no documentation or tests have been created.” This misalignment on when something is completed can put in motion a lot of conversations with customers and other go-to-market initiatives that are premature and ultimately cause frustration between teams.

Since we’re on our own journey of codifying a “Definition of Done,” I thought I'd share some perspective on its importance and our process to get there.

What is a Definition of Done?

A Definition of Done is a working agreement that details a set of standards within a team or organization defining what actions need to be completed to identify something as “done.”

It acknowledges the shared responsibility between the frontend, backend and QA (and other stakeholders.) It outlines how the entire team can cross the finish line together while maintaining alignment with the rest of the organization. 

Here are a few key principles of a Definition of Done:

• The criteria are communicated in a way that can be universally understood across the organization. 
• The Definition of Done addresses both tactical and technical requirements. 
• It should be a living document that can be amended to fit new understandings and realities. 
• The robustness of the document will vary by team maturity, and specific teams might have an addendum for special requirements. 
• Until all criteria are met, the task is not “done.” 

Why you need a definition of done 

Intuitively, a Definition of Done exists to eliminate confusion about what “done” means within an organization. But when to start building one and why it’s a critical business tool might be less obvious. 

You’ll know it’s time to codify your Definition of Done when you realize your team is expending significant energy to communicate readiness for delivery. You might experience miscommunications in translating status reports across groups; or feel undue anxiety as you deem something “ready for release.” A Definition of Done eliminates any confusion about when a project is ready to go to market. It can guide the team tactically and put minds at ease about anything slipping through the cracks. 

Other key benefits of as Definition of Done include: 

1. Creating a shared understanding and unified language for software delivery
2. Ensuring that new employees have access to tribal knowledge and process expectations
3. Detecting and removing false agreements between teams, creating real consensus 

Now you know the what and the why so I encourage you to begin crafting your very own definition of done! Currently, my team is still finalizing what our definition of done is. Be on the lookout for steps on how to craft your own definition of done and what the Allstacks definition of done shaped up to be.

More from Allstacks

• Review best practices for managing remote software development teams
• Read thoughts on managing internal and outsourced software development teams 
• Explore how sales and software engineering have more in common than not