As I engage different teams I have noted a lack of clarity surrounding product backlog concepts. Although there is no universally accepted vocabulary for labeling product backlog-related things, there should at least be agreement on the basic concepts. The goal of this blog is to clarify product backlog concepts using reasonably common vocabulary where appropriate.
Big Picture
The figure below shows a hierarchical breakdown of important product backlog concepts.
At the highest level we have the product backlog itself, which is a prioritized inventory of work to be done. The product backlog is, not too surprisingly, made up of product backlog items (or PBIs). Each product backlog item is of a particular type, and there can be several different types, such as features or defects. And each of these types can be represented using different formats, such as a user story. I’ll now elaborate on these concepts.
PBI Types
Let’s start with the types of items that might be in a product backlog. I will discuss four types, you could, of course have more.
PBI Type: Feature
The most common type of PBI is something that is of value to a user or customer. I generically refer to these as features. I know that this word is horribly overloaded! So, don’t get caught up on the term (use your own better term if you wish), but there is a type of PBI that represents items of functionality that have tangible value to a user or customer. These can be brand-new functionality or changes to existing functionality. Features, for most teams, should represent the overwhelming majority of items in their backlog!
The litmus test for these types of items is simple. Hand the item to one of your users or customers and ask her what she thinks. If she says, “I love it, when do I get it?” you have a feature. If she has no clue what you are showing her, then you don’t have a feature; instead you have something else that might still be considered a PBI, but a different type of PBI.
PBI Type: Defects
Some teams like to include defects/bugs in their product backlog. If so, these teams have a PBI of type defect. High-performance agile teams never let defects live long so they are unlikely to ever have many defects in their product backlogs. But what if your team is working to become high performing or you are working on a defect-ridden legacy product that you inherited? In these cases you will have defects and many teams include at least the high-priority ones in their product backlogs.
If you are interested in a deeper discussion on handling defects in an agile way, check out my blog post, “Treat Defects Like Milk.”
PBI Type: Technical Work
Should the product backlog include items of technical work? By that I mean things the team needs to do to work more efficiently or to allow the product to function better as a whole. Examples might include upgrading to the latest version of the Oracle DBMS or refactoring a section of previously completed code.
My primary rule for including any item in the product backlog is that the work must be something the product owner can understand and can reasonably prioritize against features. So if you do choose to include PBIs of type technical work, you will need to make the value of the item clear to the product owner.
Of course, if you work on a component team instead of a feature team, then most of your items will look like technical work and your product owner is likely a technical person. For a deeper elaboration of the differences between feature and component teams, see my blog “Distinguishing Between Feature and Component Teams.”
PBI Type: Knowledge Acquisition
Another type you might choose to include in your product backlog are items that involve knowledge acquisition. During agile development, when we are presented with a high degree of uncertainty, a common and effective solution is to buy information. Buying information has a number of more common names: prototype, proof-of-concept, research, experiment, spike, etc.
See Chapter 5 in Essential Scrum for a deeper discussion of knowledge acquisition items and some examples.
PBI Formats
So far I have discussed types of product backlog items. But how should we represent these items?
User stories, you say? Yes, that it is one option. User stories are a representation format for particular types of product backlog items. They are most commonly used to represent features. Counter to what some people say, however, you are not required to use user stories in your product backlog (and user stories are not a required practice in Scrum; instead, they are a well-proven approach). As an alternative to user stories, you might employ use cases or just simple, free-format text to represent your PBIs.
Although not required, I would venture to say that users stories or something like them are the most common representation format used for many PBIs. User stories are a convenient format for expressing the desired business value. They should be crafted in a way that makes them understandable for both business people and technical people. User stories are typically expressed using the following simple structure:
As aI want to achieve so that I get
Not every PBI needs to follow this format. Features lend themselves well to user stories. Defects, technical work, and knowledge acquisition can also be written this way, but certainly don’t need to be. Use the format that fits best your particular preferences or circumstances.
PBI Size & Scope
So far I’ve used the term feature quite generically to mean anything of value to the customer. Some people, however, reserve use of the term “feature” to specially describe a specific size of customer-valuable feature. Let me explain.
Not all items in the product backlog will be of the same size and level of detail at the same time. If you go back up and look at the image at the beginning of this post, you will notice that the items in the product backlog (represented as blue bricks) are not all the same. Some of the bricks are bigger and some are smaller. Some are lighter blue and others are darker blue. I meant for bigger bricks to represent larger pieces of functionality and smaller bricks to represent smaller pieces of functionality. Lighter blue means that the PBI is lightly detailed and darker blue means more detailed.
Let’s look at this same concept a different way.
Large Items
At the top of this image are the lightest blue, largest bricks. They represent PBIs that are too large for a sprint and often too large to be contained in a release (order of magnitude—months to develop and test). PBIs at this level are often called epics (although this is not universally true), playing off of the idea that a really big story (in literature) is often referred to as an epic story (e.g., War and Peace, Lord of the Rings).
There is an important implication in using the term epic to describe really big things—specifically, that all of the different sizes and colors of blue bricks in the picture can be represented as user stories. Remember, a user story is a representation format, and many people choose to use user stories to represent the full range of items (from big to small) in their product backlogs. So to be clear on what I am saying, epics often are written as user stories.
Medium Items
At the next level down are PBIs that are bigger than a single sprint but smaller than a release (order of magnitude—weeks). Some people call items of this size features. It is common to hear people say, “Oh, the medium-sized user stories are the features.” Again, there is no universally agreed upon name of items of “medium” size.
I often use the term feature to refer to items of this size because it resonates with people, even though doing so violates my own rule of avoiding synonyms in my term glossary. To be clear, I will refer to PBIs that deliver customer-facing, valuable functionality as type feature. If I had a better word for PBIs of this type, I would use it. I also refer to the items in the product backlog that are medium sized as features.
By the way, this usage corresponds to many of the agile scaling approaches that define multiple levels of product backlogs. The highest-level backlog (often referred to as the Portfolio Backlog) frequently contain epics. The medium-level backlog (often referred to as the Program Backlog) will contain features. And the lower-level backlogs (team backlogs) will contain user stories (more on the use of this term below).
As a note, another common term used for the medium-sized items is themes. I tend, to think of themes less as a description of size and more as an orthogonal dimension—a theme is a collection of related items, a group of PBIs that together will create a singular functionality. Themes to me are a way to affinity group items. There are obvious similarities between a theme and feature (since a feature can also be viewed as a collection of related items—in particular a collection of the smaller user stories that will be used to represent the different aspects of the feature).
Small Items
At the third level, we find PBIs that are sized appropriately for a sprint—they can be completed in days rather than weeks. These items meet the team’s Definition of Ready.
These PBIs are ready to be broken down into tasks (the green cubes in the above image) and delivered by the end of a single iteration. To add even a bit more confusion to the mix, many (most) people refer to these sprint-sized items as user stories. Remember, we have already established that user stories are a representation format that we can use with items of any size. So to avoid confusion at this level, I will often refer to the small dark blue bricks as sprintable user stories, or ready user stories, or implementable user stories.
Summary
In this blog my goal was to clarify product backlog concepts. There is an artifact in agile referred to as the product backlog. That product backlog is comprised of product backlog items. Each product backlog item is of a particular type and can be represented in one or more formats. I hope we can agree on that much!
I went on to describe some of the terminology that you are likely to encounter when discussing product backlog concepts with others. Since there is no universal agreement on terminology, I am more interested that members of the same team or organization choose their terms and use them consistently.