As a DevOps engineer, having a clear definition of done is important for several reasons. Also as a DevOps engineer, you want to code and minimize administration. Having participated in multiple projects at multiple companies, I can only give one piece of advice: Have a Definition of Done!

Why you should have a Definition of Done (DoD):

Clarity: A definition of done provides clarity on what is expected to be completed for a given task or project. This clarity ensures that all team members are on the same page regarding what constitutes a completed task.

Accountability: Having a clear DoD ensures that each team member is accountable for their work. By clearly defining what is expected, it’s easier to measure progress and ensure that each team member is completing their assigned tasks.

Quality: A DoD ensures that work is completed to a high standard. By clearly defining the criteria that must be met for a task to be considered complete, it’s easier to ensure that quality is maintained throughout the development process.

Continuous improvement: A definition of done can also help with continuous improvement. By regularly reviewing the DoD and making adjustments as necessary, it’s possible to continually improve the development process and ensure that tasks are completed to the highest possible standard.

Customer satisfaction: Finally, having a clear definition of done can help ensure that customer expectations are met. By ensuring that tasks are completed to a high standard and meet the criteria set out in the DoD, it’s easier to ensure that customers are satisfied with the end result.

Having a definition of done is crucial for ensuring that tasks are completed to a high standard, team members are held accountable for their work, and customer expectations are met. It helps to create a common understanding between all members of the team and ensures that everyone is working towards the same goal.

Here are some items that should be included in a DoD:

Code quality: Code should be clean, readable, maintainable, and follow agreed-upon coding standards.

Unit testing: All code should be tested with automated unit tests that provide high test coverage.

Integration testing: The code should be integrated and tested with other components and systems to ensure that it functions correctly in a larger system.

Acceptance criteria: All acceptance criteria for the user story or task should be met.

Documentation: Sufficient documentation should be created for the code, such as code comments, API documentation, user manuals, and technical documentation.

Code review: The code should be reviewed and approved by other team members, to ensure that it meets the required quality standards.

Performance testing: The performance of the code should be tested to ensure that it meets the necessary performance requirements.

Security testing: The code should be tested for security vulnerabilities and ensure that it meets the necessary security standards.

Deployment: The code should be packaged and deployed to the production environment, following established deployment procedures.

User acceptance testing: User acceptance testing should be performed to ensure that the user story or task meets the needs of the end-users.

Next time, when a manager asks if the user story is ready or done, do not automatically say ‘yes’, but remember the above 10 items :-)

Photo by Braden Collum on Unsplash