Reopen ticket vs new bug: which keeps the record honest

Stefan-Iulian Tesoi · 16 October 2026 · 5 min read

Reopen the story when one of its acceptance criteria was never met, because the done was wrong and the record should say so. File a new bug, linked to the story, when every criterion held at acceptance and something later broke it, or a case nobody specified turned up. Keeping the two apart is what lets a reopen rate mean anything.

The reopen ticket vs new bug question looks like tracker hygiene. It is a question about which record is true. Jira's original default workflow ships a Reopened status, so reopening is one click; nothing in the tool says when that click is the honest one.

Reopen ticket vs new bug: what is the rule?

The rule turns on one question: was the criterion ever met? If it was not, the story was accepted on a check nobody performed, and it reopens. If it was, the story was right when it closed, and whatever failed since is new work.

The Scrum Guide states the first row for the sprint itself: an item that does not meet the definition of done "cannot be released or even presented at the Sprint Review" and "returns to the Product Backlog". A story whose criterion was never met is that item, found late.

Why does a new bug hide a false done?

Because it moves the failure out of the story's history and into a fresh item with no past. The story stays Done, its acceptance stands, and the sprint that closed it keeps the credit. Anyone reading the story later sees a clean acceptance that was wrong.

Teams usually file the new bug for a respectable reason: last sprint is closed and its numbers have been reported. That protects the report at the cost of the record. Every escaped defect still reaches users either way. What the record has to show is where it escaped from: verification, or a later change. A board where done and the repository disagree usually got there one quiet new bug at a time.

How do you tell a missed criterion from a later regression?

By running the criterion's check against the commit the story was accepted on, rather than against main. If it fails there, the criterion was never met. If it passes there and fails on main, something since broke it.

1. Find the accepted commit, the one the story was verified against.
2. Run the check the criterion names at that commit: the test, the command, the request.
3. Fails at the accepted commit: reopen the story with the output as the reason.
4. Passes there, fails on main: run git bisect between the two, then file a new bug linked to both the story and the change that broke it.
5. No criterion covers the failing case: file a new bug, and add the missing case to the criteria template.

The fifth row is the one teams misfile most. In our own backend, a change added an attempts field and compared it numerically. A missing field fails every one of those comparisons, so rows written by the previous build could not be picked up. Every criterion passed, because the tests created rows through the current schema, which filled in the default. Nobody had written a criterion about old rows. That is a new bug, written up as a bug report a coding agent can act on, and "rows from the previous build" is now a case schema changes get tested against.

What does the reopen rate actually measure?

With the rule applied, the reopen rate measures verification: the share of accepted stories whose acceptance was wrong. Four reopens among fifty stories accepted in a quarter means verification let one in twelve through. That number belongs to whoever, or whatever, did the accepting.

Without the rule, the reopened tickets metric measures habit. A team that files every failure as a new bug reports a reopen rate of zero and a pile of escaped defects nobody can trace. A team that reopens everything blames verification for regressions it could not have caught.

A reopen says the check was wrong. A linked regression says the check was right and the code moved. Mixing them turns two useful numbers into one useless one.

Pair it with the regression count, which measures how well the test suite protects what was already accepted. The definition of done for agent-written code is what the reopen rate is grading.

Should a coding agent ever reopen its own work?

Yes, when it finds a criterion that was never met, because reopening moves work away from Done, never towards it. An agent rerunning checks will find these sooner than a person does.

In Laimonade a connected coding agent can reopen a Done item but must give a reason, and it cannot take the item back to Done: it can reach In Review and no further. A person closes it, or Laimon, the product owner agent, whose closures are stamped as its own. Reopening also leaves a closed sprint's delivery record as it was, which removes the usual reason to file a new bug instead.

Frequently asked questions

Does reopening a story put it back in the sprint?

Not by itself. Reopening changes what the record says; whether the work goes into the current sprint is a planning decision. In Laimonade a reopened item goes to the backlog unless it is sent to the current sprint as Ready, and a closed sprint keeps the points it delivered. Last week's velocity stays a historical fact.

Should a defect found in UAT reopen the story?

Yes, if it breaks an acceptance criterion the story was accepted against, because UAT has shown the done was wrong. No, if it is behaviour no criterion covered. That is a new item, and often a new story rather than a bug, since the user is asking for something nobody specified.

Who decides which of the two it is?

Whoever owns the acceptance criteria, usually the product owner, on evidence the reporter supplies: the failing check and the commit the story was accepted on. When to reopen a user story is a judgement about whose check failed, so neither the reporter nor whoever did the verifying should settle it alone.