The Definition Of Done (DoD)
All the arduous work put into any product development leads to the ultimate step; client satisfaction! Your team has tried their best, and now you must answer the most ambiguous question;
Are we done? Are we there yet?
You might be thinking, ‘yes.’ However, you should be aware of the difference between being done and just fulfilling the acceptance criteria. And the only way of differentiating is by understanding the Definition Of Done.
Before starting any project, it is best if you consider a definition for project completion. Such a criterion comes after discussions with the client and the team. Catalog the entire process and is then communicated to the whole team so they all can be kept in the loop. If, in any case, the criteria are not fulfilled, the Sprint is considered incomplete and does not go forward.
Without a proper understanding of the Definition Of Done, your Scrum team will have no idea what they are working on, your clients will be free to expand the scope, and your users are likely to wind up with a crowded, confused, and undesirable product.
In short, the Definition Of Done is the collective understanding of the entire team on what makes the Product Increment releasable.
When working on defining the finished product, it is crucial to set some goals. These goals will:
- Help create a shared understanding of the level of quality expected and completeness within the team – essential during planning processes so that your team is fully aware of the goal at hand
- Provide a criteria checklist from previous user feedback. It will help save time since there will be no repeated mistakes or consistent updates required.
- Help ensure that the Increment meets the quality level as designated by the product manager. It will keep everyone happy!
Incomplete work quickly increases without a clear objective in mind, leaving you with a load of “work debt” that needs cleaning.
Before we dive into the DoD details about its practical application, let us look at the concept’s origin.
It all started in 2002 when Bill Wake authored an article, bringing to attention all the inconsistencies in terms commonly used within teams, such as ‘done.’ Considering this, the Scrum training materials of 2003 started hinting at how important the Definition of Done can prove to be in the future. This endeavor led to Scrum adding exercises for their trainees that helped them focus on the Definition of Done, which we later see in Scrum’s training programs itinerary. By 2007, the Definition of Done had become a full-fledged practice is now a part of every project management.
Related Articles
The Definition of Done does not necessarily have to be the same for each organization or Scrum/Kanban team. This definition is entirely dependent on the deadline, requirements, and type of the project. However, the checklist usually includes the following.
You can alter the definition of these items to fit the requirements of each Agile team, but the idea remains the same: until all the boxes are tick-checked, the Sprint shall not be released.
Scrum Masters or Project Managers are the ones that lead the DoD. Since they are the ones that are keeping the entire project in check and dealing with clients, they can better understand the quality requirements or predict the technical difficulties.
The DoD is a collaborative work. The Scrum/Kanban Project Managers get together with their team to agree on a shared understanding of ‘done.’ Nothing is genuinely ready unless the quality assurance specialists and other stakeholders do not provide feedback and approval. Hence, it is detrimental to keep them all involved.
Defining the checklist cannot be done quickly. It requires a collection of multiple opinions. Whether it begins with a discussion, or a straw man presented by the technical team, there should be plenty of time for feedback and majority approval for the finished product.
Allocating owners to each requirement is also a brilliant idea, as they may act as the arbitrator if there is a conflict over an item’s eligibility to tick said box. It encourages consistency and eliminates any ambiguity about the equation.
A Definition of Done, like other excellent methods, should be as basic and brief as appropriate. The goal is to produce consistent quality rather than consistently fighting setbacks that hold things down needlessly.
In most cases, teams tend to fulfill the acceptance criteria and not the DoD. The two can be confusing, and the tricky part is understanding the difference between DoD and Acceptance Criteria.
Both DoD and AC help you determine whether your project is completed. However, there is a significant difference between how experts use them individually.
DoD is quite universal, which means that the main criteria remain the same even with some personalization. On the other hand, we have acceptance criteria that are unique for every project. It depends on the user stories, features, and issues at hand.
Think of it this way – if a client wants a particular feature with a specific benefit, you will need several items ticked off to deem the user story ‘done.’ The entire process will have multiple steps. Each step will have its acceptance criteria, and it will be a part of the DoD but will not meet the demand. Code and functionality tests would still need to follow. These tests will be a part of DoD but not acceptance criteria.
Hence, just following the criteria in no way means that the product is finished or benefit is achieved.
Consider these to be various levels of precision. A definition of done applies to all user stories in your Sprint, but each one will have its own set of acceptance criteria before delivery.
As a product manager, creating your own DoD is not as difficult as it seems. Like I have stated before as well, it is all about working with your team. They must know that the DoD is entirely transparent to follow the same criteria and work towards the same goal.
Once you have a clear definition, it is vital to ensure that it applies to every Sprint task. It does not matter about the size of the job – check everything with the DoD list. Most of the time, working under pressure can force team members to ignore this part. The idea of solving this issue is by embedding it into the workflow.
Even though DoD is essential to the project’s success, try not to obsess over it too much. Keep the list short and precise. Because otherwise, your team will be too hung up on checking off all the things on the list, or they will try to do it all, which we know is the recipe for failure.
Follow this rule of thumb; the DoD is the least amount of work necessary to reach the agreeable quality level.
We previously discussed the distinction between acceptance criteria and your definition of done and how both are required to complete your Sprint or label a project plan meet effectively.
As you go through the sprint planning process, ensure that each problem has the necessary details and acceptance criteria. It will benefit you and the Scrum team by making it easy to follow DoD.
However, while creating your DoD, do not forget to consider organizational needs. You DoD should not go against the organizational needs. In almost all circumstances, the definition of done should be agreed upon by the whole Scrum team. Your team is exclusively accountable in Agile for converting your product backlog into sprints and usable software.
Usually, the difficulty arises when you get overly focused on the work at hand and lose sight of your organization’s larger goals, requirements, and customs. A definition of done will need to be reviewed against your fundamental beliefs and ideals on occasion to ensure no significant concerns slip due to neglect.
When we specifically talk about product development in Agile/Scrum, the focus on Definition of Done is three main components. These are the components that will make it easier for you to create your own DoD or checklist.
- Business Or Functional Requirements: This requirement is assumed to bring value to the product by making it functional. It is usually written in user stories and opens discussions towards Acceptance Criteria, Business rules to follow, the kind of workflow expected, mock-ups, algorithms, data points, and more.
- Quality: The coding language / Rapid Application Development / technical tools used to develop the product significantly impact quality. The Development team oversees quality to guarantee that the item is the highest possible quality. Quality standards can be subjective and statistical and include coding standards, test-driven development, unit test coverage, maintainability, defects, technical debt, design principles, etc.
- Non-Functional Requirements: Usually found in Acceptance Criteria or Product Backlog, these requirements might not prove to be as beneficial for business value. However, they are the ones without which your product cannot move. They are fundamental to quality assurance since they focus on availability, maintainability, performance, reliability, scalability, security, usability, and compliance/regulatory legal.
Once you master the skill of creating a DoD on your own, you will be able to enjoy the lucrative benefits that come along with it. Quality product and efficiency aside, Definition of Done supplies an excellent checklist for guidance. Before starting the project, implementation of many activities, including discussion, estimation, design, are followed through with DoD.
Moreover, the Definition of Done acts as a great time-saver. Not only will you NOT have to worry about quality assurance, but team members will not have to do the same work repeatedly. Following the DoD, their work will be accepted as ‘done’ on the very first try!
Lastly, the product manager will not have to worry about solving conflicts between the Scrum Team and the clients. The DoD removes any misunderstanding that otherwise may be present had the proper guidelines not been given. It means that your focus can be on the project alone, and everyone leaves happy.
However, there are some pitfalls to look out for and avoid. As stated above, obsessing over the list of criteria might be counterproductive; the list should specify the least amount of labor typically necessary to get a product increment to the “done” stage. The more you obsess, the less you focus on the actual task on hand.
It is also important to keep individual factors or user stories in mind. They may have additional “done” criteria and the ones that apply to the whole project. This condition means the team must be more careful and ensure that each criterion is fulfilled for the finished product to be acceptable.
Lastly, it may lose much of its power if the concept of done is used as a shared understanding rather than stated and put on a wall. A large part of its worth is in having an explicit contract known to all team members. It is also essential to keep the contract short and simple so that every team member can have a quick look over each day and keep their goals in check.
There might be times when a need for change or alteration to the definition of done occurs. Constantly changing it is not preferable since it might cause a great deal of confusion among your sprints, and it will kill any benefits you are enjoying.
Agile is beneficial since it makes it incredibly easy to understand and adapt to your user’s needs. But even it remains unable to solve this issue. However, a little bit of guidance was found in a Scrum Guide that states.
“During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of ‘Done’, if appropriate and not in conflict with product or organizational standards.”
It gives an excellent rule for product managers and Scrum experts to follow: welcome discussions about the DoD during the Sprint, but any required changes should be left for sprint planning.
Everything aside, product managers of Agile, both Scrum and Kanban, should not ignore or take the Definition of Done lightly. The managers should understand better that the lack of a proper DoD or checklist will lead to conflicts, misunderstandings, affected revenue, and horrible customer experiences. Therefore, it is wise to set a criterion before the project even begins.
By doing so, you create a shared vision and goal for every team member. You are also collectively agreeing on features and quality which maintain customer expectations. And finally, you are building trust, among team members and organizations. You are giving customers a reason to rely on you.
