Building a Definition of Done
Joe the Developer waltzed into work one sunny Tuesday morning and was approached by Kenny the Project Manager, who asked if the feature Joe was working on was done. Joe had checked in his code to their shared source code repository yesterday afternoon and had unit tested it before doing so. With an emphatic “Yes!” Joe confirmed the feature’s completion. Kenny sighed in relief and said, “Great, then we will go ahead and deploy it into the UAT environment for our customer advocates to view.” Joe quickly backtracked on his original answer and blurted out, “But it hasn’t been fully tested by QA, the documentation is not updated, and I still need to pass a code review before it’s finished.”
Has this ever happened to you? Were you Joe or Kenny? How did you react in this situation? Did it feel like Development was not being honest? Did it seem that the project manager was assuming too much? If so, we’ve got just the tool for you: the “Definition of Done.” Here’s a list of steps that I use when I’m coaching a team on developing its own Definition of Done:
- Brainstorm. Write down, one artifact per post-it note, all artifacts essential for delivering on a feature, iteration/sprint, and release.
- Identify Non-Iteration/Sprint Artifacts. Identify artifacts that can not currently be done every iteration/sprint.
- Capture Impediments. Reflect on each artifact not currently done every iteration/sprint and identify the obstacle to its inclusion in an iteration/sprint deliverable.
- Commit. Get a team consensus on the Definition of Done: the items which are to be done for a feature and iteration/sprint.
During the brainstorming portion of the exercise, it’s important to discuss whether an artifact is truly needed to deliver features for release. Some examples are:
- Installation build (“golden bits”)
- Pass all automated tests in staging environment
- Sign -Off
- Pass audit
- Installation documentation accepted by Operations
- Release notes updated
- Training manuals updated
It’s important to note that these are not features of the application, but the artifacts that are generated for a release. Here are some questions you might ask about each artifact:
- Who is the target audience for this artifact?
- Is this a transitory artifact for the team or stakeholders?
- Who would pay for this?
- Is it practical to maintain this artifact?
When identifying non-iteration/sprint artifacts, the team creates a “waterline” mark below the brainstormed sticky notes. The team then considers each of the artifacts written on the sticky notes and discusses whether it can be produced every iteration/sprint for each delivered feature. If it can, the sticky is left above the waterline; if it’s not something that the team can do for each feature in every sprint, the sticky is moved below the waterline.
Next, the team looks at each of the artifacts below the waterline, and discusses the obstacles that stop them from delivering this artifact in every iteration/sprint. This is a difficult task for some teams, because if teams are to move beyond the status quo, answers such as “That’s just the way it is,” or “We can’t do anything about that” are not acceptable: the team can’t take action on answers like those. The obstacles, no matter how large an effort it may appear to require to remove them, can help management discover how they can support the team in releasing working software more predictably.
I’ve found that many of the obstacles identified by teams results in issues such as having a lag of unpredictable length after the last feature is added and the software is release. The obstacle may be that that the team is required to obtain independent verification from QA that the software is functional. There could be many reasons behind this requirement, from audit guidelines to governance policies, but there may be creative ways to incrementally conduct the verification, increasing the predictability of the length of the release stabilization period. Over time, these obstacles can be removed, and the artifact which was initially “below the waterline” can be included in the Definition of Done for every iteration/sprint.
Once a team has its Definition of Done, identified artifacts that can not be delivered every iteration/sprint, and captured the obstacles to delivering those artifacts, it’s time to gain consensus from the team. Any of a number consensus-building techniques can work, but I tend to use the Fist of Five. If the team agrees with the Definition of Done as described, it’s finished. If there are team members who are not on board, it’s time to discuss their issues, resolved them, and try again for consensus.
It’s important that all members of the team agree with their Definition of Done, because they will all be accountable to each other for delivering each feature according to its requirements. It’s useful to post the Definition of Done in a prominent spot in the team’s work area so it can serve as an information radiator, reminding the team of its responsibility.
The Definition of Done exercise can have many useful consequences, such as:
- Creation of an impediments list that management can use to support the team’s ability to deliver
- Organizational awareness of problems stemming from organizational structure
- Better team understanding of the expectations involved with their delivery objectives
- Team awareness of each member’s responsibility and contribution to the delivery
If your team doesn’t already have a Definition of Done, or it’s not been posted, try the exercise I’ve described. To get started, check out this example of a real team’s Definition of Done. I think you’ll find that building and using a Definition of Done helps your team get even better at its delivery.
Tags: Agile, Lean, pair programming, Scrum