Does Your User Story Carry Intent? A Side-by-Side Look
When teams went remote in 2020 and stayed hybrid into 2021, a quiet problem surfaced in a lot of backlogs. With fewer hallway conversations to patch over gaps, the words on the card had to do more work. A user story that once survived because someone could ask a question across the desk now stalled because nobody knew what it actually meant. The fix isn't more ceremony. It's writing stories that carry intent.
Scrum itself says very little about how to write a Product Backlog item. The Scrum Guide treats the format as the team's choice. User stories are simply the most popular convention, and the popular template — as a [role], I want [capability], so that [outcome] — is useful only when the third clause is honest. Drop the 'so that' and you are left with a feature request dressed up in agile clothing.
What a weak story looks like
Weak stories describe the interface, not the need. They smuggle the solution into the requirement, so the team builds exactly what was written and discovers too late that it solved nothing. They tend to share a few traits.
"As a user, I want a dropdown of provinces." — A widget, not a goal. Why does the user need to pick a province at all?
"As an admin, I want a report." — No outcome, no scope. Which decision does this report support?
"As a customer, I want the system to be fast." — Real need, but untestable. Fast compared to what, measured how?
A story so large it can never finish inside a Sprint, so it lingers across three and blocks everything behind it.
What a strong story looks like
A strong story names a person, a capability, and the outcome that makes the capability worth building — then leaves room for the team to decide how. It is small enough to finish, and it comes with acceptance criteria that tell you when it is done.
It states a real outcome. "As a site supervisor, I want to flag a delivery as short-shipped so that procurement can chase the supplier before the next pour." The 'so that' is testable and tied to a decision.
It is independent and negotiable. The card opens a conversation rather than closing one. The supervisor and the developer can still discuss whether a flag, a photo, or a quantity field serves the goal best.
It is small and verifiable. It fits in a Sprint and carries acceptance criteria — 'the flag appears on the procurement dashboard within one refresh' — so 'done' is not a matter of opinion.
It survives without the author in the room. A remote teammate three time zones away can read it cold and build the right thing. That is the real test of intent.
Notice that the strong example came from the 2021 supply-chain world: short shipments, missed pours, suppliers to chase. The story carried intent because it described what someone was trying to accomplish, not which control to render. Keep the why visible and the rest of the backlog conversation gets easier — estimation, slicing, and prioritization all hang off a goal the team can actually see.
A quick test before refinement
Before you pull a story into a Sprint, run it past two questions. First, can you state the outcome without naming a screen, a button, or a database table? If you cannot, you are holding a solution, not a need, and you have closed off the better ideas the team might have brought. Second, would a developer who has never met the requester build the right thing from the card alone? If the honest answer is no, the intent lives in someone's head, not on the card — and on a distributed team, that head may be offline when the work starts.
None of this requires a heavier process. A good story is often shorter than a bad one, because it stops describing the interface and starts naming the goal. The acceptance criteria do the precision work; the story itself just has to make the purpose unmistakable. When intent is on the card, refinement becomes a conversation about the best solution rather than an archaeology dig for what the requester actually meant.
If your backlog is full of screens instead of outcomes, XNM's program & project delivery advisory can help your teams write requirements that carry intent and survive the handoff.