OpenAI Select PartnerHow to Write User Stories That Developers Can Build From
A user story describes a feature from the point of view of the person who uses it, in one sentence, with clear conditions for when it is done. Good user stories help founders and developers agree on what to build, and they make estimates and testing much easier.
In this guide 9 sections
When a founder gives me a long feature list, I rewrite it as user stories during scoping. It almost always reveals features nobody needed and steps nobody had thought about.
The format
As a [user], I want [to do something] so that [I get a benefit]. Then list the acceptance criteria that prove it works.
Why user stories help
- They keep the focus on users and outcomes, not technical tasks.
- They are small enough to estimate and build in short cycles.
- Acceptance criteria give testers a clear definition of done.
- They make prioritisation easier: which stories matter for launch?
Examples
| Weak | Better |
|---|---|
| Add a booking system | As a salon customer, I want to see available slots for my preferred stylist so that I can book without calling. |
| Notifications | As a customer, I want a reminder two hours before my appointment so that I do not miss it. |
| Admin reports | As a salon owner, I want to see bookings per stylist each week so that I can plan staffing. |
Writing acceptance criteria
A common format is Given, When, Then:
- Given I have a confirmed booking for 4 pm,
- when it is 2 pm on the same day,
- then I receive a reminder with the time, stylist and address, and a link to reschedule.
Add criteria for errors too: what happens if the slot was just taken, or the payment fails?
Turning an idea into a plan?
Book a free 30-minute call. We will help you shape your idea into user stories and a first release.
Book a free 30-minute call →The INVEST checklist
The Agile Alliance describes INVEST as a check for good stories:
- Independent: can be built without waiting for many others.
- Negotiable: details can be discussed, it is not a contract.
- Valuable: delivers something a user or the business cares about.
- Estimable: the team can estimate it.
- Small: fits within a short cycle.
- Testable: has clear acceptance criteria.
Atlassian's guide to user stories is another practical reference.
Organising stories
- Group stories into larger themes, often called epics, such as "booking" or "payments".
- Order them by the user journey, from sign-up to the core task.
- Mark which are needed for launch and which can wait.
- Put them in a shared backlog that the whole team can see.
The scoping framework helps you decide what stays in the first release.
User stories and the PRD
The PRD explains the why: the problem, the users and the goals. User stories break that into buildable pieces. You need both, and they should agree.
Common mistakes
- Writing technical tasks as stories ("set up the database").
- Stories so large they take weeks to build.
- No acceptance criteria, so "done" is a matter of opinion.
- Forgetting admin and staff users, who also need stories.
How we use them
At Creuto scoping ends with a PRD and a prioritised backlog of user stories, which becomes the plan for each milestone. See how we run delivery in agile vs waterfall.
Frequently asked questions
What is the user story format?
As a [type of user], I want [an action] so that [a benefit]. For example: as a salon customer, I want to see free slots for my stylist so that I can book without calling.
What are acceptance criteria?
Specific conditions that must be true for the story to be complete. They are often written as Given, When, Then statements and are used for testing.
What is the INVEST checklist?
A set of qualities for good stories: Independent, Negotiable, Valuable, Estimable, Small and Testable.
How detailed should user stories be?
Detailed enough that a developer and tester agree on what done means, but not so detailed that they describe every pixel. Designs and the PRD carry the rest.
Who writes user stories?
Usually the product owner or product manager, with input from the founder, designers and developers. Writing them together reveals gaps early.
Need a PRD and backlog written?
We turn ideas into a PRD, user stories and a milestone plan that development can start from.
About Nihar Ranjan Rout
Founder & CEO of Creuto. Over the past 8+ years Nihar has led product strategy and engineering for 50+ products, including mobile apps, custom ERPs and B2B platforms. Creuto is an OpenAI Select Partner. He works directly with founders to turn an idea into a clear plan and a launched product.
More about Nihar · LinkedIn