Draft User Stories from Evidence, Then Gate Every One Through INVEST

Workflow area: Requirements Quality · Tier: Foundation · Hands-on time: ~25 minutes

Story drafting is mechanical once the evidence exists: actor, need, outcome, in your team's format. That is exactly the work AI does well — and exactly where quality erodes, because generated stories are uniformly fluent whether they trace to a stakeholder need or to the model's idea of what a system like yours usually has. The discipline is a two-stage gate: INVEST for structural quality, and an evidence trace for legitimacy. A story that cannot name who asked for it and where does not get an ID.

When to use — and when not to

• Use it when you have a validated evidence packsynthesized findings from pb-01, corrected process models, confirmed pain points — and need them decomposed into backlog-ready stories.
• Use it when converting a legacy requirements doca BRD moving to an agile delivery team can be exploded into stories fast, with each story citing its source section.
• Use it when story quality is driftinga team whose stories keep bouncing back from refinement ("too big", "not testable") benefits from the INVEST gate as a standing pre-check.
• Skip it when the evidence is thingenerating stories from a one-line feature idea produces confident fiction; do the elicitation first (pb-01, pb-02).
• Skip it for spikes and enablers that don't fit the templateforcing "As a developer, I want a database migration" through user-story format is theater; write a plain task.

The recipe

1. 1.

   Stage the evidence. Gather the synthesis document, relevant findings with their citations, and your team's story conventions — format, definition of ready, story-point norms, and two or three examples of stories the team considers good.

2. 2.

   Generate stories bound to evidence.

   Copy

   You are a business analyst drafting user stories for an agile team.
   Team format: [PASTE 2-3 EXAMPLE STORIES SHOWING YOUR CONVENTIONS]
   Definition of ready: [PASTE OR SUMMARIZE]
   
   From the evidence pack below, draft user stories.
   
   For each story produce:
   - TITLE
   - STORY: As a [specific role], I want [capability], so that
     [outcome the evidence supports].
   - EVIDENCE: which finding(s) this story traces to, quoted — e.g.
     "[S1, Ops lead, 14:32] ..." — copied exactly from the pack.
   - NOTES: open questions, dependencies, assumptions marked
     (ASSUMED).
   
   Rules:
   - Every story MUST trace to at least one finding. If a capability
     seems obviously needed but has no evidence, put it in a separate
     list titled UNSUPPORTED CANDIDATES — do not dress it as a story.
   - One user-visible outcome per story. Split anything compound.
   - The role must be a real role from the evidence, never "user".
   - Do not invent business rules, thresholds, or process steps that
     are not in the pack.
   
   Evidence pack:
   [PASTE SYNTHESIZED FINDINGS]
   

3. 3.

   Run the INVEST gate as a separate pass. Do not let drafting and critique share a prompt — the model grades its own homework leniently. Start a fresh conversation:

   Copy

   You are a skeptical agile coach reviewing user stories. For each
   story below, score it against INVEST:
   
   - Independent: can it ship without waiting on another story here?
   - Negotiable: does it specify a solution instead of a need?
   - Valuable: WHO benefits, and does the cited evidence actually
     show they want this? Challenge weak "so that" clauses.
   - Estimable: could a team size this without a spike?
   - Small: deliverable within one sprint?
   - Testable: could acceptance criteria be written with a clear
     pass/fail?
   
   Output per story: PASS or FAIL per letter, one-line reason for
   each FAIL, and a suggested split or rewrite where applicable.
   Be strict: a story that names no specific beneficiary FAILS V.
   
   Stories:
   [PASTE DRAFTED STORIES]
   

4. 4.

   Read a sample of good gated output and act on it.

   Copy

   STORY: As an intake clerk, I want duplicate vendor detection at
   entry, so that I stop reconciling duplicates at month-end.
   - I: PASS · N: PASS · V: PASS — traces to [S1, Ops lead, 19:04]
     "we found 340 duplicate vendors last quarter"
   - E: PASS · S: FAIL — detection plus merge workflow is two
     sprints; split merge into its own story.
   - T: PASS
   

   Apply the splits and rewrites yourself — you are the editor, not the courier. Anything in UNSUPPORTED CANDIDATES goes to your elicitation backlog, not the product backlog.

5. 5.

   Human-verify the trace before backlog entry. For each surviving story, open the cited finding and confirm the story says what the stakeholder meant — not a plausible generalization of it. Then load stories into Jira or Azure DevOps with the evidence citation in the description. Future-you, defending a story in refinement, will need it.

Make it yours

• Claude Project as the team's story mill: pin team conventions, definition of ready, and the two prompts in a Project; every analyst then drafts and gates in the same house style.
• Jira + Rovo / Azure DevOps Copilot: once stories are in the tool, use the native assistant for in-place edits and duplicate detection against the existing backlog — but keep the INVEST gate in your chat tool, where you control the rubric.
• ChatGPT for the compact variant: merge steps 2 and 3 into one prompt with an explicit "draft, then critique in a second section" instruction when working solo on small batches — accept slightly softer critique as the price of speed.
• Gemini in Workspace: teams living in Sheets can run the gate as a rubric table — stories in rows, INVEST letters in columns — which product owners find easy to scan in refinement prep.

Quality check

• Every story traces to real evidencethe citation exists, is quoted accurately, and the stakeholder actually meant this; a story with a decorative citation is worse than one with none.
• No invented specificsthresholds, field names, and business rules in stories all come from the pack, not from the model's sense of the typical.
• The beneficiary is named and plausible"as a user" or a "so that" clause restating the "I want" clause means the value case is missing.
• Splits happenedif every drafted story passed S on the first try, your gate is too soft; evidence-dense stories almost always hide a compound.
• UNSUPPORTED CANDIDATES stayed out of the backlogthey are elicitation questions for the next stakeholder session, and validating them there closes the loop.
• The product owner reviewed value, you reviewed traceabilitythe gate assists prioritization; it never replaces the human owner's call.