Writing a Story

A user story describes an outcome for somebody, not a task for you. The usual template is: as a someone, I want something, so that some benefit.

The template is not sacred, but the third clause is. 'So that' is what stops you building something nobody needed, and it is the clause people leave out. If you cannot complete it, you do not yet know why this work exists.

Two ways to describe the same work

Tasks

Add a posts table
Add a serializer
Add an endpoint
Wire up the form

Story

As a member,
I want to save a draft
so that I can finish
writing it tomorrow.

Compare → The left is a plan and it is fine as one. The right is a reason. The difference matters when you have to cut scope: you can drop a task and still deliver the story, and you cannot tell that from the left column.

Keep them small. A story that takes more than a couple of days is really several stories, and it hides its own progress: it is ninety percent done for a week.

Splitting well means each piece still delivers something. Splitting badly means 'build the backend' and 'build the frontend', neither of which is usable alone.

Mark this lesson complete

Signed in, your progress follows you to every device.

Next: Acceptance Criteria and Done →

← Back