How to Create a Definition of Done in Confluence
Confluence is where Atlassian teams keep their team agreements and engineering practices. Your Definition of Done belongs here because it is a team-level agreement that needs versioning, commentary, and the context of why each criterion was added. A DoD living only in Jira field configurations is opaque — no one knows why the criteria exist or when they changed.
This guide covers creating a living Definition of Done document in Confluence that integrates with Jira, gets updated through proper decision records, and is visible enough that it actually influences behavior.
Step-by-step guide
Create the DoD page using the Decision template
In Confluence, navigate to your team space. Click Create and select the "Decision" template from the template library. Rename the page to "Definition of Done — [Team Name]." The Decision template includes a Status badge (Active/Deprecated), background context, options considered, and the final decision rationale. This structure explains WHY each DoD item exists, not just what it is.
Write the DoD as a numbered task list
In the page body, add a Confluence task list (use the /task macro or type [] to autocreate). Each task should be one DoD criterion. Example items: Unit tests written with >80% coverage on new code, Code reviewed by at least one senior engineer, Feature deployed to staging and smoke-tested, Product PM has tested the happy path and one edge case, No open P0 or P1 bugs linked to this story. The task list format makes the DoD scannable and copy-pasteable into issue descriptions.
Add a "History" section with a Confluence Decision Log
Below the DoD list, add a section called "Change History." Use a Confluence table with columns: Date, Change Made, Reason, Owner. Each time the team adds or removes a DoD criterion, add a row. This creates an audit trail that prevents "why do we do this?" debates in retros. When an incident reveals a missing DoD step, the log shows the date it was added so you can tie it to the incident.
Embed the DoD page as a Jira page link on your project
In your Jira project sidebar, click "Add shortcut" and paste the Confluence page URL. Name it "Definition of Done." This makes the DoD one click away from the sprint board, visible to engineers, QA, and product without needing to know the Confluence space structure.
Set up a quarterly DoD review reminder
In Confluence, use the Reminder macro on the DoD page: /reminder. Set it to fire quarterly. When the reminder fires, it emails all page watchers with a link to the page. This prompts the team to review whether the DoD still reflects current quality standards. Add all engineering and product team members as page watchers via the Watch button.
Add version-specific DoD entries for major releases
When your team ships a major release or changes its engineering standards (adopting TypeScript, switching to a new testing framework), add a "DoD Version 2.0" section to the page. Keep the old version visible but marked as superseded. This historical record helps onboard new engineers and explains why older code does not meet current standards.
Common mistakes
Treating the DoD as a one-time setup document
A DoD that has not been updated in six months is out of date. Standards evolve: new security requirements emerge, CI/CD capabilities improve, team size changes. Schedule quarterly reviews on the Confluence page itself using the Reminder macro.
Not explaining the rationale behind each criterion
Engineers who do not understand why a criterion exists will cut corners on it under pressure. Add a one-sentence rationale in italics after each item: "Code reviewed by at least two engineers — required since the Stripe billing incident in Q2 where a single reviewer missed a race condition."
Using Confluence as the only enforcement point
A Confluence document requires people to voluntarily comply. Pair the Confluence DoD with a Jira workflow condition (see our Jira DoD guide) that mechanically enforces the checklist. Documentation explains intent; automation enforces it.
Different DoDs for different squads with no visibility
In multi-squad orgs, each squad often develops its own DoD over time. Create a parent "Engineering Standards" Confluence space with a cross-squad DoD table showing each squad's DoD side by side. Differences should be explicit decisions, not accidents.
Tips
Use the Confluence /status macro to mark the DoD as "Active" or "Under Review" — the colored badge is visible in page listings and search results
Pin the DoD page in your team's Confluence Space Overview sidebar so it is never more than one click from the engineering home page
Require a Confluence comment approval from the EM and PM before any DoD change goes live — this prevents unilateral changes
Export the DoD page as a PDF and share it in your engineering onboarding doc so new hires read it on day one
How Vantage helps
Vantage's compliance check feature runs your PRD requirements against configurable compliance rules. You can encode your Definition of Done criteria as compliance rules, and Vantage will flag any tickets generated from requirements that do not include the necessary DoD steps — like missing test coverage expectations or undefined success metrics.