A fellow Agilist recently asked me to give a presentation to a group of her company colleagues. She had a list of available topics, and given that someone had already signed up for my first choice (Definition of Ready), I picked my next favorite: Definition of Done. This blog serves as the outline for my presentation.
What is a Definition of Done all about?
A Scrum Team’s Definition of Done is a commitment to develop and deliver a working increment within a set of defined criteria that determine whether the work product is complete and acceptable. According to The Scrum Guide, it is:
“A formal description of the increment for meeting required quality measures.”
The Definition of Done intends to instill and ensure the quality of an increment; in other words, it minimally meets the team’s list of quality criteria, called the “Definition of Done.”
What is a Definition of Done?
A Definition of Done is typically a simple checklist of quality attributes the increment must have before it is “Done.” Each item on the list should be pass or fail, meaning it meets the criteria or not. There is no in-between measure or partial state of completion.
Does the team define its own Definition of Done?
It’s possible that your overall organization may have an already established Definition of Done that applies across the enterprise. If there is one at this level, your team’s definition is subsidiary to it but would be at a more detailed level.
Independent of the organization’s Definition of Done, individual Scrum Teams are responsible for creating their own definitions. If the company doesn’t have a higher-level definition, the Scrum Team may choose to include items at that higher level.
What happens if we don’t have a Definition of Done?
If the absence of an existing Definition of Done, your Scrum Team should stop whatever it’s doing right now and create one. If you don’t have a Definition of Done, there are predictable negative consequences, such as:
- Incomplete increments that are not acceptable to the Product Owner or stakeholders
- Getting stuck in a loop trying to understand what it means to be “Done”
- Repeating cycles of questions and answers between the Developers and Product Owner
- Continual rework to meet the ever-changing idea of what “Done” might mean
- Never getting stories across the finish line because no one knows what “Done” looks like
- Having to “carryover” stories from Sprint to Sprint, causing the team to feel demoralized
- Loss of trust between the Scrum Team and the Product Owner and stakeholders
- Unfavorable opinions about the Scrum framework
None of these are good things, but you can avoid them if you create your “Definition of Done” and stick to it.
How do we create our Definition of Done?
The best way to create your Definition of Done is to get your team together and brainstorm with them. The Scrum Master may facilitate, or a neutral third party could be employed to help the group with this activity. To create your Scrum Team’s Definition of Done:
- Discuss the purpose of a Definition of Done
- Create a list of all the quality areas (categories) needed for consideration
- Brainstorm potential criteria – let the team be creative – no idea is a bad idea
- As a team, review the ideas and group them into themes
- Using dot voting or some other consensus decision-making tool to decide what should be in the definition
- Document the results of the meeting
- Post your Definition of Done in a place where the team can see them
What areas should we consider for our Definition of Done?
Scrum was created with software development in mind, so this is the lens I usually use to consider what categories of quality criteria to use in my Scrum Team’s Definition of Done. However, if using Scrum in other contexts, a team’s Definition of Done could look very different. But if it is software development your team is doing, some areas to consider could be:
Coding
- Is the code documented or commented well so others can understand it?
- Was the code reviewed by a technical leader or peer and determined to be acceptable?
- Did a pair of programmers write the code together (acting as a check and balance)?
Testing
- Were Unit Tests written and tested? Did they pass?
- If items didn’t pass Unit Testing, were they fixed and re-tested?
- Were Test Cases written for either manual or automated testing?
- Did all the tests pass testing?
- If not, were defects categorized based on severity?
- For bugs of critical or high severity, were they corrected and re-tested?
- If you discovered any medium or low bugs, were they logged?
Deployment
- After team testing, did the code get deployed to the appropriate environment for the stakeholders to test?
The examples above are not a comprehensive list by any means, but it’s a starting point for things to consider when talking about and deciding what your Scrum Team’s Definition of Done will include.
How granular should our Definition of Done be?
A “Definition of Done” is typically applicable across a broad range of similar work; this means that the quality items apply to most of the work products you create. Specifics of each item do not go in the overall Definition of Done.
For each Product Backlog Item, additional Acceptance Criteria should serve as the specific requirements for that unique story. The increment must first meet the overall Definition of Done, and then it must also meet the Acceptance Criteria to be considered complete.
Is there any such thing as “Done-Done”?
No! There is no such thing as “Done-Done” or “Done-ish” or “Mostly done, except for QA testing” or any other less-than-complete definition; this is a common trap that so many teams fall into, and it isn’t fun! There is “Done” or “Not Done” (think Yoda’s “Do, or Do Not – there is no Try”). Any item that does not pass every criterion on the list is not done!
If it’s mostly done, do we get credit and can we show it?
Another emphatic “No!” If it hasn’t met your Definition of Done, your Scrum Team gets no credit for it. You earn no Story Points for that item and should not share it with stakeholders at the Sprint Review, either. The Definition of Done is a clear line of demarcation that is black or white. If it doesn’t pass, it’s simply not done!
Final Thoughts
So many problems can be avoided and mitigated by having a crystal-clear Definition of Done. Meeting quality criteria also ensures that the increment you deliver meets your Product Owner, customer, and stakeholder expectations.
One other note – your Definition of Done (like most elements of Scrum) isn’t set in stone like the 10 Commandments. Periodically, this list should be reviewed by the Scrum Team and adapted as necessary as conditions change or you learn new information.
Now, how about you? Do you have a Definition of Done? Has it helped you improve the quality or your increments? Has it prevented you from going through so much “churn” when doing the development? Has it also prevented escaped defects from getting into customers’ hands? I’d love to hear about your experiences with Definition of Done, so please share in the comments below!