Done Means Done Means Done. Your Definition of Done

Your Team's Definition of Done

Do you have a Definition of Done? Or does your team say things like: “It’s done, but I just need to push it to production”, or “It’s done, but there are a few little bugs we will need to get to later”, OR “It’s done, but when you cut into it, it goes Moo!”

Does Done mean Done for your team? Successful Agile methodologies demand that teams work hard to speak a consistent language at all levels of your project. We spend much time in refinement, planning, review, and retrospectives trying to ensure we effectively communicate with everyone involved in a product. Few things are as crucial to the success of a project as everyone understanding and articulating what Done actually means.

The “Definition of Done” is a standard list of criteria used across all Product Backlog Items to ensure to everyone involved that when we say something is done, it is actually done. It is used to ensure that all team members have a shared understanding of what constitutes completion of a task or Product Backlog Item.

Here are a few things to consider when creating your team’s Definition of Done.

What Level of Testing should be Done?

What level of testing should be done?

Testing is an essential component of software development, and Test-Driven Development (TDD) is a popular approach that allows teams to build more stable and reliable systems. But, how many acceptance tests should your team expect and what are the standards for testing? These are questions that should be answered in order to have a clear, consistent expectation of the level of testing.

When it comes to acceptance tests, it’s important to have a clear understanding of what constitutes a successful test. This can vary depending on the project and the specific requirements, but it’s generally a good idea to aim for a minimum of 80% coverage. This means that at least 80% of the code should be covered by acceptance tests. However, the exact number will depend on the complexity of the project and the risk involved.

Furthermore, it’s important to have a set of standards for testing that all team members understand and follow. This can include things like:

– The types of tests that should be written (e.g. unit tests, integration tests, acceptance tests, etc.)

– The level of detail required in test documentation

– The tools and frameworks that should be used

– The browsers/devices that the code should be tested on

Additionally, it’s important to establish a clear process for determining when work has been completed. This can include a code review process, where other team members review the code and test results before it’s considered complete. It’s also important to establish target performance levels for the code and ensure that it meets those standards before it’s considered done.

In summary, having a clear and consistent expectation of the level of testing, including the number of acceptance tests and standards for testing, is essential for building stable systems. Establishing a clear process for determining when work has been completed and setting target performance levels can also help ensure that the final product meets the desired level of quality.

Where should the code go?

Where should the code go?

Where will your Product Owner go to use your Potentially Shippable Release? If you are using tools like CI/CD or DevOps then the approval and review process will be baked into your development process. Regardless, everyone needs to know where your final releasajble product will be made available before you can call the work Done.

If you are on a technical team, then you really should be using DevOps or DevSecOps as part of your process. One of the key aspects of DevOps is the integration of development and operations teams, and this includes a focus on automating the build, test, and deployment process. By using CI/CD tools, teams can automatically build, test, and deploy code as soon as it’s pushed to the source code repository. This means that the release is always available and ready to be deployed.

For a software team, It’s important to ensure that your team has a clear process for deploying code and that everyone knows where to find the release. This can include things like:

– Establishing a central location for storing and accessing the release

– Automating the deployment process

– Providing clear documentation on how to deploy the code

– Making sure that the right team members have access to the release

In addition to knowing the level of testing and where to get their hands on the release, Product Owners must also know the process and tools that are used to deploy the code. This includes the environment where it will be deployed, the tools and frameworks used, and the target performance levels. Adding this information to your Definition of Done will ensure a consistent process when it comes to testing and deployment, and it will help the Product Owner understand the readiness of the release.

In summary, CI/CD practices and DevOps approach are essential for modern software development teams. By automating the build, test, and deployment process, teams can ensure that new features and bug fixes are delivered to users as soon as possible. However, it’s also important to ensure that everyone knows where to deploy the code and how to access it. This can be achieved by establishing a clear process for deploying code and by including information about deployment in the Definition of Done.

How Should the Work Be Documented?

How should the work be documented?

Documentation is an important aspect of development that is often overlooked. It is an essential part of ensuring that work product is readable, maintainable, and understandable by others. However, the level of documentation required can vary depending on the company and the specific domain. Some companies may rely on in-code documentation, while others may require full Software Development Kits (SDKs) with detailed documentation.

Regardless of the level of documentation required, it’s important to make sure that your team knows the expectations. This can be achieved by setting clear guidelines for documentation and by including it in your Definition of Done. The Definition of Done should include the types of documentation that are expected, the level of detail required, and the format in which the documentation should be presented.

If documentation is part of the expected work product, it should be included in the sprint and treated as a deliverable. This means that the team should be given enough time to create and review the documentation during the sprint, and that it should be included in the acceptance criteria for the work item. By including documentation in the sprint, teams can ensure that it is completed on time and that it meets the desired level of quality.

Additionally, it is important to have a process in place for maintaining the documentation. This includes making sure that the documentation is up-to-date and that any changes to the code are reflected in the documentation.

In short, documentation is an essential part of development and should be considered in your Definition of Done. The level of documentation required can vary depending on the company and the project, but it’s important to make sure that your team knows the expectations. If documentation is part of the expected work product, it should be included in the sprint and treated as a deliverable. By setting clear guidelines for documentation and including it in the Definition of Done, teams can ensure that it is completed on time and that it meets the desired level of quality.

How do you set your team's Definition of Done?

How do you set your team’s Definition of Done?

Much like you setting your team’s Definition of Ready focuses on Individuals and Interactions, setting your Definition of Done is the same. If you are just launching a team, then your team’s Definition of Done should be set early and iterated on often. If your team has been around a minute but doesn’t have a clear Definition of Done, consider using your next team Retrospective to set this important criteria.

Curious what this might look like? Here is a copy of CAVU’s Definition of Done. We use this for all of our teams, regardless of their product. If they aren’t producing software-based deliverables, the checklist is modified for the domain, but we keep to the spirit of each criteria. By doing this, everyone at CAVU has a clear understanding of what Done means.

Your Definition of Done is Never Done

A well-defined Definition of Done is crucial for the success of any Scrum team. It sets clear expectations for what constitutes completion of a task or Product Backlog Item. But, it’s important to remember that your Definition of Done is not a one-time task. It should be revisited often and updated as your team continually improves.

Consider incorporating a review of your Definition of Done as part of your team’s Retrospective. This will allow your team to integrate their learning and development into the definition, making it more effective and reflective of your team’s shared understanding. By doing so, you can ensure that your Definition of Done remains relevant and up-to-date.

In summary, a clear and consistent Definition of Done is essential for the success of any Scrum team. It helps ensure that everyone involved with the team has a shared understanding of what constitutes completion of a task or product backlog item. It should be revisited often and updated as your team continually improves and include testing, deployment, and documentation in their Definition of Done to ensure a consistent process and high-quality deliverables. By doing so, you can make your team more efficient and productive.

Related Articles

Responses