Have you ever wondered about the meaning of DONE in DevOps? If you’re including DevOps in the definition of DONE, what are the agile changes that need to occur?

Fortunately, after working with many organizations exploring these questions, I’ve figured out that the answer isn’t that difficult.

So, what’s the meaning of DONE in a DevOps world?

Definition of Done in a DevOps World

DevOps creates the need for a lot of changes in the development process, not just from the technical aspect of continuous delivery, etc., but also with regards to agile. One of the aspects of agile that’s most interesting is the definition of DONE in a DevOps environment.

This isn’t a new problem by any means; people have been arguing about what the definition of DONE should be since Scrum became popular, and maybe even prior. As development teams begin to infuse DevOps practices, they need to rethink the definition of DONE. In the DevOps world, DONE doesn’t just mean it is coded and tested; it means it will work in production.

A few years back, at one of VersionOne’s AgilePalooza events, a tester asked a question that saddened me. She asked, “So what do you do when the story is done, but it hasn’t been tested?” I think a tear rolled down the cheek of each of the panelists as we had to explain, “it’s not done, if it hasn’t been tested.”

Fast forward a few years, and now we are in a world where most people recognize if code hasn’t been tested or the story is not done and stories are still missing the hooks for monitoring tools. There may be no way of saying, “It is not done until we know that it can be deployed safely and we can monitor its health while it is in deployment.”

In advocating change, I am suggesting the addition of DevOps requirements to your definition of DONE. I’m asking for you to agree that no story is done until the code has been written. And if you aren’t pair programming, then the peer review has happened, the tests are all passing, and the hooks for monitoring, performance evaluation and health checks are in as well. This is vital if you want to be successful with DevOps.

DevOps is all about moving quickly and deploying continuously. If you’re going to deploy continuously, you need to know that what you’re putting out is ready to go out. That means you have to be prepared for when the code meets the real world. You need to know right away if something bad happens when the code is deployed. You can’t wait until somebody calls and asks, “Why can’t I get onto your website anymore?” That is not good enough. If you deploy something, you have to find out before the customer does if something is not working right.

You have to make a few additions to stories to incorporate DevOps into the definition of DONE. The first step is adding the requirements to enable you to understand how the code is doing after deployment. Second, when you are planning a story, you’re going to need to estimate based on what it means to have the code in a state that will be successful post-deployment. Third, every single member of the team is a developer, and every single member of the team is a tester. Every single member of the team is now on the operations staff as well. That is where true success will happen in the DevOps world.


If you’re not fusing DevOps into your agile stories, you should start doing so right away. If you already are, make sure you’re including the hooks for monitoring, performance evaluation, and health checks as well.

What do you think about including DevOps into the definition of DONE? Are you going to start including post-deployment requirements in your definition of DONE?


Join the Discussion

    • Damon Edwards

      If we are talking mindset shift, take developers one step further…. it’s “done” until it’s been decommissioned/turned off.

      Unless you work for a packaged software company you are part of a broader team delivering services. That service runs until it is turned off. Then it is “done”.

      Have developers go through the mental exercise of banishing the word done. It forces them to rethink how they approach the code they write and interact with the larger system they are a part of.

      • Jason Clifford

        I agree with both Damon and Steve but maybe there are differences to clarify. A service is “done” when decommissioned but a feature/bug fix, for a service, is done when it can be tested, deployed safely and monitored as Steve said. Does it make sense to have that distinction?

        • Damon Edwards

          To be clear I was talking about a mental exercise. Of course any unit of work is going to have a beginning and an end.

          I was referring to going the extra mile to get developers into an “operations first” mentality. Delivering a feature is not the goal of the business. A running service (made up of a lot of features, none of which stand alone) that delights customers is the goal of the business.

          Evolvability/maintainability, deployability, configurability, scalability, resiliency, monitor-ability… all sorts of “-ilities” need to be top of mind when developers work. Getting them to think “operations first” and how you redefine done helps to ensure this is happening.

          • Jason Clifford

            Thanks Damon for the additional clarification and insight. Completely agree.

    − 1 = 9