During my first year as a developer I screwed up a lot.

Unintended changes made their way into my files seemingly at random. My commits broke existing unit tests. Sometimes I missed entire requirements because I didn’t read the story thoroughly.

In short, I wasn’t deliberate with my work because I did not have a definable, repeatable process. My lack of process cost my team time and money when they helped me fix things that I should have done correctly in the first place.

What my well-intentioned but directionless self needed was a consistent template to follow. One that clearly laid out everything I needed to successfully finish a story. On my next project, I discovered what my first team had been missing: a “Definition of Done”.

The Definition of Done is a concept created for the Scrum methodology, but it is useful to all development teams regardless of your project management framework. It provides a written set of events that must occur before a unit of work can be finished. Adopting a Definition of Done standardizes your team’s approach to completing work and ensures that all stories go through the same process, regardless of the people involved.

This standardization reduces mistakes and leads to a better product. Common issues like not having code reviews or unit tests go away because your work by definition cannot be completed without them.

However, enforcing the Definition of Done does need buy-in from everyone on the team. Just like team working agreements, you must create yours as a team and agree to follow it for every story. Without enforcement, a Definition of Done is as useful as not having one.

A note for developers: while the Definition of Done is often focused on development, it includes processes for everyone on your team. This is more than just a developer checklist. It’s an agreement among your team to create a process that delivers high quality solutions for whatever problem you’re tackling.

What goes in a Definition of Done?

Every team’s Definition of Done will be different, but most will include many of the following items:

• All styling is implemented in the proper location
• Views are clean and concise, with no complex logic
• Code styling conventions are followed
• Static code analysis produces no errors
• Proper patterns are followed in the implementation (MVC, MVVM, MVP, VIPER, etc.)
• Code is delivered to source control with the appropriate comments and tags
• Development is complete, meaning all tasks are developed and tested
• Browser and form factor testing have been completed
• Unit tests are written and passing
• Localization has been implemented
• Code is commented appropriately
• Logging is in place
• Any required documentation has been recorded
• Code has been reviewed by another developer
• All QA test scenarios pass
• Any bugs found that will be fixed later have been documented
• Automated testing has been created and passes
• Feature has been demoed to and accepted by the Product Owner

This list is not exhaustive, but the concepts have served me well across many different teams and technology stacks.

If your team doesn’t have a Definition of Done, make one! The standardization it provides will help you deliver high quality work while saving time and money. Use my list to get started and tweak it with your team to fit your style of work. Your future self will thank you.

This is the second of nine articles delving into the processes that every effective development team needs. Stay tuned for more!