How to break Down a Feature into Epics, User Stories & Tasks

How to break Down a Feature into Epics, User Stories & Tasks

A product manager needs to balance both strategic and tactical work. Strategic work involves helping define the product strategy and vision for the company. Tactical work is all the things that go into converting that vision into reality.

So what goes into making it happen!

Let’s assume that you have:

1.Identified the customer problem that needs to be solved
2.Consider it a priority to work on

Now how do you go about:

1.Explaining this problem to the team
2.Finding a way to solve it
3.Translating the solution into a feature that the team can develop

The goal of this article is to focus on how to take a product feature and translate it into requirements. These are then worked on by the engineering team.

In smaller teams the product manager manages the end to end process from discovery to delivery. In larger organizations the product manager might focus on the customer facing side to define the problem. The product owner or delivery manager works to translate it into meaningful releases.

Why is this important?

The devil is in the details. You can’t tell your team to go build something without defining how it should behave. Otherwise they would go build it in a way they understand and not how it needs to work. I have seen it happen over and over again. You go about building out what seems to be a small feature. But then as you start defining it you realise that it isn’t that small after all! It’s better to realise this before sitting in a grooming meeting in front of the entire development team. (been there, done that! haha)

Let’s look at it through a small hypothetical example.

Your company has a blog page. Your marketing team believes that engagement on the blog page is low. Their hypothesis is that if people interact more on the blog page it will increase traffic. The team evaluates different solutions. It comes to the conclusion that if users can comment on a blog to share their opinion it would solve the problem.

You are the product manager responsible for this part of the website. What do you do? How do you go about it? There are two options:

Option 1

You talk to your engineering manager and tell him to add the ability to comment on the blog post. And then engineering takes over.

Result: There are a few different ways this can play put:

1.The engineering team has this crazy superpower - The ability to read your mind and build exactly what’s in your head. And that’s what happens most of the time. That’s what you’d like, wouldn’t you? The thing is that this will almost never happen. This scenario is a 404 error!
2.The team starts to build something. But there are tons of questions on how everything should work. You are able to answer some, others you hadn’t thought about. For example, should people be able to reply to others’ comments, can only logged-in users comment, what is the word limit on a comment etc etc. What seemed like a two day job has now ballooned into a multi week project with more and more things to figure out. This is what will happen almost every time.

Option 2

You take out the time and put in the effort to:

1.List down exactly how you’d like the feature to behave
2.Define what will the first iteration have in it
3.Write the requirements by breaking the feature into small parts.
4.Take out the time to think through all the edge cases
5.Identify and list out things that are out of scope for the project


1.There are less questions during the development time
2.Feature is ready in time
3.It works the way you expect it to behave

This is the result that we all want!

How do we go about creating the feature with Option #2?

Let’s look at the framework of epics, user stories and tasks. This is a great way to translate business requirements into product features. It’s advantages are as follows:

1.Smaller stories are easier for the engineering team to understand and work on
2.They are easier to track and give you a more accurate understanding of the progress of the project
3.It gives you the flexibility of breaking the feature into smaller releases. The users can then start using them sooner.
4.We can gauge the success or failure of the project faster through earlier feedback from users

How small does the user story need to be? Is there a method to the madness? Let’s try and understand each of the different elements.

Epic Hierarchy

What is an Epic

An epic is a logical collection or grouping of user stories that fit together.

A project can have many epics and each epic can have many user stories. Some common questions that come up when discussing epics.

Does it make sense to have an epic for every release?

No. Sometimes you might release smaller user stories. But if you have a set of user stories that relate to solving a particular problem then you can group them together under one epic.

Do you have to release all user stories in an epic together?

There is no hard and fast rule. It depends on what makes it easier for the team to manage and track projects. You can either have:

1.Multiple release versions in one epic
2.Have one epic for each release for similar stories.

The end goal of an epic is to make the team’s life easier when tracking projects. If its not doing that then you need to find out what’s not working.

What is a User Story

A user story defines an interaction that the user has with the product. It can be independently tested on its own. A common format used for it is:

As a , I want to …

The “user” in this is the end user of the feature. It could be:

1.Your customer/prospect if the feature is being built for them
2.Your internal stakeholders like your marketing manager if its an internal feature.

Acceptance Criteria:

1.The solution should be able to do “X”
2.The user should be able to the following “Y” actions
3.The user should not be able to do the following “Z” actions

The acceptance criteria defines the boundaries within which the solution needs to work.

We will go through an example in a separate blog post

What is a Task

Over the years I have heard different definitions of what a task is. For me tasks are a set of things that the development team needs to do to complete a feature.

1.Having a story is not a prerequisite for a task.
2.Anyone in the team can create a task.
3.In larger teams it’s better to define the type of tasks. It makes reporting better
4.In most cases the development team will break down users stories into tasks
5.The advantage of relating tasks to user stories is that it helps track development cost.

Note on subtasks: I have tried using subtasks but have never been able to successfully  use them! For me it’s too much of an overhead to manage for the returns it provides.

Challenges with this format

No framework is perfect. You will run into issues at some point when implementing this in your team. It could be:

1.User story not broken down enough
2.User story broken down too much
3.Development tasks converted into user stories
4.User stories converted into development tasks
5.Pointing stories versus tasks
6.Who own what- Epics, user stories, tasks


You build frameworks to improve efficiency and make everyones life a tad bit easier. But it might not work for your team. You have to find the right balance of what works for everyone. Make sure you educate the team on how you are breaking down stories and grouping them. Take their feedback and iterate until you’ve found the right balance.

So go ahead and try it out! Let us know if this works for your team!

You may also like