What is an Epic and User Story? How to name Epics & User Stories?
Basic understanding of epics & user stories.
What is an Epic?
There is no Wikipedia definition of Epic yet as the concept is still evolving. But there is a basic understanding of what is an Epic. If you are new in your PM role this will look confusing, sometimes epic can be a major feature which needs lots of components in form of user stories to be complete in order for the feature to work and sometimes it can be a major component which will include number of building blocks in forms of user stories to be complete. All in all epic can be defined as:
‘Epics are large chunks of work that can be broken down into a number of smaller pieces’.
When a feature has multiple scenarios, multiple implementation that Feature becomes an epic. When a component is bigger than one building block and needs to built in multiple building blocks that component becomes your epic.
Epic is the grouping of one or more features or functionality that we want to develop in order to achieve a goal.
In the above picture I have used an example of instant messaging service. Hence, the Instant Messaging Service becomes our initiative, and in order to achieve the goal of giving our users with the Instant Messaging Service we need to develop the service, and finalize the features/functionality we will include in our service. The initiative may have been originated based on the visions and goals of the company, but we will skip that part for now and try to understand in depth about Epics & User Stories.
The features or the functionalities that we finalize to build becomes our Epics. In one feature or functionality (Epic) the user will have multiple scenarios. For eg, in the epic of sharing photos and videos, the user will have to upload or attach a video, look at the preview and send the video. The user would may be like to come back to the video they have sent, so on and so forth, these are our User Stories. All the scenarios will then need development in multiple areas that will complete the user scenarios like upload button in the text field of keyboard, resizing the images, resizing the videos, supporting formats etc. those are the task & sub tasks.
As a PM we write epics and user stories to define the vision into real work, but our job is not to say how it should be done rather why this should be done. The reason why is valid for both our stakeholders and developers. Stakeholders are not really interested in what code base are we going to use and developer shouldn’t be told how to build this functionality. Both of them have there own roles to play in the product journey and so do we.
How to name your Epic?
Naming epics is important even though you don’t pay a lot of attention to it. While naming the epics keep two very important things in mind:
It should be the core of the development or the reason why
It should be in simple language and not lingos that we use within the team so everyone in the organization can understand if needed.
While using jira or showing a high level plan to the stakeholders or forums it plays an important role that the name of your epics are self explanatory to some extent. When presenting the summary you don’t want the stake holders to wonder what do they mean by that. It should trigger the thought process immediately after reading the name of the epic that yes this is what it is about.
Example of good epic names are:
• Implement photo & video sharing
• Allow user to add new contact
• Migrate our data to a new database
Example of bad epic names are:
• IMS media file upload and send
• Integrate contact list from mobile and email
• Migrate old photos and video to new common core
Why it is important to name your epic right?
Implement photo & video sharing, when you read this as an epic name it will broaden the perspective of looking at the feature, it will evoke thoughts on what all is possible while sharing photos and videos. Instead if I read IMS media file upload and send my thinking is limited to few features. Also, when stakeholders read a epic name in the road map it should given them a broader perspective, quicker understanding and minimize their doubts and questions.
Some of the examples of my epic names are, ‘in–store — digital catalog’, ‘digital on–boarding for minors’ etc.. I hope that even if you don’t know the product or the context of these epics it will still give you some idea of what it is actually. Epic names do prepare the mind to understand and predict what is it that’s simmering.
What is an User story?
Fortunately there is an Wikipedia definition for user story.
A user story is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system. — Wikipedia
User stories are basically the break down of an epic in a more user–focused way for the engineering team to understand the product requirement. In agile methodologies, everything that we build should be focused around users and hence the main purpose of the user story should be to shift the focus around a feature in a more human conversation manner.
The point of the user story is to clearly state the feature desired from the point of view of the user. When we start thinking from users perspective we are able to create scenarios of user behavior even though it’s not a part of our solution. For example, even though we are making a solution of specific issue of sharing photos and videos and because we are so into the space that we will take all the actions exactly as they are suppose to be, but when a user who has no knowledge about your product and is using it for the first time might end up clicking on the back button from the browser which might result in strange behavior. If you want something specific to happen that should be mentioned in the user story and those perspectives are only gathered when you think like an user.
How to name your user story?
The first misconception I have seen from many new beginners is that they all write the name of the user story in the template of ‘As a user… I want to …so that…’ This is not how you name your user story. This is the body or the first content of your user story. If you try to use this template in naming your user story you are constraining yourself first of all to shrink it down to few characters which will not to proper justice to the user scenario and goal. Secondly in the overview mode all your user stories will only be read ‘As a user…’ and you wont understand which user story contains which features from the overview mode
which is really annoying during daily stand ups.
Name your user stories by the feature or need. For example if we continue on the epic called ‘implement photo and video sharing’.
The user stories can be
• Allow user to send photo by pasting url
• Allow user to cancel in mid transfer
• Always show the preview in chat for sent photos/videos. etc.
Once you have named your user stories than move into describing ‘As a user I want to send a photo by pasting the url so that I can share online pictures without having to save it to my device’.
With our epics and user stories we are trying to boil down the vision and initiatives into doable tasks. These tasks may be very complicated to achieve development wise but we as a product manager can at least make it simpler to understand by naming them right or describing them in as simple way as possible.
If you want to learn more about how to write Epics & User stories, you can find the details in How to write epics and user stories? — Best practice.
Author: Bindiya Thakkar