DefinitionOfDoneAndTests

the team should have the responsibility to decide when the product is done

gilles mantel: for each user story consider "done" if all corresponding source code is in configuration management and the user story is deployed on acceptance platform and corresponding business model is captured in the wiki (whatever format) and at least 80% code coverage by unit tests with tools.

making all requirements measurable and see if everything is testable and; fully acceptance tested and released.

electric cloud ("eat our own dog food") - the skunk goes on your desk if you break the build and fail to follow the right process. pre-commit automated test. whem we release the product and number of open bugs and severity, do they have high likelyhood to manifest ; known defects.

user stories validated; but integration phase on the end. if integration is challenge then switch to feature-oriented teams. painful at first (esp with legacy) but pays off on the end.

AM talked about a model where off-shore partners got integrated better: - getting key off-shore people to come by and work onsite, - send on-site people off-shore to work - video conferencing, pairing over webex to promote pairing and better work integration

AM: It was considered done when the team shows it to the customer. The team and the customer need to agree that the spirit of the story is complete. initially agree at the beginning of an iteration (examples), not a contract, just what people currently think. This gets reviewed regularly (after each story is implemented).

Done might have a different meaning for projects which are already in maintenance. Late in the project, you also need to tell operators what's changed etc.

AM: when it feels right for everybody that matters

the important thing is that we had a discussion to have an understanding what a done is; checklist is there just to have a discussion.

if your customer thinks that the project can be shipped now.