The Scrum Guide says that everyone must understand what “Done” means. It sounds right, but let’s tackle it down.  There is a trend in the Agile software development project management practice community that states that “no requirement or piece of software can be considered DONE  until it is put to use”. This one sounds right at first, until you put to use any piece of crap whose committed changes build successfully on the continuous integration subsystem. G. Alleman points out that any piece of software should be related to a measure of effectiveness about the needed capabilities in the business case.

This point of view should pervade from the measures of effectiveness to the measures of performance of the software installed. The evidence of done  should populate the Work Breakdown Structure with a deliverables based description, or, at least, a deliverable column in the spreadsheet . This description must be clear enough for all actors involved. The technical terms should be widely recognised, or otherwise term clarification should be added.

Once the deliverable is clear, there are some environmental  or culture factors the project team should agree on. How products are tested, which is the required quality, who is accountable, these ones are corporate factors that must be understand by everyone. You could work for a business fond of “The Cult of Done Manifesto“, where laughing at perfection is welcome, or a pharma corporation that double checks everything or performs triple blind tests. But the meaning of done must be crystal clear for everyone. Do you agree? Not agree? Mmmm.

Check list

CC-by-sa Ben Brown