Les Cunliffe - Fotolia

Problem solve Get help with specific problems with your technologies, process and projects.

It's past time to revisit Agile's definition of 'done'

The definition of 'done' only covers what happens on the dev side. So, it's not very useful in a DevOps shop. Expert Theresa Neate explains what needs to change.

The definition of done has received much focus since its first mention in 2002.

The explicit completion/done criteria mentioned then were as follows:

  • Are all aspects of the story done?
  • Is the code as refactored as possible?
  • Is there an acceptance test?
  • Do all acceptance tests for this story pass?
  • Have we explained to the customer (or quality assurance, etc.) how everything works?

XP and Scrum experts Jeff Sutherland, Ron Jeffries, Bill Wake and Ken Schwaber have said and written much to clarify the topic and influence the breaking down of our work into actionable chunks. As a quality assurance (QA) professional, my job-satisfaction and efficiency directly benefited from this evolution, and I read and watched and listened to their materials with fervor.

The definition of done was critical in my output as tester -- what was delivered was agreed-upon, deliverable, measurable, testable and all the other fine "-able" qualities. Consequently, I became an enthusiastic participant in all discussions where done was topical.

In those pre-DevOps times, none of us realized that in our definitions of done we routinely missed the point that pre-DevOps Agile missed: operations! We never included operability criteria in the definition of done!

A new definition of 'done'

As we know, with the advent of DevOps around 2007/2008, development and operations teams began to work more closely together on Agile infrastructure, automation of repeatable work and collaboration around on how to better serve each other. The goal is to deliver better quality and high-value systems more quickly.

The traditional Kanban wall remained, though, with "Done" still lurking as the last column.

As we still treated it, however, "done" was still only "development done." The other half of DevOps was still not explicitly included and defined in that.

I have alluded to ops' exclusion previously. I originally wanted to title this article "Done is no longer done," but I realized that that may unintentionally disrespect the hard work of those I've just mentioned.

DevOps done
Definition of 'done' for DevOps means getting both development and ops set.

However, I still want you to seriously consider the definition of done, as it now applies to DevOps, and what completion (of each increment) really looks like.

Items to now possibly include in the definition of done could be, but aren't limited to:

  • Have all forms of feedback, including continuous integration, been satisfactory? Have changes even integrated back to trunk?
  • Have we built in monitoring and alerting (telemetry)?
  • Is infrastructure (relevant to this story) tested, too?
  • Where relevant, have security measures been applied?
  • Has it been successfully deployed? (To production?)

DevOps means 'delivery'

If we define these, it may help to reduce significant rework (aka waste) when the story or code hits trunk or production in the real world.

Just remember, even though the original definition of done was pre-DevOps, it was always about delivering value to customers. Bear in mind that value to the customer starts once delivered to production, not when ready to be delivered to production.

So, to each software development team, each developer, product owner, business analyst, tester, operations person and other key players: Have a look at your definition of done, and consider how the operations or operability aspect of DevOps should be applied to them.

This was last published in May 2018

Dig Deeper on DevOps and SysOps

Join the conversation

3 comments

Send me notifications when other members comment.

Please create a username to comment.

Has your organization tweaked the definition of 'done' to include operations?
Cancel
I find this is very interesting. We definitely want Done to include a lot of things. We at the same time want to have Flow, small cards to move through the wall. We don't want "big" cards that remain on the wall forever, so naturally we cut the cards up in terms of tasks of what needs to be done: feature on one card, monitoring & alerting on another one. Then what is the definition of done on each card? Should done be applied to Epic card only?
Cancel
In my view yes, we should apply Done to Epic cards. If a card is getting too big, I suspect the bulk comes from slicing horizontally, not vertically. The cake slicing metaphor can be helpful here: https://www.thoughtworks.com/insights/blog/slicing-your-development-work-multi-layer-cake
Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchITOperations

SearchMicroservices

TheServerSide.com

SearchDataCenter

Close