Allstacks guide on how to develop a Definition of Done

Because of this, a great place for software organizations to start is by creating a Definition of Done that is agreed upon and well-understood by the entire team and shared with the business. 

There’s no one right way to craft a Definition of Done. You can certainly use a template as a starting point. Some organizations will dictate criteria from the top down, and others may leave it to individual teams. At Allstacks, we view self-organization as a core part of this exercise. It’s simply human nature that if the participants of an agreement are not invested or bought in, it won’t be successful.

Since engineers are the ones living under this agreement, I knew it was critical to allow our team to lead the discussion process to build their confidence and competence in solving any friction that occurs on the journey to “done.” 

Here's our process of creating a Definition of Done at Allstacks:

This is the simple step-by-step co-creation process we used to draft and finalize the Allstacks Definition of Done. 

1. We gathered the entire team to discuss what a Definition of Done should look like and what it must include. This discussion was led by a presentation given by our senior QA engineering to share examples to level set and get common jargon. 
2. During the discussion we opened up the floor for input—everything from tooling automation to process changes that could make getting to “done” easier. 
3. We categorized the responses into buckets and divided the team into groups that aligned with each employee’s area of expertise.
4. Over the course of two weeks we sent the groups to conference about their ideas for robust criteria in their given domain. This allowed for time to work with their sprint commitments and notes were added to the master document as artifacts. 
5. We regrouped with the project leader (senior QA developer) and subject matter experts from each group to combine the criteria developed by each team.
   
6. We sorted criteria by currently achievable versus more aspirational.
7. We refined the list into a top-level list with any needed details per bullet.
8. Had all members of the engineering and product teams sign off on the document
9. We integrated it into our onboarding process through on the job training when discussing planning and refinement.,In the future, it will need to be in our New Hire Reading List alongside our Common Jargon and other documents.

We’ve refined the results of this workshop and finalized our current Definition of Done. We recognize this is a living, breathing document and is subject to improvement/revision. We will review this quarterly with the product team for any potential updates or necessary modifications. Since the product team was initially only asked for feedback and not involved in the process, we recognize the importance of having them aligned on the process going forward. It's important for the product team and any other stakeholders to know what we mean when we say done and how that impacts our commitments on sprint work. 

So were there process changes as an outcome of the Definition of Done process? 

As the Allstacks engineering and product team worked collaboratively to craft our Definition of Done, we noticed some of our process pieces needed tweaking. The first tweak aligned where QA sat in the process and the expectation around where it fell regarding merging. The second tweak was born out of the adjustments made to QA. The team realized we should rearrange our Jira boards to easily track the flow and progress of subtasks instead of stages of done since our definition was a more universal known.

Updated Jira boards to align the process with the Definition of Done 

Allstacks' original board had "Product management sign-off" as its own Jira column. This allowed the team to use the Jira board columns to track various done stages to understand progress updates. 

The updated board now has "Product management sign-off" as a Jira subtask. This allows the Jira boards to be overarching concepts and the subtasks to track progress. For instance, if an issue arises, a new subtask is created rather than using movement between Jira boards to track progress. This enables the team to be very flexible since the state of progress is easily digested, making pivoting and adjusting as necessary easier. 

Who was the driving force?

As a leader who believes in empowering his team, I am proud to say our senior-most QA automation engineer took on the role of the driving force for the definition of done project. First, he gathered his thoughts and insights to present to the team what a definition of done is. From there he ensured all of the necessary meetings took place, gathered all the notes together and refined the contents into a digestible piece to review with the team in Confluence. Once the document was presented to the team, we worked to get everyone to commit and sign off on it. 

Want to learn more? 

If you're looking for more from me or other members of the Allstacks team, you're at the right place. Here are some other favorite blogs:  

• Getting started with OKRs in software engineering
• What is a “Definition of Done” in software and why you need it for alignment
• Dear Engineering, we have a lot more in common than you think. Love, Sales.