From Chaos to Clarity: The Power of a Definition of Done

We reject: kings, presidents and voting. We believe in: rough consensus and running code. — RFC 7282

Do you ever feel like the main character in a bad comedy? Your days are spent in an endless cycle of discussions, approvals, and rework. You and your team have spent hours, days, and maybe even weeks building a new feature. Everything from testing to deployment seemed to be going according to plan, and then - you happily report: "Done!" And then the manager (or the client, or that mysterious Product Owner) shows up and says: "Well... that's cool, but isn't it obvious that you need to do things differently?".

Obvious? No, buddy, not obvious. If it were obvious, we wouldn't be sitting here right now with eyes like raccoon eyes after a night of dumping. And that, my friend, is one of the first telltale signs that your team lacks a clearly defined Definition of Done (DoD).

In software development, "ready" or "done" is a word with very blurred boundaries. For one person it means "all the code is written", for another - "everything is tested", and for another - "it is already on production and users are happy". Without an agreed-upon definition of what exactly "done" means, your project becomes a perpetual zombie series. You think I'm kidding? "The Walking Dead" has been out for 13 years. Do you want your project to stay that long?

Source - Scott Adams (Dilbert.com)

That's where the Definition of Done (or DoD for short) comes in. Simply put, it's a sort of pre-agreed checklist list that ensures that the work is actually completed. You know, like a shopping list: you can't leave the store until all the items are crossed off. It's your guarantee that what you've built aligns with the project's goals and quality standards.

The thing is: every team might have its version of DoD, which makes them somewhat unique for your team. So you need to gather the team, discuss, and set those rules for everyone what "Done" really means.

The primary reason for having a DoD is to ensure that work meet a certain level of quality. Sometimes, when a team works on something, they might not fully grasp what's needed or how good it should be. That's where the DoD can help – it's like a cheat sheet that helps the team understand what it really means to finish a task.

The DoD does some pretty cool things for teams:

1. Shared understanding: When you have a DoD, no one argues when you can call a task complete. This cuts down on unnecessary conversations like, "Didn't we already have that ready?"
2. Transparent quality standards: DoD allows you to clearly document what steps of a job must be completed. For example, "code is written" is not enough. It needs to pass tests and be code-reviewed, deployed, and documented.
3. Fewer surprises: There's nothing worse than suddenly finding out that production isn't ready to accept your changes. DoD helps you identify such risks in advance.
4. Boost communication: DoD is useful not only inside the team but also outside the team. Customers, stakeholders, or managers can quickly understand what steps are left to finalize.
5. Less technical debt: If you complete tasks correctly and efficiently, you reduce the chance that you'll have to return to that work in a couple of weeks with a sad sigh: "Well, who wrote like that?...?"

I've seen DoDs that are either too simplistic, like saying "code needs review, merge, and deploy", or overly complex — a long, confusing document. I think a good DoD should be simple and clear, covering only the essentials of what a task needs to be considered finished. It should evolve with the team's needs and be regularly reviewed and updated.

Here's what it might include:

A task is considered "done" when:

1. Acceptance Criteria: The code fully satisfies the acceptance criteria outlined in the user story and undergoes comprehensive testing to validate its expected functionality.
2. Automated Tests: All automated tests, verifying the acceptance criteria, pass successfully and are stored alongside the code. Performance and stability testing yield satisfactory results, and there are no regressions.
3. Compliance Testing: The code is compliant with legal and regulatory requirements. All dependencies and licenses used to comply with applicable regulations, such as GDPR, HIPAA, or PCI DSS.
4. Testing and Performance: New unit tests are created, all tests are stored in version control, and they must undergo peer review and pass. Performance and stability tests are conducted with positive outcomes.
5. Code Style and Peer Review: The code adheres to established style conventions, passes linter pipelines, and is peer-reviewed by at least one team member with no outstanding discussions. A peer review by another engineer is completed.
6. Naming Conventions: Object, system, and job names follow established naming conventions.
7. Future-Proofing with Monitoring and Alerts: The code is expected to perform as intended in the future, even if requirements change. To ensure this, vital metrics are monitored and defined alerts promptly notify of any unexpected behavioral changes.
8. Ticket Management: Tickets are appropriately updated to reflect their status, with accompanying comments explaining the status choice.
9. Documentation: Documentation is created and regularly updated to ensure a clear understanding of expected code behavior.
10. Branch Management: The code is merged into the master branch, and feature branches are deleted.
11. Deployment: Code is deployed and operational in production environments, not solely on developers' machines. A rollback plan is prepared for high-impact changes. Environment-specific references are verified and updated.
12. Stakeholder Awareness: Stakeholders are informed of the code's functionality and potential impacts. Communication is broad and proactive, ensuring affected teams are well-informed.

A Definition of Done is an essential tool for any software development team. It sets clear expectations, reduces ambiguity, and ensures that everyone involved in the project is on the same page.

A good DoD is straightforward and practical, laying out clear requirements that need to be met before a task can be checked off. It empowers teams to "Get shit done".