Story
A story is one specific piece of functionality a user can feel, small enough to finish inside a single sprint. The Story Writing Guide teaches the craft, the tests, the failure modes. Here is the whole card, blank and then filled out completely, because the guide shows each field on its own and the assembled card is the thing a builder actually reads.
The card, blank
Title
As a [user type], I can [action] so that [benefit].
[The whole sentence goes in the title field. That's the point.]
Description
When [the situation hits],
As [this user], I want [this],
So that [this payoff],
But [the friction in the way today].
Solution Approach
[One or two sentences on direction. Outline the approach, don't write the spec. Fill this in after the acceptance criteria, not before.]
Technical Notes
[Constraints, not preferences. The system this has to work with, the case that bit you last quarter. Implementation choices belong to the builder.]
Acceptance Criteria
- [The happy path: everything works, the user gets what they came for]
- [The edge cases: the empty cart, the already-paid invoice, the expired link]
- [The error states: something fails, and the user knows what and what next]
- [The performance bar: fast enough to be usable]
Definition of Done
[The quality bar the whole sprint agreed to, same for every card. If yours isn't written down, that's the first story problem to fix.]
Task Breakdown
- [The day-sized technical pieces, one owner each. The task template page owns these.]
Dependencies
- Depends on
- [what must land first]
- Unblocks
- [what's waiting on this]
Labels
[Your team's tags for filtering and grouping. Steal your team's convention, not mine.]
Two craft notes, both from the guide. First, the title carries the whole sentence. A stranger reading the board should know who this serves and why they'd care, from the title alone.
Second, write the acceptance criteria before the solution approach. Knowing what done means keeps the approach honest. Do it in that order even though the fields read the other way. And when a criterion needs precision, the Given/When/Then shape from the epic card works here too. You'll see it in the filled card below.
The card, filled
The pay-link story, cut from the Automate Payment Reminders epic you just read. The hour estimates on the tasks are made up to show the sizing, not real numbers off a real sprint.
Title
As a customer, I can pay an invoice straight from the reminder email so that paying takes one click instead of a login and three screens.
Description
When a payment reminder lands in my inbox,
As a customer with an overdue invoice, I want to pay straight from the email,
So that paying takes one click,
But today the link sends me through a login and three screens before I ever see a payment form.
Solution Approach
Each reminder email carries a one-click pay link to the payment processor's hosted payment page. The customer pays there, with no account login.
Technical Notes
The processor's hosted page already exists; the link must work without a login. Reminder copy stays short and polite. This removes a chore, it isn't a collections tactic.
Acceptance Criteria
- Given an invoice is past due and a reminder email went out,
When the customer clicks the pay link,
Then they land on a payment page for that exact invoice, and payment can be made via credit card. (Happy path.) - Given the invoice was already paid,
When the customer clicks an old reminder link,
Then they see the invoice marked paid instead of a payment form. (Edge case.) - Given a payment fails,
When the customer retries,
Then they see what went wrong and can try another card without starting over. (Error state.) - The payment page loads inside the bar your team sets. (Performance.)
Definition of Done
- Has the work been peer reviewed?
- Did all the unit tests pass?
- Did the product lead review it?
Task Breakdown
- Build the secure pay link: generate a unique link per invoice and resolve it back to the right one (a day)
- Build the payment page the link lands on, including the failure and retry states (a day)
- Add the link to the reminder email template (half a day)
- Integration tests across the whole click-to-paid flow (half a day)
Dependencies
- Depends on
- the payments provider's hosted pages.
- Unblocks
- the finance lead's reporting story later in the epic.
Labels
[Your team's convention. This card would carry something like invoicing, payments, reminders.]
Read the card as a stranger would. You know who it serves, what they can do after, what done means, and what got ruled out, and nowhere did anyone name a library, a schema, or a function. What solves the problem is on the card. How to build it belongs to the people building it, and each task above is a day or less of somebody's actual work, written as its own card.
The Definition of Done is sprint-wide, so it's the same three questions on every card in the sprint, not just this one. Acceptance criteria tell you this story behaves. Done tells you everything this sprint produced could ship as is. Two different gates. Both pass, or the card isn't finished.
The edge case in the middle of the acceptance criteria travels. The already-paid invoice resolves to a paid confirmation, not a payment form. That line carries down to the task cards, and you'll meet it again on the bug page, where a bug report gets written against exactly that expectation.
Copy it in
Copy the blank into your tracker and write the next story out of your current epic today. Fill the title and description first, acceptance criteria second, solution approach last. Then break the tasks out, one card each, because a story isn't buildable until the tasks under it exist. The task template is the next page.