What is Definition of Done?
Let’s start with the ‘Definition of Done’ (DoD). 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 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 DoD for releases in your organization. If it needs a lot of work, set it aside and start with stories. I’ll create a future post regarding DoD for Iterations and Releases.
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 2-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. More on that in a later post.
It’s important to note that we didn’t get there overnight. There’s an evolution to meeting these goals that I will describe in future posts, but establishing these definitions was key to setting that stake in the ground for everyone to strive towards.
Why DoD matters
It’s very important that you create a DoD for all teams, world-wide, 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 3-4 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.
DoD in Rally
You should visualize your Definitions of Done to make them easy for everyone to see. Here are a couple ways you can do this in Rally:
- Add the Custom HTML app to your dashboard to show the definition.
- Or you can post them on your intranet and link them into a dashboard using the Custom URL app.
Either way, make sure that all teams using Rally can see your definitions and what they should aspire to achieve.
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.