What is Done Criteria in Agile

Image Courtesy of www.freedigitalphotos.net

One of the primary reason why we have delayed iterations or troubled projects due to poor quality is either unclear definitions of "Done" Criteria or ineffective adherence to the "Done" criteria defined for an iteration or for stories. It would be so nice if we don't have to come back to a finished story to complete pending tasks like code coverage completion or refactoring tasks or any other. A completed story is not a bunch of unintegrated, untested code. It's ready to deploy..
There are various kind of stories. The challenge is how to define the
 done criteria for each story. Just to give an example of the different kind of stories that is applicable in a typical project :

• Functional Stories (most common)
• Spike Stories
• Refactoring Stories
• Code Quality Improvement Related Stories
• Test Design Improvement Stories
• Test Execution Stories

and so on..
Defining the right done criteria is half the battle won. For Example- Identifying the right set of acceptance test cases for the functional stories and ensuring that after the story completion, all the acceptance test cases passes is the right application of the done criteria for the functional stories. Partially finished stories result in hidden costs to the project. When it is time to release , the project may have to complete an unpredictable amount of work. This completely destabilizes the release planning and prevents from meeting the project commitments.

The million dollar questions is What does it take for a product to be "done done". Well, this depends on the organization and the kind of project you are operating. However the main point is that a story can be considered done only if the customer can use it as intended. In this post , we would provide list of key aspects that can be covered for a typical functional story:

• All code written and code review completed. All the code review comments are tracked to closure.
• Code refactored to the team's satisfaction.
• All the required testing (Unit Testing, Functional Testing, Integration and Acceptance Testing) is completed and all defects (if any) are closed.
• The story is integrated with the continuous integration system and the CI is green. The story works from end to end- typically, UI to database- and fits into the rest of the software.
• Line Coverage , Function Coverage, Branch Coverage (if the team uses this metric) meets the set expectation (the expectation may change depending on the project. Ideally we try to meet 100%)
• All the static code rules (eg, Checkstyle for Java) is run and there is no coding rule non compliance. If at all there is any non compliance, it is reviewed and actions taken accordingly.
• If the story is developed in main flow of system operation, then the relevant non functional testing is completed. (This can also be taken when a cluster of stories is completed in present iteration or future iterations).
• All the known defects are fixed.
• Customer agree that the story is finished.
• Documentation (Technical Writing) completed.

The above list can be used for any functional story with application of this in the specific context of the project. Similarly for other kind of stories, there may be different done criteria which need to be applied.  If a team wants to give successful project delivery, then the done criteria need to be rightly defined and need to be followed - of course, with no conditions. Playing Stories for incomplete tasks for a story in present or future iterations are signs of an impending danger. So beware of it and take timely actions.