“Development completed.” Your Azure DevOps Is Quietly Deleting Your Team’s Knowledge

That was one of the most common ways your team closed tickets last year. It's not a status — it's amnesia.

An engineer closes a ticket. In the comment, one line: "done."

Multiply that by a few thousand tickets a year, across every team. You just paid senior engineers to solve hard problems — and threw the solution away.

We wanted to know how big this actually is, so we measured it. Not a survey — a real audit on a live Dynamics 365 backlog: a random 8,000-ticket sample drawn from 107,776, read-only, no AI guessing, just structure.

And we ran it on our own backlog first, not a customer's. It seemed dishonest to publish someone else's numbers before we'd looked at ours. Here's the shape of it:

• 50.3% of bug reports had no usable description or repro steps. Every triage starts from zero.
• 59% of fixed defects had no link to the commit or PR that fixed them. The fix is in the code — you just can't get to it from the ticket.
• 10.7% of closed items were closed with a comment too vague to explain what happened. ("Development completed." "Issue fixed.")
• 94.2% of the open backlog had been sitting untouched for over 90 days.

Add up just the rework this creates — re-triaging bugs, re-finding fixes, re-investigating "done" tickets — and it lands around 119 hours a year on a sample this size. That's not a rounding error. That's weeks.

One detail stuck with me: in a separate look at 60,000 closed tickets, the single most common closing note was literally "Development completed" — 390 times. Zero technical substance, at scale.

This isn't a people problem you fix with a lecture. It's a measurement problem. Nobody ever put a number on how much of your ADO/Jira is unusable as knowledge — so it stays invisible, and invisible problems don't get fixed.

The offer — and where we draw an honest line

We turned that audit into something you can run on your own data: an Express ADO/Jira Health Audit.

Export your tickets → it runs fully offline on your machine (your data never leaves your network) or, if you'd rather not run anything, hosted — your export is processed in memory for that one request, never written to our knowledge base, and gone once you have the report → you get a 6-part report: data-readiness, time-to-close, backlog aging, inflow drift, recurrence, and — the part that matters — 7 hygiene rules, each with a severity, the % of your volume it hits, an estimated cost in hours, and a plain "here's what to do."

Now the honest part, because it's the whole point:

This audit measures the size of the problem. It does not diagnose root cause for you, and it will never tell you "you saved $X."

Anyone who promises that invented the number. We even tell you where our own data is thin — in that live backlog, only 21% of tickets had real close/resolve dates, so we counted timing on that 21% instead of padding it. One real number, honestly bounded, and you decide what it's worth.

The moment that convinced us we'd built the right thing

One of the rules checks whether closed defects record a cause and a resolution. On our own backlog, the tool found a resolution field that was almost entirely filled in — and then refused to score it. It had looked at the contents, seen one value dominating and too few distinct forms for that volume, and concluded the field was boilerplate: state-transition text auto-written by the workflow, not a human explaining anything.

So instead of a green checkmark, the report says this:

"These are NOT '0% = clean' — they could not be assessed from what this export carried."

A tool optimised to impress you would have reported that field as 100% complete and moved on.

Want to know your number?

We'll run an Express Health Audit on a sample of your Azure DevOps or Jira and walk you through the report.

Most teams assume their tickets are "mostly fine." The number is usually a wake-up call.