Playbook · 12 min read
A 78-question playbook for product managers, business analysts, and delivery leads. Covers context, users, current-vs-future state, dependencies, Gherkin acceptance criteria, and the non-functional stuff that blows up in production. Built on INVEST, the 3Cs, and Example Mapping.
TL;DR
The template is easy. As a [user], I want [capability], so that [outcome]. The hard part is the conversation that makes the template honest. Use this question bank during refinement, discovery workshops, or wherever a vague ask threatens to become a half-baked ticket. The goal is not to answer every question. It is to run out of red cards before engineering starts.
Foundations
Every question in this post maps to one of two patterns from agile practice. Knowing the pattern is the difference between running a refinement session and running a game of twenty questions.
Framework 01
Bill Wake, 2003. The quality checklist.
Framework 02
Ron Jeffries. The process.
INVEST is the checklist. The 3Cs is the workflow. Use both.
The question bank
Work top to bottom for greenfield features. Cherry-pick for refinement of an existing story. If a category returns blank answers, that is a red card. Park it, resolve it, and only then bring the story into the sprint.
Before anyone writes a line of Gherkin, get crisp on what is actually being asked for. If you cannot answer these in one sentence each, you do not have a story yet, you have a wish.
Questions B and C from your intake sheet live here.
Stories are promises of a conversation, but first you need to know who the conversation is with. Capture the user, the benefiter, and anyone who can veto the work.
Questions D and K from your intake sheet live here.
Every story needs a reason for being. If the why is missing, engineers will fill the vacuum with their own assumptions. That is how you end up with features no one asked for.
Questions E and F from your intake sheet live here.
The "as is" forces you to describe the real workflow, not the one on the architecture diagram. The "to be" forces you to describe the finish line in terms a user would recognise.
Questions G and H from your intake sheet live here.
Most stories fail in delivery because of something that was never written down. Force the conversation early.
Question I from your intake sheet lives here, plus the assumption work most teams skip.
This is the Confirmation in the 3Cs. Write it in Gherkin when the behaviour is testable, or as a bulleted list when it is a quality attribute. If you cannot describe how you would verify the story, you cannot finish it.
Question J from your intake sheet, expanded into the work that actually makes stories testable.
The stuff no one thinks to ask in refinement, then everyone argues about in the incident channel. Ask once, ask early.
A good story predicts the incident review. Ask the uncomfortable questions before engineering does.
A story is not small if QA cannot finish it inside the sprint. Make testability part of refinement, not a negotiation at the end.
Shipping is step one. The story is not closed until someone has looked at whether it worked.
Technique
Matt Wynne’s Example Mapping turns the question bank into a live, timed conversation. You need four colours of index card (or four shapes in a virtual board) and a 25-minute timer per story.
Yellow card
The card itself. One per session. Written in the As a, I want, So that format.
Blue card
The acceptance criteria or business rules that must hold. Usually three to seven per story.
Green card
A concrete example for each rule. If you cannot produce one, the rule is too abstract.
Red card
Anything you cannot answer in the room. A pile of red cards means the story is not ready.
Run a session every other day, one story at a time, time-boxed to 25 minutes. If you finish early, the story is clear. If you run out of time with red cards on the table, the story is not sprint-ready. This is the fastest way to expose ambiguity before an engineer types `git checkout -b`.
Copy and paste
If you are running intake through a spreadsheet, a form, or a wiki page, the columns below mirror this question bank and are enough to take a story from idea to sprint-ready. Adjust the fields for your domain.
| Field | What to capture |
|---|---|
| A. Timestamp | When the request was raised. |
| B. Specific change required | The one-sentence ask. |
| C. Front end, back end, or both | Forces a scope conversation early. |
| D. Who is impacted or benefits | Name the user, not the department. |
| E. Why this is important | The pain or opportunity driving the work. |
| F. Expected benefit | The outcome or metric that moves. |
| G. Current (as is) state | The real workflow today, workarounds included. |
| H. Future (to be) state | What a user will see or do after the change. |
| I. Dependencies and constraints | What blocks this and what it blocks. |
| J. Acceptance criteria (Gherkin) | Given, When, Then for each rule. |
| K. Stakeholders and roles | Approvers, informed parties, support owners. |
| L. Non-functional requirements | Performance, security, accessibility, logging. |
| M. Risks and edge cases | What could go wrong, by whom, when. |
| N. Test plan | How QA verifies this, with what data, in which environment. |
| O. Rollout plan | Who gets it first, how success is measured. |
Columns A through K match the intake sheet most teams already use. Columns L through O are the fields teams usually discover they need after the first production incident. Add them now.
When you have 15 minutes
Not every story needs the full bank. For smaller work, or for refinement when the sprint starts in an hour, this is the shortest responsible version.
FAQ
Card, Conversation, and Confirmation. Coined by Ron Jeffries, the Card is the short written story, the Conversation is the shared understanding built during refinement, and the Confirmation is the acceptance criteria that proves the story is done. Most failed stories failed the Conversation step, not the Card.
Bill Wake's 2003 acronym: Independent, Negotiable, Valuable, Estimable, Small, and Testable. A good story stands alone, invites discussion, delivers value, can be sized, fits inside a sprint, and has a clear way to verify it is done. Use INVEST as the pass-fail checklist before pulling a story into a sprint.
As a [specific user or role], I want [a clear capability], so that [an explicit outcome or value]. The template is a forcing function, not a format. If you cannot name a real user, a specific capability, and a measurable outcome, the story is not ready.
A refinement technique from Matt Wynne. You time-box 25 minutes per story and capture four things on coloured cards: the story (yellow), rules (blue), concrete examples of each rule (green), and open questions (red). A pile of red cards means the story is not ready for the sprint. It is the fastest way to expose ambiguity before engineering starts.
Enough to get rid of the red cards. For a small, well-understood story you might answer six questions across context, acceptance, and testing. For anything new, regulated, or cross-team, expect 20 or more. The question bank in this post is a menu, not a homework assignment.
No. Gherkin (Given, When, Then) is excellent for behavioural rules with concrete examples, especially when BDD tooling like Cucumber is in play. For non-behavioural criteria, such as performance targets or compliance rules, a bulleted list is clearer. Use the format that makes the check unambiguous.
Work in three passes. First, the Card: user, capability, outcome in one sentence. Second, the Conversation: walk through the question bank with engineering, design, and the domain expert until the red cards are gone. Third, the Confirmation: convert the rules and examples into acceptance criteria the team can test. Do not skip pass two.
Acceptance criteria are story-specific and describe the behaviour the story must exhibit. The Definition of Done is team-wide and describes the quality bar every story must clear, such as unit tests passing, documentation updated, accessibility checked. You need both.
Or skip the questions
Backlog.cloud joins your meeting, listens to the conversation, and produces user stories, acceptance criteria, decisions, and action items in your backlog before the call ends. Every question in this playbook, every time.