Why "is this really a bug?" is a harder question than it sounds

Do you ever evaluate and re-categorise tickets raised by your client? It may create a bit of friction to challenge the client's assertions. But avoiding it will cost you in other ways.

A client raises a ticket. They categorise it as a bug. Nine times out of ten, nobody on the delivery team stops to check whether that's actually true.

It sounds like a pedantic thing to challenge. In my view, it isn't. The label on a ticket does two jobs at once. At the micro level, it tells the team what kind of work is required and how urgently. At the macro level, hundreds of these labels get rolled up into a narrative about the health of the project. Get the labelling wrong often enough, and you end up with a steering committee genuinely believing the project is riddled with defects, when what actually happened is that requirements evolved and nobody bothered to say so.

The three categories, and why they get confused

• A bug means the system is not doing what was agreed it would do. There was a specification, implicit or explicit, and the build does not match it. Something is broken relative to an existing standard.
• An improvement means the system is doing exactly what was agreed, but someone has since realised a more suitable way to do it. Nothing is broken. The bar has simply moved, usually because the team (rightly) learned something mid-project that it didn't know at the start. They’re also usually complementary to existing features rather than being new features in their own right.
• A (new) user story means nobody previously agreed to this at all. It's new scope, dressed up as a follow-on task because raising it as "new scope" feels like it will trigger a bigger, more awkward conversation about budget and timeline. Depending on its complexity it may initially be considered a Change Request.

The confusion is rarely malicious. It's a matter of incentives, but not the incentive you might assume. On a Time & Materials engagement, the client is paying for the time either way, whether the ticket is a bug, an improvement, or new scope. In other words, calling it a "bug" doesn't make the work free.

What "bug" does is put the onus on the vendor. It reframes the ticket as something the vendor got wrong, which signals urgency and priority, and implicitly puts the vendor on the back foot to fix it fast, ahead of the queue, without much debate about sequencing. "Improvement" and "user story" don't carry that weight. They sit in a backlog, get prioritised against other work, and can be argued over. Calling something a bug is, whether consciously or not, a way of skipping that queue. So, there's a quiet, mostly unconscious pull toward labelling everything a bug, not to get something for free, but to get it fixed now.

Why this matters more than it looks like it should

Ticket categorisation is not just an admin exercise. It's the raw material for the story that gets told about the project.

Someone, at some point, is going to pull a report that says "47 bugs logged last sprint" and hand it to a steering committee. Nobody in that meeting is going to open each ticket and re-litigate whether it was really a bug, a reasonable scope refinement, or a new idea someone had in a workshop. They're going to take the number at face value, and the number is going to shape how the whole engagement is perceived, regardless of whether it's an accurate reflection of what actually happened.

This is how a project, that is perhaps broadly on track, ends up being discussed in terms of "quality concerns". Not because the delivery was poor, but because a category error at the ticket level quietly snowballed into a narrative at the steering committee level. And once that narrative takes hold, it's remarkably hard to undo with facts. Perception, once formed, does most of the subsequent thinking for people.

It's even more difficult if the narrative has become "the timeline and budget has been exceeded, and it's due to all the bugs".

If that is indeed the root cause of a project delay, then so be it - get it sorted. But if it genuinely is not, then it's in your interest to prevent that narrative from forming.

If the root cause of the project delay is due to endless iterations on requirements and changing of opinions - rather than bugs - then that's worth calling out and backing up with evidence.

Whose job is it to get this right

Here's the simple answer: it's the consultant’s, not the client's.

Clients, understandably, are not thinking about the downstream reporting implications when they raise a ticket. They're thinking about the immediate annoyance in front of them, and "bug" is the label that requires the least justification. Expecting client-side team members to consistently and correctly self-categorise their own tickets is expecting a level of discipline that has nothing to do with their job and everything to do with yours.

That means someone on the delivery side needs to be the checkpoint. Not adversarially, and not as an accusation that the client is trying to jump the queue. Most of the time they aren't; they genuinely don't know the difference, or haven't thought (long) enough about it. The fix is simple: before a ticket goes into the sprint, ask two questions:

• What was actually agreed before the feature was built, and does the current behaviour deviate from it? If “yes”, it's a bug. Usually, this would mean material deviance from the user acceptance criteria on a user story ticket.
• If nothing was agreed, or the ask post-dates the original design, is this a refinement of existing scope (improvement), or something genuinely new (user story)?

If the answer to the first question is “no“, say so. Not defensively, not as a "gotcha", just as a plain reclassification with a one-line rationale attached to the ticket so the client can see it too. This is a small piece of friction that pays for itself many times over, because it protects the integrity of every report that gets built on top of these tickets later.

The habit worth building

None of this requires new tooling or a new process document nobody will read. It requires a habit: read every incoming ticket with a moment of scepticism before accepting its label. Ask what was actually promised, not what the client assumes was promised. Re-categorise where needed, and do it consistently.

It's a small discipline. But it's the difference between a steering committee discussing your delivery quality, and a steering committee discussing what was actually delivered.