How to Write Epics and User Stories
Basic principles & guidelines with an example for product managers/product owners for writing an epic and user stories
Writing a good epic and user story is the most basic and the most important task at hand when you enter the role of Product Management. Hence I am going to get right to it and give you some real tips and examples of how to write epics and user stories — best case scenarios.
I understand and agree that not everything is applicable in every situation as exceptions are also part of our job. But consider this a basic guide to writing a good epic and user story.
Before proceeding to the details on how to write Epics and User Stories if you want to get a basic understanding on what is an Epic and user story ? Please read this article What is an Epic & User Story? How to name your Epic and User stories?
EPIC’s
A well-written epic is a key to have a good understanding and material to refer in case of any doubts during development. It helps in avoiding a lot of conflicts and misunderstanding in the team. Since this is what you will refer when writing the user story and all the other team member when working on the user stories it's extremely important to collaborate and put some details in your Epic. As a product manager/owner while creating an epic include the following four things as the very basic structure.
- Introduction
- Product requirement
- Technical requirement
- Design requirement
As a product manager, you are responsible for creating the epic and maintaining the epic specs sheet but from my experience, you should not try to do it all by yourself. Your major responsibility is to write the introduction and the product requirement but get as much help as you can from your engineering team, tech architect or teach lead while writing the technical requirement. Involve the UX designer or UX lead while writing the design requirement. The collaboration will serve you better in long run.
INTRODUCTION
In the introduction, you should include about ‘why’ and ‘what’ about the epic.
If you are writing an epic to develop a new feature include why you have decided to develop this feature, what are the user needs you are trying to solve and what are you trying to achieve with this new feature along with the metric you plan to use for measuring the achievement of the new feature. In addition, if you have any documentation or early wireframes for the feature include those in the introduction to provide as much clear picture & information you can provide to your team. Note: shared common understanding and goal is a key to successful delivery.
In short, your introduction can include:
- summary of what the features you’re building are for and why you’re building them
- what metrics you are trying to improve
- links to specific documentation
- marketing plans, legal requirements (if any)
- early wireframes
Example: Suppose you and your team is working with a messenger service and now you want to add a feature for the user so that the user can upload the pictures from their device and share it with their contacts. So this is how your introduction can look like:
Introduction
This feature will allow users to send pictures to their contact through our messenger service.
Our research shows that 60% of users would use this functionality and in user testing our designs were intuitive for users.
We expect that this functionality will increase the number of messages sent per user by 10% on avg, which will result in approx. 3% additional time spent using our service in the course of a month.
Ideally, we want people to be able to share multiple varieties of files, but for MVP we have decided only allow uploading photos from their mobile, desktop and tablet.
PRODUCT REQUIREMENT
An essential part of the epic where you provide with an explanation for the whole team working on it to understand what are they going to design, build, test or release. For example, if you are building a feature that the feature has to be fast or should be available in multiple languages, or should work on multiple devices like mobile, tablet and desktop should be mentioned in the product requirement section of your epic.
Continuing the above example your product requirement could look like below
Product Requirements
- User can initiate a photo message from the message window
- User can select a photo from their own device
- User can preview the image before sending
- User can cancel the send before it is complete
- User should be able to send any resolution photos from their device
- User should be notified about the successful upload
- User can see the uploaded photo in a preview mode and can click to open a full image
DESIGN REQUIREMENTS
While writing the design requirement collaborate with your UX designer as much as you can. Take their input as there might be things that a designer thinks is important in order to have a better user experience which wouldn't cross your mind. For example, a designer might think the preview should be of a certain size and the profile picture should always maintain certain resolution in order for a good experience than those kinds of requirement should be written here.
Continuing the example ahead this can be how your design requirements may look:
Design Requirements
- The photos should be stored in our servers so the user can see them even when they switch their devices
- Maximum photo size should be 2000X2000 pixels.
- Preview should be atleast 600X600 in the aspect ratio of the uploaded image
- Loading indicator to be shown to the user while the user is waiting for the upload, in case of any delays
- Success indicator to be shown for successful uploads
ENGINEERING REQUIREMENTS
Similar to the design requirement in this part of the epic try to involve the engineers or tech lead as much as possible. Their inputs in the early stage will be very useful while estimation and building it correctly. For example, the engineering team might want to build an API to integrate with some other system in order to fetch and maintain the quality of an image, those kinds of specifications and requirements should be mentioned under engineering requirements.
Continuing with the above example the engineering requirement can look like below:
Engineering Requirements
- Need a database that can scale to X number of images at a maximum of 5MB per image
- Pull user IDs from user profile to connect with the photos in our database
- Create an auto-delete system to delete images after 1 year to make it GDPR compliant
Having a good epic spec document will have a very positive effect on your team to collaborate and build the right thing. For you as a product manager to create user stories to slice it down and prioritize your backlog, have a smoother development process and easy shipment.
USER STORIES
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.
Here is a simple template that is widely used while creating user stories:
As a (type of user), I want (some goal), so that (reason).
The point of the user story is to clearly state the feature desired from the point of view of the user.
A user story must have just the right level of detail. It should be a high-level requirement with additional detail added to the accustomed acceptance criteria. The acceptance criteria are the clear picture for the engineering team to understand ‘what’ they are building and for the QA to clearly state the acceptance test. The components to be included are:
- User story
- Acceptance Criteria
- Design attached to the user story
As we have already created an epic, to build a feature that allows the user to share the photos from their devices with their contacts. I would like to continue with the same example to write some user stories.
User story: As a user, I want to select photos from my device in the messenger service so that I can share it with my contacts.
Acceptance criteria: Given I am a user and I click the “add picture’’ button in the message window, I am presented with a popup window to choose the file I can upload, submit it with the upload button and see a preview of the uploaded image.
Given I am a user who has successfully uploaded a photo from my mobile when I click send, the image is sent to my contact and it appears in our chat window.
If you want to learn in-depth about how to write acceptance criteria you can read the article on How to write acceptance criteria? Best practices, format, examples, and tips.
Writing a clear user story with acceptance criteria helps the engineers to think through the process while building the feature. Attach all the design for the engineers and the QA to follow while working on the user story. Make estimation relatively easy for the scrum master to follow. In short a well-written user story = win… win… win…
Hope the above guidelines are helpful to you when you create your next epic and user stories.
