Backlogs and User Stories

Here's a five-word test that exposes whether any task is worth doing. Take any item on any to-do list — "build the online form," "make the dashboard," "write the report" — and force it to finish this sentence: so that… what, exactly? If the sentence ends somewhere real — someone's morning gets easier, a decision gets made sooner — you have work worth doing. If it can only end by repeating itself — "build the form… so that we have a form" — you've just caught an output wearing a disguise.

By the end of this video, you'll be able to write a proper user story with a "so that" that carries real value, explain what a story actually is — hint: it's three things, all starting with C — and cleanly separate two ideas that even experienced teams tangle up: acceptance criteria and the Definition of Done.

Quick recap from Module 2, because everything today lives inside it. The Product Backlog is the single, ordered, living list of everything that might add value to the product. Three words carry the meaning. Single: one list, not five spreadsheets and a wish channel. Ordered: a real sequence, top to bottom — we'll spend all of next lesson on how to order it. Living: it changes as you learn; a backlog is never a frozen requirements document, and treating it like one quietly reinstalls waterfall behind agile vocabulary.

The backlog's native language is the user story, and it follows one pattern: As a — type of user — I want — some goal — so that — some benefit.

Here's our running example, from a neighborhood bakery going online: As a regular customer, I want to pre-order my usual online, so that it's waiting at eight a.m. — no queue.

Look at the anatomy. "As a regular customer" names who — a real person with a morning, not "the system." "I want to pre-order my usual" names the goal in the user's words. And "so that it's waiting at eight, no queue" — that's the payload. The "so that" is the outcome link. It's last lesson's lesson, smuggled into grammar: every story carries its own "we believe X moves Y."

Which gives you a quality test you can apply in seconds: a story whose "so that" just restates the feature — "I want a form so that I can fill in a form" — is an output in disguise. No bet, no benefit, no reason to exist. When you meet one, don't polish the wording. Ask the person who wrote it: what were you hoping would change? The answer is the real story.

Now, what is a story, physically? The classic answer: three Cs.

Card. A story is deliberately small — small enough to fit on a card. That's not a limitation; it's the design. The card is a placeholder, a promise to talk, not a specification.

Conversation. The real detail lives in the conversation the card triggers. When the bakery team discusses the pre-order card, they discover things no document anticipated — regulars want the same order every time, so a "repeat my usual" button beats a fancy menu. That discovery is the actual specification, and it only exists because the card stayed small enough to need a conversation.

Confirmation. How will we know it's right? Before building, the team agrees on a few concrete checks. For our story: the order confirmation email arrives within a minute; a pickup slot can be chosen at checkout; payment on pickup works. Those checks have a name — acceptance criteria — and they're about to matter.

So: a story is an invitation to a conversation, with a receipt. It is not a mini-contract, and teams that treat stories as contracts get waterfall in card-sized pieces.

Here's the pair everyone tangles, untangled with one question: does this apply to one item, or to every item?

Acceptance criteria belong to this story and no other. Confirmation email within a minute, pickup slot at checkout — those checks make no sense attached to a different story.

The Definition of Done — which you met in Module 2 — is the quality bar for every item the team ships, no matter what it is. The bakery's might read: tested on mobile and desktop, live on the real site, staff briefed before launch. The pre-order story must pass it. So must the loyalty program, the allergy page, and everything else, forever, until the team deliberately raises the bar.

One more: acceptance criteria answer "did we build the right thing?" The Definition of Done answers "did we build the thing right?" A story is genuinely done only when both say yes.

Two pieces of vocabulary you'll meet in the wild, sized for a beginner. You may hear INVEST — a checklist of story qualities. Keep the compressed version: good stories are small, valuable, and clear. And you'll hear epic: a story too big to work on yet. An epic isn't a different species — it's a story that needs splitting before anyone builds. "Take the bakery online" is an epic; "pre-order my usual" is one of the stories inside it.

You might think user stories are just tasks with fancier wording — "build form" in a costume. That's understandable; badly written stories are exactly that, and you'll meet plenty. Actually, the format exists to force two questions that a task never asks: who is this for, and what changes for them. A task tells you what to do. A story tells you why it's worth doing — and, through its acceptance criteria, how you'll know you succeeded. Strip the who and the why, and yes, it's just a task. Keep them, and every line of your backlog carries its own reason to exist.

Three things to keep. One: the backlog is single, ordered, and living — never a frozen spec. Two: a story is Card, Conversation, Confirmation — an invitation to talk, with a receipt — and its "so that" is where the value lives; a circular "so that" means an output in disguise. Three: acceptance criteria govern this item, the Definition of Done governs every item — right thing versus thing done right.

You can now write a good backlog. But a good backlog always holds more good ideas than the team has capacity — which means the order of the list isn't administration. It's strategy. Next lesson: how to choose.