User Story Template: INVEST in Plain English

Contributor
Apr 13
5 min read

The user story format — "As a [role], I want [capability], so that [benefit]" — is supposed to keep requirements small, user-focused, and conversation-friendly. In practice, most stories don't follow that promise. They're either too vague to act on, too large to finish in a sprint, or written as tasks dressed in story language.

INVEST is the canonical checklist for what makes a user story good: Independent, Negotiable, Valuable, Estimable, Small, Testable. This guide is the plain-English version, with examples of what each criterion catches.

The Basic Format

The standard form:

As a [role], I want [capability], so that [benefit].

Three parts: who, what, why. The "why" is the part teams skip most often, and it's the part that lets the team make good implementation decisions later.

A typical complete story also includes acceptance criteria:

As a [role], I want [capability], so that [benefit].

Acceptance criteria:
- [Specific condition 1]
- [Specific condition 2]
- [Specific condition 3]

The story is the conversation starter. The acceptance criteria are the definition of done.

I — Independent

The story should stand on its own, not depend on another story being completed first.

Why: dependent stories pile up in sprints and can't be reordered. The team gets locked into a sequence even when priorities change.

Bad (dependent): "As a user, I want to filter the search results" — depends on a prior story for the search itself.

Better: Bundle dependent work or order it explicitly. If the search story isn't done, the filter story can't be picked up; that should be visible in the backlog.

Independence is sometimes impossible — features genuinely build on each other. The criterion is aspirational: minimize dependencies, make them explicit when they exist.

N — Negotiable

The story describes what the user wants, not exactly how it'll be implemented. Implementation details are negotiable during the conversation.

Why: stories that prescribe implementation lose flexibility. The team can't propose a simpler approach because the story already specified the complex one.

Bad (prescriptive): "As a user, I want a left-side panel with a tree view of categories with expand/collapse arrows."

Better: "As a user, I want to browse content by category." Acceptance criteria can include "can navigate to any category in under 3 clicks" without specifying the UI pattern.

The story is a placeholder for a conversation, not the final spec.

V — Valuable

The story delivers value to a user. Not to the team, not to the architecture, not to a future story — to a user who'll experience the change.

Why: a backlog full of architectural stories means the team is doing work that doesn't connect to user outcomes.

Bad: "As a developer, I want to refactor the payment service."

Better: Refactoring is sometimes necessary; capture it as enablement work or a tech-debt item, not as a user story. If it must be a story, tie it to user value: "Customers experience consistent payment behavior across web and mobile."

Internal users count. "As a support agent, I want to look up a customer's recent orders" is a valid user story.

E — Estimable

The team can roughly estimate the work. Not precisely — roughly. If you can't estimate, it's because you don't understand the work yet.

Why: stories you can't estimate are stories you can't plan around. You might commit to them and discover they're 4x what you thought.

Bad (not estimable): "As a user, I want to use the platform reliably."

Better: Make it specific enough to estimate. What does reliably mean? What component? What user flow?

If a story isn't estimable, it usually means it's too large (decompose) or too vague (clarify). Sometimes the right answer is a spike: a time-boxed investigation that produces information needed to estimate.

S — Small

The story fits in a sprint, ideally a few days of work. If it's bigger than that, it should be split.

Why: large stories are unpredictable. They sit in "in progress" for the whole sprint. They block other work. They make it hard to ship anything incremental.

Bad (too large): "As a user, I want a complete onboarding experience."

Better: Split into smaller stories. "As a user, I want to see a welcome screen on first login." "As a user, I want to set up my profile." "As a user, I want to invite team members."

Common splitting techniques:

By user role: different stories for different users
By workflow step: different stories for different parts of a flow
By data type: start with the simplest, add others incrementally
By happy path vs. edge cases: main flow first, edge cases later
By platform: web first, mobile next

T — Testable

There's a clear, observable way to determine whether the story is done.

Why: stories without clear completion criteria drift. The team disagrees about whether it's done. QA has nothing to verify against.

Bad (not testable): "As a user, I want the app to be more intuitive."

Better: Specific acceptance criteria. "When a new user lands on the dashboard, they can identify the primary action within 5 seconds (measured by usability testing)."

Testable doesn't mean automatically testable. Some stories test manually, some require user studies, some require A/B comparison. The criterion is that some test exists.

Acceptance Criteria

Specific conditions for "done." Usually 3-7 per story.

A working format is Given-When-Then:

Given a logged-in user with at least one workspace
When they click the workspace switcher in the header
Then they see a list of all workspaces they have access to
And they can switch to any workspace by clicking it

This format is precise but verbose. For simpler stories, plain bullets work:

- Workspace list shows all workspaces user has access to
- Switching workspaces preserves the current page when possible
- Switcher is keyboard accessible

Match the format to the story complexity.

What Stories Aren't For

Spikes (time-boxed research): capture as a spike ticket, not a story
Pure tech debt: capture as a tech debt task
Infrastructure work without user-visible outcome: capture as enablement
Bug fixes: capture as bugs

Forcing everything into the user story format makes the format meaningless. Use it for actual user-facing work.

A Worked Example

A team is building workspace switching. The initial story might be:

As a user with multiple workspaces, I want to switch between them without signing out,
so that I can manage projects across workspaces efficiently.

Acceptance criteria:
- Workspace switcher accessible from any page
- Lists all workspaces the user has access to
- Switching preserves URL context where possible (deep links remain valid)
- Indicates the current workspace clearly
- Keyboard accessible

INVEST check:

Independent: Yes, doesn't strictly depend on other unfinished work
Negotiable: Yes, doesn't prescribe UI pattern
Valuable: Yes, user can do something they couldn't before
Estimable: Yes, the team has rough confidence on sizing
Small: Probably 1-2 days; on the edge of needing a split
Testable: Yes, criteria are observable

That's a workable story.

Anti-Patterns

Story shaped like a task. "Implement the API endpoint" — that's a task, not a story.

Story without why. "As a user, I want X" with no benefit. Often signals the team doesn't know why.

Story split too far. "Story 1: Add the button. Story 2: Make the button work." Splitting should produce stories that each deliver value.

Story too generic. "As a user, I want a great experience." Untestable, unestimable.

Acceptance criteria as implementation. Detailed implementation steps disguised as criteria. They constrain solutions unnecessarily.

Key Takeaway

A good user story is Independent, Negotiable, Valuable, Estimable, Small, and Testable. The format is "As a [role], I want [capability], so that [benefit]" plus 3-7 acceptance criteria. The "why" matters; don't skip it. The story is a conversation starter, not a complete spec. Split large stories by role, workflow step, data type, or platform. Reserve user stories for user-facing work; use other formats (spikes, tasks, bugs) for everything else.

ShiftQuality