WHY THIS MATTERS TO YOU

In Waterfall, the BA produces a formal requirements document. In Agile, the requirements live in the backlog as user stories. The shift is not just format; it is mindset: requirements are no longer a finished artifact that gets handed over. They are a living conversation between the BA, the Product Owner, and the team.

This module covers how to write effective user stories, how to manage a backlog as a BA, and how to write acceptance criteria that actually define done.

User Stories: The Agile Requirement

A user story is a short description of a feature from the perspective of the person who will use it. The standard format is: As a [type of user], I want [an action or capability], so that [the benefit or value].

User stories are not technical specifications. They are conversation starters. The detail lives in the acceptance criteria and in the conversations that happen during backlog refinement.

• As a warehouse receiver, I want to scan a license plate barcode, so that I can identify inbound pallets without manual data entry
• As a purchasing manager, I want to view open purchase orders by vendor, so that I can follow up on overdue deliveries
• As a finance controller, I want to see a daily inventory value report, so that I can reconcile against the general ledger

PMP / PMBOK NOTE

User stories are the primary requirement format in Scrum and other Agile frameworks. The PMI Agile Practice Guide and the PMI-ACP (Agile Certified Practitioner) certification cover user stories extensively. The PMP exam may reference the INVEST criteria for good user stories: Independent, Negotiable, Valuable, Estimable, Small, and Testable.

INVEST Criteria for Good User Stories

Criterion	What It Means	Why It Matters
Independent	Can be delivered without depending on another specific story	Allows flexible prioritization in the backlog
Negotiable	The details are open to discussion, not fixed requirements	Encourages ongoing collaboration between BA and team
Valuable	Delivers value to the user or business on its own	Stories that are only valuable as part of a larger group are epics, not stories
Estimable	The team can estimate it with reasonable confidence	If a story cannot be estimated, it needs more clarification or decomposition

Small	Can be completed within a single sprint	Stories too large to finish in a sprint create unfinished work and forecasting problems
Testable	Clear criteria exist to verify the story is complete	Untestable stories cannot have acceptance criteria

Writing Acceptance Criteria

Acceptance criteria define what conditions must be met for a user story to be accepted as complete. They are the shared definition of done for a specific story and they bridge the BA’s requirements with the tester’s verification.

Acceptance criteria should be written from the user’s perspective, be specific enough to be testable, and cover both expected behavior and edge cases.

• Given [a specific context], When [an action is taken], Then [an expected result occurs]
• Example: Given a pallet has been scanned, When the license plate number does not match any open ASN, Then the system displays an error message and prevents receiving
• Example: Given the user is a warehouse associate, When they access the put-away screen, Then they can only see tasks assigned to their user ID

 

Managing the Backlog as a BA

On many implementation projects, the BA either supports or acts as the Product Owner and owns the backlog. Backlog management means keeping stories well-written, prioritized, and ready to be pulled into a sprint.

A well-managed backlog has at least two sprints’ worth of ready stories at the top: written, accepted criteria defined, and estimated by the team. Items further down can be rougher, with more detail added as they move up in priority.

WHAT THEY SAY	WHAT THEY MEAN
The story is too big to finish in a sprint	Decompose it into smaller stories; an unfinished story at sprint end means no increment of value was delivered
We do not know enough to estimate this story	This is a signal that the story needs more clarification or a spike (a time-boxed research task)
Can we combine all the reporting stories into one	No; reports that each deliver independent value should be separate stories for better prioritization and sprint management
The acceptance criteria are too detailed, that is the developer’s job	Acceptance criteria are the BA’s primary tool for ensuring what gets built is what was meant

COMMON MISTAKE

MISTAKE: Writing user stories in technical language instead of user language.

What it looks like: A BA writes: ‘As a system, I want to call the REST API endpoint /api/v1/inventory/scan with a POST request containing the license plate JSON payload.’ This is a technical specification masquerading as a user story. It specifies the solution rather than the need.
Reality: User stories should describe what the user needs and why. How the system does it is a design decision for the team. A story written from the user’s perspective keeps the focus on value, not implementation.

QUESTIONS TO ASK YOUR STAKEHOLDER
Are user stories written from the user’s perspective, or are they technical tasks?
Do all stories in the backlog have acceptance criteria? Are they written in testable language?
Is the backlog prioritized and maintained, or is it a flat list of everything?
Are stories being decomposed small enough to complete within a sprint?
Is the team using INVEST criteria when evaluating stories during backlog refinement?

Module Quiz

1. A user story reads: ‘As a warehouse associate, I want to scan items at receiving, so that inventory is updated in real time.’ What does this follow?

1. The INVEST framework
2. The standard user story format: As a [user], I want [action], so that [benefit]
3. The Given/When/Then format
4. A technical specification format

Answer: 2

Why it matters: The standard user story format captures who needs the capability, what they want to do, and the value they get from it.

2. A team cannot estimate a user story because the requirements are unclear. What is the appropriate next step?
3. Assign a default estimate and proceed
4. Create a spike to research and clarify the story
5. Remove it from the backlog
6. Have the PM estimate it instead

Answer: B

Why it matters: A spike is a time-boxed research task used to reduce uncertainty so that a story can be estimated and planned in a future sprint.

3. Which of the following is a well-written acceptance criterion?
4. The system should work correctly
5. Given a user is logged in, When they scan an unknown barcode, Then an error message displays and no inventory update occurs
6. The feature should be user-friendly
7. The developer should handle edge cases

Answer: B

Why it matters: Given/When/Then format produces specific, testable criteria. Vague criteria like ‘work correctly’ or ‘be user-friendly’ cannot be tested or verified.

4. The ‘S’ in INVEST stands for:
5. Specific
6. Scalable
7. Small
8. Structured

Answer: C

Why it matters: Small means the story can be completed within a sprint. Stories too large should be broken into smaller, independently deliverable pieces.

5. On an Agile implementation project, who is typically responsible for maintaining acceptance criteria on user stories?
6. The developer who builds the feature
7. The tester who verifies it
8. The BA or Product Owner
9. The Scrum Master

Answer: C

Why it matters: The BA or Product Owner writes and maintains acceptance criteria. They define what done looks like from the business perspective, which the developer builds to and the tester verifies.