How Done is your Definition of Done?
In every Professional Scrum class, we talk about Done as an important concept in Scrum. And very often some students would get surprised when we tell this simple truth:
The whole point of Scrum is to have a Done product at the end of a Sprint. And Done means potentially releasable – no more work needs to be performed for us to release the product into the hands of our customers.
Another important truth that makes people feel uneasy is that if you don’t have any work that has been done as per Scrum definition, you have nothing to show in the Sprint Review.
“Why can’t we show something that is in progress? We worked hard on it after all?”
“It's not like we were sitting here doing nothing. We still did some work. We don’t want others to think badly of us.”
“Can’t we just split the user story into work done and count these story points in our velocity?”
These are the usual questions and statements I hear when I talk about “Done”. It all comes down to delivering something Done at the end of the day, and if you can’t achieve this, figuring out how to get there is what you should be focusing on (as the whole organization, not just the team).
If you try to game the system by counting extra story points, showing undone work or something similar, then you’re taking focus away from what’s really important.
What’s in Done?
When we think about the Definition of Done at first, we often think in broad terms.
I once worked with a team that had a very light Definition of Done (DoD). It literally contained four short sentences. To make it look more serious, it was written in a PDF file with a formal company header and footer.
While the team was convinced that they had their DoD ready and clear, I had a very different opinion.
The definition they had was very vague and did not include all the necessary details making it open for interpretation.
A good Definition of Done should have the following characteristics:
- Complete. All of the items that we believe are mandatory for us to consider something Done needs to be captured. You can’t leave some things as unspoken rules. Make sure everything is written down.
- Easy to understand. It has to be clear to anyone who reads the definition, whether it is someone technical or not. Remember that as we show new Increment to our stakeholders, they need to know what Done means.
- Straightforward. The best way to write the DoD is in the form of a checklist where each item on the list can only have “yes” or “no” answers. For example, “lots of testing” is too vague and might mean different things to different people.
Another thing to consider is that the Definition of Done is created for the product as a whole, not just one team and not just one Sprint.
Understanding what Done really means may take a couple of iterations.
When you first start it might be light and lack details. The most important is to inspect it and make it better, align it with key characteristics of a good Definition of Done.
An important point to make here is that the DoD is really your quality checklist. It shows what is the minimum quality of your product that you would accept.
Done as your guide
I always say that we learn best from examples and metaphors. Let me tell you how Definition of Done helped guide me during the creation of my online course Success with Agile and Scrum.
When I first started, I didn’t have a DoD. I thought to myself that since I’m working alone, it’s not needed.
However, every time I would get close to releasing a new lesson, I would have to think about what I need to get it done. To help me with it, I started creating lists of tasks to do in each new lesson. I found myself recreating all the same tasks over and over again: film video, edit video, write homework assignment, create a new page, add an image, etc.
In addition to the tasks, I also needed to verify every one of them based on my quality standards. For example, I needed to film the video needed in a specific frame, with special lights on, correct microphone setup, etc.
That made me realize that what I really need is a clear Definition of Done instead because I needed to align with my own quality standards for the course.
My first definition has drawn a lot on the tasks. However, it was not focused enough on what is the minimum quality I would accept. Because of this, sometimes I would end up with parts of the Product (lessons of the online course) that had mistakes or inconsistencies.
Definition of Done example
At this point in time my Definition of Done contains the following items:
- Aligns with the naming conventions
- Aligns with the style guide
- No broken links
- No spelling mistakes
- The correct information is displayed
- Course pages contain the necessary images and texts
- No background noise in video/audio
- Downloadable files not appearing in search results
- Pages only accessible to registered users
- Aligns with video standards
As you see here, I refer to other information that is not included in the DoD.
While we want this definition to be complete, we also do not want it to become overburdened with information.
Instead what I use is a reference to other documentation that contains more detail. For example:
In my case, I have created a clear definition of the naming conventions:
- Link structure: scrummastered.com/<main course page>/<module>/<lesson> or scrummastered.com/<main course page>/<other pages>
- Module URL naming: module-<number>-<title>
- Lesson URL naming: lesson-<number>-<title>
- Lesson page title in 2 lines:
- Module <number>: <title>
- Lesson <number>: <title>
What’s in your Definition of Done?
Hopefully, this article had clarified some important points about how to describe Done work in a better way.
It brings us to the question: how is your DoD doing? Does it align with characteristics we highlighted above? And if not, what are some of the changes that you need to make?
To conclude, I’d like you to always remember these important words:
“Done”. Or not “Done”. There is no “almost”.
Make sure that your Definition of Done always brings you to Done, not almost.