Enable javascript in your browser for better experience. Need to know to enable it? Go here.

Don’t ask AI to write the user story yet

“Users should be able to export a filtered report.”

 

Paste that into an AI assistant and you’ll get a user story in seconds, persona and acceptance criteria included. It will look finished.

 

It isn’t. 

 

What does “filtered” mean here? Every matching record, or just the page the user is looking at? Which date does the filter use? If someone has hidden a column, should it still turn up in the download?

 

None of these are writing problems. They’re product decisions, and someone has to make them. So before you ask AI to write requirements, ask it to find the decisions nobody has made yet. At that stage, what you need from it is a list of questions for the team.



The trouble with confident gaps

 

AI is good at turning a vague request into specific language. That’s the problem: specific doesn’t mean validated.

 

Say an operations team asks for a weekly report. Their notes confirm a CSV download, a date filter and access limited to authorized records. They say nothing about duplicates. The draft comes back with “remove duplicate records” in it. It sounds sensible, so nobody blinks.

 

But that line just invented a business rule. What makes two records duplicates? Could two identical-looking rows be two separate events? This ambiguity will resurface later in development or testing, where it costs more to settle.

 

I think of these as confident gaps: places where the output sounds certain because the model quietly filled a hole the team never looked at.

 

 

Ask for three piles, not a draft

 

The fix starts with what you ask for. Give the assistant the user’s task, the outcome they want, the rules you’ve already confirmed and your source notes. Then ask it to sort everything into three piles: 

 

Confirmed: Validated information. It may label an assumption as “confirmed”, so ask it to quote the source line for every confirmed item.

 

Assumed: Someone is presuming it but nobody confirmed it.

 

Unknown: Nothing in the notes touches it.

 

For the export example, a small decision record could look like this. The entries below are illustrative; “confirmed” means supported by the supplied notes.

Status

Rule or question

Decision owner

Source

Still open

Confirmed

The export must be a CSV file.

Product owner

Approved requirement notes

Nothing for file format.

Assumed

The export includes all matching records, rather than just the visible page.

Product owner to confirm

AI suggestion; no supporting source

Which records should be included?

Unknown

Should duplicate-looking rows be removed?

Business/data owner to confirm

Not covered in the notes

What counts as a duplicate, and could removing it lose information?

The useful part is seeing where each statement came from. An AI suggestion stays an assumption until someone with the right context confirms it. After that conversation, update the record with the agreed rule and its source.

 

And tell it not to fill the gaps. Anything it suggests stays a suggestion until the right stakeholder agrees to it. That one instruction changes the whole output, from “here’s your story” to “here’s what you still need to find out”.

 

 

Not every gap deserves a meeting

 

A list of 40 open questions helps about as much as a story with 40 hidden assumptions. You still need judgment about what matters now.

 

Take a retail returns feature written up as “customers can cancel a return”. Can they still cancel once the courier has collected the parcel? What happens to a refund that’s already under way? Those answers cut across customer experience, logistics and payments. They need settling long before anyone polishes the confirmation message.

 

A quick test helps. Put three questions to every gap:

 

  1. Could the answer change the scope?

     

  2. Could it change who is allowed to do what?

     

  3. Could it change what the data or the outcome actually means?

 

A yes to any of them moves the gap up the list. Ask the assistant to spell out what each open question will change, then go through the list with the team. A discussion is still just as important, what AI should do is shape it.

 

A request for an export shouldn’t quietly grow into scheduled reports, notifications and a new dashboard. Keep nice-to-haves in their own pile, too. 

 

 

Bring better questions into refinement

 

If your team already uses refinement, Three Amigos or Example Mapping, this approach can fit into that work. Refinement gives the team space to clarify a story. Three Amigos brings business, development and testing perspectives into the conversation. Example Mapping gives that discussion a structure through rules, concrete examples and unanswered questions.

 

An AI review can help prepare for those conversations. Bring its suggested gaps into refinement, ask the group which ones matter and use examples to test the answers. For the export story, “all matching records” becomes more concrete when someone asks: “If there are 20,000 matches and only 50 on screen, what should the file contain?” The people in the room still need to agree on the behavior.

 

Try it on one upcoming requirement. Note which questions were useful, which were noise and how long reviewing them took. Did the team uncover an important decision earlier? Did the discussion end with clearer examples and fewer assumptions?

 

That is where I would look for value: whether the team understands the story better before someone starts building it.

 

 

Write the story last

 

Once stakeholders have answered the questions that matter, write down what was agreed: the rule, who owns it, where it came from and what’s still open. Only then ask AI to draft acceptance criteria, and draft them from that record.

 

Say the reporting team confirms that exports include all matching authorized records and only the columns the user selected. Now the criteria have something real to describe. Date boundaries and access rules still need their own definitions, and no well-written scenario can stand in for them.

 

That small decision record often ends up worth more than the story. When a requirement changes months later, the team can revisit the decision instead of guessing at the sentence.

 

Here’s a prompt to start with:

 

Review these notes using only the evidence supplied. Separate confirmed requirements, assumptions and unknowns. For each missing decision, explain its consequence and suggest a question for the relevant stakeholder. Keep optional enhancements separate. Do not invent business rules or write final acceptance criteria.

 

Once the decisions are confirmed:

 

Draft acceptance criteria from these confirmed decisions. Link each criterion to the decision behind it and list any unresolved dependencies.

 

Run this in an AI environment your organization has approved, and share only what it’s cleared to hold. The analyst still owns the result, questions and draft alike.

Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.

Explore a snapshot of today's tech landscape