Once I was in a team with one of the most inspiring project managers - Frank. We were working on the project for a while, but nothing was live yet. As a result, in order not to use the common (mis)understanding of done as “dev-done” Frank went to our work board and added a note under the Done column: “Frank can see it.” I appreciated this wake-up call for the team - if it’s not visible to everyone, is it actually done?
However straightforward “Done” may sound, most software development teams don’t have their definition of done clearly set.
When we think of a story lifecycle and team’s work boards, often we have a column called “Done”. What does it mean, though? In this post of Quality Foundations, we’ll talk about why what “done” means matters, what “Definition of Done” (DoD) is, why it’s not the same as acceptance criteria, and look at an example of it.
Why should we agree on what “Done” means?
I’ve been in multiple daily standup meetings where a developer working on a story stated: “Oh it’s done, just the tests are missing.” That makes me cringe. How can it be done if the tests are missing?
All this is due to different subjective perspectives of what “done” means (in the case of tests, it’s not only the perspective of what “done” is - it’s also the ways of working in general, and, what “development” means I’d say).
It is easy for us to see our work as handing over boxes - I did my part, here you go. If we want to build high-quality products, we need to have quality accountability all over the team. This also means that we should aim for a better understanding and connection to the product and its state. Aligning on “Done” removes assumptions and misunderstandings in the team involving both the development team and even project stakeholders. It helps us track our work better which can save us from frustration: it is not just developing the feature on the local machine that delivers high-quality products, we need much more. Definition of Done adds a layer of transparency to everyone on the team on what work it takes to reach our goals.
What’s a Definition of Done and how to use it?
Based on scrum.org Definition of Done is: “a shared understanding of expectations that the Increment must live up to in order to be releasable into production.” In my own words, I’d say that the Definition of Done is an agreement on what a finished work item means for the team. It can result in a physical or digital artifact that often looks like a checklist. I do like the concept of questions over checklists more because not everything is always applicable for every task and it sparks a discussion. When you create the Definition of Done it acts as a requirements list for moving any tasks into the Done column.
In every team I worked in, Definition of Done popped up out of the necessity. The team realized that there was a misunderstanding, and, this is why they decided to align and put it into their Definition of Done. It is a living document where new learnings can be easily added and changed based on your context.
Example of Definition of Done
In this example, we not only said that the feature is live but also made sure to remind that cleaning up feature toggle or any legacy code is a part of done. If your team does not use feature toggles then you may not need this point at all. In our case, this definition of done helped us to know what is live and that we have done all the steps to have a good confidence net on the feature like logging or functional tests.
Definition of Done vs. Acceptance Criteria
You may be a bit puzzled, isn’t “done” just meeting the acceptance criteria? Well, that is a part of done. Some teams may even add a point in their Definition of Done: “Acceptance criteria satisfied?”. Despite that, DoD is much more than that: it is our chance to have a better understanding of what we need to finalize our job. Be it testing or good monitoring: it is all a part of a high-quality product, and it is up to you to decide what you want to advocate for.
Summary
Definition of Done helps teams track their work progress in a more aligned and connected way by providing a reminder on what “Done” means for the team. It is a very contextual agreement that teams can personalize based on their situation so it provides the most value to them.