Improving Process with Two Definitions of Done

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.

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.

This is an interesting write-up about how teams can use the Definition of Done, thanks!

The DoD describes how the team develops products, their wy of working. When teams improve, for instance by doing retrospectives and taking action, the DoD should be updated to reflect this.

Christian Vos suggests that when the team becomes capable of doing more activities in an iteration resulting in a product that's potentially shippable, then activities should be moved from the ideal to the current DoD. This is a practice that can help teams, but there are some things to be aware of:

- Moving activities from the ideal to the current DoD is not the only way that teams can improve.- Retrospectives can reveal improvements that are not yet mentioned in any of the DoDsand which are stil valuable for the team.- The ideal DoD should not be static but should be updated when the team suggests improvements in their way of working that they are not already capable of of doing in an iteration, but can do in hardening or release iterations.

Having a vision of what to improve in iterations with an ideal DoD helps teams, but it shouldn't limit them in looking what needs to be improved in a next iteration.