How to Write Epics and User Stories
Nov 16, 2018
As a product manager/owner while creating an epic include the following four things as the very basic structure.
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)
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.
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.
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.
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:
Design attached to the user story
Author = Bindiya Thakkar