User Stories
2 exercises — write well-formed user stories with role, action, and benefit, then craft testable acceptance criteria in Given/When/Then format.
0 / 2 completed
User story formats
- Story format: As a [specific role], I want to [specific action] so that [measurable benefit]
- Acceptance criteria: Given [context] / When [action] / Then [observable outcome]
- Good role: specific ("developer", "admin") — not generic ("user")
- Good benefit: measurable or describes a real problem solved — not "more easily"
- Good criteria: testable with pass/fail — "works correctly" is not testable
1 / 2
A product manager wants to write a user story for a new feature: developers on the team need a way to see all their open pull requests across all repositories in one dashboard view.
Which user story follows the correct format and captures all three required elements?
Option B is correct. It contains all three elements of the standard format: role ("a developer"), action/feature ("view all my open pull requests across repositories in a single dashboard"), and benefit/outcome ("prioritise my review workload without switching between projects"). The benefit is specific and tied to a real problem. Option A is a requirement, not a user story. Option C is a feature description in prose. Option D has the right format but the role is too generic ("user"), the action is vague ("see things"), and "more easily" is unmeasurable.
Next up: API Docs & ADRs →