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:


-> "Done" != "Done Enough"

-> "Done" = Shippable

A developer can say a work item is "Done" when:

  1. The case have specification and an entry with the specification in FogBugz (we use FogBugz for issue and bug tracking)
  2. The item was planned, designed and had an estimate (in time).
  3. Coding completed
  4. Code clean-up:
    • ReSharper is showing a green box in the code formatting column (HOW?).
    • FX Cop shows 0 warnings (HOW?).
    • Unnecessary commentaries removed
    • All TO-DO sections were removed
  5. Code was commented and checked-in
  6. Peer-to-Peer review happened
    • Coding standards and code quality
    • Code security review
  7. Hallway usability tested
  8. Unit tested (when there is a unit test sub-case)
  9. Documentation
    1. Wiki: Always have a wiki page documenting your feature and the components involved in it, like what tables, folders, configuration elements, etc.
    2. Release Notes: When configuration or deployment instructions change, it must be documented.
    3. Item was signed off by appropriate personnel and the FogBugz case was closed.

Some Rules

Some rules that apply to the definition of "Done":

  1. "Done" only applies to all user stories & sub-cases that also have children (in FogBugz)
  2. Only "Done" cases can be closed
  3. Only create Unit Test for items with a "Unit Test" sub-case.
  4. 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.