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.
What is a User Story?
“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.
- Card: A request for value and a promise to have a conversation at the appropriate time.
- Conversation: An exchange of thoughts, opinions, and feelings. Have a conversation on what is wanted, document the conversation.
- Confirmation: The acceptance criteria. How the members of an Agile team know they have delivered value.
For more foundational reading on this subject, I recommend reading Writing Good User Stories and User Stories: Making the Vertical Slice.
What about Product Backlog Items?
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:
- Features
- Fixes
- Bugs
- User Stories
- Technical Debt
- A good idea
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.
User Story Hierarchy
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: Common names for work items, sorted from big to small time box.
- Time Box: Rough estimate for how long this item takes to complete.
- Example: For this exercise, we are using various elements required to make a hypothetical three-wheeled Tesla.
- Focus Level: Who is the person most focused on this item type? Who is defining the acceptance criteria, the value, or vision?
- Value or Output: When this item type is complete, does it generate value or is it work in turn that needs to be completed to deliver a larger item of value?
| 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 |
Initiative
At the pinnacle of a company or organization's work items lies the Initiative. It symbolizes the grandest levels of investment, often revolving around a value stream or a specific product, and transcending departmental and organizational boundaries. This level has been referred to by various terms such as Projects, Products, Themes, and Solutions. An Initiative comprises one or more Epics, driving ambitious goals and aspirations. For more information about SAFe, don't forget to check out the updated
2024 Version of this article.
Epic
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.
Feature
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.
User Story
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.
Task
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
Common Vocabulary Enhances Agility
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.
