A practical coaching guide to Agile requirements—from the mindset behind them, through discovery and decomposition, to proven story formats and the refinement habits that keep a backlog healthy. Every concept is grounded in one running example you can follow from first principle to acceptance test.
As a persona / user, I want functionality so that benefit / value.
One sentence, three slots. Nearly every format in this guide is a variation on the same idea: filling the right blanks for the right situation. The card is not the requirement—it is a promise for a conversation.
Concepts stick when you watch them play out on a single, concrete problem. Throughout this guide, a teal PennyWise callout shows the idea applied to one product, so the whole site reads as one continuous worked example.
The product: PennyWise is a mobile banking app. The outcome we care about: reduce fraud write-offs by 30% in Q1. The feature we'll trace end to end: instant card freeze—a cardholder can lock a lost or suspicious card in seconds and unlock it later.
Watch this one feature travel from outcome → job → journey → map → slice → story → acceptance test as you move down the page.
Traditional requirements assume we can know everything upfront. Agile recognizes that understanding emerges through building, feedback, and learning—so we optimize for outcomes and shared understanding, not for documents.
Agile requirements are about learning your way to the right outcome, not predicting it upfront. In practice that means pairing product, engineering, and QA early, validating assumptions quickly, and refining detail closer to delivery.
Features are hypotheses for reaching the outcome. Instant card freeze is a bet that giving cardholders a fast, trusted action will cut fraud losses. We'll ship a thin slice, measure, and refine—rather than specifying the whole fraud suite upfront.
Big Requirements Documents assume certainty early and go stale fast. Agile teams replace them with structured conversations and lightweight artifacts—story maps, example-mapping notes, acceptance tests, telemetry—so knowledge stays current and shared. Traceability doesn't live in one file; it's distributed across stories, tests, code, and analytics, held together by the conversations that produced them.
Ron Jeffries introduced the Three C's as the foundation of agile requirements:
A token for planning and conversation. Just enough text to identify the need. The card is a promise for a future conversation, not a detailed spec.
The dialogue between team, product owner, and stakeholders. This is where details emerge, edge cases are discovered, and solutions are explored.
Acceptance criteria that make the story testable. They define the story's boundaries and how we'll know it is done.
Card: "Freeze / unfreeze my card." Conversation: fraud scenarios, device authentication, issuer limits. Confirmation: freeze succeeds in ≤2s, an audit entry is recorded, and rate limiting is enforced.
Rather than defining everything upfront, we shape requirements at the right time. The farther an item is from delivery, the broader it stays; as delivery nears, we add the detail needed to design, build, and test—no earlier.
Epic: reduce fraud write-offs 30% in Q1. Feature (slice 1): freeze a card from the card screen, audit the action, enforce a simple rate limit. Stories: freeze happy path · unfreeze happy path · audit view · rate-limit edge case—only the next sprint's stories are fully specified.
Cost of Delay is the economic impact of postponing delivery. Large batches delay both value and learning. When we slice smaller, we shorten feedback loops and start the flow of value sooner—which is exactly why thin, vertical slices beat big-bang releases.
Once it's live, card freeze prevents roughly $5,000/day in fraud loss. Cost of Delay is just that daily figure multiplied by how long the capability stays unbuilt—so the lever is how soon any of it goes live, not how polished it is. Compare two ways to deliver the same feature:
Where the ~$105k comes from—and why it isn't $210k. The thin first slice is not the whole feature, so it doesn't earn the full $5,000/day. But the freeze action itself is what actually stops the charges; the later slices (audit, rate-limit, issuer-retry) mostly harden it. Credit slice 1 with about half the benefit and it earns 42 days × $5,000 × 50% ≈ $105,000 that the big-bang plan simply forgoes. The exact fraction is a judgment call—the point is that you start capturing value in week 2 instead of week 8, without waiting for the whole suite.
Techniques for discovering user needs and business opportunities before a single story gets written—each one a different lens on the same question: what progress is the user trying to make?
JTBD theory states that customers "hire" products to make progress in a situation. The same person has many jobs depending on context; we design for those situations and desired outcomes, not for demographics.
The practical task. "Stop charges on a card I can't find."
How customers want to feel. "Feel safe and in control."
How customers want to be perceived. "Look responsible with money."
When I misplace my card, I want to disable it immediately, so I can prevent unauthorized charges. Notice the format names no feature—"freeze" is just one way to do this job.
Use lean, evidence-based personas to align on goals, constraints, and environment. Avoid stereotypes; tie each story to a real segment. Effective personas capture context, goals, pain points, technical proficiency, and current behavior.
Sam, 29, freelance designer. Cares about cash-flow continuity, lives on mobile, and dreads a push alert at a bus stop—not at a desk. Dislikes support calls and delays. Every freeze decision should make sense for Sam, on a phone, in a hurry.
Journey maps visualize the end-to-end experience of accomplishing a goal—the sequence of steps, the emotions, and the pain points—revealing where a thin slice can deliver outsized value. A map covers phases, actions, thoughts and emotions, touchpoints, and opportunities.
PennyWise's freeze journey. Anxiety spikes at Decide and stays high through Act—so the biggest opportunity is a single, fast, trusted freeze action, not polishing secondary screens.
Jeff Patton's story mapping arranges stories along the user journey (the horizontal backbone) and by release or priority (vertical). Start with a walking skeleton—the minimum set of stories that makes the whole flow work—then deepen.
Read left to right for the journey (the backbone), top to bottom for priority. The first band is PennyWise's walking skeleton: the smallest set of stories that makes freeze genuinely usable.
Gojko Adzic's technique keeps delivery aligned with strategy by mapping four levels—Goal (why), Actors (who), Impacts (how their behavior changes), and Deliverables (what we build). If a deliverable can't trace its branch back to the goal, it's scope creep.
Each branch answers a question: why, who, how, what. PennyWise's freeze UI earns its place because it traces straight back to the 30% goal.
Matt Wynne's technique discovers acceptance criteria through a structured conversation using four colors of cards: the story (yellow), the rules that must hold (blue), concrete examples that illustrate them (green), and open questions (red) that drive spikes or decisions. Too many cards means the story is too big.
Rules: only the primary owner can freeze · device auth required · max 3 actions per hour. Example: owner + biometrics → success in ≤2s; a 4th attempt within the hour → blocked with a clear "try again at…" message.
Capture the behavior as concrete examples so the team's understanding, implementation, and verification all point to the same truth. It removes ambiguity, creates executable specifications, and turns into living documentation.
How to break large ideas into increments small enough to deliver and learn from—and how to tell a good slice from a bad one.
Planning happens at matching horizons. Each level chooses a different unit of work and a different question to answer.
Work nests across planning horizons. This guide follows SAFe Essential, where the planning cadence is the Program Increment (PI)—typically 8–12 weeks, or several sprints, that an Agile Release Train commits to and demos together. Each level below fits inside the one above it.
Mike Cohn's SPIDR gives five strategies for splitting a story that's too big. When a story fails INVEST, reach for one of these.
Freeze happy path → Unfreeze → Audit view → Issuer-timeout retry → Rate-limit edge case. Each slice goes UI → API → data → telemetry, so every one is shippable on its own.
Each story cuts through every layer to deliver working functionality. "Freeze from the card screen" includes UI, API, and database—one complete, usable story.
Splits the work into one story per layer—a DB story, then an API story, then a UI story. No single story delivers anything a user can touch, and value waits until the final layer lands. Prefer vertical slices, even minimal ones.
Bill Wake's INVEST criteria are a quality bar for smooth flow, not a checklist to fill. When a story fails one, reach for a slicing technique.
Implement card state management.
As Sam, I can freeze my card from the card details screen so I can block unauthorized use.
Slicing tells you how to make work small; WSJF (Weighted Shortest Job First) tells you what order to build it in. It's SAFe's prioritisation formula, and every Product Owner should be able to read one—it turns the Cost of Delay you saw earlier into a running order for the backlog: do the work with the most value per unit of effort first.
Score each column relatively—a modified Fibonacci scale (1, 2, 3, 5, 8, 13…), comparing items against one another rather than in absolute units. Highest WSJF goes first. Because Job Size is the denominator, a small job with real value beats a big one: the economic case for thin slices, made explicit.
| PennyWise backlog item | Value | Time crit. | Risk / opp. | = CoD | Job size | WSJF |
|---|---|---|---|---|---|---|
| Freeze from card screen do first | 8 | 8 | 5 | 21 | 3 | 7.0 |
| Rate limiting | 2 | 3 | 8 | 13 | 2 | 6.5 |
| Audit history view | 3 | 2 | 3 | 8 | 3 | 2.7 |
| Freeze from fraud alert | 5 | 5 | 2 | 12 | 5 | 2.4 |
Read the bottom two rows together: "freeze from fraud alert" carries a higher Cost of Delay (12) than the audit view (8), yet ranks below it—because it's a bigger job. That is WSJF working as intended. It doesn't make the call for you; it puts the trade-offs in the open so the order can be defended.
Thirteen ways to write a requirement. Filter by category, study the template, and expand each card for its purpose and a worked example—several drawn straight from PennyWise.
The classic agile format, capturing functionality from a user's perspective: who, what, and why.
As Sam (primary cardholder), I want to freeze my card with one tap so I can stop suspicious charges immediately.
Focused on the underlying job or outcome customers are trying to achieve, not a specific feature.
When I misplace my card, I want to disable it immediately, so I can prevent unauthorized charges.
A hybrid combining JTBD thinking with user-story structure, emphasizing situational context over personas.
When a suspicious push alert appears, I want a single, trusted action to freeze my card, so I can feel safe in seconds.
An inverted format that starts with business value and works backward to features.
In order to cut fraud write-offs 30% in Q1, as a fraud product manager, I want an instant self-service card freeze.
Narratives about a specific user type—context, goals, and pain points—that guide story creation.
Sam is a freelance designer who needs to stop fraud the moment it's spotted but faces it on a phone, on the move, with no patience for support calls.
Complete workflow descriptions with multiple steps and interactions, often broken into smaller stories.
Scenario: Lost card. Sam opens an alert, finds the card, taps Freeze, confirms with Face ID, and sees a frozen status with an audit entry—through a 4-step flow.
Stories addressing technical debt, infrastructure, or architecture without direct user-facing value—each tied to a visible behavior or metric.
Make the freeze API idempotent because duplicate taps on a flaky connection must never double-charge state or corrupt the audit log.
Technical foundation work supporting future user stories. Four types: Infrastructure, Architecture, Exploration, and Compliance.
Architecture Enabler: add an event-driven card-status service to enable real-time freeze, audit, and fraud-team notifications.
Stories defining boundaries, limitations, or non-functional requirements the system must adhere to.
The system must complete a freeze within 2 seconds in order to meet the trust bar set during journey mapping.
Behavior-driven format describing behavior in plain language. Directly translatable to automated tests.
Time-boxed research or investigation tasks to reduce uncertainty before implementation.
Research issuer freeze APIs for 2 days to determine whether we can guarantee a sub-2-second freeze across our top three card networks.
Stories framed as experiments with clear success metrics, emphasizing learning and validation.
We believe one-tap freeze for cardholders will cut fraud write-offs. We'll know we're right when Q1 write-offs drop 30% and freeze-related support calls fall by half.
Stories focused on process and quality improvements that boost team capability. Keep their acceptance criteria measurable.
Improve our deploy process by automating freeze-path smoke tests to achieve zero-downtime releases of the card service.
Acceptance criteria define a story's boundaries. Definitions of Ready and Done keep the whole pipeline honest.
Acceptance criteria express externally visible behavior. Three common formats:
Whatever the format, good acceptance criteria are testable (they clearly pass or fail), clear (no ambiguity), concise (focused on outcomes), and complete (covering the key scenarios)—cover the happy path and the few edge cases that matter.
Before a story enters a sprint:
Before a story is complete:
Ongoing practices that keep stories healthy and the backlog ready for sprint planning. Most predictability comes from small, consistent slices—not from perfect estimates.
Keep a steady cadence—say 60–90 minutes weekly—to clarify the top of the backlog. Each top item should leave refinement INVEST-ready with updated acceptance criteria and any required telemetry noted.
Team members reveal estimates simultaneously to avoid anchoring bias. Discussion follows when estimates diverge.
Quick relative sizing using XS–XL. Good for an initial backlog assessment.
Silent grouping of stories by relative size. Fast when there are many stories.
The Three Amigos pattern brings three perspectives together before sprint planning to build shared understanding and surface edge cases—this is where ambiguity is removed.
Product owner or analyst—why it matters and what value looks like.
Developer—what's feasible and where the risk hides.
Tester or QA—how we'll prove it works and what could break.
Decide how you'll play your own story-writing game—and keep the agreements short, visible, and revisited:
The story is just the beginning of the conversation.
The goal is not to write perfect stories. It's to build shared understanding that lets teams deliver value incrementally and respond to learning. Five principles to carry into every backlog: