“Done, Done” in Agile

A user story is done after it is implemented by developers and verified by testers/business analysts. However, it is not “Done, Done”.

This article is one of the “IT Terminology Clarified” series.

The definition of “Done, “Done” varies across ‘Agile’ software teams.

Done Done
“We’re done when we’re production-ready” — The Art of Agile Development book

I have seen many ‘fake’ agile coaches or ‘fake’ scrum masters talk about different versions of “Done Done”, such as

• “Unit tested”
• “manual tester verified against the acceptance criteria”
• “passed business analyst/customer review”
• “the user story is marked ‘done’ in JIRA”
• “the feature is deployed in production”

In my opinion, none of the above is really “Done, Done”. When I told my definition (see below) to many colleagues/friends, I don’t remember a single disagreement.

“Done, Done” for a user story in Agile

After the end-to-end automated tests passed and are verified by the business analyst or customers, and the new automated tests are included in the automated regression suite, which are run frequently (multiple times a day) in the Continuous Testing server.

— Zhimin Zhan (practised this since 2006)

I read this book recently, good to know I am not the only one that links “Done” of User Stories to Automated End-to-End Testing (verified by business analysts).

The logic is quite simple. The nature of software is that many features can be easily broken by another check-in. Don’t we see it too often? If the broken features are in production, surely it is not “Done, Done”, right?

The below is an excerpt of a newspaper article on a government project, its initial budget was A$50 million, but end up costing the taxpayers over a billion. (“QLD Health payroll bungle to cost $1.25 billion”)

“Our wonderful CorpTech has done another ‘system fix’ and that has created all these other problems!!!!”, a QLD Health payroll client…