Establishing a Definition of Done: A Simple Concept to Ignite Company-wide Change

I see many people struggling to find the benefits of agility. There is so much noise in the market today, so many people telling you how to make radical changes to your organization, that it’s hard to know what to believe and what direction to move in. In this post, I will focus on sharing small changes you can make to create ripple effects of goodness in your organization.

What is the Definition of Done?

Let’s start with the “definition of done.” The definition of done is not acceptance criteria. Acceptance criteria are specific to a story and tell the person working on the story and those who test it how far they need to take it. Acceptance criteria should be specific to that one piece of work and should not be overloaded with things everyone has to do like security scans and unit tests. This is what standardized definitions of done are all about.

As a leader in a technology organization, do you have a clear understanding of the state of done in your organization? What does “yes, that’s done” mean to you? Does it mean the same to everyone whose name is aligned to that work? It should.

But don’t go overboard.

Start with defining “done” for user stories, iterations, and releases. Most companies have legacy release criteria already defined. Pull that out, dust it off, and see how close you get with each release. If it’s pretty good, then you have a starting definition of done for releases in your organization. If it needs a lot of work, set it aside and start with user stories.

Stories: Are We Done Yet?

For any story in your organization, it’s important to identify what state you want it in prior to it being called done. Here’s an example of one set of criteria that I’ve used at a company.

For stories, until the following criteria are met, the work does not get shown to the team and product owner for acceptance:

• All tasks completed (dev, QA, tech pub, UX)
• QA has run and passed all “happy path” tests
• No known defects for all new code*
• Code reviews completed, when needed
• Unit tests implemented
• Automated tests implemented for features/areas that the team agreed to automate
• All development documentation is complete

When I show people this list, I often get told “we can’t do that here.” But I created this at a real company—just like yours—that didn’t start off practicing agility. After sharing this list, there was lots of grumbling among the team who expressed “this is impossible; we cannot do that in a two-week sprint.” However, after about 3.5 years, nearly every team had accomplished these items.

*Zero defects of any severity was our ideal state. I knew we couldn’t get there quickly, but it was where we needed to end up. Every release, each team took one step towards these lofty goals. Eventually, we met them.

I could tell the teams that were taking agile principles and practices seriously because they were able to complete the definitions of done first. The laggard teams had all the same problems they always had—missed dates, poor planning, over commitment, and under delivering. Every release. Yet those teams that worked to hit these goals, and put in the infrastructure and automation needed, actually did hit them—all of them—and morale improved.

It’s important to note that we didn’t get there overnight. There’s an evolution to meeting these goals, but establishing these definitions was key to setting that stake in the ground for everyone to strive towards.

Why the Definition of Done Matters

It’s very important that you create a definition of done for all teams, worldwide, who are creating products for your business. At first, they might not be able to complete this because the infrastructure or automation doesn’t exist. But during release planning, they should be able to tell you how close they can get, which then becomes part of their commitment during planning. And each release or planning cycle, they should be getting closer. Eventually—it took the company I was working at roughly three to four years. By the end, all but one team was meeting this goal.

The upside was that everyone, from team members to our CTO, knew what “done” meant. Our defect leakage and cost of maintenance decreased dramatically, while our quality skyrocketed. Teams were being interrupted less frequently to fix bugs from previous releases and they were able to focus on new features and get more to market.

Conclusion

As a leader, you should know what “done” means in your organization. A word of caution—don’t bloat these definitions. Make them attainable if automation, infrastructure, and good agile practices are in place. It makes a huge change to your organization the minute no one needs to ask if it’s “done,” or “done-done,” anymore.