The useful first output is a small set of proposed stories, a source reference for each, and questions about unresolved behavior. The Agile Alliance's user-story guidance treats the story as part of an ongoing conversation about useful functionality. A polished sentence cannot replace that conversation.
Keep request notes and policy separate
This original fictional supply-request feature has four notes:
| Source | Supplied information |
|---|---|
| P1: current procedure | Staff submit supply requests. Only the coordinator approves or declines them. |
| I1: staff interview | “I keep emailing to ask whether my request was approved.” |
| I2: coordinator interview | “I need the purpose of a request before I can decide.” |
| N1: planning suggestion | “Maybe let people approve their own requests.” No decision recorded. |
P1 is the current authorization rule. N1 is a suggestion that conflicts with it. Do not let a model merge those records into “Staff can approve their own supply requests.” The team needs a decision before changing that permission.
No source describes confidential request categories, notification channels, or whether staff can see other people's requests. Those are questions for the product discussion, not features to add because they are common elsewhere.
Draft a story that the evidence supports
An illustrative proposed story is:
As a staff requester, I want to see the recorded decision on my own submitted supply request so I can check its status without asking for an update by email.
Its basis is P1 and I1. “Own” keeps the example within the stated requester's task; the team still needs to confirm the precise access rule. The story does not promise automatic email, self-approval, or a coordinator dashboard.
I2 suggests a different conversation: what purpose information does the coordinator need, and when must it be supplied? Keep that question beside a candidate story rather than making the first story cover submission, approval, dashboards, notifications, and reporting.
For a worked example of dividing a broad feature into useful increments, read the user-story template. Here, the immediate problem is establishing which actor and behavior your notes support before choosing those increments.
Copy a notes-to-stories prompt
Draft proposed user stories from these product notes.
Product purpose and people doing the work: [ENTER]
Current policy and authorization rules with source IDs: [PASTE]
Interview excerpts and observations with source IDs: [PASTE]
Suggestions, approved decisions, and rejected ideas: [PASTE SEPARATELY]
Known source precedence: [ENTER OR UNKNOWN]
First identify actor/permission conflicts and missing decisions.
Keep current rules distinct from suggested changes. Do not settle a
conflict merely by choosing the newest note.
Propose a small story set. For each, give role, goal, benefit, source
IDs, supported behavior, and unresolved questions. Do not invent
personas, motivations, approvals, permissions, interface features,
story points, or delivery promises. Mark inferred benefits as proposed
where the source does not establish them.
Suggest one concrete confirmation example per story. Label it proposed
and identify every missing rule needed to agree its expected outcome.
Keep questions separate from agreed acceptance expectations. Return a
discussion draft, not a ready-for-development verdict. Do not edit the
backlog or assign people.
This follows the task/context/boundary approach in OpenAI's prompting documentation, checked October 24, 2026. Review the draft against the source notes before expanding it.
Ask for a confirmation example without pretending it is agreed
For the proposed status story, use a fictional request S-28 with a recorded coordinator decision of Declined. A candidate example is: its requester opens the request and sees Declined. That is an expectation to discuss; the notes have not supplied a real application result.
Ask what appears before a decision and who may see the coordinator's explanation. Those answers affect the story's behavior. Leave them open until the responsible people agree.
If ChatGPT adds “all staff can see every request,” ask for the source supporting that permission. Remove the unsupported expansion while retaining the useful status story. Take P1 versus N1 to the policy owner, then update the backlog with the actual decision and its reference. Create rule-level test cases only after the expected behavior is settled.