As a scrum team working agreement, the definition of Done is the scrum team’s commitment to ensuring their product increment is shippable and usable every sprint. It’s essentially the checklist used to validate that what has been completed by the team is releasable.
At a minimum, the definition of Done list will include consideration for three areas of focus:
- Environment: Has the team completed work in at least the QA environment (or whatever environment reflects what the live or production environment will be)?
- Testing: What tests are required to run and pass? This can vary depending on your standards and may include unit, functional, exploratory, integration, regression, usability, etc. The more you automate, the higher your confidence will be that you have adequate coverage of your product to ensure the increment for the sprint is truly releasable.
- Documentation: What are the appropriate types of documentation you need for the work to be considered complete?
Creating a list to cover all this may sound daunting. However, once you understand how to use it and see a few examples, it will all make perfect sense. Bottom line, you want to ensure when your team says a product backlog item is complete, the team can claim their scope of responsibilities met and release the work if the value is there.
Agile values and principles
When talking about the value of the definition of Done and how it improves the development process, you can look deeper than the scrum framework to the 12 principles of the Agile Manifesto. Consider these three principles as valuable reasons to develop and implement a definition of Done for your teams:
- Working software is the primary measure of progress.
- Businesspeople and developers must work together daily throughout the project.
- Continuous attention to technical excellence and good design enhances agility.
A list of bullet points to validate work completion brings focus to ensuring tangible progress delivering a working, shippable product at the end of each sprint. The items in your definition of Done also enhance business and development team collaboration by providing clarity to the full scope of what they’re working to deliver to the customer. There is shared ownership and understanding of expectations.
Collectively, the refinement of what’s included in a shippable product also improves technical excellence by increasing consistency and quality. Validating is critical in several scenarios, including peer-review of work items and updating end-user documentation. Doing these things confirms that you don’t overlook essential components of each deliverable. Delaying these things leads to not having releasable increments.
When to use your definition of Done
Your definition of Done should be available for reference all day, every day, as it informs every aspect of the work.
During product backlog refinement activities, referencing your definition of Done supports viewing each work item from multiple perspectives. These perspectives include testing and documentation, which results in conversations and clarification of the work for improvement.
For instance, having the definition of Done front and center during estimation discussions helps the team consider all types of work required when estimating product backlog items. Don’t forget all the testing necessary to evaluate each item shippable when calculating.
Sprint planning is another crucial time to reference on your list. As your team discusses each item and creates tasks, the task list should directly reflect the checklist items from the team’s definition of Done. Having shippable functionality at the end of the sprint doesn’t just happen by itself. Tests don’t get written and pass on their own. Wikis don’t update themselves, either. It requires deliberate attention to those items. Getting to Done on planned items in the sprint starts with proper sprint planning.
Finally, during the sprint itself, as individual work items move toward completion, the list is an invaluable tool for confirming that critical actions for work to be shippable aren’t forgotten.
How to build your initial definition of Done
Start by identifying the overarching activities that frame the delivery of your product backlog. Next, add items to your list that represent those activities. Remember, the definition of Done is a tool that shapes the work’s boundaries, but it does not need to be an exhaustive list. You can look to technical standards and test strategies for inspiration.
At a minimum, give consideration to the work environment (usually at least QA), which types of testing must pass, and documentation necessary to consider work complete. More specifically, considerations can include the following activities:
- Design: Completing design reviews and documentation and architectural and integration reviews.
- Unit testing: Ensuring that each component of the code delivers the desired output.
- Functional testing: Determining that each work item or component performs as specified.
- Integration testing: Confirming that individual components also work in conjunction with the greater whole in which they operate.
- Regression testing: Validating than any change or new functionality does not break any pre-existing capability.
- Peer review: Including a team member who didn’t complete the work reviews it for accuracy and alignment with agreed-upon standards.
- Documentation: Adding items for this is vital, as many teams overlook it during building and testing. You’ll also need to reflect on the value stated in the Agile Manifesto, “working software over comprehensive documentation.” No one is against documentation; however, it should have value. Useful documentation includes details on how something works, training materials, and the rationale behind the design and functional decisions.
Tips for creating an effective definition of Done
- Consider it a team agreement that the scrum team creates, owns, and implements. Make sure that every member understands and supports all the items on the list.
- Write it out and always make it visible for the team’s use, strengthening common alignment to the items on the list and easy access through printing, posting, and sharing.
- The list is a “living” artifact open to modification via the sprint retrospective. If you find something missing in your sprint activities, discuss adding it to your list. As your development team’s capabilities expand, so should your definition of Done.
- Don’t wait until you team is sprinting to create and implement a list. Ideally, your definition of Done should be in place before the start of your first sprint. That’s because it will influence your understanding of the work and the associated activities that impact the work for each product backlog item. However, because it supports validating work as shippable, even if your work is already in flight, it’s never too late to put it into use.
Is your definition of Done good?
Your scrum team may struggle with the definition of Done. Its importance to the work is pivotal, and by following these tips and suggestions, you can refine your definition of Done.
If you have questions about scrum or agile transformations, Platinum Edge has the support and resources you need. Explore our services and see how we can help.
