Agile Q&A: Are there types of User Stories?

Editors Note:

There has been somewhat of an epiphany about the content of this post in May of 2013. Please read: “An Update: Types of User Story” for the author’s latest take on this topic.

Product Backlogs are, at their core, lists of all of the potential things a product could do.

The Question:
Are there types of User Stories, or different types of information that go in a Product Backlog?

The Answer:
Yes, we like to distinguish between 3 types of items within a Product Backlog.

  1. User Stories
  2. Non-User Stories
  3. Spikes

While traditional Scrum does not specify that Product Backlogs be made up of User Stories we believe that when team’s use User Stories they are better able to increase the quality of the product delivered. [Quality in this case defined as the degree to which the end-users find the product to be useful and meet their needs. Hopefully decreasing the % of features that are rarely or never used by end users*.]

It is important to note that a true dedicated cross-functional Agile team should only be working items from their Product Backlog, so we likely need to slightly broaden the definition of what a backlog is.

Original Definition:
A Product Backlog is a prioritized list of all potential product features.

Expanded Definition:
A Product Backlog is a prioritized list that includes…
— All potential features of the product
— All foundational elements that must be in place for the features to be implemented, and
— All key research activities and investigations that must occur to make accurate decisions on the way to approach feature development

If we take that expanded definition of a Product Backlog, we could summarize it to be:

Expanded Definition Condensed:
A prioritized list of the primary work items that must be completed & delivered by the team.

Three Types of Items
Essentially, what I am getting at is that there are 3 key types of items within an Agile team’s backlog.

  1. User Stories – Brief simple statements of a desired product function from an end user’s perspective. As a <End User Role>, I want to <desired action>, so that <desired benefit>. As a Personal Checking Account Holder, I want to register for an online banking account, so that I can access my account details online. As a Registered Online Banking Customer, I want to view a list of all my accounts, so that I can quickly see my current balances.
  2. Non-User Stories – Brief simple statements of foundational or infrastructure needed in order to deliver User Stories in the Product Backlog. As a <Team Role>, I want to <desired action>, so that <desired benefit>. As a Developer, I want to configure our assigned development region, so that we can begin developing User Stories in our backlog. As a Tester, I want to prepare a test lab, so that we have representation of all device types & operating systems we need to execute tests on.
  3. Spikes – Brief simple statements of research that is needed in order to move forward with other items in the Product Backlog. As a <Team Role>, I want to <desired action>, so that <desired benefit>. As a Developer, I want to research the latest security protocols, so that we feel confident we selected the best method for securing our customer’s financial data. As a Business Analyst, I want to research the state specific business rules for handling white goods taxes, so that our customer’s are charged appropriately for the items they purchase.

Of course, we want team’s to self organize and make decisions about managing their Product Backlog that are best for them. So it is not necessary to use these types or limit yourself to these types. Please discuss as a team and make a decision that is the most valuable for you specific situation.

Clarifying the Outputs
Before I close this out, let me be clear about the output of each of these item types:

  • User Stories → Demonstrable working software that is valuable to the product’s end-users and can be accepted by the team’s Product Owner.
  • Non-User Stories → Demonstrable working software that could not be completed within the confines of a User Story and can be verified by the team as complete.
  • Spikes → Information or a Decision that is required to move forward with other items within the Product Backlog and can be summarized and verified by the team.

*Standish’s Chaos report currently cites that 65% of features are rarely or never used by end users.