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
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 divided 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. So how does all this refer to users stories and epics? Let’s take a closer look and discover.
What is an Epic?
The Official Scrum Guide defines nor “epic”, neither “user story”. However, these terms are used in any Agile methodology 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. It is also easier to track progress and control the overall development process if you know with what epics you are working and how much time the implementation of features will take.
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 & Authentication”. 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.
What is Initiative?
Usually under initiatives we understand a collection of several epics that are aimed to achieve one common goal. Initiatives can collect epics of different teams to perform more holistic ad complex goal than any of the separate epics can do itself. Epics imply smaller amount of job that can be completed within a month or a couple of months. And initiatives can take several months and even a year to complete. Check out the picture below to get a better understanding of initiatives nature.
How does the developers team work 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.
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?
For your better understanding of how we work with epics and user stories, what level on involvement is required from our clients, and how all documentation is managed, our Chief Transformation Officer – Alexandra Rostovtseva – has prepared a great video guide. We’d recommend you to watch it till the end and in case you have any questions, leave them in the comments section or send on our email.
As we mentioned earlier, 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:
|Job role||Required working time|
|Product Owner||1-2 hrs|
|Android front-end developer||4-5 hrs|
|iOS front-end developer||3-4 hrs|
|Web/API developer||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.