Best practice and benefit of having "Definition Of Done"
Best practice for defining "Definition Of Done"
The best way to come up with a Definition of Done for your team is to sit together as a team and come up with a checklist that the whole team agrees upon.
Ask the questions, "What tasks would we always want to do?" and "What kind of checks would we always make?" before pushing code to real customers ("pushing to production").
Benefits of Having a Definition of Done
The details are as following:-
A checklist exists to make sure only high-quality work is released to real users.
Team members will have much less reason to argue over what "done" means.
User stories typically get finished (i.e., "done") before more are started. This means fewer items that are "works in progress" and more user stories are released to real customers.
Measuring "quality" becomes part of the weekly/monthly routine.
Fewer items get "pushed back" into development because they only "make it out" of development when they are genuinely ready.
Video here to explain it better.
Consider any previous times that some team members referred to work as "done" but other team members felt that it was "not done." What were the differences? Are those items that should be added to your Definition of Done?
If you have a dedicated Quality Assurance (QA) team that does all the testing of your products before release, what do they consider as important?
Many teams write automated checks (or tests) on their codebase so that they know if some new code breaks any of the logic of the old code. If you have automated tests that run on your codebase, you will probably want to include that "no new code breaks any old code." All tests should pass!
Do you have any automated systems that run on your code? Some tools like Code Climate can even provide you with a quality score and can scan your code for bad practices, such as repeated chunks of code! If you have such tools, they can be incorporated into your Definition of Done.