Once a ticket, always bullshit

How much of your development capacity goes toward maintaining existing systems? A third? A quarter? You have no idea, for one simple reason: in your system, everything is called a “ticket.”

Don’t talk to me about “tickets” anymore. What is a ticket? A user story? A technical task? A grocery list? A contract? A Post-it note stuck on the fridge? A love letter? A date with someone? A ballot for the U.S. presidential election?

“Ticket,” the perfect word for saying nothing

The word refers to the information carrier in a ticketing system, that is, “a software tool used by companies to track, manage, and organize service requests and issues from customers, employees, or internal teams” (definition: Zendesk). You could therefore replace “ticket” with “sheet” without losing any meaning, since the word says nothing about the content.

The use of this word also reflects a perspective centered on the person processing the request rather than the user. It’s therefore a matter of workload management. So, with just a touch of exaggeration, I picture you sitting at your small, gray desk. You arrive at 9 a.m., and a stack of tickets awaits you to your left. As you process them, more arrive and pile up. When the clock hanging on the opposite wall finally deigns to strike 6:00 p.m., you get up, close your briefcase, and leave. A great day, but where, exactly, is the user in all of this?

This scenario is telling. The word ticket implies a process-oriented mindset, in which success metrics include an empty queue, processing time, the number of closed tickets, and so on. In contrast, the product perspective focuses on the user and the asset used to serve them (output and outcome). The difference is fundamental.

You might say I’m splitting hairs, but I don’t think so: words matter. A poor choice of words boxes us in and leaves blind spots unexamined. Vague words lead to vague thinking, which is unlikely to result in concrete and useful outcomes. This vagueness isn’t going to disappear by magic (what is an “agile project manager,” for example?).

The problem isn’t the existence of the generic term itself, but its indiscriminate use in place of more precise terms, at a time when the distinction matters. Most tools, incidentally, do make these distinctions. It’s in spoken language that everything gets lost.

Let’s start from scratch. When you’re getting ready to develop, you can:

• Work in the immediate interest of the user: developing a User Story, resolving a bug
• Work in the user’s future best interest: PoC or A/B testing (knowledge generation), but also technical tasks. We’ll go into more detail on this point later.

In saying this, we’re assuming that the company’s interests and those of the user are always aligned: no dark patterns or short-sighted features that attract but don’t retain the user.

A User Story adds value for the user

A User Story, according to Kent Beck, is a unit of functionality that adds value for the user, small enough to be developed in a short iteration. In practice, we try to make it as small as possible (atomic) to minimize tunnel vision.

In this sense, a User Story is therefore a feature that:

1. Once deployed, adds value for the user;
2. Cannot be further broken down functionally (atomicity).

You’re free to create umbrella items (epics, features) to group different User Stories together. I won’t go into detail about that today, because the only functional item you can deploy to production is a User Story. So you really need to start with that.

Examples:

• Enable a field-by-field comparison of two products
• Allow products to be sorted in ascending order of price
• Improve the loading time of the landing page

Improving the landing page’s load time is certainly a borderline case (it’s a non-functional requirement), but it enhances the user experience and, as a result, reduces the bounce rate and benefits the company. It is therefore indeed a User Story.

On the other hand, “upgrading the database schema” will never, under any circumstances, be a User Story. It is a technical task necessary for the development of a User Story, which must be deployed at the same time as the other tasks that comprise it.

From experience, if a User Story breaks down into many technical tasks, it’s probably because it could be broken down further functionally. If there are more than 2 or 3 tasks, you really need to take a hard look at it.

The technical task, invisible yet indispensable

A technical task is a piece of work that, if deployed on its own, provides no value to the user. The user doesn’t know about your technical tasks and couldn’t care less!

As we’ve seen, these are primarily the tasks that make up a User Story. These tasks may not need to be systematically formalized, since they have no independent existence outside of a User Story. This is especially true when a User Story is small.

But, outside of User Stories, you’ll also find:

• Refactoring, which preserves the code’s ability to evolve, and thus its ability to deliver quickly over the long term
• Tasks that improve the Developer Experience (DX), foremost among which is the CI/CD pipeline
• Security-related tasks, to prevent a massive data breach and some serious negative publicity
• And it can even lower your cloud bill: in the end, that’s money you can invest in new features.

In other words, technical tasks all preserve or increase the future ability to produce value, as perceived by the user.

Conclusion

Your backlog (product backlog or sprint backlog, if you use one) mostly contains two types of work:

• User Stories, which provide short-term value to users;
• Technical tasks not tied to a User Story, which add long-term value for users.

Prioritizing the backlog therefore comes down to balancing different time horizons: delivering value to users now, or delivering value to the company now so that it can deliver value to users later.

Treating both types interchangeably as “tickets” makes this trade-off invisible. For those who manage IT assets (CEO, CTO), however, this distinction is essential!