The Definition of Done (DoD) is a shared understanding of what work must be completed for a work unit (think: user story, sprint, feature) to be released.
Why does the Definition of Done matter?
- It provides a baseline for sprint planning. If you know ahead of time what is expected in terms of testing, documenting, and deploying then you can more accurately size backlog items and thus, plan accordingly.
- Avoiding repetitive conversation and redefinition. A clear DoD provides a framework for defining the tasks required for each work unit. Therefore, you can focus on execution rather than be stuck in a constant loop of defining.
- Reducing the need for rework. A clear DoD limits the risk of misunderstanding and conflict among the dev team and product owners. Once a backlog item is accepted as “done”, the chance that it will need to be reworked is reduced, and required (non-critical) updates can be moved into the backlog.
The DoD doesn't happen in a vacuum
It can't focus on just building usable software. It must be aligned with the overall organization’s needs, goals, and core values. And that's why a DoD should be a collaborative process among all those involved.
Should the Definition of Done include developer documentation?
I believe this question is key. And I say yes, the DoD should include documentation.
I think it's useful to go back in time here and remember the conversations we used to have about e2d testing and whether it should be included in the DOD. And guess what. The exact same concerns were raised then.
It hasn’t taken long, though, for us to recognize that writing tests sooner rather than later has provided great value and allowed us to make significant quality advances. And as a result, end-to-end testing has become part of the DoD for a lot of developers I've spoken with.
So, what do you think? Should it become the new standard?
Top comments (2)
Great points!