User stories are how agile teams describe what they’re building, from the user’s point of view. They’re short on purpose. The whole thing should fit on a post-it or an index card so it can sit on a Scrum or Kanban board without anyone needing to squint.

Kent Beck introduced them in 1997 as part of Extreme Programming, as a lightweight alternative to the heavy specs of the time.

The reason they work is that they keep the user in the frame. You can’t write a good story without thinking about who’s affected and why they care.

The format

The standard form is:

As a (User), I want to (Goal), so I can (Reason).

Three pieces:

• User. Who benefits. Be specific. Not “the user,” but the actual person.
• Goal. What they’re trying to do. Not the feature you’re going to build, but what they’re after.
• Reason. Why it matters to them. This is the context that keeps the team from building the wrong thing.

That last piece is the one teams skip most often, and it’s the one that pays off most.

Who writes them

There’s a lot of debate about this. Product Owner? Scrum Master? Tech Lead?

My answer: anyone can write them, and the best results come when the whole team has a hand in it. Refinement is a team sport. The team decides together what’s ready to pull in.

Writing ones that work

The user has to stay at the center. Every story should express something the user genuinely needs.

What about technical stories?

Teams get hung up on things like “update database indexes” or “set up CI/CD.” They feel purely technical, but most of them roll up to a user benefit. Faster queries mean a faster app. A working pipeline means fewer broken releases.

There are edge cases, especially at the start of a project, where the link is genuinely thin. Even then, “user” doesn’t have to mean external customer. Internal users count.

For a much deeper treatment, User Stories Applied by Mike Cohn is the book to read.

Examples

A few that follow the format:

• As a user, I want to download my invoice, so I can pay my order.
• As a user, I want to select my delivery address, so I can receive my package at the right location.
• As a marketer, I want to create personalized discounts, so I can attract more customers to our platform.

What I’ve learned

A handful of things that have helped me over the years:

• Write from the user’s perspective. Technical work usually benefits users indirectly. Surface that link.
• Internal users count. Your colleagues are users too.
• Keep stories small. If you can’t deliver it in a sprint, it’s an epic, not a story.
• Don’t over-engineer the wording. If the team knows what to do, the story is good enough.

The format is a tool, not a religion. The point is shared understanding. If your team has that, you’re doing user stories right.