Nowadays there are many development methodologies and depending where you work they can change.
What it's true in your company can be totally different on mine, and the same agile will have for sure different interpretations, even inside the same company teams will interpret differently.
So in many cases each team creates a 'contract' that is usually referred as 'Definition of Done' or DoD.
My team is no different and we have one DoD, right know you can be asking yourself, do you really follow it? Let me tell you right away, no. I believe that the way we implemented is the reason it was forgotten or not followed, when it was presented to us this brand new DoD, ir was a must, like a dictatorship, "you must follow it, you are forbidden to push anything without all the requirements meet", this lead the team to stop using it soon we had to rush something.
We as Devs don't like dictatorship's, we like flexibility and we kinda coop well with it, instead of forcing this must be something natural and archievable.
So here it's comes some tips from a guy that say this failing 3x in less than 2 years.
1) Don't brute force DoD into your team, this is not a dictatorship
2) Just because everyone said that agree don't mean that they are fully onboard so be flexible
3) Let the team decide it's on DoD contract
4) Do not create separated DoD for ticket type, create one that can contemplate bugs, stories and tasks
If this previous steps are followed, the chance you get your DoD implemented and fully accepted in your team grows exponentially.
But now what should have a DoD? In my opinion it should be the minimum to go to production, in an acceptable time, so let me give you some bullet point here.
Ticket must be complete and with all information required, do not start if not
Write tests if possible (optional) here is where DoD fails most of the times, when working with legacy most of the times is not possible to write tests without a hug refactor, this will cost more money to the company than not writing them, also if it's a frontend application you should write end-to-end tests, legacy excuse do not apply here
If applies to your team, add some tracking, on my case when we develop new features we always add trackers, so be sure you do it if applicable
All ticket requirements must be meet
Code must be reviewed by other members of the team
Do not be a dictator but also make your team remember that your have a DoD and should be followed
This are some simple actions that can be part of your DoD, just remember to keep it simple and put the bare minimum that applies to your project and team, help others to follow and explain how good to have a DoD can be.
This was my first post, everything I write is based on my own experience and how I think the issues could be solved, please feel free to share your ideas and opinions.