Skip to main content
Mobius
Beginner

What is a user story

Also known as: story, agile user story

Definition

A user story is one short sentence that says who needs something, what they want to do and why, so the person building it understands the goal.

Why it matters

A user story keeps the reason attached to the request.

Common mistakes

Writing a technical task, such as "add a database field", instead of what the customer needs.

Related terms

Worked exampleIllustration

Repeat booking story, front and back

Front of the card

As a returning client, I want to rebook my usual treatment from the reminder message, so that I do not have to call during work hours.

Back of the card: done when

  1. The reminder holds a rebook link.

  2. The usual treatment and staff member are preselected.

  3. The confirmation arrives in the same WhatsApp chat.

  4. The clinic calendar shows the booking.

The front says why. The back says when it is done.

Illustration

The story card

As aWho

returning client

I wantWhat

to rebook my usual treatment from the reminder message

so thatWhy

I do not have to call during work hours

The card says who needs it, what they want and why. The why is the point: it lets the developer judge a simpler way to the same goal.

Illustrative: the front of a fictional clinic's repeat booking card. Hide the "so that" line and see what the card loses.

Definition

A user story is a short description of something a person needs from a product, in their own words, usually in the form "As a [who], I want [what], so that [why]". That form is credited to a team at Connextra in London around 2001. In the same year Ron Jeffries described three parts. The Card is the written sentence. The Conversation is where the people who need it and the people who build it agree the details. The Confirmation is the tests that show it works. So the sentence is not the whole story. It is a promise of a conversation, with a "done when" list on the back.

Why it matters

A developer or agency who knows why a client needs something can suggest a simpler way to get there, while one who only gets a task builds exactly the task. For a small business, a brief to a freelancer or an agency written as three or four stories is usually clearer than a page of features. The "so that" line matters most: without it, nobody can tell whether the result solves the problem.

Directly related: Backlog, Prototype, Scrum.

Improvement tips

  • Write the story in the customer's words: "As a new client, I want to see free slots before giving my details, so that I can decide quickly."
  • Add a "done when" list of three or four checks the result must pass.
  • Keep each story small enough to finish and test on its own, and split it if it is not.

Common mistakes

  • Leaving out the "so that" line, so nobody knows what the story is for.
  • Treating the card as a full specification and skipping the conversation with whoever builds it.

Related terms

ProductBeginner

Backlog

A backlog is the one ordered list of everything a product might get next, with the top items small and ready and the bottom items still rough ideas.

ProductIntermediate

Prototype

A prototype is a cheap, early stand in for a product or service, built to show people and learn what to fix before paying to build the real thing.

Project ManagementBeginner

Scrum

Scrum is a lightweight framework in which a small team works in sprints of one month or less, meets for 15 minutes a day and shows a working result each sprint.

Project ManagementBeginner

Sprint

A sprint is a fixed period, one month or less, in which a Scrum team works toward one goal and delivers a working result. The dates stay, the work can flex.

ProductIntermediate

UX

UX, user experience, is everything a person goes through with your business, from the first search to the follow up, and above all where they get stuck.

MarketingBeginner

Value Proposition

A value proposition is the one clear promise of what a customer gets from you: which problem you solve, for whom, and why that beats their other options.

From the blog

Startups vs Stocks: The Real Investing Logic

A careful comparison of public stocks, bonds, funds, private startup exposure, liquidity, diversification, and founder lessons.

Early-Stage Fundraising: What Investors Need to See

How founders can prepare for early fundraising with clearer milestones, traction evidence, dilution thinking, and investor-ready answers.

Quick check

Which part of a user story tells the builder why the work matters?

Choose an answer

Frequently asked questions

Do I need user stories before I start my business?
Only when you brief someone who builds for you, an agency or a freelance developer. Then three or four stories say more than a list of features.
When do user stories first become useful?
The first time you ask someone to build or change something and the result is not what you meant. A story sends the reason along with the request, so there is less to guess.
How do I write a user story without a technical background?
Use the form "As a [who], I want [what], so that [why]" and your customer's words. Then list three or four checks that tell you it is done. No technical terms are needed.
Can I brief a developer without user stories?
Yes, and many owners do. The risk is a brief that says what to build but not why, so the developer cannot suggest a simpler way and cannot tell when it is good enough.
Why do user stories matter for a business already running?
Every change to the website or the booking system is a small brief. Writing it as a story keeps each change tied to a customer need instead of a guess.
What goes wrong when requests are not written as stories?
Features arrive that work but miss the point, such as a rebook button hidden where returning clients never look. Fixing them costs another round of work.
How do I start using stories without slowing down?
Take the next three things you want built and rewrite each one as a story with a "done when" list. It takes minutes, and it changes the conversation with the builder.
How do I check that a story is really done?
Write the "done when" list before the work starts and tick each line when the work is delivered. Ron Jeffries called this part the Confirmation.
What is a user story in plain words?
One sentence that says who needs something, what they want to do and why, plus a short list that says when it counts as done.
What are Card, Conversation and Confirmation?
The three parts of a user story that Ron Jeffries described in 2001. The card holds the sentence, the conversation settles the details, and the confirmation is the checks that prove it works.
Who should write user stories?
Whoever knows the customer best, often the owner or the person who answers customers every day. The builder joins the conversation to agree the details.
How long should a user story be?
One sentence on the front and three or four checks on the back. If it needs more, it is probably two stories.

Sources: Ron Jeffries, "Essential XP: Card, Conversation, Confirmation" (ronjeffries.com, 2001)

Last reviewed: 2026-09-24

I have worked with

What Clients Say

From different fields, at different stages of business

Dan Manto

Eclipse Capital

Real Estate Investment and Finance, USA

Arty McLabin

GameReady

Game Development Education and Outsourcing, International

Anna, Beautician

Anna

Beautician

After I finished a cosmetology course at a leading company, I was confused. I didn't know how to open a business, what to sell from home, or how to bring in clients. Since I reached out to Mobius, everything has changed. We built an organized plan with clear steps and no unnecessary risks. Today I see results, and I'm growing and developing every month.

Mark, Massage therapist, Gan Yavne

Mark

Massage therapist, Gan Yavne

When I finished a massage course, I imagined a different world. I found out it's a hard field, and financial stability isn't easy to find. When I came to Mobius, something changed. We started an organized process and built a business plan. Without Mobius? I probably would have given up. Today I believe in myself and in my own path.

Building a product and unsure of the next step?

Alex helps Israeli teams turn product ideas into something that ships and sells. The first call is free.

+972 055-248-6151. Better on WhatsApp: I am in meetings most of the day and answer as soon as I am free.