If you have ever developed any software or just plan to do this, you’ve probably heard the words “epic” and “user story”. There are also good chances that you’ve seen epics and user stories in a budget estimation received from IT outsourcing company, in case you’ve ever requested such. This is because both terms are pretty popular in the tech world since coding teams and other participants of the development process use them quite often.
The problem, however, is that different people usually mean different things when they talk about epics and users stories. Nothing is engraved in stone and teams tend to adapt terminology to what is convenient for them. The bad news is that such state of affairs may lead to some misunderstandings between developers and a client, which is a rather unfortunate outcome.
In this article, we’ll try to sort things out and explain what is epic and what is user story based on our practical experience. To make it even clearer, we’ll also illustrate everything with examples and the processes we have here, at GBKSOFT.
- A brief background: Scrum
- What is an epic?
- What is a user story?
- How the team works with epics and user stories
- How do we use epics and user stories for the estimation
A brief background: Scrum
Epics and user stories are mostly used by the teams which follow the Agile approach to software development. For the sake of simplicity, we’ll focus only on Scrum rules and terminology since it’s the most widespread project management methodology from under the Agile umbrella.
In Scrum, the development process is broken up into sprints. The latter ones are the short time spans during which a development team should create a potentially releasable feature-set called increment. Every increment usually consists of several product backlog items (or PBIs). A product backlog item is a general term for all the product features, functions, enhancements etc. to be developed. In other words, PBIs are building blocks of the scope of work for a coding team.
For more detailed information about Scrum, read this article:Scrum: What It Is and Why It’s Incredible
So how does all this refer to users stories and epics? Let’s take a closer look.
What is an epic?
The Official Scrum Guide defines nor “epic”, neither “user story”. However, these terms are used in any Agile development. Basically, an epic is one big piece of product functionality. Usually, it is too big to be completed in one sprint and should be split up into smaller bodies of work. For instance, an epic may be registration & authorization, authentification, user profile etc. As simple as that.
The functionality of a product is decomposed into epics in order to estimate the time and budget for a project, organize the work of a coding team and identify the chunks of the highest priority. It’s also more convenient to discuss the product at a high level, for example, with stakeholders with no technical background, by looking at it as a set of epics.
What is a user story?
A user story (or just a “story”) is a specific task within an epic. For instance, we may have such user stories as “Sign Up with Email”, “Sign Up with Facebook”, “Log In with Email”, “Log In with Facebook” “Forgot Password”, and “Log out” in the epic called “Registration & Authentification”. So to create user stories, we just need to look at a particular epic more scrupulously and determine exactly what may be included in it.
It’s also worth mentioning that if there are several types of users for one feature, for example, logging in as a user and logging in as an admin, different stories should be created for each of the roles.
Ideally, all user stories have to be written in a standard format that goes as follows:
Using such wording is important because the above template allows you to simultaneously focus on the end-user and provide programmers with the guidelines on the feature to be developed.
You may wonder why not just break the scope of work down into stories from the very beginning skipping the epics? Well, it’s a matter of efficiency. First of all, it would be quite challenging to properly define the list of stories, if there were no epics. And, secondly, without epics, it’s quite hard to see the big picture. As a result, it becomes almost impossible to properly estimate and prioritize the work since the only thing we can see is an endless list of relatively small tasks.
How the team works with epics and user stories
In the Scrum team, the responsibility of writing epics and user stories lies on a Product Owner. He or she is a person who determines what has to be developed and in what sequence. But, of course, a Product Owner doesn’t work in isolation. To turn stakeholders’ ideas into epics and user stories, he constantly communicates with a development team.
For the development team, all user stories which are to be developed in one sprint are a to-do list. Or, using the Scrum terminology, we may say that user stories are product backlog items which all together constitute one increment, i.e. potentially shippable piece of software to be developed within a sprint.
More on the Scrum team and processes in this article:Scrum in a Nutshell: How It Works
During one sprint, developers can work on user stories belonging to different epics. Everything depends on prioritization and team velocity, i.e. a number of stories a team is capable of completing in one sprint.
How do we use epics and user stories for the estimation
As we mentioned above, besides being useful for organizing the team’s work, epics and user stories also help to calculate the budget for a project. This is because breaking the functionality down into pieces and estimating each of them separately makes the whole process much easier and much more transparent.
Here’s how the estimation process looks like at GBKSOFT:
In the estimation document provided to a client, we mention the number of hours our specialists need to complete a user story. For instance, let’s say a team has to develop a “Log In with Facebook” feature for iOS, Android, and web. The estimation for it might contain the following information:
- Product Owner: 1-2 hrs
- Android front end: 4-5 hrs
- iOS front end: 3-4 hrs
- Web/API: 4-6 hrs
In simple words, the main difference between a user story and an epic lies in the scale of view. The user story is the tiniest piece of product functionality. A big user story that may be decomposed into a set of smaller user stories is an epic. There are two main purposes of having two terms which sound so similar. First, it’s more convenient to discuss a product on different levels (i.e. stakeholders – product owner; product owner – coding team; developers – developers). And, secondly, it helps to optimize the development process. We hope you found this article helpful. But if you still feel confused, don’t worry at all. Our expert team would be happy to answer all your questions.
Looking for professionals who can write decent tech documentation for your project?