Product backlogs and user stories

In an adaptive project, the product backlog plays the role that the scope statement and WBS play in a predictive one, but it behaves very differently. It is never finished, it is ordered rather than just listed, and its items become more detailed as they rise toward the top. This lesson looks at how a good backlog is built and kept healthy, and at the user story, the most common format for backlog items. Lesson 8 covers how items are prioritized and sized.

What makes a good product backlog

The product backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work for the Scrum Team. A widely used summary of a healthy backlog is DEEP: detailed appropriately (items near the top are small and well understood; items further down are larger and vaguer), estimated (items have size estimates, rough for lower items), emergent (it changes as the team and stakeholders learn) and prioritized, or more precisely ordered (there is a clear sequence, not a list of "high priority" items with equal rank).

A backlog can hold many kinds of items: features, defects, technical work such as upgrading a library, knowledge-acquisition work such as a prototype, and improvements from retrospectives. Keeping them all in one ordered list forces honest trade-offs. If the Compass team kept bug fixes in a separate list, the product owner would never see that fixing the login timeout matters more to patrons than the room booking feature.

The hierarchy of backlog items

Teams use different words, but a common hierarchy runs from themes or initiatives (broad goals) to epics (large bodies of work that will take several sprints), features (meaningful capabilities that might fit in a release) and user stories (small slices of value that fit easily in one sprint). Developers may break stories into tasks during sprint planning, but tasks are the team's internal plan, not backlog items the product owner orders. On the Compass app, "Get the item" is an epic, "Holds" is a feature and "As a patron, I can see my position in the holds queue" is a story.

User stories

A user story describes a small piece of functionality from the point of view of someone who wants it. The classic template is "As a [type of user], I want [some capability] so that [some benefit]". The template is a prompt, not a rule. Its strength is that it keeps three things in view: who the work is for, what they need, and why. The "so that" clause is the part teams most often skip and most often regret skipping, because it lets developers find a simpler way to deliver the same benefit.

Ron Jeffries described stories with three Cs. The card is a short written statement, small enough to fit on an index card, that serves as a reminder. The conversation is the discussion between the product owner, developers and stakeholders that fills in the details; it matters more than the card. The confirmation is the set of acceptance criteria that will show the story is done. A story is a promise of a conversation, not a full specification.

INVEST

Bill Wake's INVEST acronym lists qualities of a good story. Independent: it can be built and delivered without waiting for other stories, as far as possible. Negotiable: details are worked out in conversation, not fixed in advance. Valuable: it delivers something a user or customer cares about. Estimable: the team understands it well enough to size it. Small: it fits comfortably in a sprint, ideally taking a few days. Testable: there is a clear way to tell it is done. When a story is hard to estimate, that usually means it is too big or too vague, and the team should split it or run a spike first.

A spike is a timeboxed research or experiment item whose output is knowledge rather than product. When the Compass team did not know whether the library's room booking system could be reached from the app at all, they added a two-day spike to find out. The answer (no interface existed, but one could be built by the system's vendor for a fee) changed the release plan for room booking and became a cost item for the project manager.

Acceptance criteria and the definition of done

Acceptance criteria are the conditions a particular story must satisfy to be accepted by the product owner. They are specific to the story. A popular format, borrowed from behavior-driven development, is "Given [a context], when [an action], then [an outcome]". The definition of done, in contrast, applies to every item: code reviewed, tests automated, accessibility checked and so on. A story is complete only when it meets both its own acceptance criteria and the shared definition of done.

Non-functional requirements, such as performance, security and accessibility, can appear in three places: in the definition of done when they apply to everything (all screens meet WCAG 2.1 AA), as acceptance criteria on particular stories (search results appear within two seconds) or as stories in their own right when they need dedicated work (penetration test before release 1). The exam may ask where a requirement belongs; the deciding question is whether it applies universally or to one piece of work.

Splitting stories

Large stories are split into smaller ones that still deliver value. The key word is vertical: each slice should cut through all the layers needed to give a user something working, not deliver one layer (all the screens, then all the database work) at a time. Common splitting patterns include splitting by workflow step, by business rule, by data variation, by interface or channel, by simple case first and complex cases later, and by performance (make it work, then make it fast). A useful test is whether the product owner would see value in releasing the smaller story by itself.

Story mapping and the minimum viable product

Jeff Patton's story mapping arranges the backlog in two dimensions. Across the top runs the user's journey as a sequence of activities, such as find an item, get the item, manage my account. Under each activity, stories are stacked by priority. Horizontal lines then slice the map into releases: the top slice is the smallest set of stories that lets a user complete the whole journey in a basic way. This prevents a common mistake of building one activity perfectly while users cannot complete the journey at all.

That top slice is closely related to the minimum viable product (MVP): the smallest version of the product that delivers value to users and lets the team learn from real use. A related idea is the minimum marketable feature (MMF), the smallest piece of functionality that is valuable enough to release. The Compass team's map put search, holds and account management in release 1 and room booking and event sign-up in release 2.

# Story map: points per activity, split into release slices.
story_map = {
    "Find an item":   {"R1": [21, 13, 34, 8], "R2": [8, 5]},
    "Get the item":   {"R1": [34, 21, 13],    "R2": [5, 3]},
    "Manage account": {"R1": [21, 13, 8, 4],  "R2": [5]},
    "Book a room":    {"R1": [],              "R2": [13, 8, 5]},
    "Join an event":  {"R1": [],              "R2": [8, 8, 4]},
}
for release in ("R1", "R2"):
    total = sum(sum(acts[release]) for acts in story_map.values())
    print(f"{release}: {total} points across "
          f"{sum(1 for a in story_map.values() if a[release])} activities")

R1: 190 points across 3 activities
R2: 72 points across 5 activities

Release 1 holds 190 points across the three core activities; release 2 holds 72, including two activities that are not in release 1 at all. Together they make up the 262 points of total scope at the end of sprint 6 that PMP-130 tracked on the burn-up chart. The story map makes the trade-off visible: if release 1 must shrink, the product owner can move lower stories in a column down to release 2 without breaking the journey.