Definition of Done Evolution

1. Puzzles called Products

In the realm of software development, the initial path forward is usually clear, with a well-defined goal of creating a high-quality product through incremental task deliveries. However, amidst this journey, it’s not uncommon for the team members to have varying interpretations of what constitutes a task being truly “Done.” My team encountered a similar challenge, and in this article, I will share how we successfully overcame this obstacle.

2. Done – so simple yet so abstract

The concept of “Done” may appear deceptively simple, but it proves to be rather abstract and intricate in practice. Achieving completion requires a shared understanding among the Scrum Team members to ensure transparency throughout the software development process. This shared understanding is encapsulated in the Definition of “Done” (DoD) for Scrum, representing the agreed-upon conditions that must hold true to consider a backlog item truly completed. While certain DoD may suffice for a period, they often need adjustments as the team and product evolve. 

Here are some examples of real-life situations where you realize that your team urgently needs to have a clear DoD: 

A team member completed work on functionality as defined in the user story, but the following scenario occurred:

• The unit tests were skipped depending on who was working on the code
• Some of the functionalities in the system got broken
• The UI review for the particular feature never happened
• Some of the small parts that weren’t done fully per design got noticed after the feature was ready to be released

The purpose of the definition of done is not to complicate matters or impose rigid rules that stress the team. Rather, it serves as a transparent and well-known guide, catering to the unique work cycle and needs of each team. It should be customized to fit the needs of the team and follow their unique work cycle. 

Since Scrum promotes work transparency, executing the proper definition of done goes hand in hand with it. The whole team is well aware of the expected amount of development, testing, documentation, and deployments involved with a backlog item.

3. Real-life challenges 

There were several situations where our team recognized the need to upgrade their DoD and evolve the procedures.

In a timeframe of one year, we faced several changes in the team: 

• Significant team expansion with  some members joining the team at the same time
• Members switching to other teams reducing shared tribal knowledge
• Shorter release cycle due to the product needs

All of these circumstances brought us to the point where we needed to consider evolving our DoD in order to return balance and understanding of the standards we as a team want to preserve and improve:

• Our initial DoD was nowhere documented – it was a rather verbally agreed set of steps that need to be followed to achieve Done. Back in the days when team was smaller and the product wasn’t mature as now, it was fine to have it that way
• Ambiguous ownership – in one point it became very unclear who owns the certain part of DoD at each phase since sometimes there could be few people responsible at the same time
• Current work procedures didn’t fit the product’s needs any longer  – most of our work procedures were defined in a way that assumed well-defined, finite tasks that were present at the very beginning of the project. As the product evolved, most of our new requirements implied investigation, bug fixes, refactoring, prototyping, and so on

We understood that documenting DoD is the first step to evolving it and adjusting to our new needs. 

To overcome this situation, we have created the following action plan:

• Meetings with representatives from each sub-team – Each sub-team (UI/UX design, Software Development, QA testing, and DevOps) had its own daily challenges. We tried to extract each sub-teams’ biggest issues: 
  • for the UI/UX team, those were mostly regarding the urge to have a unique place to perform UI reviews
  • the Software Development team was facing large PRs and complex code to analyze
  • the QA testing team had several challenges regarding documenting and automating tests
  • DevOps team was having issues with frequent releases
• Analyzing work procedures and adjusting them to the current team’s needs
• Collecting each sub-teams needs and combining them into set work procedures

This brought us to a newly created DoD that fits our needs.

4. Good practices adopted

Reflecting on the implementation of our customized Definition of Done (DoD), several key aspects stand out.

• Each DoD Step has its Owner – Perhaps the most crucial aspect for our expanding Scrum team is the assignment of ownership to each step within the DoD. It’s not just one person handling all tasks; instead, as a ticket progresses through various phases, from design to deployment, clear responsibilities are designated to specific individuals. These designated owners are accountable for executing, monitoring, and transitioning the task to its subsequent phase. As soon as a task is added to the Sprint backlog, the owners for each phase are promptly defined. They are also responsible for gathering and analyzing all necessary information from the rest of the team to ensure smooth progress
• Integrating Work with our Tools – Emphasizing the integration of our work tools is another beneficial practice we diligently nurture. Our toolkit includes Figma, JIRA, and GitHub, and we make the most of their integration options to facilitate seamless tracking of each task’s lifecycle. Leveraging the extensive configurability and automation modules of JIRA, we have constructed a custom-made set of rules, adding various phases, fields, and workflows tailored to our specific needs. This integration not only streamlines our processes but also enhances collaboration and visibility across the team

5. Conclusion

Over time, our team has wholeheartedly embraced and adapted to our new Definition of Done. It almost feels like tasks are effortlessly flowing through a well-oiled conveyor belt. With every team member keenly aware of their responsibilities, there are no bottlenecks or standstills in any phase of our work. This approach has proved instrumental in consistently delivering high-quality increments and, ultimately, a top-notch product.

Beyond the tangible benefits of a high-quality product, providing a clear set of steps that emphasize quality and efficiency elevates the work atmosphere to a new level. By establishing well-defined procedures, ensuring thoroughness, and maintaining consistency, we invest not only in the product’s future but also in the team’s well-being. The synergy between a satisfied team and the creation of high-quality products is undeniable.

As we continue to refine and optimize our processes, we find that our journey doesn’t just lead us to a successful product but fosters a culture of growth, collaboration, and pride in our work. A well-crafted Definition of Done is more than just a checklist; it becomes the cornerstone of our achievements, pushing us toward excellence in every aspect of our software development endeavors. And the work is not done there yet. We will continue to evolve, as our team and product grow, change and mature.

6. References

• https://www.scrum.org/resources/blog/dod-evocycle-simple-technique-effectively-manage-your-definition-done
• https://www.productboard.com/glossary/agile-definition-of-done/#:~:text=What%20is%20the%20definition%20of%20done%20in%20agile%3F,perform%20for%20every%20backlog%20item
• https://www.scrum.org/resources/what-scrum-module
• https://www.atlantbh.com/design-review-in-product-development-2/