The evolution of Definition of Done (DoD) from zero to DevOps

How did user stories acceptance criteria evolved over time? And its relationship with DevOps

3 min readSep 22, 2019

The journey of the DoD started with a humble code committed all the way to code in Production with data collection to prove the hypothesis that give birth to the release. And even further. The meaning of done is completely different in the DevOps era compared to early days.

DevOps is a combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.

The DevOps model main goal is to reduce friction in the development pipeline. Also is oriented towards how quickly you can fix issues in Production (‘mean time to recovery’ or MTTR) rather than reducing the ‘mean time between failure’ (MTBF). And this impacts the way we perceive Done-ness of a feature/user story. We should aim to always be continuously and actively improving Software Engineering capabilities including processes, practices, tools and of course people.

Each new criterion added to the definition has increased the level of maturity in the process. Some criteria is shared by the whole Software Engineering community and others are optionally included depending on several circumstances such as product being built, CI capabilities, deployment frequency, and so on.

The following task-oriented items are usually part of a user story DoD (depending on the situation):

Code reviewed
Code committed
Tests (unit, integration, functional, etc) passing
Code shippable to Production
Code shippable and in Production
Code in Production with monitoring in place
Code in Production with data collection to prove the hypothesis that give birth to the release
Architectural fitness functions verified
Product Owner accepts user story

The list can be endless and will depend on each product and team particular situations.

Where are we?

Let’s now expand this idea into a DoD Maturity Model. Not as a way of bringing strictness or rigidity; rather a way to assess the question “where are we?”.

Martin Fowler defines maturity model as:

A maturity model is a tool that helps people assess the current effectiveness of a person or group and supports figuring out what capabilities they need to acquire next in order to improve their performance.

Let’s imagine 5 levels where level 1 is complete anarchy and level 5 is full efficiency.

Level 1. No definition of done / regressive

Each developer determines that the piece of work is finished when he/she thinks it is finished based on his/her experience. Hopefully, code is committed into a source repository and backed up regularly.

Level 2. Repeatable but not all treated equal

Expectations are documented or partly documented so most user stories have DoD. However, in same apps it is not applied due to different circumstances such as legacy code, not enough time to do it properly, etc.

Level 3. Defined and consistent

Expectations are documented and well defined hence all user stories have the same DoD applied. It is not as much how many ingredients each cake has but rather all cakes being equal and tasting the same. Nevertheless, I would expect Production-ready code coming out of automated pipelines after every change is committed at this level.

Level 4. Capable and measurable

Build metrics gathered, made visible, easily accessible to everybody and acted upon. Architectural fitness functions are part of the pipelines. Complex deployments with several apps are orchestrated and rollback is available.

Level 5. Efficient and optimizing

Highest level of maturity. All previous levels have been achieved and we are continuously and actively improving processes, practices and tools

Conclusion

DoD has changed over time for good reasons. Processes are more robust and quality of code is higher. DevOps has influenced significantly on this evolution for good reasons. I expect this trend to continue for the benefit of all Software Engineers.

References

[1] The Agile Maturity Model By Jez Humble and Rolf Russell

[2] What we learned moving 65,000 microsofties to DevOps on the Public Cloud by Martin Woodward

[3] Definition of Done by Derek Huether

[4] The Definition of Done: What does “done” actually mean? by Danny Smith

[5] Maturity Model by Martin Fowler

Disclaimer

This is a personal article. The opinions expressed here represent my own and not those of my employer.