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:
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.
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.
