Definition of Done
Start finishing tasks
Finishing things is one of the hardest tasks there is. Almost finishing what you’re doing is simple, you’re motivated by the results it promises. But, once fully or partially obtained, finishing and making it to the end feels like an obstacle that prevents you from continuing with the next task.
As Tom Cargill of Bell Labs advanced in the 80s:
The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.
Finishing tasks, especially in software, is not only the most expensive thing, but also, in many ways, the most important one.
What is finishing tasks?
Apart from the lack of motivation to finish tasks, many times the problem also lies in the fact that it is not entirely clear what it means to finish something. Or it may even be that different people have very different conceptions of what they mean by something that is finished.
If you’re already delivering the expected value, is it finished? If we’re not going to touch it anymore, is it finished?
The first step to knowing if we have finished something is to know what we consider to be finished. This consensus on the status of the task is usually called Definition of Done.
Defining a good DoD is essential to have clarity on when we have finished a task and can move on to the next. Being clear about this and being clear about it for the entire team (and business) is essential to meet expectations and reduce possible misunderstandings.
In addition, it serves as a quality check. For example, defining the things we need to do before leaving a code productive for posterity before moving on to the next task also makes us focus on the long-term maintainability of that code and prevents potential technical debts and accidental complexity.
And above all, it brings transparency about what we’re doing. Having a shared DoD gives us absolute clarity about when a task is finished or missing for us to consider it as such. This helps third parties or members of our own team to better manage the possible expectations that exist about that part of the product.
How to define a good DoD?
Defining Definitions of Done is a skill that comes with time and ongoing work with our team. Here are some tips to define robust DoDs that help manage our tasks:
- Include the whole team: this is the most important of all, a DoD has to be agreed upon by the whole team so that everyone’s expectations are well managed. We must consider the completeness criteria of the parties involved. These include product requirements, both product and technical quality criteria, associated documentation (if required), etc. But it’s important that everyone sees themselves represented in this DoD and their needs are addressed.
- Crystal Clear: Be explicit, clear, and concise. Getting to the point and making the DoD as clear as possible and easy to understand will prevent potential misunderstandings.
- Cover all aspects: Don’t just look at product requirements or the clearest technical aspects. Make the effort to think of the list of things that need to be done in order to consider the task finished. Take into account all your quality criteria and the values of your team for this.
- Different tasks require different levels of DoD: You don’t need to be super detailed on every task, invest more effort in important things, and define more lax DoDs for routine tasks. And remember that you don’t need DoDs for everything, start implementing them where you feel most comfortable.
- Make sure the DoD criteria are measurable and verifiable: If you have doubts about whether one of the conditions is met or not, it is not well defined from the beginning. There should be no doubt or discussion.
- Align DoDs to your team’s reality: Overly demanding DoDs can cause your team’s delivery to suffer in the state and context it is in at the moment. Take it one step at a time and adapt the levels of demand to ensure quality without compromising feasibility. Unrealistic and achievable DoDs can lead to frustrations and arguments.
And try different things, like everything, we never get it right the first time. Experiment and test to find the formula that works best for your team. Little by little you will get practice and improve.
Finishing things is something that is difficult for us. If we are at least clear about the horizon we want to reach, it will be a little easier. Test, iterate, and start finishing tasks properly!
DoD Example
Here’s a possible DoD to make the points clearer and show what an example of any user story could look like. Note: this is just an example and depending on the epic, story or task it could be more or less extensive.
- Product:
- Meets the acceptance requirements for the new functionality (they would be listed).
- Enough demo has been made with the rest of the team about the new changes.
- A validation test has been performed with a selected group of users.
- Code:
- The code has been written following the established standards.
- TDD has been made to cover the developed code.
- The code has gone through a final refactor to ensure its future maintainability.
- The code has been paired or reviewed by at least one teammate.
- The code has metrics associated with it to identify potential performance issues.
TL; DR
Definition of Done (DoD) is an essential component for overcoming the challenges associated with task completion, especially in software development. The DoD not only marks the end of a task, but also acts as a guarantor of quality, facilitates transparency, and manages expectations.
The key to an effective DoD lies in comprehensive team consensus, encompassing product requirements, technical and product quality criteria. Clarity, conciseness and verifiable measurement of the criteria are essential to avoid misunderstandings and ensure undoubted compliance.
We have to adapt the level of detail of the DoD according to the importance of the task. Alignment with the reality of the team is crucial to avoid excessive impositions or unrealistic standards. Continuous iteration is a key practice for refining the DoD definition process over time.
In conclusion, the DoD provides a clear guide to overcome the difficulty of completing tasks. Teams are urged to experiment, iterate, and approach task completion effectively, using the DoD as an essential tool in their development.