Lean-Agile methodologies are rich with specialized terminology. Some of the terms are intuitive and have fairly clear definitions, while others depend on the framework you are using, what tool you are using, or even who taught you the terms. User Stories fit into the latter category — the concept sounds simple enough, while in practice has plenty of nuance. 

This article is intended to be a quick reference guide to align your team to a common vocabulary around User Stories and User Story Hierarchy. These definitions are based on years of working with teams to align on the most intuitive and usable definitions.  

We’ll start with the basic terms and move on to the more complicated concepts.

 

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.

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?

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.

 

User Story Hierarchy

The following table outlines the User Story Hierarchy for the common work item types used by Agile teams. 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

 

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

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.

 

Feature

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.

 

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 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.