Christian Vos, founder of Rood Mitek and Microsoft .NET consultant at Rabobank International, proposed separate ideal and current versions of Definition of Done for agile teams in his recent blog, in order to expand Definition of Done to grow in maturity and quality. Vos cites competence and maturity of the team as reasons why a team would use two versions.
Vos defined ideal and current Definition of Done as:
The ideal Definition of Done defines all steps necessary to deliver a finished increment from development till deployment in production. No further work is needed. The current Definition of Done defines the steps the team is currently capable of doing in one sprint.
Vos suggested making both versions of Definition of Done visible on the wall to increase transparency. Team and product owner can constantly work towards bridging the gap between both versions of Definition of Done.
Putting two versions on the wall will create transparency for the product owner. It represents the current capability of the team and shows what could be improved. The team can try to regularly expand the current Definition of Done with steps from the ideal Definition of Done. Expanding the Definition of Done will actually mean growing in quality and maturity.
Vos stated because of less maturity and competence of agile teams, Definition of Done doesn’t include all the steps necessary to deliver production ready code. Typically when finishing a sprint, different items are still left undone. The problem with this undone work is that it piles up every sprint and many teams solve this undone work by introducing extra sprint dedicated for release preparation.
Many teams solve this by introducing so-called "hardening sprints" or "release sprints." These sprints are used to, for example, create the deployment packages, solve some last bugs, do some final testing, and so on - everything to make the software ready for production. When the team defines a complete Definition of Done and applies it, all the undone work is done within the sprints and no release sprints are necessary.
A good Definition of Done helps with following points mentioned by Vos:
- Getting feedback and improving your product and process
- Better release planning
- Giving burn-down charts sense
- Minimizing the delay of risk
- Improving team quality and agility
- Creating transparency for stakeholders
David Lowe, agile coach at Net-A-Porter, supports the idea of having two versions of Definition of Done.
I think it's a clever idea: at least it accepts what the team knows it SHOULD be doing. Of course, how you move towards that ideal is another matter.
On similar lines Wouter Tengeler, owner of The Motion Studio Multimedia Productions suggests creation of separate user stories.
I would recommend adding stories that will complement the difference between the current DoD and the target DoD to make the (technical) debts visible. I would opt to add a story to write a user manual just to be transparent about the task so everyone knows that it is something that still needs to be done. When the team matures you will add the writing of the manuals to the DoD.
Dave Meyer, product marketing specialist at Atlassian explained how to use Jira, for managing Definition of Done over the period of time, in his recent blog.
A Definition of Done is a live document that should be reviewed regularly. As your dev team strives to improve, you can make your practices more stringent over time. Rather than deleting or modifying options, simply disable them. Disabling an option will keep the option in JIRA but prevents it from appearing on issues. This allows you to keep a record of your DoD over time.