Testers do not define done, the customer (Product Owner – PO) does. The PO is also the one that determines if the acceptance criteria are met. Testers write the tests to ensure that the code and UI is meeting the acceptance criteria.

Acceptance criteria defines done for a story. If you don't have acceptance criteria, then “done” will never be accomplished, and the team is left coding forever.

As for test coverage, deployment to a test server, etc. – all of those items can be defined in the acceptance criteria.

-maybe meeting the acceptance criteria is not enough to finish story….
If acceptance criteria is not enough to finish the story, we should add it to our acceptance criteria. Some time it is not good to include every thing in acceptance criteria – and the development team will raise a technical task card associated to the user story.

During the sprint review, the product owner verifies that the user story is done per the acceptance criteria that he set up.

Your second question is a good one. It is up to the product owner to define the acceptance criteria, which can include that there is a certain level of test coverage, and that it contains documentation. For us, those are standards that we have imposed on ourselves, rather than our clients asking for it. Deploying to a test server (which should be a standard part of the development workflow) is a standard for us. That's how our clients can verify that the stories are in fact done.

Scrum is simply a process. To enable it, processes and other standard must also be put into place. Your second question hits on a number of them. Great stuff.

We always implement deployment as a separate user story (I don’t consider that updating builds to be part of deployment… its just something to do before you are done – or even before you can start).

My experience is that user stories really need a clearly defined exit condition or they will hang around forever. A criteria like “the implementation must be tested” allows developers to leave the story open for months (“I might add a few more tests…”) or to close it as soon as it “worked” one time.

If you must use unit tests as an exit condition, I think it must be explicit in what has to be tested. A given level of test coverage is not useful here, we have to know what exactly what functionality must pass the test before we can exit. Test coverage can not guarantee that the story\s functionality has been implemented (only that the tests visit all the lines of code).

During the sprint review, the product owner verifies that the user story is done per the acceptance criteria that he set up.

Your second question is a good one. It is up to the product owner to define the acceptance criteria, which can include that there is a certain level of test coverage, and that it contains documentation. For us, those are standards that we have imposed on ourselves, rather than our clients asking for it. Deploying to a test server (which should be a standard part of the development workflow) is a standard for us. That’s how our clients can verify that the stories are in fact done.

Scrum is simply a process. To enable it, processes and other standard must also be put into place. Your second question hits on a number of them. Great stuff.