We have a starting team using scrum and we understand the value of establish a clear "definition of done" in our development. We have selected the set of things or processes a task must have to consider "done", but actually we have no clear way how to address it.
Must we put the definition of done in in all task's acceptance criteria; set as sub-task that we must complete or just address it as a some documentation related to this product that everyone have to know?
The traditional Scrum solution would be to ask the team. Since the Scrum Team is self-organizing, much of the specific methods to do things should be left up to the team, with the Scrum Master coaching the team to ensure that the values, principles, and intents of the Scrum Guide are maintained.
In practice, I would favor some kind of lightweight documentation over assigning it to every task or Product Backlog Item in a ticket tracking tool. Unless you can automate the process a good deal, it seems like putting your Definition of Done in a task or ticket tracking tool would add a lot of overhead and end up making tracking work more difficult. A wiki page, or something similar, can get the information down so that way the whole team can refer to it, and can be changed over time as the team enhances their Definition of Done over time.
Something I would add to support the other answers here is that it may be the case that the Definition of "Done" (DoD) is not wholly 'owned' by the Scrum Team:
When a Product Backlog item or an Increment is described as "Done", everyone must understand what "Done" means... If the definition of "Done" for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum... If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of "Done". - The official Scrum Guide
I would suggest "everyone" who is interested in quality encompasses not only the development org but additionally the stakeholders. Therefore, it is probably necessary to make the DoD accessible to all parties.
On a practical note, I've found a DoD in the form of a checklist most useful. This way, the DoD items can be checked-off when a Scrum Team member verifies a Sprint Backlog item as being "Done". Therefore, have the DoD in a format where it can be easily shown on a screen or printed to a sheet of paper.
First I agree with what others are saying about the team setting the defintion of done. You need to get that buy-in and shared understanding if you are going to be successful in implementing DOD.
There are two ways we are addressing the definition of done. One is from a workflow perspective (a la Jira boards). We initially started as code complete was Done, but as out CI deployment capabilities improved, we moved that to In Production. This works for 90% of our work which is based on coding against an existing product where we are modifying something that is already functioning in production.
For SPIKES or Stories that are progressing to MVP, but not production ready, we spend more time on documenting Conditions of Acceptance (COA) as these tasks aren't going to meeting the workflow definition of Done in Production.
Examples would be: Document research findings on Wiki page Diagram future state architecture and document approval from CTO
If they are observable, concrete deliverables, then there should be very little ambiguity in whether or not the task meets the criteria.
Doing it, and getting it done, are not separate tasks (or subtasks).
A backlog can consist of nothing more than definition-of-dones. Often is is vaguer, and this definition is created in the sprint, then it is done. These two activities should not however appear as two tasks.
You may have disagreement of what done looks like. I may argue for Test-Driven-Development, the rest of the team may argue for something less rigorous. Shouting loudly will not work. Therefore I will accept the teams definition, but will track to so if features are revisited. If we are revisiting features too frequently, I will show the team that our definition-of-done is not working. (There may be other reasons to re-evaluate definition-of-done. E.g. Increasing technical debt, and fear of refactoring.
Adding one of the representatives of the clients to know the progress and validate the task done can increase the transparency and refine definition of Done task.
