(I'll add to this post more in the near future, but I wanted to get it started based on an email I answered for a student of mine.)

As for creating a definition of DONEness, my recommendations would be as follows:

1. Get as many different examples as you can find of DONEness definitions. The more material you have, the more complete your first version can be.

2. Recognize that the definition that you will create is a “version” – reviews of the effectiveness of DONEness should occur during Sprint Reviews and those discussions should lead toward modifications to the “official” definition of DONEness. You may even want to plan on a bi-annual review of DONEness to review what’s been added and to ensure that the definition is brief, concise, and clear/unambiguous.

3. Remember that DONEness definitions are how you drive quality practices into a Scrum team. For example, if your quality practices require code reviews or peer reviews of certain types of code, make sure that the DONEness definition includes this element.

As for the meeting itself, here’s what I would do (and figure on a day for this -- this is more of a workshop than a meeting):

1. Create subtopics for DONEness (product, technical, infrastructure, regulatory, etc.).

2. Get a good sized group together (20 or more people) from all areas of the company. Form them into teams around the aforementioned subtopics.

3. Set the goal that every team works for 90 minutes to create a list of DONEness from within their subtopic.

4. Take a break.

5. Get everyone back together.

6. Have a rep from each team review their list – give each team 10 minutes to review and 10 minutes for questions.

7. Discuss/debate/combine/simplify/clarify – 60-90 minutes

8. Merge the result into a single list.

Remember, in any meeting like this, your greatest tools are 1) setting clear goals describing the desired end result and 2) timeboxes!