Describing work from the user's view.
WHAT A USER STORY IS
A short description of something a user wants, and why.
WHAT THE COMMON FORM IS
Who wants it, what they want, and what it achieves for them.
WHY THE LAST PART MATTERS MOST
It states the purpose, which allows the team to propose a better solution.
WHAT A STORY IS NOT
A specification.
WHAT IT IS
A placeholder for a conversation.
WHAT MAKES A GOOD ONE
Independent of others, where possible Negotiable in how it is achieved Valuable to someone Estimable Small enough to complete in an iteration Testable
WHAT ACCEPTANCE CRITERIA DO
State what must be true for it to be complete.
WHY THEY MATTER
They prevent disagreement about whether something is done.
WHAT TO INCLUDE
The normal case The important failure cases Anything explicitly out of scope
WHAT TO AVOID
Stories describing technical tasks with no user value Stories too large to complete Stories nobody can test
WHAT TO DO WITH A STORY TOO LARGE
Split it by behaviour, not by technical layer.
