This article has been revised in February 2024 to include the SAFe Backlog Hierarchy. See the updated Article Here.
This article is written by a human and is enriched with prompts from the Horizon Assistant to help you put this material into action. Horizon is a generative AI-powered tool for product land business leaders.
Lean-Agile methodologies are a treasure trove of specialized terminology that can sometimes be confusing. While some terms have clear definitions, others can vary depending on the framework or tools being used. User Stories fall into the latter category, where the concept may seem simple, but there are nuances to consider in practice.
This article aims to serve as a quick reference guide to help your team establish a shared vocabulary around User Stories and their hierarchy. These definitions have been refined over years of working with teams to ensure they are intuitive and practical.
Let's delve into the basics first and then explore more complex concepts together.
“A user story is a promise for a conversation.” – Alastair Cockburn, 1998
The purpose of a user story is to describe features or functionality that will deliver value (see my related article on Defining Value). User Stories are written from the perspective of an end user or customer. The term was first coined by Kent Beck as part of Extreme Programming and has since been adopted almost universally across Lean-Agile. Looking for information on SAFe? Check out the updated 2024 Version of this article.
Good User Stories adhere to the 3Cs of a User Story format created by Ron Jefferies in 2001.
For more foundational reading on this subject, I recommend reading Writing Good User Stories and User Stories: Making the Vertical Slice.
Is a Product Backlog Item simply a synonym for a User Story? Well, not exactly...
A Product Backlog Item, often referred to as PBI, represents an individual item on the Product Backlog. In accordance with the Scrum Guide, the Product Backlog is described as an "emergent, ordered list of what is needed to enhance the product."
A Product Backlog Item can be any of the following:
Not everything needs to be written in a User Story format. If you need a new server, you don’t need to write, “As a developer, I need a new server so that…” As long as there is a clear description, it can be sized and ordered with the other PBIs; then, the format is optional. A user story is just a great format for describing desired customer-facing value. Looking for information on SAFe? Check out the updated 2024 Version of this article.
Here's a comprehensive breakdown of the User Story Hierarchy, detailing the various work item types frequently utilized by Agile teams. Before we dive into that, let's establish some definitions:
| Item Type | Time Box | Example | Focus Level | Value or Output |
| Initiative | ~ 1 year | Build a 3 wheel Tesla | Sponsor / Business Owner | Value |
| Epic | ~3-6 months | Create the dashboard | Product Manager | Value |
| Feature | ~2-3 Sprints | Center console display | Product Owner | Value |
| Story | 1 Sprint | Volume control | Agile Team | Value |
| Tasks | ~4 hours
(1 day) |
– Write the test
– Code the User Interface – Connect to the APIs |
Developers | Output |
The Epic is the most common “large” chunk of work in Agile. The Agile Alliance defines an Epic as “a large user story that cannot be delivered as defined within a single iteration or is large enough that it can be split into smaller User Stories.” Scaled Agile defines an Epic as “a container for a significant Solution development initiative that captures the more substantial investments that occur within a portfolio”.
All the Agile lifecycle management tools we know of (e.g., Jira, Azure DevOps, VersionOne, Rally, etc.) have Epics. In most of them Epics are the largest work item commonly used.
Epics are made up of one or more Features.
Looking for information on SAFe? Check out the updated 2024 Version of this article.
A Feature can be described as a "deliverable component," although it is not commonly used among the different work item types mentioned earlier. Some Agile management tools may not even have default support for Features. While some Agile Coaches believe that Features can lead to scope creep on Epics, others find them helpful in allowing Epics to have a more focused approach in portfolio and business cases.
In many organizations, Features represent the smallest unit of work that is delivered to the end customer. A collection of User Stories, aligned with a common function, is completed, integrated, and then released as a Feature.
Features are typically composed of two or more User Stories.
As described above, a User Story is a work item sometimes used interchangeably with Product Backlog Item (though they are arguably quite different).
User Stories are the work a Scrum team takes on during Sprint Planning. A team using Kanban would pull a Story from the “To Do” column of their board.
User Stories are commonly broken down into tasks.
The smallest work type, tasks are also the only work type not designed to deliver value. Instead, tasks are a way to break a User Story or PBI into “bite-size” chunks. The idea here is that as an Agile Team meets for its daily sync, they are able to easily see the progress of multi-day Stories through the progression of tasks. If a Story takes, on average, five days to complete and it has ten tasks, then on average, you should expect two tasks per day to be completed.
Note: Some Agile Tools (notably Jira) use “Sub-Task” to indicate this level of work. It means the same thing, just different because of the tool.
Pro Tip: Don’t size tasks beyond the very basic “Can it fit into one day?”
Bonus Pro Tip: If your Agile team has broken its work down to the point that a story is taking one or two days, then don’t task. You don’t need it
Whether you use our recommendations, follow a structured framework such as Scaled Agile, or create your own terms, the most important thing is to ensure that everyone in your Agile teams consistently understands the language.
We suggest sticking with the common conventions, as this makes communication with other organizations and new people coming into yours easier. There is no need to learn a whole new language. Looking for information on SAFe? Check out the updated 2024 Version of this article.