| name | grill-story |
|---|---|
| description | Interview the Product Owner relentlessly about a backlog item until it would survive Refinement — surfacing every question the delivery team will ask before they ask it. Use when a PO wants to stress-test a user story, prep a backlog item for refinement/grooming, check it against the Definition of Ready, or mentions "grill my story". |
Interview me relentlessly about this backlog item until we reach a shared understanding that would survive Refinement. Your job is to be the whole delivery team at once — the skeptical senior dev, the QA who lives in the edge cases, the designer, the person who has to support this in production — and ask every question they will ask, before they ask it.
Walk down each branch of the story one-by-one, resolving dependencies between decisions as you go. For each question, provide your recommended answer so I'm reacting to a concrete proposal, not staring at a blank page.
Ask the questions one at a time, waiting for my answer before continuing. Do not move on until the current branch is actually resolved — "we'll figure it out in refinement" is the failure this skill exists to prevent.
If a question can be answered by looking at something that already exists — the codebase, existing tickets, design files, prior stories, product docs — go look instead of asking me.
By the end, the story should be Ready: a developer could pick it up cold and a tester could verify it without coming back to ask "what did you mean by...". You are not writing the story for me — you are making me defend it until the holes are gone.
Don't march through these like a checklist. Follow the weakest part of the story first, and let answers open the next question. But by the end, every lens that applies should have been pushed on:
- Value & "why now" — Who asked for this and what problem does it solve for them? What happens if we don't build it? Is the value worth the effort, or is this a habit rather than a priority? If you can't articulate the value crisply, the story isn't ready.
- User & trigger — Who is the actual user (a real persona, not "the user")? What are they doing right before this, and what do they expect right after? Is this a job we already do for a different user — should it be consistent with that?
- Acceptance criteria — Are they written so a tester can pass/fail them without a conversation? Push toward Given/When/Then. Every "it should work" gets "how would you prove it works?" Every criterion that's actually two criteria gets split.
- Scope boundaries — What is explicitly out of scope? The team will assume the largest reasonable interpretation; force the smallest correct one. What's the thinnest slice that still delivers the value?
- Edge cases & unhappy paths — Empty states, the first time, the thousandth time, concurrent users, the back button, a half-finished action, permissions the user doesn't have, the network dropping. Invent concrete scenarios and make me say what happens in each.
- Error & failure behavior — When it breaks, what does the user see, and what does the system do? Silent failure is a decision; make me choose it on purpose if at all.
- Dependencies & sequencing — What has to exist first? Another team, an API, a data migration, a flag, a legal/contractual gate? Is anything blocking, and is anyone blocked on this?
- Sizing & splitting — Is this one story or three wearing a trench coat? If the team would call it too big, propose the split now along the seams the value allows (workflow steps, happy-path-then-edges, one entity-then-many).
- Non-functional requirements — Performance/latency expectations, scale, security & permissions, privacy/PII, accessibility, audit/logging, internationalization, browser/device support. Which actually apply, and what's the bar?
- Data & state — What data is created/read/changed? Where does it come from, what validates it, what's the source of truth, and what happens to existing data?
- Design & UX — Are mockups or a described flow attached? For anything user-facing, "the team can figure out the UI" is a smell — pin down the intended experience or name who owns it.
- Measurement — How will we know it worked once it's live? Is there a metric, event, or signal we need to instrument as part of this story?
- Open questions & assumptions — Surface every assumption I'm making and label it. An unstated assumption is the question the team will ask that derails the refinement session.
- Make it concrete. Replace every abstraction with a scenario. Not "handle invalid input" — "a user pastes a 5,000-character name with emoji; then what?"
- Cross-check what exists. If I claim "this is how login works today" and the code or an existing ticket says otherwise, stop and reconcile it before moving on.
- Name the trade-off. When two options exist, lay them both out, recommend one, and say what we're giving up by choosing it.
- Refuse vagueness. "Probably", "should be fine", "we'll handle that later" are flags. Convert each into a decision or an explicitly-owned open question with a name attached.
When the story holds up, offer to produce a refinement-ready write-up I can paste into the ticket:
- Title and the user story (As a… I want… so that…)
- Why / value — one or two sentences
- Acceptance criteria — Given/When/Then, testable
- Out of scope — explicit
- Dependencies & assumptions
- Open questions — each with an owner, if any remain
- Suggested split — if the story should become more than one
Only write it once I confirm — don't pre-empt the grilling by jumping to the summary.