Definition of Done in Jira: Agree What “Finished” Means

An engineer finishes a change and moves the Jira issue forward. A tester discovers that the new screen works, but an existing flow has broken. Customer support finds out about the change from a confused customer. Everyone used the word finished, but each person meant something different.

A Definition of Done gives the team a shared completion standard. It makes the expected quality checks visible before work begins, so that review is less dependent on who remembers to ask the right question.

In this guide, we will build an example for a fictional customer portal team, distinguish shared quality checks from feature-specific acceptance criteria, and put both alongside a Jira issue using Power Pack’s Definition of Done & AC tool.

What is a Definition of Done?

The Scrum Guide describes the Definition of Done as the quality standard that an Increment must meet. It provides a shared understanding of completed work. Where an organization has established a standard, that standard is the minimum for its Scrum Teams. See the official Scrum Guide.

For our practical example, think of it as a small set of questions the team asks about every relevant change. Has the implementation been reviewed? Have the agreed verification checks passed? Is the information people need to support the change available?

The exact questions depend on the product and its risks. A public customer portal, an internal report and a safety-critical system need different standards. Copying another team’s checklist without discussion can leave important gaps while adding work that serves no purpose.

A useful standard describes an observable result. “High quality” expresses an ambition. “The agreed regression checks have passed, with results linked from the Jira issue” describes something a reviewer can inspect.

Separate shared quality from feature behaviour

Our fictional team is adding notification preferences. Customers will be able to turn a weekly summary email on or off. Important account messages remain outside that preference.

The feature needs its own acceptance criteria. For example, a saved choice must still appear after the customer signs out and returns. That requirement belongs to this feature because it describes what the customer should experience.

The Definition of Done covers the broader completion standard. Reviewing the implementation, checking affected existing behaviour and updating support guidance may apply to many different changes.

Both lists matter. A feature may behave as requested while missing essential quality work. Equally, reviewed code and passing regression checks do not establish that the requested feature behaves correctly.

Start with the gaps your team actually sees

Bring the people who build, verify and support the product into a short discussion. Use a recent example of work that seemed complete but needed unexpected follow-up.

Our portal team identifies three recurring problems. Review comments sometimes remain unresolved. Existing account settings receive little regression coverage. Support instructions arrive after the feature is available.

Those problems suggest useful checks. They also give the team a reason to keep the standard short: each entry should prevent a recognizable failure or establish a necessary quality condition.

Ask how someone will verify each proposed entry. If nobody can describe the evidence, improve the wording before adopting it. “Documentation complete” could refer to release notes, internal design notes or a customer help article. Agree which information is needed and where it belongs.

Also agree who normally performs the checks. That conversation can happen in your usual planning process. A checklist alone does not assign a reviewer or reserve time in someone’s calendar.

Draft a practical shared checklist

Here is the portal team’s first draft. It is an illustrative working agreement, not a universal standard.

• Implementation review is complete and required review comments are resolved.
• The issue’s agreed acceptance criteria have been verified.
• Agreed regression checks for affected account flows have passed.
• Agreed accessibility checks for changed screens have passed.
• Support guidance reflects the changed customer behaviour.
• Verification results and relevant review links are recorded on the Jira issue.

Before using this checklist, the team writes down what its regression and accessibility checks include. Otherwise, two people could tick the same sentence after doing different work.

For the portal, the agreed regression set includes signing in, opening account settings and updating an existing profile field. The accessibility review for changed controls includes keyboard operation, visible focus and understandable labels. These are examples of this team’s chosen checks, not a complete accessibility standard.

The support entry also needs a practical interpretation. If a change has no customer-facing effect, the team should establish an appropriate standard for that kind of work in advance. Avoid making reviewers improvise exceptions merely to turn a list green.

Add the standard to a Jira issue

Open the relevant Jira issue and find Power Pack’s Definition of Done & AC card. It contains separate Acceptance Criteria and Definition of Done tabs. Select Definition of Done before adding the shared checks.

For a small list, enter a check’s title and select Add, or press Enter. Keep each title focused on one reviewable condition. A long sentence containing three unrelated checks makes partial completion difficult to represent.

You can also select Bulk Import and paste a Markdown list. For example, paste the six bullet entries above with a hyphen and space at the beginning of each line. Ordinary Markdown checkbox entries are another supported option.

Import adds entries to the selected tab. Check the tab before confirming and inspect the resulting list afterward. Importing the same content again can add entries that already exist, so use it deliberately rather than as a refresh action.

Use unchecked entries for work that has not yet been verified. Checked Markdown checkbox inputs are imported as done; copied checkmarks from an earlier issue should not stand in for reviewing the current change.

The agreed standard must be placed in each relevant issue manually. Keep a reference copy in the team’s normal documentation and paste the appropriate checks into new issues. This process is a team practice, not an automatic connection between a central standard and every issue.

Walk through a real review

Suppose the notification-preferences feature is ready for review. Maya checks the customer outcomes while Priya verifies the agreed regression set. Leo resolves the remaining implementation-review comments and links the review record.

The first pass reveals that the preference saves correctly, but keyboard focus disappears after selecting Save. The team leaves the accessibility check incomplete, records the problem in its normal Jira discussion and fixes it before repeating the relevant check.

Support guidance is also unfinished. That remains visible even though the feature-specific acceptance criteria are complete. The separate lists help explain why the team still has work to do.

After a check has actually passed, select its Done button. Select it again if new information means the item should return to todo. Record test results, review links and important decisions through the team’s normal Jira or documentation process.

A completed item records the team’s judgment. It does not run the check, collect its evidence or establish who performed the verification. If reviewer identity or timing matters, record that information explicitly in your usual review process.

Read the readiness indicator carefully

The tool shows completed and total counts for each tab. Its readiness indicator displays Ready for Release only when both lists contain at least one item and every item in both lists is done. Otherwise, it displays In Verification.

That rule makes the indicator useful for spotting unfinished entries. It also explains why a completed Definition of Done list does not produce the all-complete state while Acceptance Criteria remains empty.

Treat the wording as a summary of checklist state. It does not prove that the checks were sufficient, the evidence was persuasive or the product is safe to release. A team can mark a poorly written check complete just as easily as a useful one.

The checklist also does not block a Jira transition or a pull-request merge. Continue using the team’s normal delivery and release process to make those decisions.

Keep the standard useful as work changes

Review the standard when a repeated defect exposes a missing check, when the product changes materially or when an existing check stops providing useful information.

For example, the portal team might discover that preference changes work immediately but fail after a delayed synchronization. That finding could lead to a broader verification rule for features that depend on delayed processing. The team should first decide which changes it applies to and what evidence will demonstrate success.

Update the reference standard and discuss how to apply the change to work already in progress. Existing issue lists do not inherit that revision automatically. Inspect affected issues and add the newly agreed checks manually where appropriate.

Avoid expanding the checklist after every isolated mistake. Sometimes the better response is a specific acceptance criterion, a clearer implementation task or a change to the review process. The shared standard should remain something the team can understand and genuinely apply.

Try it on one current issue

Choose an issue approaching review. Agree a short shared quality standard, place it in the Definition of Done tab and add that issue’s specific customer outcomes under Acceptance Criteria.

Walk through the checks together and link the evidence where your team normally records it. Mark entries done only after verification, then review the remaining work through your usual delivery process.

The useful result is a clearer conversation. When someone says the notification-preferences change is finished, the team can explain which outcomes work, which quality checks passed and where that conclusion came from.

• The Scrum Guide — Definition of Done