Chapter 21. Why There Are No User Stories at the Top of Your Product Backlog

James O. Coplien

Words mean things. The words “user story” suggest something that is a story and in the user space. The term has come to mean a formatted sentence of the form: As an X, I want Y because of Z. Some Agile folks take that literally and dutifully write stuff in that format. But, more insightfully, Ron Jeffries once correctly pointed out that this shorthand is just an invitation for a future conversation between an end user and a developer. We can breathe a sigh of relief at having restored the possibility of storytelling.

Stories are priceless in understanding end user needs. The Sprint Goal should probably be a potential title or moral of the key user story. But user stories are, so to speak, just the beginning of the story. Perhaps they should be called “User Riddles.” The job of design is to solve the riddle and to deliver an implementation commensurate with the answer.

Scrum follows the Lean practice of eliminating muri (i.e., overburden) and instead smoothing out flow. Though a user may come to us with a need, we don’t just transform that need into a solution overnight or at some meeting called Sprint Planning. Business solution design takes time, dialogue, exploration, and feedback. A solution eventually emerges and works its way to the top of the Product Backlog as an Enabling Specification.

The Product Owner owns specifications: that is, it is the Product Owner’s responsibility that they be there. They are not specifications of the problem, but of solutions. The Product Owner doesn’t maintain a requirements backlog, but rather a Product Backlog. The products serve the Product Owner’s vision of the product Increments that will generate value—not just of the problem that provides a market opportunity. A single solution might support several user stories, but the opposite isn’t true. A good Product Backlog documents the agreements between stakeholders about what will be delivered, particularly in the near term. The Product Owner may socialize user stories with stakeholders to create Product Backlog Items (PBIs) and may tag them with user stories, but a proper Product Backlog Item is not a story. It’s something the team builds.

If a product has a long backlog (six or seven Sprints), then some bottom items may be user stories. It’s too early to nail down a specific implementation yet. As they come to the top, they become Enabling Specifications. Good Scrum practice recommends reducing muri by striving to make the top three Sprints of the backlog into Enabling Specifications. And a great, agile Scrum Team usually does not have a long backlog, but instead looks three or four Sprints ahead. Anything else is guessing. If a product can look six months ahead with certainty, waterfall probably suits them better than Scrum.

So, if your backlog is seven Sprints long, or if it is a list of user stories, you have some kaizen to do—to look beyond a casual understanding of Scrum to something that really rocks.