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:

Now how do you go about:

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:

Option 2

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

Result:

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:

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.

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:

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:

Acceptance Criteria:

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.

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:

Conclusion

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!