What this resource covers
User stories summarize a user goal. Use cases describe interactions, alternatives, and exceptions in more detail. Acceptance criteria define the observable conditions that must be satisfied. These tools complement rather than replace workflow and data analysis.
- Write user stories around a role, goal, and business reason
- Use detailed use cases for complex, regulated, integrated, or exception-heavy workflows
- Document preconditions, normal flow, alternatives, failures, and postconditions
- Attach business rules and data validation requirements
- Define acceptance criteria that a reviewer or tester can evaluate
Information to prepare
Bring user roles, goals, triggers, preconditions, normal steps, alternate paths, exceptions, business rules, data, permissions, and examples of acceptable and unacceptable outcomes.
- Approved user roles and goals
- Current and proposed workflows
- Business rules, permissions, calculations, and exceptions
- Examples of valid and invalid data
- Release priorities and Definition of Done
Expected planning outputs
Produce stories for planning, use cases for interaction detail, and acceptance criteria that state observable pass conditions. Each artifact should reference the same underlying workflow.
- Prioritized user stories
- Detailed use cases where needed
- Acceptance criteria for each deliverable
- Business-rule references
- Testable completion conditions
Practical example
How it can be applied
Story: As a dispatcher, I want to assign an available vehicle and driver to a booking so the trip can be scheduled. Acceptance criteria can cover active licenses, vehicle status, schedule conflicts, required documents, successful assignment, and the audit record.
Common mistakes to avoid
- Writing every requirement as one-line story without supporting rules
- Describing implementation instead of the user outcome
- Using acceptance criteria that simply repeat the story
- Ignoring negative paths and permission failures
- Calling development complete before agreed testing and review are satisfied
FAQ
Common questions
Do user stories replace requirements documents?
Not always. They work well for backlog planning but may need supporting workflows, rules, data definitions, designs, and integration specifications.
When is a use case better than a short story?
Use cases help when an interaction has several actors, alternatives, exceptions, or system boundaries that a short story cannot explain clearly.
Who approves acceptance criteria?
The responsible product or business owner should confirm them with delivery and quality participants before implementation is considered complete.