TL;DR. More than once, development teams struggle with determining when a task is truly “done”. Why? Because software development is a complex process where the definition of done can be a subjective one, mirroring personal experiences. That is why for today’s read we propose a larger definition of DoD. Call it a checklist, a guide, a set of criteria or a documentation, a DoD (definition of done) is a practice that offers clarity, ensures quality standards and makes us declare with confidence “Thank you, next!” whenever one task reaches the green light.
If you think about it, a DoD is applicable to non-technical departments too. So this might be a nice read for a broader audience.
Context
Have you ever seen a demo and only 50% of the things worked and the other 50% needed more work to be done in order to be released to production?
Or… have you complained about spaghetti code?
Or even better, have you ever heard the term: “worked on my machine”?
Well, these are typical problems of the software development world.
That is why deciding on a clear definition of done (or DoD) allows teams to work on their tasks more efficiently and to know where they are headed with them. But let’s not just assume we all agree on the definition of the term, so here are some of the efforts made in defining the concept:
- A DoD is a set of criteria that a product increment must meet for the team to consider it complete and ready for customers;
- A DoD is a simple checklist for what it means that a task/user story/bug/epic is delivered and considered done;
- A DoD is basically a documentation that makes the software development process easier and more transparent;
- What is not a DoD? A substitute for good communication within a team.
To summarize these definitions, a DoD is a best practices guide, one that helps the people in a team to apply the same quality standards while knowing what is expected of them. And this is relevant not just for technical teams or departments.
A DoD for a project varies depending on the type of project, tasks and on the team involved. Therefore, a generic project might have these as part of the DoD:
- All errors have been resolved.
- All documentation has been written and edited.
What is it?
A DoD is made in order to provide a clear, agreed-upon checklist of criteria that must be met before a task is considered complete. In software development, the DoD emphasizes that a task isn’t done just because the code works; it must also meet other criteria such as passing tests, being reviewed, and having adequate documentation. The DoD typically includes thorough testing as a mandatory criterion for completion. This ensures that developers consider a wider range of scenarios and confirm that the code not only works, but is also reliable and robust.
A DoD also leads to a more cohesive and reliable product by setting a common standard that all team members must follow. A DoD reinforces that quality cannot be compromised, even under pressure. So this holistic view of “done” ensures that all facets of quality are considered.
DoD at abac software. Inside a software development team, the concept of “done” involves more than just writing functional code. It involves having in mind the bigger picture, understanding the “Why?” in each action we make and being able to rely undoubtedly on each other’s work.
At abac software we have defined rules or principles depending on the moment we find ourselves at: before a pull request and after a pull request. Our process looks something like this:
Definition of done before PR (moving task from In Progress to Review):
- All the functionalities that are presented in the ticket’s description are implemented;
- All the functionalities that are presented in the ticket’s description are tested;
- Minimum two unit tests are implemented (one for happy flow and the other one for a corner case flow);
Definition of done after PR (moving task from Review to Done):
- All the code review changes are handled;
- All the checks are green;
- PR is approved by at least one person;
- All the functionalities from ticket’s description are verified;
- Ticket’s branch is merged into sprint branch;
We use a DoD as a fundamental tool that ensures quality, consistency and alignment within software development teams, regardless of the team’s structure and level (juniors, mid level or seniors).
Why is it relevant?
Having a DoD is crucial for software development teams because it sets clear standards for when a piece of work is truly complete. Here are several reasons why a DoD is relevant:
- A DoD promotes transparency and accountability: this helps in reducing misunderstandings and sets the stage for accountability.
- With a DoD in place, progress can be objectively measured. If a task doesn’t meet the DoD criteria, it is not considered done, which holds the team accountable for completing work to the agreed-upon standards.
- In Agile methodologies like Scrum, knowing the DoD helps teams plan their sprints more effectively. It ensures that tasks are estimated with all the necessary work in mind, including testing, documentation, and reviews.
- A DoD that includes code quality checks and documentation requirements ensures that the codebase remains clean and understandable, which is critical for long-term project health.
- A DoD fosters a shared understanding within the team about what it means to complete a task. This alignment enhances collaboration as everyone works towards the same standards and goals.
- When team members know that their work is complete and up to standard, it increases job satisfaction. It also reduces the stress and frustration of having to revisit tasks that were previously considered done but failed to meet all necessary criteria.
- A DoD serves as a baseline for evaluating the team’s performance. Regular retrospectives can involve revisiting and refining the DoD to improve processes, which supports the continuous improvement of both the product and the team.
When it comes to non-technical tasks, such as finding a suited place for the next team-building, for example, the definition of done involves a date, a location, participants, activities. Anything less than all these checklists makes this task an incomplete one. The main rule is that the result should be able to cover all of the task’s requirements…or to provide an explanation if the result differs from the original expectations.
Other tasks are applicable to both technical and non-technical departments. Take for example a research task: in this case, the DoD will consist of a document that presents different options with pros and cons for each one; or the DoD refers to a guide of how to use and integrate a specific solution.
In conclusion, the type of the task might play an important role in what DoD means and looks like. This just shows the versatility of this practice.
Pro
Yes from the get-go: “Definitions of Done” (DoDs) play a significant role in avoiding conflicts within software development teams. By providing a clear, shared understanding of what constitutes a “done” task, DoDs help prevent misunderstandings, miscommunications, and disagreements that can arise during the development process. Here’s how:
1. Aligned Understanding: A DoD ensures that everyone on the team, from developers to testers to product owners, shares the same understanding of what needs to be done for a task to be considered complete. This alignment prevents conflicts that can occur when different team members have different expectations.
2. Eliminating Gray Areas: A well-defined DoD eliminates gray areas by detailing specific steps that must be taken, such as code reviews, testing, and documentation. This specificity reduces the chances of tasks being marked as complete when they are not, which can lead to conflicts.
3. Preventing Rework: By ensuring that all necessary steps are completed before a task is marked as done, a DoD reduces the likelihood of rework, which is a common source of frustration and conflict within teams.
4. Avoiding Last-Minute Crises: When tasks are prematurely marked as done, issues often surface later in the development process, leading to last-minute crises. A DoD helps prevent these situations by ensuring that all work is completed to the required standard from the outset.
5. Enhancing Trust and Morale: When team members trust that everyone is adhering to the same DoD, it can enhance morale and reduce conflicts. Knowing that everyone is pulling their weight and delivering quality work builds trust within the team.
Con
Nonetheless, even with so many advantages, we must always act with prudence.
Too detailed DoDs could lead to wasting huge amounts of time on unnecessary formalities. We must also remember that this document is not a cure for all the problems. It can never replace healthy communication nor precise function requirements.
Therefore, while having a “Definition of Done” (DoD) is generally considered a best practice in software development, there might be some perspectives where teams could question its necessity. Here are some arguments against having a DoD:
- Perceived Bureaucracy: In very small teams or startups, there might be a perception that defining a DoD adds unnecessary bureaucracy. When the team is small, informal communication and shared understanding might suffice without formalizing a DoD.
- Stifling Creativity: Some teams might argue that a rigid DoD stifles creativity by enforcing too many constraints on how tasks should be completed. They might prefer more flexibility to explore unconventional solutions without being bound by a predefined checklist.
- Adaptability: In highly dynamic environments, where requirements and goals frequently shift, a fixed DoD might be seen as too rigid, potentially limiting the team’s ability to adapt to new challenges or opportunities.
- Individual Autonomy: In some cases, developers or team members might prefer to rely on their judgment rather than adhere to a standard DoD, especially if they feel experienced enough to determine when their work is complete.
In most cases, the benefits of having a DoD outweigh the potential downsides.
Conclusion
In summary, a DoD helps teams working towards the same goals while having healthy quality standards.
But a major aspect of a DoD is that it helps in avoiding conflicts and frustrations. If you think about it, a DoD acts like a good family doctor: preventing possible malfunctions and also acting first hand when the system is signaling red alerts.
Sources:
