How to understand the Definition of Done?
Imprecision is a common flaw of a human mind that is not very fond of a cognitive effort. We love to make things easier on our brains, and therefore generalization happens frequently, not only in everyday situations but also on professional grounds. Software Developers must be detail-oriented while producing code, yet they are still prone to the trap of subjectivity when it comes to the perception of the project rules and best practices. Each of us has biased opinions that may perfectly reflect our individual experiences, yet not necessarily the reality itself, and this is a usual cause of misunderstandings. How to determine whether a particular piece of music, art, or even a house is complete? It is sometimes challenging to know for sure, due to the mentioned ambiguity, and you should undertake any possible steps to avoid it in your software project.
To avoid misunderstandings in our projects, the Definition of “Done” standards must be agreed upon before a product improvement (the latter is often in the form of User Stories). The Definition of Done ensures transparency and the common understanding of what it means when we communicate that something is complete. It also serves as a border separating tasks that are still in progress from those done and is a tool securing the minimal expected quality in each of our projects.
Without a clear DoD, there is an increasing probability of having stakeholders complain about the final shape of a product, even though it meets business requirements and seems to work just fine on the surface. Issues indicating that the quality of delivered software isn’t satisfactory, like security vulnerabilities or harmed performance will pop up sooner or later, which may result in extra hours spent on refactoring for example. These dangers are usually harder to detect during standard acceptance testing, yet when missed, they cause severe troubles in a longer perspective. At the end of the day, the amount of work necessary to finish the project grows extremely, only because the criteria for task completion hasn’t been there in the first place.
Definition of Done in SolDevelo – the beginning
Research conducted in our company revealed that the Definition of Done is a widely-known concept, frequently used in one way or another in our projects. Soon enough, however, it turned out that not everyone understood it in the same way, and therefore operated on it differently. It forced us to analyze whether the DoD standards are unified, kept across the organization, and corresponding to our transparency policy. Fortunately, the results of this little investigation came up rather positively and showed only a few things to work on in the future. We should especially emphasize the importance of regular updates to our Definition of Done, for example. Sprint retrospectives are great opportunities to go through project DoD, check if it is still accurate, and introduce appropriate adjustments when needed. Developing such a habit would make our software delivery process even more reliable. Yet, to ensure that SolDevelo teams have universal standards as their starting point, we decided to create a basic, exemplary version of Definition of Done, and have all projects adhere to it before implementing their alterations. Such an approach would also propagate a common understanding of the perfect DoD in our company.
As the team and project mature their Definition of Done should evolve and become more strict to ensure higher quality and compliance, not only with company standards but also project-specific risks and priorities. We agreed that at no point can a specific project DoD be less restrictive than the company-wide policy and therefore our basic, internal set of commands for finishing tasks.
Luckily Scrum Guide has our back on this: If the Definition of Done for an increment is part of the conventions, standards, or guidelines of the development organization, all Scrum Teams must follow it as a minimum.
Why is it important to start from the Definition of Done?
Besides the importance of a clear Done definition in boosting transparency with stakeholders (in terms of requirements and processes), or reaching a mutual agreement between team members, implementing such completion criteria has lots of other pros. Scrum framework tells us that Scrum Teams are self-managing so they can decide how to best meet their goals independently. Through Definition of Done though, the organization can guide their Scrum Teams in terms of minimal, acceptable quality levels. It is, in fact, the only place in the whole Scrum Guide, where the development organization is explicitly mentioned to have a say on the final product delivery. Providing reliable, unified, minimal standards to all the teams, within a company sounds like a good idea in this context as well.
The clear Definition of Done is notably relevant during Sprint Planning, for it indicates how much effort is required to consider a particular task finished and complete. The Definition of Done also helps to set and then track the desired norms that result in a higher quality of the final product. Equipping the team with at least minimal guidelines in this matter is vital due to the software development specific character. Delivering a digital solution is nothing like a manufacturer’s work. Few things are repeatable the majority will be different each time: customers, technologies, requirements, goals, and priorities. Thus, if the product does not meet basic standards outlined in the organizational DoD, there is a great chance of not releasing at all, or releasing a product that won’t make your client, nor users, happy.
SolDevelo Definition of Done
After several Project Managers meetings, and cross-team cooperation, we have established our principles of organizational Definition of Done:
- The functionality described in the story was implemented (or bug fixed) according to the provided acceptance criteria or reproduction steps.
- Automated unit tests were added for the core business features at the minimum.
- The code built clean (at the minimum it compiled, tests and static code analysis passed) on the CI server.
- All code changes, additions, and removals went through code review, conducted by at least one person with technical expertise, not involved directly in making the code changes; the code review feedback was incorporated or discussed with the reviewer.
- The changes were deployed to the testing/UAT environment.
- The changes were tested manually on a test environment that best replicates the production environment – the summary of the conducted tests is attached to the ticket (e.g. as a comment or as a link).
- The changes did not introduce a known, critical regression.
It is important to emphasize that the above Definition of Done list is only a foundation, kind of a starting point which can and should be extended but never reduced. We are aware that as the project progresses with each iteration, the team gets to know potential risks much better, and therefore anticipate them more accurately. Such experience will allow the developers to adjust DoD so that preventing the spotted dangers becomes a common practice.
Moreover, we decided that a Quality Assurance Engineer assigned to the project is responsible for ensuring that the Definition of Done is regularly checked and used. If there is none in this particular role, a designated developer needs to take on this obligation.
The next step to consolidate the DoD role in our organization was establishing a new function – SolDevelo Auditor, who reviews the Definition of Done compliance periodically. The person responsible for DoD implementation makes sure the project’s current DoD is published and available for all employees. The auditor, on the other hand, verifies if the project standards are compliant with the organizational definition list. To perform this task, SolDevelo auditor contacts an assigned QA engineer or another person responsible for ensuring the DoD is followed and asks them about the practices in the project.
During the initial rollout phase, the inspection will be more frequent, but it gradually winds down. The SolDevelo Auditor will also be able to provide some feedback and insights that might improve how the team works with and handles DoD.
How is the Definition of “Done” tracked in SolDevelo projects?
In our case, the confirmation that a task meets the quality assumptions needs to be attached directly in the appropriate ticket before it moves to Done. Each point of the DoD has to be checked with a note saying who verified and confirmed that the given part fulfills requirements. This can be achieved by using comments, a description of the ticket, or other built-in project management tool features, yet such information must always be available directly in the task-related ticket. For Jira, Multiple Checklists for Jira can be used to keep the Definition of Done as a checklist within Jira issues. The plugin helps not only mark things that were finished, but it automatically collects valuable data like who and when completed a given activity. You can also easily track the progress of the DoD checklist as well as the number of checkboxes left to do so that the whole ticket can be considered complete.
As proved above, it is crucial to keep a clear Definition of Done in the company. It minimizes misunderstandings between an organization and stakeholders, as well as team members. But most importantly, the company services and final products are always of the same high quality, regardless of the project type. It is what our happy clients always appreciate.
