User story

Most wasted building starts with a vague task such as "add an export feature". Nobody can say when that is done, so the argument about whether it works happens after the work. A story forces three decisions up front: who it is for, what they do, and what proof counts. The "see a result" clause is the important part, because it turns an opinion into something that can be checked on the live product.

For people building with AI, a story is also the best instruction to give a coding agent. It carries the purpose, so the agent builds the right thing rather than the literal thing.

• Name a specific type of user, not "the user" in the abstract. A bookkeeper and a sales rep want different things.
• State the action in plain words and leave out the implementation.
• Write the result as something observable: a file, a screen, an email, a changed number.
• Keep each story small enough to build and check in one sitting. If it has two results, it is two stories.
• Keep the finished stories. Together they are a list of provable capabilities and a ready-made test plan.

A user story names a type of person, an action and an outcome. The classic shape is: "As a finance lead, I can export last month's invoices and see a file whose totals match the dashboard." It says nothing about databases, buttons or code. It describes what a real person can do once the work is finished, and how anyone can tell.

• Writing a technical task and calling it a story, for example "add an index to the invoices table".
• Leaving out the result, so nobody knows when to stop.
• Bundling five outcomes into one story, which makes it impossible to say which part failed.