Product Backlog Items (PBI’s) – Not just User Stories

In Scrum, the User Story represents the main item in the Product Backlog. However, it is not the only item in the backlog. So let’s take a look at other items in the Product Backlog.

According to the Scrum Guide, “The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.”

For the purpose of simplicity, we group the backlog into four types of items:

1. User Stories
2. Technical Stories
3. Spikes
4. Defects

Let’s take a look at each type of item.

User Story
Written in the format: As a Type of User, I Want to do something, So that why do I want it. User stories are not complete without Acceptance Criteria and a discussion with the team to gain the full requirements of the story. User stories cover features, functions, enhancements, and epics. Typical guidance is that a user story can be completed in 2 days or less, while some experts say the work of the team on a story may last up to a week. Whether you call large User Stories epics, themes, or features may depend on what tool you are using, or how you were trained. User Stories originate from XP where any large story needing to be broken down was called an Epic. As these large stories were broken down, we could actually tear up the Epic as it was being replace with multiple smaller stories. Product Owners may not have the skills to break stories down as small as they need to be for a Sprint. This is where the team comes in during grooming/refinement to help break down stories and discover gaps. Our tools (Version One, Rally, Jira, etc) allow us to maintain a parent child relationship using the labels like Epic, Theme, or Feature.

For tips on writing user stories check out this link.

User Stories can be written by anyone. They are often written during user story workshops where the team and stakeholders are together brainstorming user actions and system needs. The goal of the Product Owner is to thoroughly understand stakeholders needs in order to create and explain the User Stories in the backlog. For me, the PO or their surrogate are the main writers of user stories for end user applications. PO’s are the ones that will typically be engaging stakeholders. So while they may get some help in writing the stories, they are still the ones accountable for ensuring complete understanding, and to accept the story as the work is completed.

Technical Stories
Technical Stories represent any technical work the team must undertake during a sprint. While it is possible to use the typical user story format by identifying ‘the who’ as something that isn’t really a person, like “System X”. However, I ask teams I’m working with: is there any value in writing Technical stories in this format? For me, where there is no benefit, there is no reason to write technical stories in the user story format. A simple statement will work, e.g. “upgrade test tool”. While the format of a user story isn’t needed, it is still important to include acceptance criteria. Team members typically write these stories, and let the PO know where in the backlog they should sit in order to be completed in a timely manner, often as a predecessor to doing other user stories.

For more on writing Technical Stories look here check out what Mike Cohn says about using the FDD format here.

Spikes
Spikes are done for knowledge acquisition. Spikes should be time-boxed, and have specific acceptance criteria. A team member may ask for a spike in order to do some research, proof-of-concept, or prototyping to gain knowledge prior to working on a set of user stories. There is no reason to write spike in user story format. The maximum duration for a Spike is the length of a sprint. Another attribute of Spikes, is that they should be the exception and not the rule.

For more on Spikes see this article.

Defects
As users work with the system, and testers test the system, bugs or other defects may be found. For me, these are not the same as rejecting a current user story because it fails testing. User Stories that fail testing are rejected and reworked within the sprint if time allows. If time doesn’t allow, the PO can decide if the story will be in the next sprint or not, and the team will not get points for the story until it passes test.

As other defects or bugs are found in the system new user stories are written to identify the desired functionality. The PO will stack rank these PBI’s along with all other stories.