When we think Agile, we think self-organizing teams, cross-collaboration, and consensus-based decision making. In Agile development, work assignments don’t trickle down from upper management into various departmental silos. Instead, Agile businesses trust motivated team members to find the best development solutions together.
What’s the key to success in this fast-paced, collaborative work environment? Excellent communication among all stakeholders. Agile teams must speak the same work language, creating shared definitions of the terms they use. And one important term Scrum teams need to define for themselves is “done.”
Let’s say you ask a team member whether a user story is done. If they say yes, do you know exactly what that means? Or, you move a work item from “in progress” to “done.” Is everyone on the team confident which processes were completed?
If not, your team likely needs to clarify their definition of done. Scrum Agile teams develop a shared definition of done, or DoD, to improve consistency, transparency, and quality in their product management. A DoD checklist ensures all stakeholders know what steps must be completed before a product increment is truly “done.”
Without a clear definition, “done” can mean different things to different people. Amid the confusion, important steps can be missed and product quality can suffer.
Hold a Whiteboards session to establish a definition of done with your Scrum team. The Whiteboards app integrates deeply with Jira so you can create and manage Jira issues without leaving the digital whiteboard. Import a Jira story from your product backlog to use as an Agile definition of done example issue. Ask the team what steps they’ll take to complete that user story. Gather input on virtual sticky notes to compile your list. Publish a working definition of done, follow it consistently, and revisit it periodically to make updates.
From defining when work is “done” to getting that work done, Whiteboards-Jira integration keeps your product management seamless. Try Whiteboards Pro for free today, and keep reading to learn about the definition of done and how to write an Agile DoD checklist with your team.
What is the definition of done in Agile projects?
According to the Agile Alliance, the definition of done in Agile is “an agreed upon list of the activities deemed necessary to get a product increment, usually represented by a user story, to a done state by the end of a sprint.”
In other words, the definition of done governs when a work item on the Scrum board moves from “in progress” to “done.” A Scrum team’s DoD checklist includes steps that ensure product quality, not merely feature functionality. A definition of done accounts for coding, review, testing, quality assurance, documentation, and compliance. How the list is arranged depends on the individual team or organization.
For some teams, the definition of done is what must be accomplished before a feature is released. However, this is not a hard and fast rule. The team decides how the DoD fits into their release schedule. For instance, the development team may release a minimum viable product mid-sprint. They also may still need to do additional documentation, testing, or tweaks to meet their agreed-upon definition of done.
The 2020 Scrum Guide™ states that every Scrum team must establish and abide by a common definition of done. In an Agile DoD, a user story is either “done” or “not done.” Any user story not meeting all criteria for the Scrum team’s definition of done is considered not done.
What does this mean practically in a Scrum setting? User stories that meet the definition of done by the end of a sprint are included in the sprint review. Unfinished stories are not included and are not counted toward sprint velocity. These stories return to the product backlog and are often rolled over into the next sprint. The Scrum team continues working on them until the stories meet the DoD.
Why does a Scrum team need a definition of done?
Whether or not a work increment is done may sound pretty simple. However, many activities – Agile and otherwise – don’t have a straightforward definition of done. Consider these personal and professional product scenarios and how “done” could mean many things:
- You are done baking cupcakes. Does this mean the oven timer went off? Did you check that the cupcakes are baked all the way through? Are they out of the oven? Has the frosting been applied? Have you taste-tested and approved the final product?
- You are done writing a novel. Does this mean you’ve written the full draft? Has the proofreader fixed all the typos? Did the editor deem it ready for publishing? Have you approved the cover art? Has the book gone to press?
- You are done developing a user story. Does this mean the coding is finished? Has this product increment passed all testing stages? Was initial end user feedback already incorporated? Is the feature ready for release? Has it been released? Is all associated documentation complete?
Ask different Scrum team members if a user story is done and you may receive a different reply from each: “It’s done.” “It’s basically done.” “All the major work is done.” “It’s as good as done.” So what makes a given increment done-done?
It’s important for Agile Scrum teams to use a single definition of done. This keeps the development team, Product Owner, Scrum Master, and client on the same page. If your team hasn’t established a definition of done, hold a Whiteboards session on a blank template to create your DoD checklist. Test out your definition of done for a sprint or two, then assess how it’s going. Revise your definition based on feedback from the team about their experience using it.
Why are there different definitions of done?
You might be asking, why does each Scrum team develop their own definition of done? Why doesn’t the Agile community, or at least the Scrum community, share a standard definition of done?
The Scrum framework does dictate certain processes, events, and even a common vocabulary for describing these things. But there’s no such thing as a definition of done that works best across the board for every Agile team.
So what are some factors that might influence your Scrum team’s definition of done?
- The team’s established workflow. Each Agile team or organization has its own way of coordinating design, development, testing, and QA. Your team’s definition of done will be affected by how those processes intersect and the order of operations.
- Relevant stakeholders. Small teams might have a single developer or product tester. A large organization might include multiple Scrum teams developing different products. Your DoD reflects who’s doing what work, who needs to be informed, and who needs to sign off on a work increment before it’s done.
- Coordination among departments. How the development team works with other teams affects the definition of done. For instance, your DoD might require new feature documentation to be sent to the support team before release. Or it may include communicating with the marketing team in specific ways pre-release.
- The product in question. You may need to tailor your definition of done to better fit the product or client. It’s best to have a standard definition in place, but different types of work might call for DoD checklist modifications. For instance, developing an app from scratch for your own company may require different checks than overhauling a client’s existing website.
Agile is a set of guiding principles, and Scrum refines those principles into a specific framework. From there, individual teams develop on-the-ground practices that work for them.
Want to brush up on these core principles to help you keep Agile values front and center? Download our guide How to Go Agile the Right Way and learn (or review) the difference between “doing” Agile vs. truly “being” Agile.
Who decides on the definition of done?
In Agile, the Scrum team and Product Owner typically collaborate to write a definition of done. An organization may also establish a definition of done at the company level. And companies with multiple Scrum teams working on different products may allow each team to create their own definition.
That said, the definition of done applies to an entire product, not to individual features or to a specific sprint. DoD in Agile exists at the product level and is applied consistently to each increment of that product.
The team or teams working on a given product may use the company’s definition of done, or one team’s standard definition of done. Or, the collaborators might adjust the definition to better fit that particular product. The important thing is that everyone involved with the product adheres to a single, clearly understood definition of done.
To this end, the Product Owner should communicate the team’s definition to all relevant internal and external stakeholders. That way, all product stakeholders speak a common language when using the word “done.” This reinforces team accountability and manages client expectations, reducing faulty assumptions and failed attempts at mind-reading.
What are the benefits of a definition of done?
An established definition of done is a must for Scrum product management. Agile teams who check each product increment against a clear definition of done see many benefits:
- Better quality assurance. Every feature goes through the same rigorous checklist before its release, supporting uniform, well-vetted product output.
- Improved team communication. Each team member uses the word “done” to mean the same thing, reducing internal confusion and miscommunications.
- More satisfied customers. The client and other external stakeholders know what the Product Owner means by “done,” allowing expectations to be managed more successfully.
- Greater process accountability. Each box on the list is checked before the increment hits the Scrum board done column, creating a clear trail back to the source if issues arise.
- Consistent sprint metrics. Sprint velocity is measured against the same criteria in each iteration, standardizing data collection for better overall project management.
Taking the time to standardize a definition of done does work up front to save more work later. One buggy release that slipped through the cracks can set the whole team back for hours or days. A client’s confusion over the idea of “done” – and their resulting disappointment in the state of the product – can sour a working relationship. Why not be proactive in creating a simple checklist to get everyone on the same page from the beginning?
How does an Agile team establish a definition of done?
Ready to write a definition of done for your team or organization? Gather your Scrum team around your digital whiteboard and start a video chat.
Your task is to examine your product development and deployment process, then decide how you will summarize it into a definition of done. Add the following Agile definition of done example categories to virtual sticky notes to get the conversation started. Consider these to be a starting point, not a comprehensive list:
- Coding
- Review (UX design, acceptance criteria, issues, bugs, PO signoff)
- Documentation (developer, support desk)
- Testing (unit, integration, user acceptance, load, regression)
- Compliance (legal, security)
Sometimes it’s easier to picture a process using a real life example. In Whiteboards, your Jira backlog is always one click away. Open the backlog from the right hand menu and pull a user story onto the whiteboard. Have the team walk through the steps they’d take to complete that story.
Then, maybe examine a user story from another product or project. You want to catch all the main checkpoints for your list, even if they don’t apply to every product increment. That said, don’t make your DoD inventory too long. Five to eight steps is generally plenty. Too many boxes to check can cause overwhelm and undermine the process, making your DoD counterproductive.
Scrum teams write wildly different DoDs (just do a quick Google search and see!), and every DoD in Agile is a living document. Don’t get bogged down trying to find the perfect breakdown of your process. Here’s an Agile definition of done example checklist:
- Code reviewed
- UX reviewed
- Unit test complete
- Integration test complete
- UAT complete
- Documentation submitted
- Outstanding issues resolved
- Product Owner signed off
A different team might group all testing together into one step, trusting the testers to cover their bases. A definition of done can always be more or less detailed depending on what makes sense for your team.
Once your working definition is in place, communicate it to all relevant stakeholders. Decide how long you will test it out. Schedule a review in a few weeks to discuss how it’s going and make any revisions.
Pro tip: Add the advanced custom field called “checklist” to your Jira story cards. Edit the checklist to match your DoD inventory. This integrates your definition of done into Jira so the Product Owner (or any user) can quickly check the status of a user story. It also creates a concrete checkpoint for a user who’s getting ready to move an issue from “in progress” to “done.”
Finally, remember that creating the perfect Agile process matters less than consistently following the process you’ve established. You’ve already improved your product management by creating a DoD checklist. Your team’s next step is to get comfortable following the definition of done protocol consistently. Then, revisit your DoD checklist regularly and make updates as the team learns what works best for them.
Getting work done right is easier with Whiteboards’ seamless Jira integration. Your Jira admin status and user permissions sync in Whiteboards for seamless issue management during any whiteboard session. Robust import and update zones let you easily batch-manage Jira issues. Import issues, create new issues, and update any issue field – all without leaving Whiteboards.
Sign up for Whiteboards Pro today to get 100+ Jira-integrated templates and a palette of powerful diagramming tools. Whatever your team’s definition of done, the Whiteboards app is there to help you meet it.
