User Stories & Backlogs
The unit of work that keeps a team focused on user value rather than technical tasks in isolation.
8.3.1Definition
A user story is a short description of a feature from the user's perspective — typically in the form "As a [role], I want [goal], so that [benefit]" — capturing intent rather than implementation detail. A backlog is the prioritized, ongoing list of all such stories (and other work items) not yet completed, serving as the team's single source of planned work.
8.3.2Why It Exists
Technical task lists describe what to build but not why, making it easy to lose sight of the actual user value a feature is meant to deliver. User stories exist to keep that "why" attached to every unit of planned work, and a backlog exists to hold and prioritize all such work in one place, so the team always knows what's next and why it matters.
8.3.3Anatomy of a Good Story
- User-centered framing — written from the perspective of who benefits, not the internal system change required.
- Acceptance criteria — a clear, testable definition of what "done" means for this specific story.
- Right-sized scope — small enough to complete within a single sprint (8.5), large enough to represent genuine, shippable value.
8.3.4Common Mistakes
- Stories written as technical tasks ("refactor the auth module") rather than user value, losing the connecting thread back to why the work matters.
- No acceptance criteria, leaving "done" ambiguous and open to disagreement between the person who wrote the story and the person who implemented it.
- An unbounded, never-groomed backlog, accumulating hundreds of stale items nobody prioritizes or removes.
8.3.5Best Practices
- Write stories from the user's perspective, with the underlying benefit stated explicitly, not just the feature.
- Attach clear, testable acceptance criteria to every story before it enters active development.
- Groom the backlog regularly — reprioritizing, splitting oversized stories, and removing genuinely stale items.