How to Turn a Feature Into User Stories With AI
A feature arrives as one line — "let users change the pickup location" — and AI splits it the two wrong ways: it restates the spec, or it hands back a task list. Here is how to turn a feature into user stories with AI: sliced by the user's path, each one shippable and checkable on its own.
Get the User Story TemplateOne line in the roadmap, six behaviors underneath
The feature is a single line: let renters change the pickup location of a reservation. It reads like one thing to build, and it is six — a way to see which branches can fulfill the item, a way to make the switch, a warning when a branch can't, the price difference, the notifications to the branches involved, and the cutoff after which none of it is allowed. Ask an AI to "break this into user stories" and you tend to get one of two wrong answers, both fluent.
The first is the spec handed back to you in smaller font — a restatement of the goal and the constraints that reads like stories but is really the requirements document again, one level shallower. The second is a task list: build the endpoint, build the picker UI, add a column. That one looks like decomposition and is actually the opposite of a user story, because the renter gets nothing until all three land. Neither gives you the thing user stories are for — a set of slices each of which could ship on its own and mean something to somebody.
That is the work this guide is about: taking an already-approved feature and cutting it into stories along the user's path rather than the code's. The cut is the whole skill, and it is the part an AI will get wrong by default, because "break this down" pulls it toward the layers of the system it can see in the description instead of the moments of the person using it.
What the AI slices, and what it cannot decide for you
The stories that come back are candidates, and the word matters. They are cut from the feature scope and the rules you supply, and that supplied material is the whole of what the model has to work with — there is no backlog behind it, no issue tracker or repository it can consult. A requirement you never wrote down is one it cannot recover; a business rule, a priority, or an estimate is something it can restate but has no way to check; and a cutoff time nobody gave it is a gap it will either leave open or quietly fill, only one of which is safe. It proposes a slicing. It does not own the backlog, assign the work, or plan the sprint.
So the division of labor is clear: the AI proposes a slicing, and the product owner and the delivery team decide whether the slicing is right, whether the set is complete, and whether each story is worth building. There is no guarantee the set is exhaustive or ready to implement — it is a fast, structured first cut you review, run in your own assistant, and correct. What you keep is the judgment about your product; what you hand off is the mechanical part of proposing slices and catching the ones that overlap.
This also fixes where the guide sits. Upstream, a PRD has already decided the problem, the goals, and the scope — this takes that as given and does not re-argue it. Downstream, each story's pass/fail conditions get written as acceptance criteria, which is its own artifact and its own job. This guide is the middle: scope in, a reviewed set of user-visible slices out, each one pointing at the criteria that will say when it's done.
Step 1: Start from the approved scope, not the feature title
Before any slicing, lay out what you were actually handed: the feature goal, the actors and everyone the feature touches, the primary workflow with its entry and exit conditions, what is explicitly in and out of scope, and the assumptions and open questions that came with it. The title — "change pickup location" — is a label, not a specification, and slicing from the label is how out-of-scope work sneaks in. The renter changing dates, or the item, or the return location are all adjacent and all easy for a model to helpfully include; the scope you were given is what says they are somebody else's feature.
Name the affected parties too, not just the primary user, because some of the best stories belong to them. The branch staff who have to release an item and ready another one are not using the feature, but the feature fails for the renter if the notification story that serves those staff is missing. A slicing that only sees the primary actor misses whole slices that the workflow actually depends on.
The one rule that runs through all of this is traceability: every story you end up with has to map back to something in the supplied scope. A story that traces to nothing is either scope creep or a requirement nobody approved, and catching it here — against the scope, before the set grows — is far cheaper than catching it in a sprint.
- Write down goal, actors, workflow, entry/exit, in-scope, out-of-scope, and open questions before slicing anything.
- The title is a label; the scope is the specification. Slice from the scope, or adjacent work creeps in.
- List the affected parties, not just the primary user — their stories are the ones most often dropped.
- Every story must trace back to the supplied scope. One that traces to nothing does not belong yet.
Step 2: Slice along the user's path, never by technical layer
This is the move the whole guide turns on. A user story is a slice of user-visible capability, so cut the feature where the user's experience has seams — a workflow step, an outcome, a distinct scenario, a permission boundary, a business rule, a rung of progressive capability — and never where the system has layers. "Frontend, backend, database, API, testing" are how the work is built; they are not stories, because a database column delivers nothing a user can see until the code and the screen that use it also ship.
The test for a real slice is independent value: could this story ship by itself and leave someone — a user, or an operation — better off than before? "See which branches have my item" passes; a renter can use that alone even before the switch itself exists. "Add a new_branch_id column" fails; nobody is better off until three other tasks land. When a proposed story fails the test, it is almost always because it was cut along a layer, and the fix is to re-cut it along the path.
This is exactly where an AI needs steering, because the feature description is written in the language of the system, and left alone the model will slice along the nouns it finds there — the endpoint, the table, the component. Tell it the seams you want (scenario, rule, permission, step) and forbid the layer split explicitly, and the same model that would have handed you a task list hands you a story map instead.
- Cut at user seams — step, outcome, scenario, permission, rule, progressive capability — not at system layers.
- The layer split (FE / BE / DB / API) produces tasks, not stories: nothing is usable until all the layers land.
- Independent-value test: could this ship alone and help someone? If not, it was cut along a layer — re-cut it.
- Name the seams you want and ban the layer split outright, or the model slices along the system's nouns.
Step 3: Lay the stories out as a map in workflow order
A pile of stories is not a set; a set has a shape. Lay them along the workflow in the order the user meets them — the happy path first, then the alternatives, then the failure and recovery paths — so you can see the walk end to end and spot what is missing. It is the gaps a flat list hides that this catches: the "what happens when the branch can't fulfill the item" story is invisible next to "change the pickup," and obvious the moment the two sit in path order with nothing between the switch and its failure case.
Walking the path is also how you find the stories that are not about the primary actor at all. Between the renter confirming a move and the renter collecting the item, something has to tell two branches to release and prepare — and that story only appears if you follow the workflow past the click, into what the system and the staff have to do for the click to have meant anything.
Keep the map honest about ordering without turning it into a schedule. Which story a later one depends on is worth noting — the failure-path story leans on the availability check existing — but that is a dependency between capabilities, not a build sequence or a set of stages. The moment the map starts saying "do this in week two," it has stopped being a story map and become an execution plan, which is a different artifact with a different owner.
- Order the stories along the workflow: happy path, then alternatives, then failure and recovery.
- Path order exposes the missing story — the failure case a flat list quietly drops.
- Follow the workflow past the primary actor: the operations stories live in what has to happen after the click.
- Note dependencies between capabilities, but do not turn the map into a schedule of stages — that is the plan's job.
Step 4: Fix granularity, merge duplicates, pull the enablers out
Now clean the set. Three moves do most of the work. Split the story that is too big — the one that bundles discovery and availability and price and confirmation into "change the pickup location" is really four stories wearing one title, and it cannot be estimated or checked until it is cut apart. Merge the duplicates — two stories that describe the same behavior in different words are one story counted twice, and a model generating candidates produces these constantly. And separate the enablers from the stories: the technical work that has to exist for a story to function — "make availability queryable by branch and date" — is real and worth tracking, but it is not a user story, because no user is better off when it lands alone. Name it an enabler and keep it out of the story count.
The "As a … I want … so that …" form is useful here, and it is a tool, not a law. Its value is that the "so that" forces a reason: if you cannot finish it, the story probably has no independent value and is really a task in disguise. But a story that reads better as a plain sentence is still a story, and contorting every slice into the template — "as a system, I want a database index so that queries are fast" — is how the format gets used to smuggle tasks back in wearing a persona. Use the shape to test for value; do not let it certify a task as a story.
This is the point where a reusable story shell earns its place. The User Story Variable Builder is that shell — the persona, goal, and outcome, plus slots for the constraints, the edge cases, the definition of done, and a pointer to acceptance criteria — so every story in the set is written to the same shape rather than each one improvised. It does not slice your feature for you; the slicing above is yours. What it gives you is one consistent template to pour each finished slice into, and its companion Prompt Variable Builder standardizes the variables across the set — catching the drift where one story says "acceptance criteria" and the next says "criteria" — and exports the whole thing for your team. It builds the template in your browser and runs nothing; the stories are yours to write into it.
- Split the story that bundles several scenarios; it cannot be estimated or checked as one lump.
- Merge stories that are the same behavior in different words — a model produces these by the handful.
- Pull technical enablers out and label them enablers. Real work, tracked separately, not counted as stories.
- "As a / I want / so that" is a value test, not a mandatory truth — do not use it to dress a task as a story.
Step 5: Split MVP from later, and leave the unknowns as questions
With a clean set, decide what the first slice needs and what waits. This is not product-scope cutting — the feature's scope is already fixed — it is deciding which stories the first shippable version of this feature requires and which are enhancements that can follow. The discipline that matters most: nothing in the "later" pile can be a thing the MVP secretly depends on. "Suggest the nearest branch that has the item" is a fine later story, but it leans on the availability check being in the MVP, so it cannot lead — and a slicing that puts a dependency after the thing that needs it is a plan that cannot run.
Where a story hinges on a value you were not given — a cutoff time, a fee, an eligibility rule — that value is an open question with an owner, not a blank for the AI to fill. "Blocked after the cutoff" is a real story; the cutoff being two hours is a number nobody supplied, and writing it in makes the set look decided when it is not. Mark it as owner-confirmation and move on. The set is allowed to have holes; it is not allowed to have invented facts hiding the holes.
What comes out of this step is a story set with a clear first slice, an honest "later" that respects its own dependencies, and a short list of questions pointed at the people who can answer them. That is a set a team can start on — not because every value is filled, but because every gap is visible.
- MVP is the smallest set that ships this feature; "later" is enhancements — decided within an already-fixed scope.
- Nothing in "later" may be something the MVP depends on. A dependency placed after its dependent cannot ship.
- A missing rule value (cutoff, fee, eligibility) is an owner question, never a number the AI supplies.
- A set with visible gaps is workable; a set with invented facts hiding the gaps is not.
Common mistakes
The ways a feature-to-stories pass goes wrong, most of them because the model slid toward the system instead of the user:
- Slicing by technical layer. "Build the endpoint / the UI / the column" is a task list; a story has to be usable on its own, and none of those is.
- Handing back the spec in smaller pieces. If the "stories" just restate the goal and constraints, no slicing happened — that is the PRD again.
- Stories with no independent value. A slice nobody is better off for shipping alone was cut along a layer; re-cut it along the user's path.
- Counting duplicates as separate work. Two wordings of one behavior double the estimate and split the review; merge them.
- Listing an enabler as a user story. The availability query is real work and no user sees it land — track it as an enabler, not a story.
- Inventing the rule you were not given. A cutoff, a fee, or an eligibility value written in to look complete turns an open question into a false decision.
- Writing the acceptance criteria here. Naming a story is not defining when it is done — the observable conditions are the next artifact, not this one.
A worked example: change a reservation's pickup location
Here is the feature from the opening — changing a reservation's pickup branch in a fictional multi-location equipment-rental app — worked from one line of approved scope down to a reviewed story set. The interesting parts are the cuts: where a too-big story splits, where the wrong layer-split is shown so it can be avoided, and where a value that was never supplied is left as a question instead of guessed.
Read it as a demonstration of the slicing, not a template to copy: six user-visible stories along the renter's path, one enabler named as an enabler, a duplicate merged, MVP and later kept honest about their dependencies, and every cutoff, fee, and eligibility rule left as an owner question. The acceptance criteria — the pass/fail conditions for each story — are deliberately not written here; that is the next step's job.
One line of scope becomes six path-sliced stories plus a named enabler — with the wrong layer-split shown as the anti-pattern, a duplicate merged, and every unsupplied rule value left as an owner questionTHE FEATURE (as it arrives, one line of approved scope):
"Let a renter change the pickup branch of an existing reservation,
without cancelling and rebooking."
THE SCOPE, UNPACKED (from what was handed over, not re-derived):
actors : renter (primary); origin + destination branch staff
(affected -- inventory and readiness); an agent who can
make the change for the renter (a permission boundary)
in scope : change the pickup branch; re-check item availability at the
new branch for the dates; show any price difference; notify
the affected branches; enforce the change cutoff
out : changing the rental DATES; changing the ITEM; changing the
RETURN location; multi-item reservations that would split
across branches (in scope or not? -> owner TBD)
SIX CANDIDATE STORIES (sliced by the renter's path, not by tech layer):
S1 as a renter, I want to see which branches have my item for my dates,
so that I only consider pickups that can actually be fulfilled.
S2 as a renter, I want to move my pickup to an available branch and get
a confirmation, so that my reservation is now held there.
(the old hold releasing and the confirmation showing are S2's EXIT
CONDITION -- part of one behavior, not a second story)
S3 as a renter, I want to be told when a branch cannot fulfill my item
for my dates, so that I do not move my pickup somewhere it will fail.
S4 as a renter, I want to see the price difference before I confirm, so
that the move holds no billing surprise.
S5 as branch staff, I want the origin and destination branches notified
of the move, so that the item is released and made ready in time.
S6 as the business, I want the change blocked after the cutoff or once
the item is collected, so that a pickup cannot move when it is too
late to matter. (the cutoff VALUE -> owner TBD)
SPLITTING A TOO-LARGE STORY:
"as a renter I want to change my pickup location" bundles discovery,
availability, price, and confirmation across several scenarios into one
untestable lump. It splits into S1 / S2 / S3 / S4 -- each one a thing you
can demo and check on its own.
THE WRONG SPLIT (this is the anti-pattern, shown so it is not copied):
x "build the change-pickup API endpoint"
x "build the location-picker UI"
x "add a new_branch_id column to reservations"
these are technical TASKS, sliced by layer. The renter gets nothing
until all three land, so not one of them delivers value on its own.
They belong in the execution plan, not the story set.
MERGING A DUPLICATE:
"renter picks a new branch from a list" and "renter selects a different
pickup location for the booking" are the same behavior in two wordings.
One story: S2. Two would double-count the same work.
AN ENABLER (named as an enabler, NOT a user story):
"make the item-availability service queryable by branch + date range."
It delivers nothing a renter can see on its own; it is what S1 and S3
stand on. Track it as an enabler so the set stays honest about what is
user-visible and what is plumbing.
MVP VS LATER:
MVP : S1-S6 -- the smallest set that ships the feature end to end.
later : "suggest the nearest branch that has the item" (an enhancement
that DEPENDS on S1, so it cannot come before it); "support
multi-item reservations that split across branches" (gated on
the scope question above). Nothing later is pulled into MVP.
OPEN QUESTIONS (left for the owner -- no value invented here):
- is the change cutoff the same as the cancellation cutoff? (ops)
- is a price difference charged now, at pickup, or refunded? (billing)
- are split-across-branches multi-item reservations in scope? (product)
- can an agent make the change on a renter's behalf, and if so does
that need its own permission story? (product)
LEFT TO THE NEXT ARTIFACT (acceptance criteria -- a different guide):
each story names a capability; the observable pass/fail conditions that
say when it is DONE are written next. For S2 that is a given/when/then
about a not-yet-collected reservation before the cutoff -- not written
here, so this guide does not pretend to have finished the job it starts.Where this fits in NewPrompt
The User Story Variable Builder is the concrete takeaway: the reusable shape each sliced story gets written into — persona, goal, outcome, constraints, edge cases, definition of done, and a slot pointing at acceptance criteria. It is a template, not a slicer; the cutting is the guide's method and yours to run. Its live tool, the Prompt Variable Builder, turns that shape into a set of named variables you can standardize and export so a whole story set stays consistent — it builds and documents the template in your browser and never writes the stories for you.
The scope you slice from usually comes from upstream. A Feature Request Template structures a raw request into the goal, users, constraints, and out-of-scope that a slicing needs as input — it is where the approved scope in Step 1 tends to come from. The Product Requirements Assistant sits at the same upstream edge, shaping a fuzzy need into a structured requirement; note that its output includes acceptance criteria, and writing those is a separate job from slicing stories — take it as the source of scope, not as a shortcut around the criteria step.
Zoomed out, this is one step of a larger arc. The AI Product Requirements Workflow runs from interrogating a fuzzy need into requirements, to shaping those requirements into user stories, to assembling the whole into a requirements document — and this guide is the deep-dive on that middle step, the one where a set of requirements becomes a set of user-visible slices. Two neighbours mark the edges to stay off: the requirements document itself is the PRD's job, upstream, and the observable pass/fail conditions for each story are acceptance criteria, downstream. Naming a capability and defining when it is done are different artifacts, and a story set that tries to do both ends up doing neither well.