By Rahul Dhakate · PMP & PSM I Certified · 23 May 2026 · learnxyz.in
If you are preparing for the PMP exam and coming from a traditional project management background, user stories are one of the Agile concepts that can feel unfamiliar at first. Requirements in traditional PM are written as detailed functional specifications — formal documents that describe exactly what the system must do. User stories are different in both format and philosophy.
I have written and groomed a large number of user stories across projects at Bizsense Solutions and Valethi Technologies. The process taught me something important about why user stories work — and when they do not. This article explains the concept clearly, with real examples, so you can answer exam questions confidently and use user stories effectively in practice.
What is a User Story?
A user story is a short, simple description of a software feature or capability written from the perspective of the person who will use it. It captures what a user wants to do and why — not how the system will implement it.
User stories are the primary way Agile teams capture and communicate requirements. They replace lengthy requirements documents with small, conversation-starting descriptions that can be discussed, refined, estimated, and delivered incrementally within a sprint.
The standard user story format is:
| As a type of user, I want to some goal or capability, So that some reason or benefit. |
This three-part structure is deliberate. Each part serves a specific purpose:
- As a [type of user]: identifies whose perspective the story represents — and forces the team to think about users rather than system features
- I want to [goal]: describes what the user wants to accomplish — the capability, not the technical implementation
- So that [benefit]: explains why this matters to the user — the value the feature delivers
The ‘so that’ clause is the most important and most frequently omitted part of a user story. Without it, the team may build a feature correctly but miss the underlying need. The benefit statement keeps the team focused on delivering value, not just functionality.
Real Examples From a Working Project Manager
At Bizsense Solutions, I wrote and groomed user stories for healthcare applications — platforms like Price Align for hospital procurement, and patient management systems for US-based healthcare clients. At Valethi Technologies, user stories drove eCommerce platform delivery. Here are real examples in the correct format:
Healthcare Procurement Application
| As a hospital procurement manager, I want to compare prices for the same medical supply item from multiple vendors on a single screen, So that I can select the best-value vendor quickly without switching between systems. |
| As a hospital administrator, I want to receive an automated alert when a vendor’s pricing deviates more than 10% from the last purchase, So that I can investigate pricing changes before approving new orders. |
eCommerce Platform
| As a registered customer, I want to save my delivery address and payment details securely in my account, So that I can complete future purchases faster without re-entering my information. |
| As a online store owner, I want to view real-time inventory levels for each product variant from my admin dashboard, So that I can prevent overselling and manage stock replenishment proactively. |
Who Writes User Stories?
This is a question the PMP exam tests and one that plays out differently in different organisations.
In Scrum’s framework, the Product Owner owns the product backlog and is ultimately responsible for user stories. In practice, writing good user stories requires both business knowledge and an understanding of technical feasibility — which means the process works best when it is collaborative.
In my experience, user stories were primarily written by the Product Owner but with active participation from the BA and project management team. We wrote stories based on discussions with the team, organised dedicated grooming calls to review and refine them, and received formal approval from the Product Owner before stories entered the sprint backlog. In some projects, our BA team had a free hand to write stories independently — but always with the understanding that Product Owner review and sign-off was required before the story was scheduled for development.
The collaborative writing process matters as much as the story itself. A user story written in isolation by the Product Owner and handed to the development team as a fait accompli misses the entire point of Agile requirements. The conversation around the story — in grooming, in planning — is where shared understanding is built.
Acceptance Criteria — What Makes a Story Complete
Every user story must have acceptance criteria — specific, testable conditions that define when the story is done. Acceptance criteria are not optional. Without them, ‘done’ is subjective and disputes about completion are inevitable.
Acceptance criteria are typically written in one of two formats:
Given-When-Then Format (BDD Style)
This is the most structured format, commonly used when stories will be linked to automated test cases:
| Story: As a hospital procurement manager, I want to compare vendor prices on a single screen… Given I am logged in as a procurement manager and have selected a medical supply item, When I navigate to the price comparison screen for that item, Then I should see prices from all approved vendors for that item, sorted by price ascending, with vendor name, unit price, minimum order quantity, and last updated date visible for each. |
Checklist Format
Simpler and faster to write — used when detailed BDD scenarios are unnecessary:
- All active vendors for the selected item are displayed
- Prices are sorted by unit price, lowest first, by default
- Each row shows: vendor name, unit price, MOQ, last updated date
- Filtering by vendor category is available
- Page loads in under 2 seconds with up to 50 vendors
The INVEST Criteria — What Makes a Good User Story
A well-written user story satisfies the INVEST criteria — a checklist used to evaluate story quality:
| Letter | Criterion | What It Means |
| I | Independent | The story can be developed and delivered without depending on another unfinished story |
| N | Negotiable | The story is not a fixed contract — details can be discussed and adjusted before development begins |
| V | Valuable | The story delivers clear value to the user or the business — it is not just a technical task |
| E | Estimable | The team can estimate the effort required to complete the story |
| S | Small | The story is small enough to be completed within a single sprint |
| T | Testable | The story has clear acceptance criteria that can be verified through testing |
The most common user story quality failure is the S — Small. Stories that are too large to complete in one sprint are called Epics. An Epic must be broken down into smaller user stories before it enters the sprint backlog. A story that the team cannot complete within a sprint creates an unfinished increment at sprint end — which violates Scrum’s definition of done.
Epics, Stories, and Tasks — The Agile Hierarchy
User stories sit in a three-level hierarchy of Agile requirements:
| Level | Name | Description | Example |
| 1 — Largest | Epic | A large body of work too big for one sprint — must be broken into stories | Complete vendor management module |
| 2 — Middle | User Story | A feature small enough to complete in one sprint | As a store admin, I want to add a new vendor to the system… |
| 3 — Smallest | Task | A specific technical action needed to implement a story | Create vendor database schema, Build vendor API endpoint |
The Grooming Process — Where Stories Get Refined
Writing a user story is only the first step. Before a story enters a sprint, it goes through a grooming process — also called backlog refinement — where the team reviews, discusses, and improves the story.
In my practice, grooming calls were scheduled sessions where each story was discussed at length. Every point of the story — the user role, the required capability, the acceptance criteria, and the technical approach — was examined. QA team members were present to write test cases aligned to the acceptance criteria before development began. Stories were updated based on the discussion, and then reviewed and approved by the Product Owner and Product Manager before being marked ready for sprint planning.
This collaborative grooming process — not just the written story — is what makes user stories work. The conversation builds shared understanding that no document alone can create.
For the PMP exam: grooming or backlog refinement is not one of Scrum’s four official ceremonies, but it is an expected activity. PMI acknowledges it as an ongoing process throughout the sprint. When exam questions describe the team preparing the backlog for the next sprint, they are describing grooming.
How User Stories Are Tested on the PMP Exam
- Format questions: What is the correct user story format? As a [user], I want [goal], so that [benefit].
- INVEST questions: A story cannot be completed in one sprint. What should happen? Break it into smaller stories — it is an Epic.
- Acceptance criteria questions: Why are acceptance criteria essential? They define the testable conditions for story completion — without them, done is subjective.
- Role questions: Who is primarily responsible for the product backlog? The Product Owner. Who can contribute to writing stories? Any team member — but the Product Owner owns and prioritises.
- Epic vs Story: A question describes a feature that will take three sprints to complete. What is this called? An Epic.
About the Author
Rahul Dhakate is a PMP and PSM I certified project manager and product management leader based in Nagpur, India, with 20 years of experience managing software projects across BFSI, eCommerce, and enterprise software. He wrote and groomed hundreds of user stories across healthcare procurement and eCommerce projects, applying the three-part format and acceptance criteria in collaborative grooming sessions with QA and product management teams. He writes at LearnXYZ.in to help working professionals understand both the theory and the real-world practice of project management.
Next Article:
