Product Backlog: Epic, User Story, and Tasks

You’ve probably heard the terms Epic, Story, and Tasks, right? There’s plenty of confusion about these terms around, so we figured it would be best to start from definitions. So here we go!

Product Backlog (PB)

It’s all consumer and business needs that’ll be solved by the product. It’s kept and evaluated by the Product Owner. They’re not bound to use the User Story format for it, though.

Epic

It’s a user story that’s not been detailed yet, or is really long, or is still packed full of uncertainty and thus cannot be turned into product incrementation. An Epic must be sliced into smaller user stories, so let’s propose a simple example: I, as a visually impaired professional, want my work environment to be more accessible so I don’t have to depend so much on others.

User Story (US)

We’ve talked a lot about user stories in What’s a User Story?, How does that User Story go?, and User story: avoiding dysfunctions.

In short, a User Story is a short format to write down the requirements to build a product. It must be intelligible to clients and consumers. Here are some examples of user stories for the epic above.

Story 1: I, as a visually impaired human, want places I have to go to be accessible so I don’t have to go through the embarrassment of asking people for directions all the time.

Story 2: I, as a visually impaired human, want to get to the emergency exit quickly so as to… you know… not die in a fire or something.

Notice that a good Product Owner can slice the story even more if they try and grasp the most important part of the most important problem of the most important client. For example:

Story 1.1: I, as a visually impaired human, want places I have to go to be accessible so I don’t have to go through the embarrassment of asking people for directions all the time.

Story 1.2: I, as a visually impaired human, want to easily get to elevators so I don’t have to go through the embarrassment of asking people for directions all the time.

Story 1.3: I, as a visually impaired human, want to get to meeting rooms easily so I don’t have to go through the embarrassment of asking people for directions all the time.

And they can slice it some more. Let’s say most visually impaired professionals work on the 5th floor.

Story 1.1.1: I, as a visually impaired human working on the 5th floor, want to get to the toilets easily so I don’t have to go through the embarrassment of asking people for directions all the time.

Tasks

Tasks are the necessary items for a user story to become an increment to a product. Examples of tasks for Story

1.1.1:
Acquire a presence sensor module;
Acquire speakers;
Design new signs;
Creating engineering models;
Assemble the new signs;
Installing signs and tactile floorboards all around the 5th floor; etc.

Hierarchy

The hierarchy between all kinds of user stories is:

The Product Backlog is the complete set of user stories we have to write. A user backlog has always N+1 stories. The backlog doesn’t have to include epics. Usually, teams that work with fully flexible scope and constant validation keep an extremely streamlined backlog.

If there’s an epic in the backlog, it can be sliced into N+1 user stories. The epic can be ditched, however, if it’s found that it won’t bring as much value as initially thought.

A user story can be divided in N+1 technical tasks. However, when the Product Owner slices user stories well, when a Team has a well-mapped flux of value on the Task Board and masters the necessary tools and techniques, when everybody knows the context of each demand, the need to break up stories into tasks drops drastically.

These are the only four user story levels, and yet confusion abounds. Much of it arises when people start using agile projects’ management tools before actually knowing its concepts.

Confusion? Names and tools

The chart below shows some names used by the most popular tools on the market: C.A. Agile Central (former Rally), Jira, IBM Rational Team Concert (RTC), Trello, and VersionOne. We can quickly see the terms follow only a semi-standard. This of course results in no shortage of… confused people.

Some of these tools start from the top to control the workflow from the portfolio of projects. Some accept custom names and structures. So, if your company uses one of these, you might have a different hierarchy than the one presented here. For IBM Rational Team Concert (RTC), for example, everything is a work item. You can have epics, or not; and subtasks, or not; etc.

Conclusion

Some concepts in Agile Methods can be tough when we’re just beginning, especially when we come from the Project Management world, but we get used to them with time.

Also, consider yourself invited to join our Certified Scrum Product Owner (CSPO) training and learn to create good user stories by actually doing it.

Avelino Ferreira
Avelino Ferreira

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it. Please notice that we do not keep any personal information though.