User Stories
In the last section, we recorded HopPress’s initial-release functional requirements directly. In this section and the next, we will look at two common ways to capture those requirements: user stories and use cases. A user story is a short statement of a functional requirement from a user’s point of view. A use case describes the interaction in more detail, including its main path and alternatives. We will use the same HopPress behavior to see how the two forms differ.
A common form for a user story is: “As a [role], I want [goal], so that [value].” For example: “As an author, I want to submit a draft so that an editor can review it.”
This form identifies who wants something, what they want to accomplish, and why it matters. The structure is a convention, not a rule; another clear sentence can express the same requirement.
A user story is usually a starting point, not a complete functional requirement. Teams commonly pair a user story with acceptance criteria: a checklist of conditions that must be true for the team to consider the story complete. The criteria make the story testable and clarify details that the short story leaves open.
Add acceptance criteria
For the draft story, the criteria are:
- A signed-in author can submit a draft that the author owns.
- HopPress changes the draft’s state to submitted.
- The submitted draft appears among the editor’s submissions.
- The submitted draft does not appear in the list of published posts.
- Another author cannot submit the draft.
These criteria describe results a user or tester can observe.
Given–When–Then is one optional way to write an acceptance criterion: “Given Mei is signed in as an author and has an editable draft, when she submits it for review, then HopPress confirms the submission, changes its state to submitted, shows it among the editor’s submissions, and does not show it to readers.”
“Given” states what is already true. “When” states the action. “Then” states the result we expect to observe. For simple rules, a plain list may be clearer. When different conditions produce different results, you may need several Given–When–Then statements to cover all the cases.
Check the story with INVEST
INVEST is a memory aid for six useful qualities. It is a way to find problems in a story, not a demand that every story be perfect.
- Independent: it can be planned without unnecessary dependence on several other stories.
- Negotiable: its details can be clarified instead of being treated as a fixed contract.
- Valuable: it produces a result that matters to a user or customer.
- Estimable: the team understands it well enough to make a rough judgment about the work.
- Small: the team can finish it soon enough to receive useful feedback.
- Testable: the team can describe observable evidence that the result works.
Our draft story has clear value and one focused goal. The team can clarify its details before deciding how to implement the behavior. The story is testable because the acceptance criteria describe observable results. Whether it is small and estimable depends on the team’s skill and experience. It also depends on the state of the application: what is already built and what is still missing.
The qualities affect one another. A large story is usually difficult to estimate. A story with no visible value is difficult to prioritize. A story that cannot be tested may have an unclear goal. When a story fails one of these checks, revise or split it.
A user story records a functional requirement in a compact form. Acceptance criteria make its expected results testable. Together, they help a team plan and verify one unit of behavior. It is common to turn a specified system requirement into one or more user stories, each with its own acceptance criteria, before the team designs and implements the behavior.