Bad user stories are stories that hide their value, bundle too much work, prescribe the solution, or repeat the request as its own reason. You can diagnose most of them with the six INVEST questions (Independent, Negotiable, Valuable, Estimable, Small, Testable) and fix them by rewriting the value, splitting vertically, and moving detail into acceptance criteria. This guide shows four anti-patterns with before-and-after rewrites. Last verified: October 2026.
What makes bad user stories bad
A user story is a short description of a need, written from the point of view of the person who has it, that starts a conversation about how to meet it. Mike Cohn's Mountain Goat Software guide gives the familiar template (As a ..., I want ..., so that ...) and calls the sentence "a reminder to have a conversation".
When I started as a business analyst, I spent many sessions with a mentor arguing about definitions. The one I settled on: a user story is a requirements technique that helps the team understand a customer's need, so the team can then choose, describe, and agree on a solution. The template is not the point. The value is.
So a story is bad when it fails that job. The template can be perfect and the story still useless, because the reader cannot tell who benefits, why, or what done looks like. For the basics of the format, job stories, and decomposition, see User Stories, Job Stories, and Decomposition. This article is about repair.
Why bad user stories matter for the PSPO I exam
The Professional Scrum Product Owner I (PSPO I) exam tests Product Backlog management, not story templates. According to Scrum.org, the exam has 80 questions in 60 minutes, a passing score of 85%, and costs $200 per attempt.
| PSPO I fact | Value |
|---|---|
| Questions | 80 (multiple choice, multiple answer, true/false) |
| Time | 60 minutes |
| Passing score | 85% |
| Price | $200 USD per attempt |
| Relevant focus areas | Product Value, Product Backlog Management, Stakeholders & Customers |
Last verified: October 2026.
The Scrum Guide 2020 does not mention user stories at all. It talks about Product Backlog items (PBIs) and says refinement adds details "such as a description, order, and size". It also says items that can be Done within one Sprint are deemed ready. A Scrum.org forum reply in the INVEST thread makes the same point: "Scrum does not specify how requirements are captured."
That is why the exam asks about stories indirectly. Expect questions on who is accountable for the Product Backlog, what to do with an item too large for a Sprint, and how to express value. INVEST gives you a quick way to reason through those questions. Practice them on the PSPO I exam simulator.
How to diagnose a story with INVEST, step by step
INVEST is a six-question checklist for story quality that Bill Wake published in his 2003 article INVEST in Good Stories, and SMART Tasks. The Agile Alliance glossary credits Wake with the acronym and Mike Cohn's 2004 book with spreading it.
Run each story through the six questions in order. Each failed letter points to a specific fix.
| Letter | Diagnostic question | Typical symptom | Fix |
|---|---|---|---|
| Independent | Can we build it in any order? | Story B is blocked until story A ships | Merge the dependent pair, or split along a different line |
| Negotiable | Is the how still open? | Hex codes, field names, button positions in the story | Keep the need; move specifics to acceptance criteria |
| Valuable | Does a user or the business gain something? | Database-only or analysis-only stories | Slice vertically so each story reaches a user |
| Estimable | Can the Developers size it? | Wild estimates or refusal to estimate | Split, add information, or run a spike |
| Small | Can it be Done within one Sprint? | The team carries it over Sprint after Sprint | Split into thinner valuable slices |
| Testable | Can someone say pass or fail? | Words like fast, easy, intuitive | Add measurable acceptance criteria |
Independent: the card networks example
Take a product that must accept three card networks, such as Mastercard, Visa, and a local scheme. The obvious split is one story per network, but the first one also carries all the shared work: the payment form, tokenization, error handling. The other two depend on it.
My fix is to make that dependency explicit. The first story covers general card support plus one network and is the biggest. The two follow-up stories each add a network and stay small. Wake's advice for dependent stories is the same: combine them or find another split. What matters is that the team sees the dependency instead of discovering it mid-Sprint.
Negotiable and Valuable
Wake puts it this way: "A good story captures the essence, not the details." Negotiation is about the user's need, not the implementation.
Valuable does not ban technical work. A refactoring or database migration can be a valid backlog item if its description states the effect people will notice, such as faster responses. What fails the V is a story whose only beneficiary is the next technical layer.
Estimable and Small
In my experience, Developers cannot estimate a story for three reasons: it is too big, it lacks information, or they lack experience with that kind of work. Each has a different fix: split it, refine it, or time-box a learning spike. Sizing itself is covered in Estimation and Relative Sizing.
How small is small varies. Some teams cap a story at one working day; others accept items that take most of a Sprint. Wake's original guidance was a few person-weeks at most. For a Scrum team, the hard limit is the Sprint: an item that cannot be Done within one Sprint is not ready.
Testable
A tester must know what to check. Acceptance criteria do most of this work. I once pushed Gherkin (Given/When/Then) scenarios on a project several times; developers and testers never warmed to them, and plain acceptance criteria became the team's real test basis. If your team likes executable specifications, see Behavior-Driven Development (BDD). For acceptance criteria rules and how they differ from evaluation criteria, see Acceptance and Evaluation Criteria.
Four anti-patterns of bad user stories, with before-and-after rewrites
I group the most common bad user stories into four anti-patterns. Each also appears in Charles Suscheck and Andrew Fuqua's 2013 StickyMinds article Identifying and Improving Bad User Stories, under different names.
| Anti-pattern (my name) | Suscheck and Fuqua name | INVEST letters it breaks |
|---|---|---|
| Overloaded so-that | Excessive So That | Estimable, Small |
| The historical novel | Odyssey | Small, Independent, Estimable |
| Too specific | Rigidity | Negotiable |
| Want X so that X | Parakeet Value | Valuable |
1. The overloaded so-that
Before.
As a café visitor, I want my order to be saved somewhere, so that I can see my order history, print receipts, and email them to myself.
Diagnosis. Three features hide in the reason clause. The team reads "saved somewhere", sizes a database write, and underestimates the story. Suscheck and Fuqua describe the same trap: requirements buried in a multi-part so-that.
After, step 1. Move each hidden feature into the want, each with its own value:
As a café visitor, I want to see my order history, print a receipt, and email a receipt, so that I can track and claim my spending.
After, step 2. The story is now honest, but it is long. That leads to the next anti-pattern.
2. The historical novel
Before.
As a café visitor, I want to view my past orders, see and print receipts, and send the same order to the café again, so that I save time and keep track of my spending.
Diagnosis. One story, two unrelated goals, at least four capabilities. Suscheck and Fuqua note that "Stories containing 'and' or 'or' are likely candidates for splitting". The word "and" in the want clause is the signal.
After. Split by goal, not by screen or layer:
As a regular café visitor, I want to repeat a past order, so that I do not rebuild my usual lunch every day.
As a café visitor, I want to view the receipts of my past orders, so that I can compare what I spent.
Each story now delivers value on its own and can be ordered independently. Splitting techniques are covered in more depth in User Stories, Job Stories, and Decomposition.
3. Too specific
Before.
As a restaurant visitor, I want salads shown in #2E7D32, soups in #F9A825, and desserts in #AD1457, so that I can find dishes faster.
Diagnosis. The need (find dishes faster by type) is fine. The hex codes are a design decision that removes negotiation. Steve Smith (Ardalis) wrote back in 2009: "Having too much detail in the story can limit options."
After.
As a restaurant visitor, I want each type of dish to have its own color, so that I can find what I want faster.
Acceptance criteria then hold the specifics: each dish type uses a distinct color from the brand palette; colors pass contrast checks; the menu legend lists the mapping. If a designer later proposes icons instead, the story still stands.
4. Want X so that X
Before.
As a hiker on a hot day, I want ice cream, so that I can eat ice cream.
Diagnosis. The reason repeats the request. It names a means, not a value. Suscheck and Fuqua call this Parakeet Value. Ask why until you reach a real outcome; the 5 Whys technique works well here.
After.
As a hiker on a hot day, I want to cool down quickly, so that I avoid heatstroke.
Now ice cream is one option among shade, water, and a rest stop, and the team can negotiate the cheapest one that works. The same pattern in software: a shopper who wants a save-cart button so that the cart is saved. The real value is finishing the purchase on another device later.
Two more checks: who and why
Two related problems are worth a fast check. First, the role. Suscheck and Fuqua's "For Whom?" pattern covers stories written for a vague user or for the system. Name the real person; a short list of personas helps, including a negative persona the product deliberately excludes (in a taxi app with direct client-driver contact, the dispatcher). In practice, my teams ignored most persona details such as biography or favorite brands; role, goals, and main use cases were what they used. More in Stakeholders and Personas.
Second, the 3 Cs: Card, Conversation, Confirmation, from Ron Jeffries' Essential XP: Card, Conversation, Confirmation. Many bad stories are cards that never got a conversation. Rewriting the sentence will not fix that; a refinement session will. See Backlog Refinement.
What practitioners say about bad user stories
Practitioners agree that INVEST is a balance, not a gate, and that splitting is the most common repair.
- INVEST letters pull against each other. In a 2019 ProjectManagement.com discussion, Kiron Bondale argued the six criteria are competing forces: "If any one is given greater precedence we won't get a good story." Over-weighting Small produces micro-items with no standalone value.
- Splitting is not dividing. In a 2016 Scrum.org forum thread on large user stories, Timothy Baffa said a story that cannot fit a Sprint usually means the team needs more practice at splitting, and that dependent fragments add no value. Ian Mitchell added that the Developers are not obliged to take on an item they cannot finish in a Sprint.
- Slice vertically. A Scrum Alliance article on splitting user stories recommends vertical slices over splits by architecture layer, because only vertical slices are demonstrable on their own.
- Requirement lists are not stories. In a 2014 Scrum.org thread from a beginner Product Owner, Chee-Hong Hsia pointed the poster to INVEST and noted that the posted items read like acceptance criteria. Other replies said the Product Owner should define the what and leave the how to the team.
- Value must be visible. In a 2014 Scrum.org thread on tasks versus stories, Ludwig Harsch reminded the team that "The idea of Scrum is delivering small pieces of value each sprint."
Common misconceptions
Misconception: Scrum requires user stories. It does not. User stories come from Extreme Programming (XP); the Scrum Guide only defines Product Backlog items. The PSPO I exam follows the Scrum Guide.
Misconception: Only the Product Owner writes stories. The Product Owner is accountable for the Product Backlog, but anyone can draft items, and refinement is a whole-team activity.
Misconception: Technical work cannot be a story. It can be a Product Backlog item when its value is stated. What fails is a horizontal layer with no visible effect.
Misconception: A perfect template makes a good story. A story can follow As a / I want / so that exactly and still repeat itself, prescribe hex codes, or bundle four features.
Misconception: More detail up front is safer. Mountain Goat Software's article on adding detail to user stories argues detail is best added close to development, by splitting or by adding acceptance criteria.
Practice Questions
Question 1
A Product Owner notices that a backlog item for a new checkout flow cannot be Done within one Sprint. What should happen?
- A. The Developers start it and carry the rest into the next Sprint.
- B. The Scrum Team refines it into smaller items that each deliver value and can be Done within a Sprint.
- C. The Scrum Master extends the Sprint so the item fits.
- D. The item is split into a database story, an API story, and a UI story.
Answer: B. The Scrum Guide says items that can be Done within one Sprint are deemed ready, and refinement breaks items down. D splits by layer, so no single piece delivers value. A and C break the Sprint as a fixed-length container.
Question 2
Which statement about user stories is consistent with the Scrum Guide?
- A. Every Product Backlog item must be a user story with acceptance criteria.
- B. Only the Product Owner may write Product Backlog items.
- C. User stories are an optional practice for expressing Product Backlog items.
- D. User stories replace the Sprint Goal.
Answer: C. The Scrum Guide does not prescribe a format for Product Backlog items. The Product Owner is accountable for the Product Backlog but may have others do the work.
Question 3
A backlog item reads: As a developer, I want the orders table created, so that the orders table exists. Which INVEST criterion is most clearly violated?
- A. Independent
- B. Valuable
- C. Small
- D. Negotiable
Answer: B. The beneficiary is a developer and the reason repeats the request. No user or stakeholder gains anything visible. Rewrite it as a vertical slice, for example a visitor who can save an order and see it later.
Related techniques
- User Stories, Job Stories, and Decomposition: formats and splitting patterns.
- Stakeholders and Personas: who the story is for.
- Acceptance and Evaluation Criteria: where specifics belong.
- Behavior-Driven Development (BDD): Gherkin scenarios as executable criteria.
- Backlog Refinement: when stories get fixed.
- Estimation and Relative Sizing: what Estimable and Small mean in practice.
FAQ
What are the signs of bad user stories?
Look for an "and" in the want clause, several features hidden in the so-that clause, design details such as colors or field names, and a reason that repeats the request. Also check whether the Developers can size it and whether a tester can say pass or fail. Each sign maps to an INVEST letter.
Who created the INVEST criteria?
Bill Wake introduced INVEST in his 2003 article INVEST in Good Stories, and SMART Tasks. Mike Cohn spread it through his 2004 book User Stories Applied. The letters stand for Independent, Negotiable, Valuable, Estimable, Small, and Testable.
Are user stories part of Scrum?
No. The Scrum Guide 2020 defines Product Backlog items and never mentions user stories. User stories come from Extreme Programming and are a common, optional way to express Product Backlog items. PSPO I questions follow the Scrum Guide.
How do you fix a user story that is too big?
Split it by user goal or workflow step so each piece delivers value on its own and can be Done within one Sprint. Avoid splitting by architecture layer, because a database-only or UI-only piece gives users nothing. Do the split during Product Backlog refinement with the Developers.
Where should details like colors or validation rules go?
Put them in acceptance criteria, not in the story sentence. The story states the need and its value; acceptance criteria state the measurable conditions for pass or fail. This keeps the story negotiable and the criteria testable.
Sources
- Bill Wake, INVEST in Good Stories, and SMART Tasks, XP123, 2003
- Agile Alliance, INVEST glossary entry
- Charles Suscheck and Andrew Fuqua, Identifying and Improving Bad User Stories, StickyMinds, 2013
- Ken Schwaber and Jeff Sutherland, The Scrum Guide 2020
- Scrum.org, Professional Scrum Product Owner I
- Ron Jeffries, Essential XP: Card, Conversation, Confirmation
- Mountain Goat Software, User Stories and The Two Ways to Add Detail to User Stories
- Mike Cohn, User Stories Applied, Addison-Wesley, 2004
- Jeff Patton, User Story Mapping, O'Reilly, 2014
- Alan Cooper, The Inmates Are Running the Asylum, Sams, 2004
- Karl Wiegers and Joy Beatty, Software Requirements, 3rd Edition, Microsoft Press, 2013
- Ryan Abel, When Is a Story Done? Three Criteria to Decide, Atomic Object, 2018
- Ryan Hewitt, Gherkin for Business Analysts, Modern Analyst
- What is Acceptance and Evaluation Criteria in the context of Business Analysis?, Business Analysis Excellence
- Acceptance criteria checklist, Agile for Growth
- Steve Smith, INVESTing in User Stories, Ardalis, 2009
- ProjectManagement.com, Which point will be in more focus while writing good user stories wrt INVEST?, 2019
- Scrum.org forum: INVEST (2015), Large User Stories (2016), Beginner Question - User Story (2014), Using Tasks vs Stories (2014)
- Faisal Ansari, Splitting User Stories, Scrum Alliance