Definition of Done

A user story is done if all of its identified tasks are:

 * implemented
 * reviewed
 * tested
 * documented
 * deployed
 * making the product owner happy

The remainder of this document details the parts of “done”:

Implemented
Implemented code adheres to the following principles:
 * adheres to the coding style guide
 * code is compiled and runs against the current “trunk” version in launchpad version control
 * code is commented according to the coding style guide
 * all FIXME/TODO tags in the code have been addressed. If they are not resolved (yet) the product owner has to explicitly agree that thy story still is “done”

Additionally, it must be possible to automatically build the implemented code. This will be accomplished by TAC Energy CI server, which automatically creates a binary release of the latest HEAD version from the code repository as soon as a code change is checked in.

Reviewed
Every task must be peer reviewed. There is no formal process how this should be done though we really like to use the default launchpad review functionality.

Just make sure that a colleague has a look at the changes you made an incorporate his / her feedback.

Tested
Make sure that all changes are thoroughly tested to keep overall code quality consistently high. For Java / Groovy Code this means:
 * Write unit tests for all non-supertrivial code
 * Make sure that Cobertura reports a solid code coverage for your piece of code
 * runs Cobertura automatically for you on your local machine
 * The TAC Energy Continuous Integration server will do so as well upon every detected code change in the launchpad code repository
 * Write integration tests to automatically test the end-to-end scenario described in the user story (involves creating / manipulating database objects, like e.g. persons, competitions, shouts etc.)
 * Write Selenium based tests if there is a web interface involved

Deployed
Code must be deployed on the production machine (currently http://ibwmarkets.iw.uni-karlsruhe.de)

Documented
The documentation must allow a reasonably knowledgeable person to understand the implemented code. To check this level of documentation, reviews should be usually handed over just pointing the reviewer to the code documentation (java / groovy doc) and / or the documentation in this wiki or generated through the grails documentation engine (check http://www.tacenergy.org/docs/latest/manual/index.html to see how generated documentation of the grails documentation engine looks like). In addition you have to clearly state licensing conditions whenever you use a 3rd party API or tool if that license is different from our currently used one (for TAC Energy this is Apache 2 License).

Making the Product Owner Happy
Ask the product owner (for the time being this is Carsten for the TAC Energy server and John for the TAC Energy client) on how satisfied he is with the implementation of the user story (best before the review and release meeting). Please note that we are not developing for ourselves or for the product owner but for the prospect competition participants that will use the framework to base their research upon!