This article is intended to be a quick reference guide to align your teams to a common vocabulary around User Stories and User Story Hierarchy and, if necessary, to provide a cross-walk or translation between environments following patterns from the Scrum Guide versus those using SAFe. While the SAFe definitions are formally defined on the SAFe website and recommended for SAFe deployments, the generic Scrum definitions shared here are based on years of working with teams to align on the most intuitive and usable definitions. We recommend that coaches, in particular, should be familiar with both nomenclatures and definition schemes.
We’ll start with the basic terms and move on to the more complicated concepts. Along the way, we'll provide some examples to help you in your work.
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 Joel's 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.
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, and 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, we recommend reading some of our content such as, Writing Good User Stories by CST Carlton Nettleton and User Stories: Making the Vertical Slice by CST Kim Poremski.
Pro Tip: Generative AI can help! Here are some examples of users stories for a company creating an app to help patients maintain their drug regimen from the Horizon Assistant designed specifically for product and business leaders.
What About Product Backlog Items?
Isn’t Product Backlog Item just another word for User Story? Not exactly…
A Product Backlog Item (often abbreviated as PBI) is an individual item on the Product Backlog. According to the Scrum Guide, a Product Backlog is “an emergent, ordered list of what is needed to improve 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.
SAFe handles the distinction between User Stories and other PBIs by identifying some backlog items as Enablers. Stories in SAFe may be User Stories or Enabler Stories, and the label Enabler can also be applied at any level in the SAFe backlog hierarchy.
User Story/Backlog Item Hierarchy
For Teams following the Scrum Guide:
The following table outlines the User Story or Backlog Hierarchy for the common work item types used by Agile teams following the Scrum Guide. First, 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 |
For Organizations using SAFe:
SAFe follows a slightly different scheme, first defined in Dean Leffingwell's 2011 book Agile Software Requirements. Here are some additional definitions used in SAFe:
- ART: Agile Release Train, a team of agile teams.
- PI: Planning Increment, typically 8 to 12 weeks in duration.
- Solution Train: A team of ARTs collaborating to deliver a large or complex solution.
- Value Stream: Who is the person most focused on this item type? Who is defining the acceptance criteria, the value, or vision?
- Team Iteration: This is a synonym for Sprint, adopted by SAFe to accommodate agile teams not using Scrum.
| Item Type | Time Box | Delivered by | Example | Focus Level | Value or Output |
| Epic | Longer than one PI | Solution Train or ART | Build a 3 wheel Tesla | Epic Owner | Value |
| Capability | Not more than one PI | Solution Train | Create the dashboard | Solution Management | Value |
| Feature | Not more than one PI | ART | Center console display | Product Management | Value |
| Story | Not more than one Iteration | Team | Volume control | Product Owner & Agile Team | Value |
| Tasks | ~4 hours
(1 day) |
– Write the test
– Code the User Interface – Connect to the APIs |
Developers | Output |
Typical in Scrum |
Defined in SAFe |
|
Initiative This is the highest level of work item. It represents the largest levels of investment in a company or organization. Initiatives can be focused around a value stream or individual product and typically cross departments and organizations. Other terms that have been used at this level are Projects, Products, Themes, and Solutions. An Initiative is made up of one or more Epics. |
Epic This highest level of long-lived work item in SAFe typically represents a significant investment and is supported by a brief Lean Business Case. Epics can by focused on ARTs, Solution Trains, Value Streams or may be cross-cutting initiatives at the Portfolio-of-Value-Stream level. Epics may deliver Business Value directly, or may be Enablers that deliver infrastructure. Epics are guided by an Epic Owner, and implemented by Features and/or Capabilities. Here is an example from Horizon:Assistant to an example Epic describing how the drug app can be connected to a patient's Electronic Health Record.. |
|
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. |
Capability Capabilities are delivered by a Solution Train (a team of ARTs) and are sized such that they can be delivered in a single PI. Capabilities are delivered through the integration of Features, delivered by individual ARTs. Organizations using SAFe ARTs, but not utilizing a Solution Train, will typically not need to define and use employ Capabilities. |
|
Features A Feature is commonly defined as a “shippable component.” It is the least commonly used of the Item Types above and some Agile management tools don’t even support it by default. Many Agile Coaches feel that Features lead to scope creep on Epics, while others find it a useful breakdown to allow Epics to be more focused at the portfolio and business cases. In many organizations, Features are the smallest increment of work delivered to the end customer. A collection of User Stories aligned to a common function are completed, integrated, and then released as a Feature. Features are made up of two or more User Stories. |
Features Features and Enabler Features constitute the ART-level backlog in SAFe. A Feature in SAFe is delivered by a single ART in a single PI. A Feature has a Name, Description, Benefits Hypothesis and Acceptance Criteria. Features are made up of User Stories and/or Enabler 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 or Iteration Planning. A team in SAFe using SAFe Kanban would pull a Story from the “To Do” column of their board.
Some teams break down User Stories into tasks, and this is often recommended for teams that are early in their lean-agile journey. More experienced teams that have built their competency in collaboration often pull User Stories into their sprint or iteration backlogs without decomposing them 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/Enabler Story into “bite size” chunks. The idea here is that as an Agile Team meets for its daily sync, they are able to easily see progress of multi-day Stories through the progression of tasks. If a Story is taking 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 one of the structured frameworks such as Scaled Agile, or make up your own terms, the most important thing is to make sure the language is consistently understood by everyone in your Agile teams.
We would suggest sticking with the common conventions, as this makes communication with other organizations and new people coming into yours easier. No need to learn a whole new language.
Continue your education
No matter where you are in your Agile Journey, Applied Frameworks has a course or workshop right for you. Learn more about our public Foundational Scrum, SAFe, Advanced Scrum offerings or Contact Us to learn more about private team training.