Tickets Are Not Project Management Anymore. They Are Context.

Story points are on the way out, and good riddance. They were always a negotiation tool wearing a lab coat, and agent-assisted work finished them off: any given task now takes two hours or two weeks with little warning which, so there is nothing left to estimate against.

Half the industry has drawn the obvious conclusion and started asking whether tickets go out with them. If we cannot estimate, and an agent can write the code, what is the ticket for?

We think that question has the right target and the wrong answer. Tickets as an estimation and status-reporting instrument are finished. But that was never the only thing a ticket did, and the other thing it does just became the most valuable artifact in your engineering organisation.

Hallucination stopped being the problem. Specificity replaced it.

The failure mode people prepared for was the model inventing things. In practice that has been beaten down hard enough that it is no longer what ruins your afternoon.

What ruins your afternoon is specificity. A language model is a statistical machine, so absent anything else it hands you the most common answer to the question you appeared to ask. Not the wrong answer. The average one.

Ask it today how to measure AI adoption in an engineering org and it will tell you cycle time, because that is what most of the internet says. Build a product on that answer and you have shipped the metric we already know is broken. The output is plausible, standard, well structured, and wrong for you specifically. There is no error message for this.

The only fix is context: why this work exists, who it is for, what it has to hold up against. Which is a description of a well-written ticket hierarchy.

Three levels, three different questions

The structure most teams already have maps almost exactly onto what an agent is missing.

An initiative carries the why. This is why we are doing it, this is where the money comes from, this is how our customers will use it. That level rarely helps you write a function and is the only thing that tells you whether the function should exist.

An epic carries the use cases. These are the situations this has to handle, this is what a person is trying to accomplish, this is what done looks like from outside.

An issue carries the implementation detail. This is the shape of the endpoint, this is how authorization is handled, this is the rate limit, this is what happens on failure.

Each level answers a question the level below cannot. That was true before agents and it was mostly a nicety, because a human engineer carried the missing levels around in their head. Agents do not have a head to carry it in. Everything they know about your intent has to be written down somewhere.

The property nobody talks about: it is reviewable before execution

Here is the part we think is genuinely underrated now.

A written issue can be reviewed before any code exists. You can read it and ask whether it matches your SOC 2 obligations, your API conventions, the way your team handles auth, the standards you agreed to last quarter. You can fix it in a sentence.

Compare that with the alternative, which is reviewing generated code after the fact. Review is where the bottleneck went. Almost all output measurement now sits on pull requests, and so does almost all review time. Writing code stopped being the constraint. Reading it became the constraint.

So the cheapest possible review is the one that happens on intent, in a paragraph, before an agent turns that paragraph into eight hundred lines. Teams that skip the ticket have not saved a step. They have moved the same review to the most expensive point in the process.

It also changes what review means. Without a ticket, reviewing generated code means asking "is this good?", which is close to unanswerable at volume and is exactly the judgement that fails when a reviewer is tired and the diff is large. With a ticket, the reviewer, human or agent, has a question that has an answer: does this match what was approved?

Context compounds, if you write it down at the time

The second thing you get is accumulation.

When a bug turns up, it goes back onto the ticket it came from rather than into a fresh empty prompt. The bug, the original intent, the use cases, and the reason the decision was made in the first place all sit in the same place. You are not reconstructing the story, you are appending to it.

We have written something like 3,000 tickets since the start of the year. The useful part is not the count, it is that we can open any one of them and see why the decision was made. When an agent works on something today, we routinely see it reach back and pull issue 300 or issue 500 into its reasoning. That only works because somebody wrote down the why at the time, when it was cheap, instead of trying to recover it afterwards, when it is not.

Not everything maps, and forcing it is theatre

The honest caveat, because the version of this advice without it is useless in a real company.

Plenty of work does not belong to an initiative. A security issue turns up and needs patching this afternoon. Something in operations is keeping the lights on. There is no business objective to attach it to, no open epic waiting for it, and inventing one is paperwork pretending to be strategy.

So an issue with no epic and no initiative is fine. What matters is the ratio, and which direction it is moving. You want as much work as possible attached to something, you want the unattached share small and shrinking, and you want it concentrated in the places where it genuinely belongs: incidents, security, operations.

A second number worth watching, which most teams do not: whether epics are actually being closed, or only issues. It is entirely possible to burn down a great many tickets while nothing at the level above them ever finishes.

Unattached work is not neutral. It is your alignment problem.

This connects to something uncomfortable in our own customer data. The highest performers in almost every instance we measure are the people contributing least to the roadmap.

That is not a mystery once you see the mechanism. It is easy to move fast when you answer only to yourself. You build what your own tooling needs, you skip the conversations, and nobody sends it back. Everyone working on roadmap items is two to three times slower, because they have to listen to customers and absorb being told they got it wrong.

Every instrument you are likely to have rewards the first group. Commit counts, pull request counts, velocity, cycle time. All of them go up. Only a measure of what actually landed on the roadmap tells you the difference, which is why we score delivered output per commit as ETV and then ask how much of it attached to a named objective.

Work with no ticket above it is invisible to that question by construction. You cannot report on alignment for work that was never connected to anything.

The cost of skipping it changed

Ticket hygiene used to be for humans who would forget. The penalty for being sloppy was that in eight months nobody could remember why a decision was made, which was annoying and survivable.

The penalty now is different. The thing writing your code takes whatever context it is given and fills the rest with the most statistically ordinary answer available. Skip the why, and it will not stop and ask. It will produce something reasonable, quickly, at volume, and hand it to a reviewer who has no way of telling whether it was what anyone wanted.

Tickets stopped being how you predict the work. They became how you specify it.