Epics and User Stories: What and how?

When I first ventured into the IT industry as a Business Analyst, there was so much to learn. I had to (and still) take help from Google to educate myself with many concepts, techniques and technologies like JIRA, Slack, Agile methodologies, Kanban, and every other idea that’s ready to turn the industry on its axis.

If I were to give an overview of what is BA’s job, in a nutshell, it is: to gather client requirements, polish and consolidate them, share ahead with the development team, and ensure timely delivery.

One crucial part of the BA’s task is writing epics and user stories. These form the path on which the entire development and design team walks to achieve the desired results. Today, I will share everything I know and have learned about epics and user stories in my career.

What is an epic?

Epic is a large chunk of work that is broken down into many smaller pieces or stories.

What is a user story?

A user story is the subset of an epic; when user stories are clubbed, they together become one epic that outlines one feature of the proposed software application.

Let’s understand the epic and better with the below example. Here we wish to create a food delivery application for the client. A list of restaurants and eateries in the area, an option to place the order online, store user details for ease, integration with multiple payment portals, etc., are some features expected from this application. These features become epic.

Now each epic will be further divided into a user story. In the below example, the feature ‘user registration and login’ will have multiple user stories that will be written from the end user’s perspective. If needed, the user story can be further divided into sub-tasks that help in completing the application.

You must be wondering how to write an epic or a user story. The process of writing epics and user stories varies from one individual to another. I usually follow this approach.

Label > Narrative > Acceptance Criteria

• Label: It is the name of the user story. It should be small, precise, and highlight the feature.
• Narrative: Narrative is a short description of the user stories and must be written in a way that it is easily understood by the people working on the project. The narrative is always written from the end user’s perspective and focuses on the who, what, and why of the feature.

It is written in the format > As a (user), I’d like to (reason for the feature) so that (benefit/outcome achieved from the feature).

Points to remember while writing epics and user stories.

• When you start working on a new product or a new feature, always write the highest-level epic first. From there, start moving down the hierarchy with other epics, user stories, tasks, sub-tasks, etc.
• It is crucial to know the product users and customers as it will help in writing user stories. The stories describe features that the users will find helpful. Hence, conducting research and interviews is an ideal way to go. Never write user stories based on speculation.
• A user story should be small enough to be delivered within a sprint. If it is too large to be delivered in one sprint, then break it down into tasks.
• Collaboration and communication are the backbones of the agile development methodology. Hence, it is essential to make the epic and user stories visible and accessible to all project members. Discuss scenarios and use cases with colleagues to polish the stories.
• Always keep the user stories short, simple, and to the point. Avoid any ambiguity by focusing only on what is necessary and leaving out the rest. Also, always use active voice while writing user stories.

Well-written epics and user stories help deliver the project on time and ensure that it matches the client’s requirements and accepted quality standards. If you have any other queries about epics and user stories, I will be more than happy to answer them. You can reach me at hello@sarvika.com .

Originally published at https://www.sarvika.com on May 20, 2021.