It’s not uncommon for pseudo scrum teams to not have a precise definition of what it means to be DONE. You may have a developer thinking that a feature is “done” once the functional development is complete, but when QA gets to it, they’ll have to raise necessary things like, why is it so slow, or why is it not secure. Such a disconnect will inevitably lead to a long and painful back and forth, and the product owner must then make a trade-off decision to make the release date (i.e., choose the best of the worst options).
The following are some approaches to making sure that the whole team knows what the Definition of Done is:
Define what Done means in your context (this might be an obvious step..but just in case). The Scrum Alliance has many articles on how to do this, but some basic ones include:
a. Code complete
b. Unit tests run
d. QA tested
e. Product Owner Reviewed
f. Follows FURPS
Create posters and put them up on walls around the development area. Putting up such signs may sound hokey, but it works.
Create a “Done” dashboard. In cases where you have a release plan, you can create a Dashboard with themes and use two colors, Green for Done and Red for Not Done.
Here is a basic dashboard in PPT, but you can use any tool like post-it notes on a wall. The whole point is to make progress clear.
Although setting a definition of done may sound odd, it’s a valuable tool to reduce ambiguity, especially in newly formed scrum teams.