You Know the Feature, Now Write the Stories: Part Two of The Art of the User Story
Three sprints. That's how much runway you have before your team runs out of work. The feature is clear in your head. The stories aren't. You need to start writing, and you don't know where to begin.
This is one of the most common places a PO gets stuck, and it's not because you don't know your product. You do. The problem is translating what you know into a set of discrete, well-formed stories before the clock runs out.
There's a way to get unstuck. Use AI as your writing partner. Not to generate stories for you, but to ask you the questions your team would ask in refinement — some of which you haven't asked yourself yet.
Set It Up as a Conversation
The way most people use AI for story writing is wrong. They dump everything they know into a single prompt and wait for stories. What they get is generic, surface-level, and needs heavy editing before it's usable.
The setup matters. Before you share a single detail about your feature, send this:
"I'd like to have a conversation about a new feature I want to add to an existing system. I'll share what I know, and I'd like you to ask me questions and create user stories based on my answers."
That one sentence changes everything. You're not asking for output. You're opening a dialogue. Now you're the expert being interviewed, not the person waiting for answers.
Once the conversation is set up, describe your feature the way you'd explain it to a friend. Plain language. Skip the technical spec. For a trucking application I've worked with, the description looked like this:
"I have an application where commercial truckers can pick up loads from anywhere in the country. I want the truckers to be able to see what the shipper is offering to pay for a shipment."
No acceptance criteria. No edge cases. No data model. Just enough to start the conversation.
The Questions You Didn't Think to Ask
The AI doesn't generate stories. It asks questions. And some of them will catch you off guard.
In the trucking example, the tool came back with four:
Is a rate always available, or is it sometimes negotiable? Do some shippers post a fixed rate while others post "make offer" loads?
What does the rate represent? Is it a flat dollar amount per load, a per-mile rate, or both? Are there accessorial charges — fuel surcharge, detention — that would also be visible?
Who sees the rate? Is it visible to any logged-in trucker, or only to truckers who meet certain criteria — verified, right equipment type, within a certain radius?
Can truckers respond to the rate: counter-offer, accept, or just view?
Two of those questions surfaced things I hadn't considered. The make-an-offer scenario. The per-mile calculation. Both are real considerations. Neither was in my original thinking.
That's the value. You get the questions your team would raise in refinement, before refinement, plus a few you genuinely hadn't gotten to yet.
Answer With Discipline
This is where most POs lose control of the session.
The AI asks good questions. Some of them point to real features worth building. But not now. If you answer everything, your scope explodes and you're no longer writing stories for this sprint. You're sketching a six-month roadmap.
Your job is to decide what this feature includes right now, and hold that line when you answer.
You don't have to respond to every question individually. A partial answer that covers the spirit of several questions is enough to keep the conversation moving. When something is out of scope, say so. In the trucking example, the response to the four questions was simple:
"Shippers can set their rate. Others may want to post make-an-offer. It's always one or the other."
That acknowledged the make-an-offer scenario exists without committing to build it. The conversation continued, the questions got more specific, and the scope stayed manageable.
The discipline here is exactly what you'd apply when your team asks questions in refinement. Stay anchored to what you're building now. Name what's out of scope and move on.
What a Well-Managed Session Produces
After a few rounds of Q&A, the output from this session was four well-formed stories with acceptance criteria.
User Stories: Load Rate Display
Context
Commercial truckers browse available shipments on the platform. Shippers always post a flat rate. The system calculates a per-mile rate from the flat rate and route distance. Truckers must be verified and logged in to view rates. Fuel surcharge details are visible inside the load detail, not on the browse list.
Story 1: Authenticated Access to Rates
As a verified trucker, I want to see shipment rates while browsing the load board, so that I can quickly assess which loads are worth pursuing.
Acceptance Criteria:
A trucker must be logged in and verified to view any rate information.
Unauthenticated users browsing the load list do not see rate values — rates are hidden or replaced with a prompt to log in.
Unverified truckers who are logged in do not see rate values until verification is complete.
Story 2: View Flat Rate on Load List
As a verified trucker, I want to see the shipper's flat rate for each load while browsing the load list, so that I can compare total payout across available shipments at a glance.
Acceptance Criteria:
Each load card/row in the browse list displays the shipper's posted flat rate (e.g., $1,250).
The flat rate is formatted as a dollar amount.
All loads on the board have a flat rate — no load can be posted without one.
Story 3: View Per-Mile Rate on Load List
As a verified trucker, I want to see the per-mile rate for each load while browsing the load list, so that I can evaluate the efficiency of a load relative to the distance I'd travel.
Acceptance Criteria:
Each load card/row displays a calculated per-mile rate alongside the flat rate.
The per-mile rate is calculated by the system: flat rate divided by route distance in miles.
The per-mile rate is formatted as a dollar amount per mile (e.g., $2.15/mi).
The route distance used for the calculation is based on the load's origin and destination.
If the route distance cannot be calculated, the per-mile rate is not displayed, and an appropriate fallback is shown.
Story 4: View Fuel Surcharge in Load Detail
As a verified trucker, I want to see fuel surcharge details when I open a specific load, so that I can understand the full breakdown of what I'll be paid before committing.
Acceptance Criteria:
Fuel surcharge details are not shown on the browse list — only inside the load detail view.
When a trucker opens a load, the detail view displays fuel surcharge information.
The flat rate, per-mile rate, and fuel surcharge are all visible on the load detail page.
If no fuel surcharge applies, this is clearly indicated (e.g., "No fuel surcharge").
Out of Scope (Future Stories)
Make-offer functionality
Offer counter-flow between the trucker and the shipper
Rate/offer expiration
Booking or accepting a fixed-rate load
The Last Step Is Yours
The final review belongs to you. AI doesn't know what your team is actually ready to build, what's been scoped in other epics, or what the real sprint priority is. You do.
In this case, Story 4 was outside the team's needs for the first pass. Cut it. That left three solid stories: authenticated access, flat-rate display, and per-mile display. Not a lot. Enough to get started.
Three stories and a clearer picture of where the feature goes from here. That's a good place to be when you walk in stuck.
Now you try it. Tell AI what you're trying to build, in plain language, and see what it asks you.
