User Stories · Business Analysis Notes

What it is#

The BABOK® Guide describes a user story as a brief description of functionality or a quality that users need from a solution to reach a business goal. Teams use stories to capture and prioritize needs, to estimate and plan, as the basis for acceptance tests, and as a unit for measuring work.

The statement. The common format, sometimes called a statement of value:

As a <role>, I want <capability>, so that <business value>.

For example: “As a passenger, I want to buy a train ticket online, so that I save time and avoid the ticket office queue.”

Acceptance criteria spell out what the story means and where its boundaries are. Business analysis training materials recommend the behavior-driven development (BDD) form: Given a context, When an event happens, Then a result follows. Each criterion is one scenario that can become a test.

Maglinets’ lecture on Extreme Programming (XP) shows an earlier form of the same idea: acceptance tests written on the back of the story card in three sentences (setup, operation, verification). The same lecture describes how XP deals with size: a story too big to estimate or to fit an iteration is split, and when the team cannot estimate a story at all, it runs a short investigation (a spike) first.

INVEST is a widely used quality checklist, also covered in the training materials:

Letter	Criterion	Meaning
I	Independent	Can be built and delivered without waiting for other stories
N	Negotiable	Details can change until it enters an iteration
V	Valuable	Delivers value to a user or the business
E	Estimable	The team can estimate the effort
S	Small	Fits comfortably into planning and one iteration
T	Testable	Gives enough information to write tests

When to use it#

In agile and other iterative work with a backlog and frequent feedback.
When stakeholders find formal specifications hard to read. Stories are easy to understand and can come out of almost any elicitation technique.
To build shared understanding of the domain through conversation between business and team.

The BABOK Guide also names the limits. Stories are not meant for long-term storage or detailed analysis. Without traceability to business goals, the team loses the big picture. Regulated environments may need extra documentation. So complement them:

complex flows with many branches → use cases;
data, rules, and interfaces → models and specifications linked to the story;
goals → epics or objectives the stories trace to.

How to do it#

Start from goals and users. Who uses the solution (personas or user classes), and what are they trying to achieve?
Write the statement with a specific role, a need, and a benefit. Keep solutions out of it.
Discuss it with the team and a user representative. The card is a reminder to talk, not a contract.
Write acceptance criteria in Given/When/Then: the main path, key rules, errors, and boundaries.
Check INVEST, and split the story if it fails.
Estimate, prioritize, and link it to its epic or goal.
Refine it before the iteration and confirm it at the review against its criteria.

Common ways to split a large story: by workflow step; by business rule; by data variation; main path first, error paths later; simple version first, enhancements later; one channel at a time. Each slice should still deliver something a user can see.

Example#

The training materials describe one feature, viewing login history, both as a user story with four Given/When/Then criteria and as a classic use case. Seeing both side by side is a good way to learn when each format fits. Here is a story for The Workshop, a fictional chain of bike-repair workshops:

Template

WS-12 Ready notification
As a customer who has left a bike for repair,
I want a message as soon as my bike is ready,
so that I can collect it without phoning the workshop.

AC1 Message sent
  Given a job in status "In repair" for a customer who accepts messages
  When the mechanic marks the job complete
  Then the customer receives a message with the workshop address and opening hours

AC2 Contact preference
  Given the customer chose email as the contact method
  When the job becomes ready
  Then the message is sent by email, not by text

AC3 Delivery failure
  Given the message cannot be delivered
  When the provider reports the failure
  Then the job appears on the front desk's call list

AC4 No duplicates
  Given a ready message was already sent for the job
  When the job is set to ready again
  Then no second message is sent

INVEST check: the story works for walk-in jobs too, so it does not depend on online booking (Independent). If text and email turned out to be too much for one iteration, AC2 could become its own story (Small).

Common mistakes#

“As a user…” → name the real role or persona; different users need different things.
No “so that” → without the value you cannot prioritize or spot a better solution.
A solution in the story (“I want a drop-down list”) → describe the need; design comes later.
An epic in disguise → split it into slices that each deliver visible value.
Technical tasks written as stories (“As a developer, I want a database”) → treat them as tasks under a real story.
Criteria that repeat the story or describe clicks → state observable outcomes, one scenario per criterion.
No link to goals → trace stories to epics and business objectives.

Template#