Epic, Feature, or User Story? Get the Answer Here!
Updated: Oct 6
"International shipping" – is that a feature or an epic?
"The Checkout" – is that an epic or a user story?
"Order confirmation" – is that a user story?
If you or your team are struggling to properly break down features, stories, and epics in your product backlog, you're not alone! Many teams rely on their best guess when splitting epics into features and user stories.
But today, we’ll stop guessing!
I’m going to share a direct method you can use to clearly define the scope of an epic, a feature, and a user story.
Ready? Let’s get started!
The Problem with Defining Epics, Features, and Stories
Since I can remember, I’ve struggled with finding the right way to break down items in the backlog. And it becomes even harder when you switch teams (or jobs!). Every team seems to have its own take on what’s an epic, a feature, or a user story.
But… it doesn’t have to be like that!
Your backlog structure should newver reflect personal preferences or guesses. Instead, you need an objective metric or method to structure your backlog the right way.
The Two Key Metrics for Defining Backlog Items
For the method I’m sharing today, we’ll use two metrics:
Complexity
Time
Using these metrics, we’ll apply the following definitions:
A user story must be fully done within one sprint.
A feature must be fully done within one Planning Interval (PI).
An epic must be fully done within one product release.
Now, let’s see how this works with a real example.
A Real Example: Breaking Down a Mobile Project
Let’s say I’m working on a new mobile application project for a fashion company.
The project duration is estimated at 8 months. Using 2-week sprints, that means 16 sprints in total. I’ll divide this project into 3 planning intervals (PIs), with 5 sprints each.
Based on this timeline, things like Shipping, Checkout, Product Catalog, and Pricing are major epics. These are large features that will be built incrementally over the entire project.
Let’s focus on Shipping. This epic will consist of smaller features, each fitting into their respective PIs. One feature on the roadmap is “International Shipping with FedEx”.
We’ll classify this as a feature because, according to estimates, it can be fully implemented within one PI.
This feature will then be broken down into multiple user stories that are small enough to be done in a single sprint. For example:
“Choose FedEx at Checkout”
“Track FedEx Shipment Status”
“Receive Shipment Notifications from FedEx”
My team has estimated these user stories, and they’re small enough to fit within the boundaries of one sprint.
The 3 Essentials for Breaking Down Your Backlog
To implement this approach successfully, you need three things:
A Definition of Done: what does it mean for a feature, story, or epic to be fully “done”? Usually, this means the work is implemented, tested, deployed, and accepted by users. Your team needs to have this agreement.
Preliminary Estimates: have your epics, features, and stories preliminarily estimated by your team or team leads. This will allow you to reasonably gauge the complexity of backlog items early on.
Atomic User Stories: keep your user stories small and atomic so they can be completed within a single sprint.
Summary
To wrap up, here’s how you should break down your backlog:
A user story must be fully done within one sprint.
A feature must be fully done within one PI.
An epic must be fully done within one product release.
Feeling stuck at the same BA level and don't know where to go? Join me for a free, 1-hour webinar. We'll walk through a career model used by top IT companies for business analysts - from Junior to Lead - and how you can use it to see where you are and what it takes to move up.
Comments