I've been using SCRUM to manage my team for sometime now. When a new member joins the team one of the first things to get him/her up to speed is to get them aquainted with the team definition of "DONE". So here we go. When thinking whether or not a work item is "Done", ask yourself "Is this feature ready to be shipped?" if the answer is not a STRONG yes, then it is very likely the work is not "Done".
One basic principle we can follow when developing features and trying to complete work is:
-> IT IS OK TO BE BASIC, BUT NOT OK TO BE FAULTY
-> "Done" != "Done Enough"
-> "Done" = Shippable
A developer can say a work item is "Done" when:
- The case have specification and an entry with the specification in FogBugz (we use FogBugz for issue and bug tracking)
- The item was planned, designed and had an estimate (in time).
- Coding completed
- Code clean-up:
- Code was commented and checked-in
- Peer-to-Peer review happened
- Coding standards and code quality
- Code security review
- Hallway usability tested
- Unit tested (when there is a unit test sub-case)
- Wiki: Always have a wiki page documenting your feature and the components involved in it, like what tables, folders, configuration elements, etc.
- Release Notes: When configuration or deployment instructions change, it must be documented.
- Item was signed off by appropriate personnel and the FogBugz case was closed.
Some rules that apply to the definition of "Done":
- "Done" only applies to all user stories & sub-cases that also have children (in FogBugz)
- Only "Done" cases can be closed
- Only create Unit Test for items with a "Unit Test" sub-case.
- If the user stories has a "Unit Test" sub-case, then the unit test must be created prior to the actual implementation of the case.