Technical story
"As a server, I want an index on the invoices table, so that I can respond faster" exists in almost every backlog in the world and communicates nothing. The fake user is not a writing slip: it is the consequence of a misunderstood rule. When the organization requires every item to take the form of a story, the team complies with the form and gives up the content. The damage is twofold: the story cannot be prioritized, because it says neither whom it serves nor how much it is worth, and it hides the conversation that was actually needed, which was technical and called for technical judgement.
The three honest ways out
- Find the real beneficiary and their value. Often they exist and nobody has looked for them. The index on the invoice table does not serve the server: it serves the freelancer who waits four seconds every time they open their list, and the value is expressed in abandonment or in support requests. When the beneficiary appears, the item becomes a legitimate story again.
- State it plainly as technical work, with its economic justification: "reindex the invoice store to sustain next year's expected growth." It can be called a technical item, an FDD-style feature, a spike, or an enabler, and none of those forms needs a template.
- Turn it into a constraint or a criterion of the Definition of Done. When the work expresses a quality that must always be met (response time, accessibility, encryption), it does not belong in an item that is done once, but in a criterion that is verified in every increment (see Non-functional requirements).
The dishonest way out—inventing a user—satisfies the form and disables the three decisions that needed to be made: who benefits, how much it is worth, and how it is verified.
Honest Technical Story vs. Disguised Task
It is the distinction most often used in refinement, and it has a simple test:
| Honest technical story | Disguised task |
|---|---|
| Produces a change that someone identifiable needs. | Is a necessary step of something else. |
| Can be postponed, discarded, and explained to someone non-technical. | Cannot be postponed without blocking the story it serves. |
| Makes sense outside the context of another item. | Makes no sense outside the context of another item; its place is inside it. |
Humanizing Work sums up the rule: if the item makes no sense outside the context of another, it is a task. Applying this test clears out much of the backlog, because many of the technical items that clutter it are tasks belonging to stories that are already on the list.
Technical Debt and Platform Teams
Technical debt, stated as work with no beneficiary, always loses out to a new feature. Stated with its observable effect—how much it slows down each change, how many incidents it causes—it competes on equal terms. The framing that works is the one based on interest: instead of "we need to refactor the billing module," say "every change to billing costs twice as much, one in three causes an incident, and it will stay that way until it is restructured." That makes it a product decision, not a concession to the technical team.
There is one case where the "technical user" is not a fiction: platform teams, whose product is an internal platform. There, whoever develops is a real customer, with needs and alternatives, and stories with developers as users are legitimate and necessary.
Technical Stories and AI
AI-assisted code generation can produce technical debt quickly, because plausible code is not always maintainable. Stating cleanup work in terms of its observable interest is even more important when the volume of code grows fast.
A data point from a verified source: the July 2025 METR study found that 16 experienced developers took 19% longer when working with AI on their own repositories, even though they believed they had been 20% faster. Perceived speed is not actual speed, and debt that accumulates unmeasured makes matters worse.
Common mistake
Inventing a technical user. "As a database, I want…" satisfies the template but disables prioritization, and it also prevents the technical conversation that was actually needed. When work has no visible user, choose one of the three honest ways out: find the real beneficiary, state it plainly as technical work with its economic rationale, or turn it into a criterion of the Definition of Done.
Resources
🏦 Skill User storiesState of the art and development guide · Skill Arena
📄 Historias de usuario v.5.0 [User Stories v.5.0, in Spanish]Free download · Scrum Manager · Jan 2026
📄 Scrum Master en equipos con IA v.1.0 [Scrum Master in Teams with AI v.1.0, in Spanish]Free download · Scrum Manager
References
- Cohn, Mike. (2004). User Stories Applied. Addison-Wesley.
- Skelton, Matthew; Pais, Manuel. (2019). Team Topologies. IT Revolution.
- METR. (2025). "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity."
See also
Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.