Defining “done” is a remarkably important step if any Scrum team hopes to succeed and keep succeeding. It’s entirely too possible to overwork a solution or milestone without defining where the finish line is, and this is why Dhaval Panchal writes this article discussing what the definition of done means, why it’s important to define it for the team, and how to achieve success with a DoD. First, it’s important to understand that DoD is the “primary reporting mechanism for team members,” and that reporting is important for making sure work is completed as planned. Panchal notes, also, that it’s important to make sure the DoD is a living document. It will and should change during the life of the sprint and as the team removed issues it may be able to consider more activities than initially planned. Panchal talks to that as well as how to recognize the limitations of the DoD checklist here: It is important to note that the generic nature of the definition of done has some limitations. Not all value-added activities will be applicable to each feature since the definition of done is intended to be a comprehensive checklist. The team has to consciously decide the applicability of value-added activities on a feature-by-feature basis. For example, following user experience guidelines for a feature that provides integration point (eg: web service) to another system is not applicable to that particular feature; however, for other features within the system that do interface with a human being, those user experience guidelines must be followed. Panchal closes with this important note: the DoD checklist must be based in reality. If it does not reflect the “activities that can be realistically committed by the team”, it is useless.