Enabling Self-Selection with the Power of Narrative: User Stories and the Product Backlog

This is the third of a series of introductory posts about Scrum. The previous post discussed the different roles on the Scrum team.

Welcome back! This is a pretty technical post, so let’s get started. We’ve already spoken about the nature of the Scrum team: it’s self-organizing and iterative. We’ve also discussed three different roles that a team member can take: Product Owner (PO), Development Team Members (DTMs), and Scrum Master (SM). We’ve also mentioned that while the PO is the one with the overall vision for the product, the Development DTMs must self-select to translate the PO’s ideas into a usable, tangible product. How does this process happen? As in much of life, progress happens with a compromise. Let’s begin with the basics.

Scrum organizes product features by framing each of them in the form of a User Story, which is just a statement of the following form:

AS A(N)…                I NEED…                 SO THAT…

This might seem a little tedious, but in practice, formulating features in this way is useful for clarifying what the team should work on, why they should work on it, and for whom the work is intended. This structure serves to keep the team focused on the end result: a goal that assuages a pain for an audience – put differently, the outcome must satisfy some consumer demand. Perhaps you’ve been on a team without a clear goal and strategy. Teams like this default to what XCOR Aerospace’s Jeff Greason refers to as “Institutional Rule Zero: Preserve the Institution.” If you’ve been on a team that exists only to preserve itself, you know how static (read: frustrating) that can be.


The Heracles Papyrus

These User Stories (USs) are guided by a team’s Epic User Story, an intentionally overarching and broad statement that defines, in one stroke, a team’s audience, strategy, and goal. As an example, let’s take this series of blog posts:

AS A person who might be interested in expanding their list of professional tools,

I NEED a series of introductory blog posts about Scrum,

SO THAT I have enough information to decide whether or not I want to learn more about Scrum.

The nice thing about this Epic User Story (EUS) is that it defines who the posts are for (not seasoned Scrum experts, not people whose sole raison d’être is underwater basket weaving). It also presents a clear and concise description of the product to be produced. Critically, it also describes the goal that that product should accomplish. If, by the end of this series of blog posts, a reader has no idea what Scrum is and whether or not they should learn more about it, then this series of posts is a failure.

Each EUS begets a number of USs. The US for this post, for example, might be:

AS A person who is trying to assess their interest in Scrum,

I NEED a rough explanation of how User Stories and the Product Backlog work,

SO THAT I can have a basic understanding of the operations of the Scrum process.

Again, if you don’t have a more-or-less basic understanding of how User Stories and the Product Backlog work together in the Scrum framework, then I haven’t done my job – and therefore, I had better explain how a Product Backlog works:

So if the Product Owner (PO) has the big vision for the team, and each Development Team Member (DTM) self-selects for USs – then how are we to be sure that DTMs do what the POs need them to do in order to preserve the continued viability of the team? The way that this happens is as follows: the PO and the Scrum Master (SM) work together to sort each US in order of priority. This results in a list called the Product Backlog (PB). Then, at the beginning of each iteration, the DTMs volunteer to accomplish those USs in order of their priority.

A Backlog is a Stack of User Stories. Push Pops were candies popular in the 1990s.

In other words: the PO and the SM prioritize USs into a PB, then the DTMs self-select for them in order of priority.


Next time, we’ll talk about how these meetings – called Sprint Planning meetings – take place, and how regular meetings called Scrums help the team to stay on top of changing circumstances before serious problems arise.

These articles are for you! Please don’t hesitate to ask questions or give comments. Let me know what you’d like to see, and what’s unclear – and, in true Scrum fashion, I’ll try to tune the future posts so they’re more interesting, informative, and entertaining for you.