Why the Definition of Done Is Different for Every Engineer on Your Team

The sprint board shows eight tickets in Done. The product owner is preparing the stakeholder update. She assumes Done means what it says: the work is complete, in production, verified. She is about to be wrong about at least four of those eight tickets — not because anyone lied, but because Done means something different to each of the engineers who closed them.

This is not a niche dysfunction. It is the default state of any team with more than two engineers and a Definition of Done document that lives in Confluence and gets read approximately never. The DoD is well-intentioned. It says things like "acceptance criteria met," "code reviewed," "QA sign-off." What it does not do is change the private, internalized standard each engineer applies in the moment they drag a ticket from In Progress to Done. Those private standards diverge. The sprint board reflects all of them, uniformly, as if they were the same.

The four definitions that live in the same sprint

Most teams have at least four competing definitions of done in operation simultaneously, none of them stated explicitly and all of them applied in good faith. Engineer A marks Done when the work is complete on their machine and the tests pass locally. They will open a PR shortly. Engineer B marks Done when the PR is merged to main and CI is green. The code exists in the repository; that's done. Engineer C marks Done when the code is deployed to staging and they have eyeballed it. Engineer D does not move the ticket until it is deployed to production and smoke tested in the actual environment where users will encounter it.

All four are defensible. In fact, all four are correct by some reasonable interpretation of "done." The problem is not that any of these engineers is wrong. The problem is that they are all using the same Jira status to mean four different things, and the sprint board reflects none of those distinctions. When the scrum master looks at the board, she sees Done. She does not see "done on my machine," "done in CI," "done in staging," or "done in production."

Same ticket. Four engineers. Four definitions of Done.

  Ticket: FEAT-1847 — "Add user notification preferences screen"
  Status: Done (marked by Engineer A, 9:42 AM Tuesday)

  Engineer A's definition:
  -> Tests pass locally against the dev database.
  -> No linting errors, no TypeScript errors.
  -> Ticket moved to Done.
  -> PR not yet opened.

  Engineer B's definition:
  -> PR opened, reviewed, approved, merged to main.
  -> Tests pass in CI.
  -> Ticket moved to Done.
  -> Not deployed anywhere yet.

  Engineer C's definition:
  -> Code merged and deployed to staging.
  -> Manually verified on staging that the screen loads and saves.
  -> Ticket moved to Done.
  -> Not in production.

  Engineer D's definition:
  -> Deployed to production.
  -> Smoke tested: preferences screen loads, changes save, user receives
     a notification after opt-in is toggled.
  -> Ticket moved to Done.

  Sprint board shows: 1 ticket Done.
  Reality: four different states of completion across four engineers,
  indistinguishable from the board.

The sprint board in the block above is not a pathological team. It is a normal team with a normal spread of interpretations. What makes it a problem is that the board presents all four states with identical formatting and identical weight. The scrum master cannot distinguish them. The product owner cannot distinguish them. The stakeholder update assembled on Friday afternoon will treat all four as equivalent.

Why the sprint board becomes meaningless

A sprint board is supposed to be a real-time signal of what is actually complete. When Done means something different on every row, the board stops being a signal and becomes noise dressed as a signal — which is worse than no signal at all, because it looks authoritative.

Scrum masters use the Done column to assess sprint health, report to stakeholders, and judge whether the team is on track for the release. If Done means "in staging" for three of the eight tickets, the sprint is in a different state than if Done means "in production and tested." Those are not the same sprint. The board says they are.

Product owners use the Done column to confirm that features are ready to demo, ready to tell customers about, ready to include in release notes. If a feature is Done by the engineer's standard but not by the product owner's standard — not deployed, or deployed behind a feature flag that is off, or deployed but not accessible to the relevant user segment — the sprint demo will reveal that gap in front of everyone. Sprint demos fail for this exact reason: something that looked Done on the board is not demonstrable in the environment where the demo runs.

Retrospectives are the downstream casualty. When the sprint ends with three items carried over, the retro surfaces problems like "we need better estimates" or "we got hit with too many interruptions." Neither of those is wrong. But the underlying driver — that Done meant four different things and the board could not distinguish them — never enters the retro conversation because nobody had enough visibility to name it.

What scrum masters actually need to know

A scrum master running a sprint has a specific information need that the current tooling does not satisfy: for each ticket marked Done, what is the actual deployment and verification state? Not what the engineer understood Done to mean when they closed it. What the system can confirm about that ticket's code: is there a merged PR? Is that PR deployed? To which environment? Is there a feature flag, and is it on?

This information exists. It lives in GitHub, in the deployment pipeline, in the feature flag system. The problem is that it is not surfaced in Jira, which is where the scrum master is looking. Jira shows ticket status. It does not show deployment state. It does not show whether the linked PR has been merged. It does not show whether the feature is actually accessible to users in production. The scrum master has to assemble that picture by asking engineers individually — a process that is slow, inconsistent, and happens too late to do anything about it.

The practical result is that scrum masters are managing sprints with incomplete information about the things that matter most: what is actually complete, what is actually deployed, and what will actually be demonstrable at the sprint review. The DoD document in Confluence was supposed to solve this. It does not, because the DoD is not enforced at the ticket level — it is a reference document that individual engineers consult, interpret, and apply differently.

What the scrum master sees in Jira at sprint end:

  FEAT-1847  Notification preferences screen  Done
  FEAT-1851  Dashboard filter improvements     Done
  FEAT-1855  API rate limit headers            Done
  FEAT-1859  Export CSV endpoint               Done

  Questions that Jira cannot answer:
  -> Which of these have merged PRs?
  -> Which are deployed to staging? To production?
  -> Which have been smoke tested in a real environment?
  -> Which are Done by the engineer's standard and
     not-done by the product owner's standard?

  Questions the scrum master has to answer by asking engineers individually,
  one by one, before every sprint review — if they ask at all.

The product owner's problem is harder than it looks

Product owners operate one level further removed from the system than scrum masters, which means their exposure to DoD inconsistency is higher and their ability to detect it before it matters is lower. A product owner preparing a stakeholder update pulls from the Done column and treats it as ground truth. She has no practical way to verify the ground truth. She cannot log into GitHub and check merge status for ten tickets. She cannot check the deployment pipeline to see which are live. She is relying on the Jira status, and the Jira status is a composite of four different engineers' four different standards.

The stakeholder call on Thursday becomes the verification mechanism, which is exactly the wrong time for verification. The product owner tells the VP that the notification preferences feature shipped. The VP asks a follow-up question about behavior in a specific edge case. The product owner does not know the answer because the feature is in staging, not production, and has not been fully smoke tested. The gap surfaces in the call rather than before it. This is not a communication failure. It is an information failure that looks like a communication failure because the moment it surfaces is conversational.

The root cause is the same as the scrum master's problem: Done is a status that carries no information about what Done means in practice. The product owner cannot report accurately to stakeholders because the sprint board does not tell her what she needs to report. She is working from a label — Done — not from the state it is supposed to represent.

How Kognita surfaces what Done actually means per ticket

Kognita indexes your codebase continuously and connects it to Jira ticket state. For the DoD inconsistency problem, this means a scrum master or product owner can ask a plain-language question — "what is the actual state of the tickets marked Done in this sprint?" — and get an answer grounded in what the system knows: merged PRs, deployment records, feature flag state, environment coverage.

Query: "What is the actual state of the tickets marked Done in this sprint?"

  Kognita returns:

  FEAT-1847 — Notification preferences screen
  -> PR #2204: merged to main 3 days ago
  -> Deployed to: staging only
  -> Production: not deployed
  -> Smoke test: no record
  -> Jira status: Done

  FEAT-1851 — Dashboard filter improvements
  -> PR #2198: merged to main 5 days ago
  -> Deployed to: production (deploy log: 2 days ago)
  -> Smoke test: no record
  -> Jira status: Done

  FEAT-1855 — API rate limit headers
  -> PR: not found — no linked PR in this branch or any branch
  -> Deployed to: not deployed
  -> Jira status: Done

  FEAT-1859 — Export CSV endpoint
  -> PR #2211: merged to main 1 day ago
  -> Deployed to: staging only
  -> Feature flag: export_csv_v2 — OFF in production
  -> Jira status: Done

  Summary: 1 of 4 "Done" tickets is fully deployed to production.
  1 has no PR. 2 are in staging only. 1 has a feature flag still off.

The answer in the block above does not require an engineer. It does not require reading the deployment pipeline directly. It does not require a Confluence page. It comes from Kognita's continuous indexing of the repository and its Jira MCP integration, which connects ticket state to codebase reality. The scrum master gets a factual picture of what Done means for each ticket in the sprint — not what each engineer decided Done meant when they moved the card.

This changes the pre-demo workflow. Instead of discovering on Thursday afternoon that a feature marked Done is actually in staging behind a disabled flag, the scrum master finds out Monday when she asks Kognita what the sprint looks like. There is still time to either get the flag turned on or adjust the demo plan. The sprint demo does not fail because the information was available before the demo, not during it.

For product owners, the same query becomes the source for stakeholder updates. The gap between what product reports and what engineering has actually shipped is a persistent tension on most teams. Kognita closes that gap by making the actual deployment state queryable without requiring any technical background. The product owner asks in plain language, gets the answer grounded in what the system has actually done, and reports from that rather than from what engineers told her they had done. Those two things are not always the same.

Why a better DoD document does not solve this

The standard response to DoD inconsistency is to improve the DoD document: make it more specific, require sign-off, add it as a checklist item in the Jira transition workflow. These interventions help at the margins. They do not address the structural problem, which is that the enforcement of any DoD standard happens at the individual engineer's discretion, in the moment they drag the ticket to Done.

Even a perfectly written DoD document, read by every engineer before every ticket close, cannot account for the engineer who genuinely believes staging is close enough to production to count. Or the engineer who marked Done at 11 PM on day nine because the sprint was ending and the PR was open and it felt close enough. Or the engineer whose environment was not configured to deploy to staging, so they did what they could and marked it Done. These are not malicious acts. They are the product of ambiguity, time pressure, and the absence of any verification mechanism that sits between the engineer and the Jira status field.

The verification mechanism is what matters. Not a document. Not a process. Not a checklist in the ticket. A mechanism that can answer, independently of what the engineer believes, whether the work is merged, deployed, and live. That mechanism is a live connection between Jira and the actual state of the system.

Final take

The Definition of Done is not inconsistent because teams are undisciplined. It is inconsistent because Done is a status field in Jira, and status fields do not enforce standards — people do, and people apply different standards. The Confluence page does not change that. A better DoD checklist does not change that. The inconsistency is built into the structure: the only person who knows what Done means for a given ticket is the engineer who closed it, and they have already moved on.

The sprint board becomes trustworthy when Done is verified against system state, not just the engineer's judgment. That verification does not require changing how engineers work. It requires connecting Jira ticket status to what the codebase and deployment pipeline actually show — and making that connection queryable by the scrum master and product owner who need to report on it, before the sprint demo, not during it.