Many times as a software professional we all go through turmoil of "My work is done" or "Your work is done" or "That work is/was done". Many times it leads to unnecessary friction between teams as to the work is done or not. One of the major reason behind this is a loose definition of when the work is actually termed as "DONE" or no common understanding or common grounds on "Definition of Done".

Now the next question arise is why we need to answer the "Definition of Done" question, well there are many reasons but some of them are:

Of course "Definition of Done" depends on many factors and so there is no standard definition for it. Its as per Organizatio's specific set of needs it can have its own "Definition of Done" standards.

An important distinction between Agile estimation and traditional estimation is that Agile estimation is based on completed functionality that has been coded,tested, reviewed, and accepted so that there is no ambiguity if it is complete or not. In a traditional approach, sometimes testing or any rework that might be needed based on user acceptance testing is not included. As a result, an estimate might be misleading.

I tried to list down below some relevant points for Developer's version of "Definition of Done" which can be agreed upon commonly by teams or team for when the work/task is consider as "DONE". Make a note there is no standard definition for "Definition of Done", so we should define it as close as it would be help to our projects.

In a services context, it might look something like this: "Done means every task under the User Story has been completed and any work created is attached to the User Story so the Product Owner can review it and make sure it meets his or her expectations." - Scrum Inc.