Writing User Stories That Carry Intent, Not Just Tasks
If you have spent any time around Scrum, you have seen the format: 'As a user, I want a button, so that I can click it.' It checks the boxes and teaches nothing. A user story is meant to carry intent — the human reason behind a request — into the work, so that a developer making a hundred small choices makes them in the right direction. When the intent is missing, the team builds exactly what was written and still misses the point.
The Scrum Guide does not actually require user stories. It talks about Product Backlog items and the Product Backlog. User stories are a popular technique for expressing those items, not a rule. That distinction matters: the goal is a backlog the Developers understand and the Product Owner can order by value, and the story format is just a reliable way to get there.
The three parts that matter
A useful story answers three questions. Who is this for? What do they want to be able to do? And why does it matter to them? The classic 'As a / I want / so that' template exists to force the third question, which is the one teams most often drop. The 'so that' is where the value lives. A story without it is a task wearing a costume.
Consider the difference. 'As a site manager, I want to export the daily log as a PDF' is a task. 'As a site manager, I want to export the daily log as a PDF, so that I can hand inspectors a record without giving them system access' tells the team what success looks like and opens better solutions. Maybe the real need is a read-only share link, not a PDF at all.
How to write ones that hold up
Anchor it to a real person. Name the actual role, not a vague 'user.' A procurement lead and a frontline worker want different things; the story should say which one.
Lead with the outcome, not the screen. Describe what the person needs to accomplish, leaving room for the team to find the best way to deliver it. Prescribing the interface too early throws away their expertise.
Add acceptance criteria, not a design. List the conditions that make the story done — the checks a reviewer can confirm. These turn 'so that' into something testable without dictating implementation.
Keep it small enough to finish. If a story cannot plausibly be completed within a Sprint, split it along the value it delivers, not the technical layers. Two thin slices that each work beat one big slice that half-works.
Refine it together. Backlog refinement is where the team asks questions and the Product Owner clarifies. A story is a placeholder for a conversation, not a contract handed down.
Signs a story has lost its intent
Every story names the same generic 'user,' so no one can picture who is actually affected.
The 'so that' clause restates the 'I want' — 'so that I can export' — which adds words but no reason.
The story specifies buttons, fields, and layouts, leaving the team to type, not to think.
It is too big to finish in a Sprint and keeps rolling forward untouched.
In 2022, with teams spread across home and office and budgets squeezed by rising costs, the cost of building the wrong thing is higher than ever. A user story that carries intent is cheap insurance: it lets a developer working alone at 9 p.m. make the same call the Product Owner would have made. That is the whole point of writing it down.
If your team wants backlogs that drive value instead of just listing tasks, XNM's program & project delivery advisory can help you sharpen how the work is framed.