How to write user stories
employers value

User stories describe what users need in small, valuable pieces the team can build and test. The familiar format — As a [user], I want [goal], so that [benefit] — keeps attention on people and outcomes. Good stories follow the INVEST checklist that Agile Alliance documents: independent, negotiable, valuable, estimable, small and testable.¹ Acceptance criteria, often written in given–when–then form, define what "accepted" means.²

Stories work within a wider system. The Scrum Guide describes the product backlog and the Definition of Done, a formal description of the quality an increment must meet.³ Stories are not complete specifications; they're placeholders for conversation, refined by the product owner and developers together. Story writing is a core skill for business analysts, whom AmbitionBox lists in India at a typical ₹9.6–10.7 lakh,⁴ and for product owners at ₹23–25.4 lakh.⁵

INVEST criteria for good stories

6

Parts of given–when–then criteria

3

Typical business analyst pay in India (AmbitionBox)

₹9.6–10.7 lakh

Typical product owner pay in India (AmbitionBox)

₹23–25.4 lakh

Table: How user story skills are assessed (editorial summary)

Table: A user story with acceptance criteria (illustrative)

Table: How user stories developed (editorial summary)

• Ten stories following INVEST
• Acceptance criteria in given–when–then
• An epic split into thin slices
• Unhappy paths covered
• A Definition of Done you helped write
• A verified user stories certificate

Show delivery impact: "Rewrote claims epic into thin stories with testable criteria; first slice delivered in three days; refinement time halved."

"What makes a good user story?"

A real user, a clear goal and benefit, small enough for a sprint and testable acceptance criteria.

"How would you split this large story?"

By workflow step, business rule, user type or happy vs unhappy path — each slice still valuable.

"Acceptance criteria vs Definition of Done?"

Criteria are specific to a story; the Definition of Done applies to every item.

"Who writes stories?"

Typically the product owner or BA, refined with the whole team.

"Should technical tasks be user stories?"

Not always; enabler or technical items can be written differently, but link them to user value.

• "How are stories refined here?" — process.
• "Is there a Definition of Done?" — quality standards.
• "How big is a typical story?" — slicing culture.
• "Who accepts stories?" — ownership.

Table: Roles that write user stories and typical pay in India (AmbitionBox, October 2026; indicative)

Table: Common user story tools (editorial guidance)

• Junior BA / QA — reads and tests stories.
• Business analyst — writes stories.
• Product owner — owns the backlog.
• Product manager — product direction.
• Product leader — product practice.

1. Week 1: Write — Ten stories with criteria for an app you know.
2. Week 2: Split and prove — Split an epic; take the User Stories Certification.

Related: Product Owner, Agile and Scrum and PRDs. Guides: product owner, agile and Scrum and PRDs.

• Writing — new stories from discovery.
• Refining — with developers and QA.
• Splitting — large items into slices.
• Clarifying — answering questions in sprint.
• Accepting — checking criteria are met.
• Pruning — removing stale stories.

"How do you write stories for an API?"

The user is the developer or system consuming it; focus on what they need to do and why.

"What's a spike?"

A time-boxed investigation to reduce uncertainty before estimating a story.

Table: A first-90-days plan (editorial guidance)

Learn the team's conventions first, then raise the quality of stories one improvement at a time — testable criteria, explicit unhappy paths and thinner slices. Use story mapping for big features so the team sees the whole journey.

AI tools can turn a PRD or meeting notes into a set of draft stories and acceptance criteria in seconds. That saves time, but drafts often include vague criteria ("should be fast"), invented requirements or slices that aren't independently valuable. Treat AI output as a starting point and review it against INVEST and your Definition of Done.

AI is also useful for spotting gaps: asking it to list edge cases, error states or accessibility considerations for a story often surfaces things humans miss. Stories for AI features need special criteria, such as quality thresholds on an evaluation set and behaviour when the model is uncertain. In interviews, show that you can write stories well yourself and use AI to make them more complete.

Splitting is the skill that separates good story writers from great ones. Aim for vertical slices — each touching every layer needed to deliver value — rather than horizontal ones like "build the database". Useful patterns include splitting by workflow step (upload, review, submit), by business rule (one document type first), by data variation (one city first), by user type and by happy versus unhappy paths. After splitting, check that each slice still delivers something a user could notice. If not, combine or reslice. Thin slices reduce risk and speed feedback.

Story mapping, popularised by Jeff Patton, arranges user activities left to right in the order people experience them, with stories stacked beneath each activity by priority. The top row forms a "walking skeleton" — the thinnest version of the whole journey — which becomes the first release. Lower rows add depth in later releases. Mapping a feature this way helps teams see gaps, avoid building one step perfectly while others are missing and agree what a valuable first release looks like. Run it as a workshop with product, design, engineering and business stakeholders, using real user scenarios.

"Stories replace documentation." They summarise needs; context, designs and decisions still need a home.

"Every task must be a story." Technical work can be framed differently, as long as its value is clear.

"Bigger stories are more efficient." Thin slices deliver feedback sooner and reduce risk.

• Stories with no user or benefit.
• Huge stories that span sprints.
• Vague acceptance criteria.
• Ignoring errors and edge cases.
• Treating stories as contracts.

INVEST and given–when–then come from Agile Alliance; backlog and Definition of Done concepts from the 2020 Scrum Guide; and India pay from AmbitionBox (read October 2026). The example story, splitting guidance and history are editorial. Science of Apps publishes the free test linked here. Last reviewed October 2026.

• User story — a small feature described from a user's view.
• INVEST — a checklist for good stories.
• Acceptance criteria — conditions for accepting a story.
• Definition of Done — shared quality standards for completion.
• Epic — a large body of work split into stories.