AI writes the code now, so your stories need more detail, not less

"Fix the export." On plenty of boards, that is a perfectly good story. Everybody knows which export, knows what is wrong with it, and knows what fixed would look like, because they were in the standup where it came up. The story is a bookmark for a conversation that already happened.

Hand that same line to a coding agent and watch what comes back. It will fix an export. It will do it quickly, with tests, and with a tidy summary of what it changed. It just may not be the export you meant, or the problem you meant, and you will only find out once you read the diff.

That is the shift I want to make the case for. As more of the typing gets automated, the written story stops being a bookmark and becomes the actual specification. So stories need more care than they did when a human was on the other end, not less.

Why do vague stories hurt more when AI writes the code?

A developer who gets a vague story asks a question. They lean over, or drop a comment, or at the very least hesitate before building something big on a guess. That friction was annoying, and it was also doing a lot of quiet quality control.

An agent mostly doesn't hesitate. It fills every gap in the story with the most plausible assumption and keeps going. And because it is fast, a wrong assumption no longer costs you an afternoon of someone's time before it surfaces. It costs you four hundred lines of well-structured, confidently wrong code in a couple of minutes, which you then have to read carefully enough to notice it is wrong. Reviewing is slower than writing, and reviewing code that looks right is the slowest kind.

There is a second, less obvious loss. The context that used to live in people's heads (why this customer cares, what we tried last quarter, which edge case bit us) never reaches the agent unless someone writes it down. A team that talks a lot and writes little got away with it when the people who talked were also the people who coded. That link is getting weaker.

What should a story contain when an agent will build it?

Nothing exotic. The same things a good story always needed, just written down rather than assumed. I would check for five:

1. The problem, and who has it. Not "add a filter", but who is struggling with what, and why it matters now. This is what lets the agent (and the reviewer) judge whether a solution actually solves anything.
2. What done looks like. Acceptance criteria written as statements you can check. "Exports include archived stories" is checkable. "Export works better" is a wish.
3. What you are not doing. Agents are eager. Without a boundary, a small fix grows a refactor and two new settings. One line of "out of scope" saves a surprising amount of review.
4. How to verify it. The steps you would take to convince yourself it works, including the awkward case you already know about.
5. Where to look. A related story, the part of the codebase involved, the customer thread. Pointers, not an essay.

Here is the export story again, rewritten with that in mind. The details are invented, but the shape is the point:

Title: Include archived stories in the Excel export

Why: Two customers use the export for quarterly reporting to their
clients. Archived stories are missing, so finished work from earlier
in the quarter disappears from their reports.

Done when:
- Archived stories appear in the export, with their archive date
- Active stories export exactly as they do today
- Deleted stories are still excluded

Out of scope: changing the column layout or adding new filters.

Check: archive a story, export, confirm it is present with the date.
Then delete a story and confirm it is not.

That took maybe three minutes to write. Nothing in it is clever. But every line removes a guess, and each guess the agent no longer has to make is one you no longer have to catch in review. It also happens to be a better story for a human, which is rather the point: none of this is new advice. The basics of a good user story have not changed. What changed is how much it costs to skip them.

Isn't writing detailed stories the slow part now?

Yes. And I think that is fine, because it is where the slow part belongs.

When I first started working with coding agents, I half expected the backlog to become less important. If a machine can build a feature from one sentence typed into a chat window, why keep a board at all? It took a few weeks of reviewing plausible, wrong diffs to see it the other way round. The time the agent saves on typing does not disappear. It moves to the front, into deciding exactly what you want, and it shows up at the back as review time when you skip that step.

That said, I don't want to oversell this. For a typo, a clear bug with a clean reproduction, or a mechanical change, a one-line story is still fine. An agent that can read your codebase will cope, and writing a page of acceptance criteria for a colour change is its own kind of waste. My rough rule: if the change involves a choice a user will notice, or something you would have to explain to a new colleague, write it down. If it doesn't, don't.

Why not just write the prompt in the chat?

Because the chat is gone the moment you close it.

A prompt in a chat window is a spec only you and the agent ever saw. Your teammate reviewing the pull request doesn't have it. The product owner checking whether it is done doesn't have it. You, three months from now, trying to remember why the export behaves this way, certainly don't have it. A story in the backlog is the same brief, but somewhere the whole team can read it, comment on it and check the result against it. There is a lot more to say about that record, and it deserves its own post.

This is also why I care about where the words go. In Scrumpy, a story has separate fields for the description, the acceptance criteria and a test description, so the "done when" and the "check" from the example above each have a home instead of being buried in one long paragraph. Story templates can prefill that structure for the kinds of work you repeat. And yes, there is AI in there too: the writing assistant can turn rough notes into a clearer story or draft acceptance criteria, and a team can give it a short house-style playbook so it writes the way you do.

I use it, and I would still add one warning. Letting AI draft the spec is fine. Letting it make the decisions in the spec is not. If the same model invents the requirements and then implements them, nobody on your team actually decided what to build. The draft is a starting point for your thinking, not a stand-in for it.

The skill that got more valuable

For a long time, writing a crisp story was treated as a product owner chore, the admin you did before the real work. With agents in the loop it is starting to look like the real work. The team that can say precisely what it wants, in writing, will get far more out of the same tools than the team that types "fix the export" and hopes.

If you work solo, this applies twice over: you are the product owner, the developer and the reviewer, and the story is the only place those three roles can check in with each other. Keep the stories short when the change is small. When it isn't, give the agent what you would give a sharp new colleague on their first day. If you want a board that is built around exactly that kind of story, Scrumpy is free to try, and you can have your first properly specified backlog up before lunch.