These are the words of somebody trying to explain what it mean “DONE” in his team context:
When you have completed work on your currently assigned Sprint Backlog Item, you must ensure that “it is done” before assigning it to the Tester. The definition of a Sprint Backlog Item being done is:
* All facets of the Sprint Backlog Item are satisfied (including creative content such as images / general design)
* Test cases have been updated – or if it’s a new feature – created.
* The code is fully commented – not just method headers – write “the whys” behind your reasoning.
* You have created a unit test where possible – this can either be a normal unit test or a WATIR script
* You have run a Dev Build and it has completed successfully
* If you’ve worked on a new feature or a complex bug fix – you’ve done a buddy build and got your buddy to do a code review.
* You have linked the Source Control ChangeSet to the Sprint Backlog Item
* Once your Sprint Backlog Item has fulfilled these criteria – ensure that the state field of the Sprint Backlog item is “In Progress” and change the “Owned By” field to the user id of the Tester. Once the Sprint Backlog Item has been tested and passed it will be marked as “Done”.
If a bug is discovered a new Sprint Backlog Item (with Sprint Backlog Type set to “Bug”) will be created, linked to the original Sprint Backlog Task and then assigned to the developer who created the feature. This cycle should be repeated until all Sprint Backlog Items are marked as “Done” and are ready to be deployed in the next release.
Ok, but all of us could complain telling “hey this is a kind of mini-waterfall” embedding in Scrum framework, and all of us would be right, but it’s not prohibited to do it in the explained way.
However my intention was also try to explain that done means those things that the team decided and conceptually this meaning will help to the team to generate the best work team process.