Definitions of Done in cloud application development

Picture the scene: A dimly lit office, cluttered with stacks of papers, crumpled post-it notes, and empty coffee cups. The room is filled with the sounds of frustrated developers typing frantically on their keyboards, while project managers pace back and forth, muttering to themselves. The air is thick with tension and disagreement, as everyone works independently, with no clear standards for quality or completion. A bug notification suddenly appears on the screen of one developer, causing him to slam his fists on the desk in frustration. Another developer chimes in, "Yeah, I've been trying to fix that for hours. Anyway, the client wants something different now…"

Okay, maybe it was never quite that dramatic but it’s a scene familiar to anyone who worked in the earlier days of software development. Many things have improved since then and one invention that has helped bring order to chaos, improved the lives of developers (and created happier clients) is the formalised understanding of Definition of Done or “DoD”.

Where did DoD come from?

The concept of Definition of Done (DoD) originated in the Agile software development methodology, which was first introduced in the early 2000s. The Agile Manifesto emphasizes the importance of delivering working software frequently, with a focus on collaboration, flexibility, and customer satisfaction. The Definition of Done was introduced as a way to ensure that everyone on the development team had a shared understanding of what it meant to complete a user story or feature.

Agile, DevOps and CI/CD for streamlined delivery.

One core benefit of having a well-defined Definition of Done (DoD) is that it enables a User Story or feature to be deployed into production without any further delay. This approach also aligns with our use of Continuous Integration and Continuous Deployment (CI/CD) and DevOps principles and, by automating the testing and deployment process, we can quickly and easily deliver new features and updates to our customers.

By having a well-defined DoD, we can ensure that each feature meets the necessary quality standards, which minimizes the risk of introducing errors or bugs into the production environment.

Further reading:

• DevOps in Scrum
• How to get started with AWS DevOps tools
• Fixing Integration roadblocks with CI/CD and AWS

Case Studies:

• Using CI/CD and AWS Lambda to develop better booking systems
• AWS DevOps automates release management

What is the DoD in practice?

The form that the Definition of Done (DoD) takes in practice can vary depending on the nature of the project but, in general terms, the DoD is a shared understanding among the team of what it means to complete a feature or user story to the required standard. It sets out the criteria that must be met before the work can be considered done, and it is used as a tool to ensure consistency and quality through the 3 distinct phases of Coding, testing and user acceptance.

The DoD typically includes a list of specific tasks or activities that must be completed, such as coding, testing, documentation, and deployment. It may also specify the quality standards that the work must meet, such as adherence to coding conventions or compliance with regulatory requirements. Additionally, the DoD may set out the criteria for user acceptance testing and specify the DoD for the specific product increment.

How do you identify checklist items?

It’s one thing to have a general idea of what needs to be done but the big secret of effective project management lies in creating an accurate and comprehensive list of required items.

Likewise, it’s usually easy to know what your own personal requirements are, but understanding and documenting what other people need — and communication your own needs to them — requires an organised and methodical approach. The following general steps are a core part of this process:

1. Identify stakeholders: This should cover anyone involved in creating and approving the DoD, including developers, testers, product owners, project managers, and other relevant team members.
2. Brainstorm checklist items: Stakeholders get together to suggest items, using techniques such as mind mapping or affinity diagramming.
3. Categorize and prioritize: These items are then arranged according to code quality, testing and documentation, and prioritized based on their importance.
4. Refine and finalize: The list should next be refined based on feedback and approved by all the stakeholders.
5. Communicate and enforce: After approval, the DoD should be shared with all team members and enforced via regular reviews.
6. Evolve and improve: In line with the general spirit of the Agile methodology, the DoD is not a static document and can evolve over time as the team learns and improves, serving as a tool for continuous improvement and supporting all other aspects of your agile process.

More than just technical requirements

For a programmer or someone with a technical background, it’s tempting to believe that the project completion criteria are primarily technical in nature, and would include things like:

• Code has been reviewed and tested.
• Automated tests have passed.
• Code has been integrated with the main codebase.
• Documentation has been updated.

However, non-technical requirements can be just as important — especially to the clients — and may include things like:

• The feature has been approved by the product owner.
• User acceptance testing has been performed.
• The feature has been demonstrated to stakeholders.

The exact criteria included in the DoD can vary from team to team and project to project, which is why it’s important to identify the correct stakeholders and to involve them properly in the generation phase. The DoD also helps ensure that all the people involved have a shared understanding of what it means for a feature to be "done" and can help prevent misunderstandings and delays as the produce process moves forward.

Benefits for clients and end users

As well as improving communication within the development team, a DoD checklist carefully crafted using the above processes can deliver a number of benefits your business:

1. Improved quality: The DoD helps ensure that each feature is thoroughly tested and meets the team's standards for quality. This means that clients and end-users will receive a more reliable and stable product that is less likely to have bugs or other issues.
2. Increased transparency: The DoD creates a shared understanding between the development team and stakeholders about what it means for a feature to be "done." This transparency can help build trust and ensure that everyone is on the same page regarding project progress and expectations.
3. Faster time-to-market: By having a clear definition of what it means for a feature to be complete, the development team can avoid delays and reduce the time needed for testing and debugging. This means that clients and end-users can receive new features and updates more quickly.
4. Better communication: The DoD encourages regular communication between the development team and stakeholders, which can help ensure that everyone is aligned and working towards the same goals. This can also help identify potential issues or roadblocks early on, allowing for faster resolution and a smoother development process.

Is DoD the definitive definition of Done?

Like any tool, the DoD has its limitations, and it's important for teams to be aware of these if they want to use it effectively.

1. Good DoD takes time: It can be time-consuming to create good definitions, and some team members may feel that it detracts from development time.
2. Limits to flexibility: Sometimes rapidly changing requirements or other unexpected circumstances can make it difficult to agree on good criteria that stay relevant long enough to be useful.
3. False sense of completion: Badly defined criteria can mean that people think something is finished when it isn’t.
4. You need to know what you want: Some types of software development projects actually benefit from unpredictability, such as R&D or experimental projects, and may not lend themselves well to a DoD approach.
5. DoD requires consensus and understanding: If the DoD is not clearly communicated or agreed upon by all stakeholders, it may not effectively guide development efforts.

DoD: A checklist for success

All this being said, Definitions of Done are a clearly useful tool and a central part of Agile cloud software development — especially if the limitations are noted and taken into account. When used correctly, they can help to ensure the successful completion of projects by establishing a clear and comprehensive set of requirements that must be met before a project is considered complete. By following these guidelines, you can be confident that you’re already on the road to success.