How to write a user story when you’re not the one building it

A user story is the smallest unit of a build brief. Written well, it gets you what you pictured. Written badly, it becomes the invoice you didn’t expect. Here’s the format, the four checks that tell a buildable story from a landmine, and a worked example.

A founder I worked with last year approved a story in about four seconds. It read: “As a customer, I want to manage my account.” She nodded, dragged the card into the sprint, and moved on to a sales call. Three weeks later the build team came back with a bill for the account page: profile editing, password reset, two-factor setup, billing history, plan changes, data export, account deletion. All of it defensible. All of it “manage my account.” None of it what she had in her head, which was a single screen where a user could change their email.

That gap is what a user story is supposed to close, and it’s why learning how to write a user story matters more for the person paying for the build than for the developers doing it. A user story is one sentence describing something a specific person wants to do with your software and why, small enough to build and check in a few days. The canonical format, popularized by Mike Cohn and the early Extreme Programming teams, is: As a [type of user], I want [to do something], so that [I get some benefit]. That’s the whole template. The hard part isn’t the sentence. It’s writing one that can’t quietly turn into three weeks of work you never agreed to.

What a user story is, and what it is not

A user story is not a spec. This trips up founders from finance and consulting backgrounds, who expect a document that pins down every detail up front. Cohn’s phrase for a story is “a promise for a conversation.” The card is a placeholder. It says we agree this is worth building and worth talking about, and it trusts that you and the build team will settle the details when the work comes up, not months before.

That’s the “3 C’s” you’ll see referenced everywhere: Card, Conversation, Confirmation. The card is the one-liner. The conversation is where you and the developer figure out what the screen actually does. The confirmation is how you both know it’s finished, which we’ll get to, because it’s the part founders skip and the part that costs them.

So a story is deliberately incomplete. But there’s incomplete-on-purpose and incomplete-because-it’s-vague, and the difference is the entire game. “As a customer, I want to manage my account” is not a small promise for a conversation. It’s a whole feature area wearing the costume of a single story. The build team can price it at anything from a day to a month, and whatever they pick, you’ll be surprised.

The user story template, and the three parts you actually own

Here’s the format again, filled in properly:

As a first-time buyer, I want to change the email address on my account, so that I still get order updates after I switch jobs.

Three slots. As a who, I want what, so that why. People call the “who/what/when/where/why” the 5 W’s of a story, but you as the founder really only own three of them: who it’s for, what they’re trying to do, and why it matters. The when and where belong to the conversation with the build team.

The three slots are not decoration. Each one is a lever:

The who stops you building for a generic “user” who doesn’t exist. A first-time buyer and a returning power user want different things from the same screen. Name the real person and half the ambiguity disappears.

The what is a single action, not a capability. “Change the email address” is an action. “Manage account settings” is a capability, and a capability is a bucket that holds a dozen stories. If your what contains the word “manage,” “handle,” “support,” or “and,” stop. You’ve got more than one story.

The so that is the part everyone drops, and it’s the most useful. It tells the build team why you want the thing, which lets them propose a cheaper way to get you the same outcome. Half the time the developer’s version of the so that is better than the feature you asked for. You only find that out if you wrote it down.

The four checks that tell a buildable story from a landmine

Agile teams use a checklist called INVEST for this. It’s good, and it was written for practitioners. Here’s the founder translation: the four questions I actually ask before a story goes into a sprint I’m paying for.

Can it be built and shown to me on its own? A good story is a slice through the whole product, not a layer of it. “Build the database for accounts” is a layer. You can’t see it, can’t test it, can’t tell if it’s right. “Change my email address” cuts through the database, the screen, and the confirmation email all at once, and ends with something you can look at. If a story only makes sense as part of a bundle, it’s not a story yet.

Is it small enough to finish in a few days? Not because developers can’t do big things, but because big stories hide surprises, and surprises on a fixed budget come out of your pocket or your timeline. If you can’t imagine the thing being done inside a week, it’s a boulder. Split it. “Change my email” and “verify the new email before it takes effect” are two stories, and pricing them separately protects you.

Could I reject it on delivery? This is the one founders never think about until it’s too late. A story you can’t fail is a story you’ll pay for twice. “Improve the checkout experience” can never be wrong, which means you can never send it back. “Show the total, including shipping, before the pay button” either does or doesn’t. Write stories you could refuse, and you keep leverage all the way to delivery.

Is it about the user, not the plumbing? “Add a Redis cache” is a technical task, and technical tasks are the build team’s call, not yours. Your stories describe what someone can do with the product. If you find yourself writing about databases, queues, or caches, you’ve wandered onto the developer’s side of the table. Hand it back and stay on yours.

Acceptance criteria: how a story stops being a wish

Here’s where the four-second approval goes wrong and where you get your money’s worth. A story is the promise. Acceptance criteria are the confirmation, the checklist that says exactly what “done” means, written before the work starts. They’re the difference between a story you hope gets built right and one you can objectively accept or reject.

For the email story:

• The user can open account settings and see their current email.
• Changing it sends a verification link to the new address.
• The email doesn’t actually change until the link is clicked.
• If the new address is already used by another account, the user sees a clear error.
• Order-update emails go to the new address only after verification.

Notice what those five lines just did. They turned a one-sentence wish into something a developer can price accurately and you can check line by line on delivery. They also surfaced a decision (what happens to a duplicate email?) that would otherwise have become a mid-sprint question, or worse, a silent assumption you’d discover in production. Acceptance criteria are cheap to write and expensive to skip. We go deeper on this in our piece on writing acceptance criteria a non-technical founder can actually enforce.

A worked example: from a vague ask to a story you can ship

Start with what founders actually say in a kickoff: “I want users to be able to invite their teammates.”

That’s a capability, not a story. It’s the “manage my account” trap in a new outfit. Run it through the checks and it splits into stories, each of which you can see, size, and reject:

As an account owner, I want to send an email invite to a teammate, so that they can join my workspace without me sharing my password.

As an invited teammate, I want to accept an invite and set my own password, so that I have my own login instead of a shared one.

As an account owner, I want to see which invites are still pending, so that I can chase the ones that haven’t joined.

Three stories where there was one line. Each one is a few days of work, each ends in something you can look at, and each has its own acceptance criteria. When the build team quotes them, you can decide that “see pending invites” is nice-to-have and drop it to hit a deadline. You couldn’t have made that call on “let users invite teammates,” because you couldn’t see the seams. Good stories give you seams to cut along. That’s most of what they’re for.

Stories like these don’t float in space. They sit on your product backlog, ordered by what matters, and they ladder up to the bigger picture you set in your product requirements document. The story is the atom. The backlog is the molecule. The requirements doc is the compound.

Write fewer, write them tighter

The instinct, when you first learn the format, is to write forty stories in a weekend and hand over a stack. Don’t. A pile of vague stories is worse than none, because it gives everyone false confidence that the thinking is done. It isn’t. Vague stories are what scope creep is actually made of: the quiet expansion of “manage my account” into seven screens, discovered one invoice at a time.

Write the five or six stories for the next slice of work. Make each one pass the four checks. Give each one acceptance criteria you’d be comfortable enforcing. Then talk them through with whoever is building, because the card was always a promise to have that conversation. Do that and the story does its real job, which is not documentation and not process. It’s keeping the thing that gets built and the thing you pictured in the same room.

FAQ

What are the 3 C’s of a user story?
Card, Conversation, and Confirmation. The Card is the one-line story. The Conversation is the discussion between you and the build team about what it really means. The Confirmation is the acceptance criteria that define “done.” The format comes from Ron Jeffries, one of the authors of Extreme Programming, and it’s a reminder that the sentence is a starting point, not the whole agreement.

What is a user story example?
“As a first-time buyer, I want to change the email address on my account, so that I still get order updates after I switch jobs.” It names a specific user, a single concrete action, and the reason behind it. Contrast that with “As a user, I want to manage my account,” which names no one, describes a whole feature area, and can’t be priced or rejected.

What is a user story template?
The standard template is: As a [type of user], I want [to do something], so that [I get some benefit]. Fill all three slots. If the middle slot contains “and,” “manage,” or “support,” you almost certainly have more than one story and should split it.

What are the 5 W’s in user stories?
Who, what, when, where, and why. In practice a founder owns three of them: who the story is for, what they want to do, and why it matters. The when and where (which screen, which state, which edge case) get settled in conversation with the people building, and get pinned down in the acceptance criteria.

What is the 3-5-3 rule in agile?
It refers to Scrum’s structure: 3 roles, 5 events, and 3 artifacts. It’s about how a Scrum team is organized, not about how to write a story, so it’s a different question from this one. If you’re commissioning a build rather than running the team yourself, the story format above matters far more to you than the ceremony count.