Have you ever been confused about whether a product backlog item is an epic, feature, or user story?
Ever questioned whether you needed themes?
As long as your team understands what the product backlog item means when you start to work on it, you really shouldn’t care if it’s called an epic, feature or user story.
Yes, I realize that answer is not particularly satisfying, especially to anyone who has lost an entire day of their life to a semantic argument about levels of a product backlog hierarchy.
I’d like to help you avoid those discussions in the future and help you help your customers get the outcomes they seek. With that in mind, here are some definitions for these key product backlog terms followed by a more in depth explanation of why I chose the definitions I did.
Some of my definitions may be controversial, in part because there are different ways to define the same word depending on your framework of choice.
The inventors of the various agile frameworks love to come up with new names in an attempt to emphasize the difference between their ideas and concepts that currently exist. Unfortunately, those founders have also decided to use some terms in their frameworks differently than how they are used in other frameworks. Where those situations exist, I’ll explain how I use a particular term and why.
In case the length of this post is intimidating (I’ve been influenced by Wait But Why), here are the key points.
A feature is something your product has or is… this is typically functionality offered by a software program that enables users to do something.
Benefits are the outcomes or results that users will (hopefully) experience by using your product or service.
User stories identify what someone wants to accomplish with your product and why.
- User stories are placeholders for a conversation.
- User stories are a planning tool.
- It’s not the writing that’s important.
An epic is a large user story.
- Epics are for stakeholders, users, and customers. User stories are for the team.
Don’t use themes for prioritization. Use decision filters.
Keep your product backlog hierarchy to two levels.
I need to start by clarifying the use of this particular word, because some of the other definitions depend on it.
In Beyond Requirements, I used the Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3 definition of feature: “A distinguishing characteristic of a solution that implements a cohesive set of requirements and which delivers value for a set of stakeholders.”
That definition is written from the context of business analysis so it is inevitably going to relate to requirements.
Since I wrote Beyond Requirements, I’ve refined my view of features and now think of feature in these terms:
A feature is something your product has or is… this is typically functionality offered by a software program that enables users to do something.
That definition is taken from the article Features vs. Benefits: What’s the Difference & Why It Matters and has much more of a marketing slant to it. I like this definition better because it provides a nicer tie in with outcome based thinking. In fact that’s what benefits point to as that post describes:
Benefits are the outcomes or results that users will (hopefully) experience by using your product or service
This use of feature is consistent with the dictionary.com definition of feature:
A distinctive attribute or aspect of something, or
A prominent or conspicuous part or characteristic
That means that features are helpful for distinguishing the different versions of a product (for example what options each version of a product does and does not have.) See this feature listing for Evernote as an example.
Use feature to describe something your product does or has, don’t use it as a certain type of product backlog item. Use one of the of the other terms for that purpose – I suggest epic. It will just save you some confusion.
In Beyond Requirements, I defined user story as “a description of a product feature used for planning and scoping purposes. User stories will be decomposed to a level that can be delivered in a single iteration and provide value.” (If you’re a Scrum purist, replace “iteration” with “sprint”.)
Looking back on that definition now, I realize it’s not quite right. It looks at user stories through the all too common output based perspective.
You should view user stories from an outcome based perspective. To do that, consider a couple of thoughts that Jeff Patton shared in his book User Story Mapping:
Stories get their name from how they should be used, not what should be written. – Jeff Patton
If we get together and talk about the problem we’re solving with software, who’ll use it, and why, then together we can arrive at a solution, and build shared understanding along the way. – Kent Beck
You still use user stories for planning and scoping purposes. You still want user stories to provide value. You still want user stories small enough that they can fit in a sprint (if that’s your approach).
But they don’t describe a product feature. They describe a need that can be satisfied by introducing a new feature or changing an existing feature.
In other words:
User stories identify what someone wants to accomplish with your product and why.
As a product person you want to understand your customers needs. You want your product to satisfy those needs. You want to build a shared understanding of those things with your team.
You want to build that shared understanding quickly so you can get stuff done.
User stories are a tool to help you build that shared understanding, but they are not sufficient for fully describing your solution.
User stories are placeholders for a conversation.
User stories are intentionally brief and non descriptive.
They reinforce the idea that shared understanding of what you’re trying to build grows through the process of trying to build it. You can’t know everything up front.
User stories are reminders to have conversations about what you’re trying to help your product’s users and organization’s customers accomplish.
You’ll most likely need to remember what you talked about during those conversations. You can record that information when you describe your user stories.
User stories are a planning tool
User stories allow you to break up the work to build a product based on things your users can accomplish with the product.
That’s different than other ways of organizing work that were based on listing out the tasks you need to perform.
For example, if you wanted to create a membership site, some user stories might be:
- Share my biography and social media contacts with other members
- Display my photo on posts I write
- Connect with other members
These are things that someone might accomplish with your membership site. All of those activities require a profile on the membership site, so another user story might be Create and maintain a member profile.
Contrast those product backlog items with a task based approach which might look like:
- Identify profile fields
- Design profile screen
- Design profile table
- Build profile screen
- Build profile table in database
- Create new profile record in profile table
- Update profile record in profile table
- Delete profile record from profile table
- Display profile information to members
- Load photo to profile
- Add photo to blog post template
- Build member contact screen
The work you end up doing in both situations is the same, but organizing the work by user stories groups the work together in a way that results in a change that allows your user to accomplish something and puts them in a better position to provide feedback.
You could start with Create and maintain member profile and once you’ve delivered that you can get meaningful feedback on whether you’re collecting the right information for a profile. You could even release that to your users and allow people to start signing up.
When you organize your work by tasks, you effectively assume that you know everything you need to do upfront (you don’t). You can easily lose sight of ways to get intermediate feedback on how your solution is coming together.
You still eventually do the tasks I listed in the second example, but you identify them right before you start working on the particular user story, and you only do the tasks you need to do to allow the user to accomplish that particular thing.
User stories help you decide which problems you are going to use your product to solve and in what order you are going to solve those problems.
User stories also help you get to details in a just in time fashion so you can be as informed as possible when you dive into the deep details of a particular bit of work. You don’t have to pull together a bunch of information too early – only to find out the assumptions you made were wrong, or you don’t need to solve a particular aspect of the problem.
When you use cards to represent your user stories – whether they are actual cards, or virtual ones – you have something you can move around while you’re talking about what you will and won’t do. That visual cue can help your team build a shared understanding and keep focused on the part of the product you’re going to create or change in the next week or two.
It’s not the writing that’s important
The intent for user stories was to remind you to communicate further, not to be the only means of communication. As a result how you write user stories is not as important as you may think.
That’s not to say that the information you know about a story is not important, it is. It does mean you don’t have to be overly pedantic about writing stories in a specific way.
You want to make sure your team is clear about who wants to accomplish something, what they want to accomplish and why. That does not immediately mean that you have to write everything in terms of “As A, I Want, So That”
And just because I said you don’t have to the format, doesn’t mean that you shouldn’t use the format at all. As a, I want, So That is a great reminder to identify the who, what, and why. If you need that reminder.
Have trouble pinning down the why? Perhaps you should use the format In Order to (Why) As A (Who) I want (What).
Do you find that the nature of who uses your product is based more on what they are trying to accomplish rather than who they are, perhaps a context specific format (aka Job Stories) is more helpful: When (Situation), I want to (Motivation), so I can (Expected Outcome).
When I put together the backlog for the Submission System, I usually provide a short title for the user story then provide a longer description where I may sometimes use one of the above formats, if I find it helpful.
For example a current item on the Submission System backlog is:
Title: Indicate sessions where submitter has responded
Short Description: As a reviewer I want to know on which sessions a submitter has responded to my feedback since I last viewed the session so that I know which sessions to go back and view for changes.
You may or may not understand all of that, and that’s ok, as long as the team that works on the Submission System understands it. (I think they do…)
As long as your user story has enough information to remind your team what the intent is, and you have somewhere to note any additional information that comes about as a result of the discussions about the story, that’s sufficient, regardless of format.
What that information actually is varies by team, and can often be described in terms of a definition of ready.
In Beyond Requirements I defined epic as “a large user story, effectively a description of a product feature that cannot be delivered as defined within an iteration and is therefore too large to be estimated.”
Yes, I doubled down on my mistake from the user story definition. I probably should have simplified matters as I did when I wrote the definition of epic for Agile Alliance:
“An epic is 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.”
An epic is a large user story.
Epics are for stakeholders, user stories are for the team
As I mentioned above, we want user stories to reflect what a user wants to accomplish with the product.
And when we identify the things customers want to do, those things are often (but not always) general enough that you will want to split them into smaller chunks so that you can can shorten your feedback cycle.
Once you’ve identified your desired outcome, you can start populating your backlog with the main things users want to (or need to) accomplish in order to reach that outcome. Those items may require fairly large chunks of work and it’s why the idea of epics (as big user stories) came into being.
In order to learn whether satisfying specific needs will get you the right outcome you’ll probably have to split those epics into smaller chunks. Those smaller chunks are generally referred to as user stories. You may even find you need to take those user stories and split them into even smaller user stories. That’s ok.
Epics tend to be more meaningful to stakeholders, users, and customers because they represent a complete idea of something that someone wants to accomplish. The user stories that result tend to be influenced by the team’s thoughts on how to gradually flesh out the functionality that will help someone accomplish the thing that the epic represents.
So put another way: Epics are for stakeholders, users, and customers. User stories are for the team.
What does that mean in a practical sense?
Say your team has decided to tackle the Create and maintain a member profile product backlog item. As you start to dig into it you realize that it’s big enough to be an epic. You can split it into several small user stories to exercise a bit of extra control over what you do and do not deliver and in what order.
Create and maintain a member profile may become:
- Create a member profile
- Read a member profile
- Update a member profile
- Delete a member profile
And voila, you have identified the set of CRUD user stories for that epic.
You may not hear users explicitly saying that they want to maintain their member profile, but if you start diving into the specifics of creating and maintaining a member profile, they will identify things they want to accomplish which requires the ability to create and maintain their member profile.
There’s an aspect of context involved in determining whether CRUD type user stories are helpful representation of user stories.
If you are creating a product that does not already exist, anytime you need to manage something – a profile, an order, an order item – you’ll find the people using that product want the ability to create that thing, read that that thing, update that thing and delete that thing.
CRUD, in that case, makes sense.
If your product already exists and you want to add additional capabilities – such as associate your photo with your posting, or get notification of replies – then you may be able to represent the work to accomplish that with a single backlog item. A user story.
When I used the example of Create a member profile, Read a member profile, Update a member profile and Delete a member profile above, the context was building a new product. You were building a membership site and you wanted your users to be able to manage their profile.
Having a hierarchical backlog – consisting of big chunks split into smaller chunks (epics sliced into user stories) – helps you deal with these situations.
You want to avoid having too many levels of hierarchy (I’d argue any more than two) because otherwise you’ll find that you’ll spend more time arguing how to classify items than you do understanding what those items are.
It’s far better to identify big chunks on your backlog that directly tie to things your customer is trying to accomplish and then split that big chunk into smaller chunks as you get ready to start addressing that particular need.
I’ll address the idea of backlog hierarchies a bit more later.
In Beyond Requirements, I defined a theme as “An aggregation of user stories to show business value delivered and to help with prioritization as well as show planned product delivery at a high level.”
I’m having a bit more definition regret. In this case, it’s the phrase “show business value delivered and to help with prioritization as well as show planned product delivery at a high level” that I don’t think is accurate.
So I prefer this definition of a theme:
A grouping of user stories that share(s) one or more common attribute.
I don’t use themes. Here’s why.
Use a filter, not a bucket, for prioritization
Todd Little has established the metaphor that proper strategy is a filter, not a bucket. What he means by that is you should use your strategy to decide what you will and (more importantly) will not do. Your strategy should be a filter instead of using your strategy to categorize things into one of a series of buckets, without excluding anything.
Themes are the backlog equivalent of buckets.
Some teams associate each user story with a theme and then when they are planning a sprint they’ll pick a certain theme as the main thing they’ll accomplish that sprint. They then pull the user stories associated with that theme and slot those into the upcoming sprint.
User stories have been thrown into a bucket and then during a given sprint, the team chooses to work on that bucket.
That approach introduces the risk of doing more things than are necessary, simply because some of the user stories you worked on happened to have the same attributes as other user stories.
Instead, establish your sprint goal as a decision filter: “By the end of this sprint, a member can create their own member profile without any assistance”. The team then identifies the user stories to include in their sprint that are needed to allow the member to create their own profile. As they consider each story, they can ask each other “will this help us allow a member to create their own profile without any help?” If they can answer yes to that question, they include that user story in the sprint. If the answer is no, it stays in the product backlog (or gets thrown away altogether).
Other teams use themes as a label to tie product backlog items (user stories and epics) to organizational goals. This is the theme working as a bucket at a higher level: Want to make sure a user story gets done? Show how it contributes to a specific goal. Better yet, tie it to multiple goals!
You’re better off using organizational goals (which hopefully are consistent with the outcome you seek to deliver) as filters to decide whether to keep a product backlog item around. If you do this, there’s no need for themes. You have the goals themselves.
Caveats and Considerations
Keep your product backlog hierarchy to two levels
There is value to having different levels of granularity in your product backlog. It allows you to easily change priorities on work that you have not started yet, and it allows you to incorporate what you learn in how you structure your product backlog. Your product backlog will be a lot more manageable, and you’ll avoid rework.
You generally want two granularities in your product backlog:
- Big chunks that represent things your stakeholders, users and/or customers want to accomplish. These are our epics. Use these epics to do higher level prioritization and indicate progress to your stakeholders using a technique such as the parking lot diagram.
- Small chunks that represent the smaller aspects of the solution that your team will implement. These are your user stories. Each user story should still add some new capability and provide a means for your team to get some feedback. These user stories provide the team a mechanism to plan out their specific work and a way to organize their detailed description of the product.
That’s all you need. If you add any additional levels in your hierarchy, any benefit you gain (which frankly I’ve never experienced) is overridden by the extra work you have maintaining those extra levels and the soul-draining conversations you’ll end up having over whether something is level a or level b.
But what about if we split an epic and find that some of the user stories are still too big to fit into a sprint? Split those user stories into smaller user stories. It’s ok. The world will not end.
What about projects?
Another “what about” that follows from the two level hierarchy discussion is what about projects? How do you decide what the team works on next and communicate that out to everybody?
“Project” has become a dirty word in many parts of the software development world. It’s unfair to some extent because the concept of a project is still useful and helpful in certain contexts. The way projects have been implemented in product development cause the issues.
The reasons why you don’t want to do projects are a discussion topic for a different article, or even an entire book. The key points are that project thinking tends to encourage temporary teams working on something where success is based on meeting scope, time, and budget constraints. In a product development context (and that includes internal products) You’re going to be more effective if you have a consistent, focused team that measures success based on the outcomes they achieve.
So I avoid the word projects and use the word initiative instead. Yes, I know that makes me no better than those inventors of agile frameworks who create new terms. In my defense the use of initiative is somewhat common in the industry.
You could escape the need for initiatives altogether. Here’s how:
- Fund a team that is focused on a specific product for a specific time frame. (how you identify what is a product, especially in the internal product case is definitely a different article)
- Establish a product roadmap that indicates what outcomes you intend to accomplish within certain time frames.
- Only populate your product backlog with epics and user stories related to the outcome you’re trying to accomplish now.
That may be too much of a reach for where you’re at, especially when it comes to funding decisions. In that case, you may find it helpful to keep a portfolio kanban populated with initiatives. The portfolio kanban provides a structure for analyzing initiatives in order to decide if they are worth investing in. One technique I’ve found helpful in evaluating initiatives is the internal product opportunity assessment.
What about SAFe?
The definitions of epic, feature, and user story listed above are helpful, but they contradict SAFe’s definitions:
- User Story: “Stories are short descriptions of a small piece of desired functionality, written in the user’s language…User stories deliver functionality directly to the end user. Enabler stories bring visibility to the work items needed to support exploration, architecture, infrastructure, and compliance.” (© Scaled Agile, Inc.)
- Feature: “A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI).” ( © Scaled Agile, Inc.)
- Capability: “A Capability is a higher-level solution behavior that typically spans multiple ARTs. Capabilities are sized and split into multiple features to facilitate their implementation in a single PI.” (© Scaled Agile, Inc.)
- Epic: “An Epic is a container for a Solution development initiative large enough to require analysis, the definition of a Minimum Viable Product (MVP), and financial approval before implementation.” (© Scaled Agile, Inc.)
In other words, according to SAFe:
- An epic is (as I described it in the post Epic Confusion) “something that is almost, but not quite, entirely unlike a project.”
- A feature is what everyone else refers to as an epic,
- A user story is a type of story
- Epics can be broken down into capabilities which can be broken down into features which can be broken down into user stories.
To be fair, the SAFe requirements model has these different levels of hierarchy because SAFe also has multiple backlogs. Each backlog contains a different type of backlog item:
- Portfolio backlog: “The Portfolio Backlog is the highest-level backlog in SAFe. It provides a holding area for upcoming business and enabler Epics intended to create and evolve a comprehensive set of Solutions.” (© Scaled Agile, Inc.)
- Solution backlog: “The Solution Backlog is the holding area for upcoming Capabilities and Enablers, each of which can span multiple ARTs and is intended to advance the Solution and build its architectural runway.”(© Scaled Agile, Inc.)
- Program backlog: “The Program Backlog is the holding area for upcoming Features, which are intended to address user needs and deliver business benefits for a single Agile Release Train (ART). It also contains the enabler features necessary to build the Architectural Runway.”(© Scaled Agile, Inc.)
- Team backlog: “The Team Backlog contains user and enabler Stories that originate from the Program Backlog, as well as stories that arise locally from the team’s local context. It may include other work items as well, representing all the things a team needs to do to advance their portion of the system.”(© Scaled Agile, Inc.)
If it helps, imagine taking a product backlog and splitting it into three parts dependent upon the scope and type of product backlog item and whether it impacts a single team, a team of teams or multiple teams of teams.
Oh, that doesn’t help? Too complicated?
Yeah, I agree.
It might be possible that your product is so big that you may need multiple teams working on it, and you may want to organize those teams into multiple teams of teams.
Even if you do find yourself in that situation, experience has shown me that you don’t need four separate backlogs with four separate levels of hierarchy to coordinate the efforts of over 90 teams split across multiple locations. A two level hierarchy and some good old fashion communication can work wonders.
You may have guessed from the above that I’m not a fan of SAFe. You would have guessed right.
I rarely work with organizations large enough to warrant using that particular framework, and when I have worked with organizations of the appropriate size they’ve generally been able to adopt less complicated approaches.
There are probably some contexts where a four level hierarchy and multiple backlogs work. Ultimately, you need to understand the needs of your situation and figure out what works in your context.
I’d like to close up with some thoughts that are heavily influenced by the post I wrote for the Agile Alliance on the confusion that exists in different uses of the term “epic.”
There is no one way to label your product backlog items. You need to consider your context and build a shared understanding with your team(s) as to what will work for you (collectively). Agree to the terms you’re going to use, agree to what they mean, then consistently use the terms in that way. I certainly have a preference for the definitions suggested above, but you may find different interpretations work better for you, perhaps even the SAFe definitions.
An even better approach is to get back to the original idea behind the user story. Spend more time talking about the items on your backlog and less time categorizing and documenting them. If you do that, you may find you may not even need a product backlog hierarchy.
Focus on the outcome you’re trying to get from your efforts rather than obsessing about the way your outputs are represented.
Remember, the right size for the story is the right size for the conversation. It doesn’t really matter what you call them.