Scrum AI: Big User Stories Hide Problems
I was sitting in a sprint review when a development lead I respect dropped his pen on the table and said, "We're not demoing this sprint. Story 4 isn't done. We've been working on it for three sprints."
Scrum AI: Big User Stories Hide Problems
By Chris Daily
A field guide to splitting user stories — and how to put an agile coach on speed dial.
I was sitting in a sprint review when a development lead I respect dropped his pen on the table and said, "We're not demoing this sprint. Story 4 isn't done. We've been working on it for three sprints."
The PO looked at the team. The team looked at the PO. The scrum master looked at the ceiling.
Story 4 wasn't a bad story. It was a too-big story. And too-big stories have a way of hiding problems until it's too late to fix them cleanly.
Small stories surface problems early — when you can still do something about them. Big stories hide them until the demo.
This is a field guide to slicing oversized stories into vertical, valuable, ship-ready slices. It's based on Richard Lawrence's How to Split a User Story framework and Bill Wake's INVEST model — the canonical tools agile coaches have used for more than a decade. At the end, I'll hand you a free AI tool that puts the framework in your pocket, and five prompts you can paste into it right now.
INVEST: the bar every story must clear
Before you split anything, the original story has to actually be a story. Bill Wake's INVEST acronym is the cleanest test we have:
- I — Independent. Can it ship without waiting on another story this sprint?
- N — Negotiable. Does it capture intent, leaving room for design conversation?
- V — Valuable. Does it deliver observable value to a real person?
- E — Estimable. Can the team size it?
- S — Small. Does it fit comfortably in a sprint? (Rule of thumb: ⅙ to ½ of velocity.)
- T — Testable. Are there clear, demonstrable acceptance criteria?
Most stories that "won't split" turn out to be stories that aren't really stories. They're tasks dressed up in story syntax. Features pretending to be stories. Aspirations with a "so that" clause stapled on.
If a story fails INVEST on anything other than Small — fix the story before splitting. You can't slice a bad story into good ones.
If it fails only on Small, you're ready to split. That's where the patterns come in.
The nine patterns
Lawrence's framework gives you nine ways to slice. Most stories fit one of the first three. The rest cover the harder cases.
- Workflow Steps — Slice along the steps in a process. Or take a thin slice all the way through the workflow and enhance later.
- Business Rule Variations — When the story has pricing tiers, eligibility rules, or "flexible" anything, ship the simplest rule first.
- Operations (CRUD) — When the story uses verbs like manage, configure, or administer, split into Create, Read, Update, Delete. Read is often the safest first slice — it validates the data model with low risk.
- Variations in Data — When the story does the same operation across multiple data types, pick one type first.
- Interface Variations — When the story works across multiple channels, pick the simplest channel first to prove the underlying logic.
- Defer Performance — When most of the complexity is non-functional, build correctness first and speed second.
- Simple/Complex — Ship the simple core. Defer the edge cases. Sometimes you discover you didn't need them.
- Major Effort — When the obvious split puts the hardest case first because it builds the underlying infrastructure, do the hard one first. Subsequent stories become easy.
- Break Out a Spike — When you genuinely can't split because the team doesn't understand the problem yet, time-box research with one to three specific questions. Spike output is knowledge, not working software.
The decision tree, in three sentences
- Prepare the input. Confirm the story passes INVEST except possibly Small. If it doesn't, repair the story before you slice.
- Apply patterns. Walk the diagnostic questions ("Does the story describe a workflow?" "Does it include multiple operations?" "Does it have a complex interface?") until one fits.
- Evaluate the split. Are the new stories roughly equal in size? Does each satisfy INVEST? Anything to deprioritize? Which one starts first — the one with early value, learning, or risk reduction?
That's the whole framework. Two pages of decision logic, nine pattern names, one acronym. Worth tattooing on the inside of your laptop lid.
Where AI fits in
Here's the part I want to be honest about: every agile coach I know has had this conversation hundreds of times.
"Walk me through INVEST again." "Which pattern fits this story?" "Is this a spike or just hard?"
The patterns are durable. The conversation is repetitive. That's exactly the kind of work AI is suited to — not replacing the coach, but giving every team member access to coaching at 11 PM the night before refinement.
I built Story Splitter Coach on Pickaxe.co. It's a chat tool that:
- Evaluates any story against INVEST and shows the scorecard
- Recommends the right splitting pattern and explains why
- Produces the actual split with acceptance criteria written out
- Accepts whole backlog uploads — .docx, .pdf, .csv exports from Jira, Azure DevOps, or monday.com
- Coaches conversationally when you're stuck
It's free, no login required for basic use, and it lives here:
👉 Story Splitter Coach
The framing matters: this isn't an automation that replaces refinement. It's a coach that prepares you for refinement so the conversation in the room is about value and trade-offs, not about which acronym we're using.
Five prompts to try right now
Open the link above and paste any of these. Each demonstrates a different scenario you'll meet in real backlogs.
Prompt 1 — The classic "manage" trap
As an administrator, I want to manage user accounts so I can keep our system secure and organized.
Acceptance criteria: Admin can create, edit, deactivate, and delete users. Admin can assign roles and permissions. Admin can reset passwords. Admin can view audit history per user. Admin can bulk-import users from CSV.
What you'll see: The INVEST scorecard flags Small as ❌. The coach recommends the Operations pattern and produces five or six split stories. It will recommend starting with "view a list of users" — Read first, because it validates the data model at the lowest risk.
Prompt 2 — The performance-loaded story
As a user, I want to search our product catalog of 50 million items and get sub-200ms response times across all queries, including fuzzy matching, filters, and faceted navigation.
What you'll see: Defer Performance is the primary recommendation. The coach splits the story into two distinct work items — "search returns correct results" and "search returns results in under 200ms" — with separate acceptance criteria. Functional first, non-functional second.
Prompt 3 — The multi-channel story
As a customer, I want to submit a support request from any channel — web, mobile app, email, SMS, or chat — and have it route to the right team automatically.
What you'll see: Interface Variations is the recommended pattern. The coach picks the simplest channel first (usually the web form) to prove the routing logic, then layers in additional channels as separate stories. You ship value by week one instead of week six.
Prompt 4 — The "is this a spike?" question
My team is stuck on this story and we're not sure how to proceed: "As a financial analyst, I want anomaly detection on our transaction stream so we can flag potentially fraudulent activity in real time." Should we split this or run a spike first?
What you'll see: A coaching response that asks one clarifying question — usually about the team's familiarity with anomaly detection or the existing data infrastructure — then recommends either a time-boxed spike with specific questions to answer, or a Major Effort split if the team has enough foundation to attempt it.
Prompt 5 — Whole-backlog analysis
Upload a .docx, .pdf, or .csv with five to ten stories from your actual backlog. Then send: "Please analyze each story, flag the ones that need splitting, recommend a pattern for each, and suggest a sequencing order across the whole batch."
What you'll see: A portfolio overview (which stories are already small enough, which need splits, which need spikes), condensed per-story analysis, and a recommended sequence across the whole set. Run this the morning before refinement and bring the output to the room.
A note on craft
Splitting stories well is craft work. Patterns help. Decision trees help. AI helps. But none of them replace the conversation between the team and the product owner about what actually matters.
What good tools do is take the cognitive load of pattern recall off your plate so you can spend your refinement meeting on the real conversation:
What's the smallest thing we can ship that delivers real value to a real person?
That conversation is irreducibly human. The patterns just make sure you don't have to reinvent the framework every time you have it.
Closing thoughts
The Lawrence framework has been quietly stable since its last update in 2018. It works because it's grounded in something true: small things ship, big things hide. Vertical slices deliver value; horizontal slices deliver disappointment. INVEST isn't a checklist — it's a shorthand for "would I bet money on this story finishing this sprint?"
If you're a PO, a BA, a scrum master, an RTE — try the patterns on your next refinement. Try the Pickaxe on your hardest story. And if you find a tenth pattern Lawrence missed, please tell me. I'll be the one in the back of the sprint review with a big story, looking for someone who can help me cut it.
Resources
- Story Splitter Coach (try it free): Open the tool →
- How to Split a User Story — Richard Lawrence, Agile For All (richardlawrence.info/splitting-user-stories)
- INVEST in Good Stories — Bill Wake, original 2003 article
Where this fits at belithe.com
Agile + AI for Entrepreneurs is where this kind of thinking — Agile discipline plus practical AI tooling — gets taught session by session, with hands-on practice, not just a framework to read about.
Chris Daily is a Certified AI Master Trainer with 30+ years of technology leadership experience, and the founder of beLithe. He believes AI should amplify human judgment, not replace it.