Regardless of the framework, method, methodology, all software development processes could benefit significantly from applying validation steps across the entire process. Let’s turn Definition of Done into a powerful mechanism to assure built-in quality.
Understanding Definition of Done
Definition of Done is an underestimated mechanism to guide the development team not only towards completing a user story but from the very beginning of the idea through the actual delivery and acceptance by the customer.
Here is a new approach to applying Definition of Done to every step of the development process. I’ll show you how to define the criteria for high-quality deliverables throughout the entire workflow.
What Is Not High-Quality?
The representation of poor quality is identical, regardless of the way we run the project. Low quality means delays, bugs and rework.
We’ve started to take the quality of the deliverables at any point of the process as a given.
Well, it’s not. We have to build it. We need to start assuring the quality of the product as soon as we hear about the original idea and continuously validate our decisions along the process.
Applying Definition of Done
It turns out the hardest thing in software development is not solving the problem and designing the algorithm. The biggest challenge is to organize the work within the limitations of your environment. Whatever the methodology, the dependencies are the greatest obstacles. It becomes even more difficult to handle when the team is not always aware of their responsibilities.
Applying Definition of Done at every step of the process ensures that the team works with high confidence. It builds trust between the product, design, development and testing. Regardless, if the team is indeed cross-functional or there are different teams, these quick validations will significantly reduce the risk of bottlenecks, and increase the self-organisation capabilities. It’s simple – everyone must have done their job. Here what it means for each step of the process.
Product Backlog
Let’s imagine a Scrum team. We can’t expect a working increment at the end of the Sprint if the input for the Sprint is incomplete, ambiguous and lousy-structured. We’re not covering the backlog refinement on purpose, but how well the user stories have been detailed can be evaluated by Definition of Ready or a requirements review. Below are a few expectations that must be met before the Sprint Planning.
Definition of Done for Product Backlog
- User Stories are created before the start of the Sprint.
- Enough information, details and mockups are added to the User Stories.
- User Stories have meaningful acceptance criteria.
- User Stories are prioritised per release.
- User Stories are reviewed with the team before the start of the Sprint.
- User Stories are prioritised per Sprint.
Acceptance Criteria
It has been a challenge for many teams to write the Acceptance Criteria for user stories adequately. Usually, this is due to lack of proper training and understanding how powerful Acceptance Criteria are. Appropriate Acceptance Criteria can decrease the cost of the development tremendously.
Definition of Done for Acceptance Criteria
- Every User Story must have Acceptance Criteria.
- Acceptance criteria must define the functional and non-functional requirements.
- Acceptance criteria must be testable and independent of the implementation.
- They must be written before the developers start working on the User Story.
- Acceptance criteria must adequately represent the customer perspective.
- Acceptance criteria can serve as test oracles.
- Acceptance criteria verify that “It Works as Intended” and not that “It Works as Coded.”
Sprint Planning
Sprint Planning is where the Scrum Team agrees on what their commitment for the next Sprint is. If the Product Owner has ordered the Product Backlog, and the user stories have the right Acceptance Criteria, the Sprint Planning will be very effective. The team will sit together, imagine and discuss what it will take to accomplish their Sprint Goals. And they will do a bit of estimation if that’s their way.
Most importantly, this is the time for the team to decide what type of work they are going to do during the Sprint. A meaningful approach is to allocate their capacity to specific portions of work items. For example, 40% of the capacity is for new development and testing of new features, 30% is for fixing bugs for the new features, 10% is for technical debt and refactoring, and 20% is for high priority items that the team has the right to decide to include in the Sprint.
The team doesn’t work in isolation, and the world outside keeps moving. So even though the fact that nobody from outside has the right to change the scope of an ongoing sprint, unplanned events will happen – like production issues, that will force the team to change the scope. The team needs to plan for those. If they don’t happen, there will always be bugs to fix, tech debt to pay and unplanned delays to compensate.
Definition of Done for Sprint Planning
- User Stories have story points assigned if the team uses story points.
- The team has allocated its capacity accordingly to the Sprint Goals.
- The team commits to user stories that they understand well enough to deliver a potentially shippable increment at the end of the Sprint.
- Development, design and testing tasks are created and estimated if the team uses tasks and not states.
- The team has identified and committed to the Sprint Goals.
Teams very often make a massive mistake in breaking down the user stories into items that are neither testable nor releasable by themselves. For example, create a page layout without binding the buttons and the links. None of it can be released. The right thing to do is to create one button that leads to somewhere and completes a part of the user journey, so it makes sense for the user. Ask for feedback and then move forward. This is an increment. A page with boxes is not an increment for this Sprint.
Working in Sprints
To achieve a smooth workflow during the Sprint, the whole team must follow the agreed commitments. The team must not allow external interference and must closely monitor the burndown chart. The team is responsible for their own success, so they must proactively share any obstacles that can put the release of the potentially shippable increment at risk.
Definition of Done for Working in Sprints
- Development and testing start with tasks whose parent User Story has the highest priority.
- If any additional details are added to a User Story – new tasks with new estimation are created.
- No new User Stories are allowed to enter an active sprint.
- The team holds the Daily Scrum meetings every morning – essential decisions made by the team are published.
- Daily Standup is where the team has the opportunity to check their metrics like the burndown chart.
- The team monitors the Sprint Backlog carefully for delays and unexpected increase in new bugs, for example.
- The team makes sure to balance the capacity within the team.
The team should talk all the time. The Daily Standup is rather the last chance for someone to speak up if there is a problem. Even the most explicit priorities and the brightest horizons during the Spring Planning don’t guarantee something unexpected won’t happen, and the team will not exceed its capacity. That means that there are too many reasons to fail, and we can’t plan for all of them. That’s why the Daily Standup – the team has the immediate opportunity to act when something unexpected happens, to decide with the Product Owner what’s the best outcome they can achieve and how to adjust their scope and capacity accordingly. That’s what Agile is about – ready to change, prepared to face uncertainty, ready and willing to take the most efficient decisions on time.
UI/UX Tasks
These can be tricky. UI/UX work can be challenging to put into frames. There’s significant pressure on designers because they can quickly become a bottleneck if the product increments are not correctly identified and prioritised. For the sake of thoroughness, the work to the design on a user story within a Sprint might vary from story mapping, user journeys, developing the personas, through user interviews, accessibility testing, to validating the copy and performing usability testing. Assuming the discovery phase has run successfully, here are some essential criteria that would assure the design work is nicely integrated with the Sprint.
Definition of Done for UI/UX Design Tasks
- Designs for the highest priority user stories are created and attached to the user stories.
- Wireframes for the user stories of the lower priority are created and attached.
- Colours, fonts, sizes, paddings and margins are clearly annotated for each design.
- Each design has a version for the required resolutions.
- An interactive prototype of the main user journey for the Sprint is created and agreed with the team.
Development Tasks
Most often, the Definition of Done is defined for the development tasks only. That’s the reason for this article. We can use a checklist for completed work in everything we do, and it will save us a lot of trouble at later stages when we know it will cost us much more to handle it.
How to write clean code is among the most disputable topics, we’re not going to talk about it here. The important thing is that development does not end with writing some code. It doesn’t even end with checking it in. You can’t imagine how often the code is not checked in at the right place, the item is moved for testing, or a developer has broken the main branch and gone on vacation. Developing good habits is not easy, but here’s where to start.
Definition of Done for Development Tasks
- Working code is checked in.
- Meaningful unit tests are checked in.
- Source code and unit tests are reviewed.
- Code and unit tests are refactored.
- Code quality policies are satisfied.
- Code quality metrics are within required limits.
- Bugs and exceptions in the Sprint are fixed.
- Unit tests are updated to cover bug and exception fixes.
- Unit tests pass.
- Acceptance criteria of the User Story are satisfied.
Testing Tasks
The testing unit in the cross-functional team has the responsibility to first check if the rest of the deliverables and artefacts have met their Definition of Done. If anything is missing, it will most probably result in a bug – from a coding error, through inconsistent designs to missing details in the user story or ambiguous acceptance criteria. However, the testing must be done properly, as well.
Definition of Done for Testing Tasks
- Test Cases are written – manual or automated or hybrid.
- Test Cases are documented and organised in a way useful for all team members.
- Test Cases cover all aspects of the acceptance criteria, including negative and edge cases.
- Test Cases are repeatable and reusable for regression tests.
- Test Cases are reviewed and optimised.
- Test Cases are up to date.
- High-priority test cases are executed.
- Bugs and exceptions are reported, including regressions.
- Bug/exceptions are retested and verified.
- Acceptance criteria of the user story are satisfied.
User Story
Ideally, a User Story represents an actual customer need, and when done within the Sprint or earlier, it can be released immediately to the customer.
Definition of Done for a User Story
- Development, design and testing tasks for the user story are done.
- All high priority test cases pass.
- Product Owner has approved and confirmed that the acceptance criteria are satisfied.
- User documentation is created or updated per User Story.
- Installation and configuration manuals are created or updated per User Story.
Delivery
Whether the customer can get the user story right away because continuous delivery is in place, or features are released in other cadences, this simple checklist is a must before you send the version to the customer. Always keep up-to-date instructions for assembling release packages if it’s not fully automated.
Definition of Done for Delivery
- Continuous integration builds are steadily successful.
- Delivery packages are assembled, installed and verified on staging environments.
- Delivery packages are installed and verified in production environments.
- User documentation and Release notes are updated and published.
- The customer has been provided with training materials.
- The customer has been provided with support channels.
- The customer has accepted the delivery.
Next Steps
As we see, Definition of Done can indeed improve the transparency and predictability of the work (not only) in a Scrum project by providing clear guidelines about what’s expected from the team. And clarity is the first step to improved efficiency. It can be a fun exercise for the team to brainstorm their own DoD’s. The ones stated above have been proven to be effective and successful, but your team might need different, more or less detailed and by all means, continuously elaborate them as the team matures. Use this guide as a starting point. Grab a beer at the end of the day and build your list together. Just try it out and see how much smoother your Sprints will go. And if you liked the ones from above – download our Definition of Done infographic here.
