Epics, User Stories, Themes, and Initiatives: The Key Difference and Examples

If you have ever developed any software or are just planning on doing so, chances are that you’ve heard the words “epic” and “user story”. You’ve likely also seen epics and user stories in a budget estimation received from an 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 development process participants use them quite often.

The problem, however, is that different people usually mean different things when they talk about epics and user stories. Nothing is engraved in stone and teams tend to adopt terminology to what is convenient for them. The bad news is that such a state of affairs may lead to some misunderstandings between developers and clients, which is a rather unfortunate outcome.

In this article, we’ll try to sort things out and explain what epic is vs what a user story is based on our practical experience. To make it even clearer, we’ll also illustrate everything with examples and the processes we have developed here at Altamira.

Scrum methodology: a brief Overview

Epics and user stories are mostly used by development teams that follow the Agile approach to software development. For simplicity’s sake, we’ll focus only on Scrum rules and terminology since it’s the most widespread project management methodology under the Agile umbrella.

In Scrum, the development process is divided into sprints. That is, the project development is broken up into components of short periods of time during which a development team should create a potentially releasable feature-set that is called an “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 by the team. In other words, PBIs are building blocks outlining the scope of work for a coding team. So how does all this apply to user stories and epics? Let’s take a closer look and discover.

What is an Epic?

The Official Scrum Guide defines neither the term “epic” nor “user story”. However, these terms are used in any one 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 constitute the pieces of code that are responsible for registration & authorization, authentication, user profile, etc. As simple as that.

The functionality of a product is decomposed into epics in order to estimate the time and budget outlay required to complete the aggregate project, organize the work of a coding team, and identify the chunks that are 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 what epics you are working on and how much time the overall implementation of the features will take. 

Example of epics

Now we would like to show you some examples of epics and how exactly they appear in the project management flow. Let’s imagine we are developing a custom corporate website for a company where workers and users need to have different levels of website access. As we’ve already established, epic represents a part of the development project, being responsible for the development of a particular web app function. So the epics for the development of a website could be divided into creating sprints as follows:

• Log in;
• Registration; 
• User profile;
• Website;
• Services;
• Order management.

Thus, the epic is in and of itself a voluminous piece of a software product that needs to be further subdivided into smaller components that are called user stories and will carry detailed descriptions of each step a user will have to take to start using a website.

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 or Google”, “Log In with Email”, “Log In with Facebook or Google”, “Forgot Password”, and “Log out” in the broad epic that can be 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, separate stories should be created and devised for each of the roles. Ideally, all user stories have to be written in a standard format that goes as follows: Using consistent wording is important because the above template allows you to simultaneously focus on the end-user and provide programmers with the guidelines on the features 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 that somehow have to be logically linked and connect.

Example of user stories

A user story is one of the elements of epics that splits one epic into several consistent steps that describe what website users will see on a screen and what action they will be asked to perform considering the acceptance criteria. To show it with an example, let’s take a common epic that is present in many software products – registration. The stories that could be added to this epic are the following:

1. Sign up – as an unregistered user I want to have an opportunity to “Sign Up” onto the website in order to get access to its functionality.
2. Email verification – as a user completing registration I will be tasked with verifying the email address provided in order to prove that the email address provided in fact belongs to me.
3. Log in – as a registered user I want to have the ability to “Log In” to my account in order to get access to the website options.
4. Forgot password – as an unregistered user I want to have an option to change my password in case I forgot it or lost it, or else.
5. Log out – as an authenticated user I want to have the option to “Log Out” of the account in an attempt to keep my account private and safe.

We have described a basic registration process and its surrounding elements without entering/specifying the types of buttons, acceptance criteria, filed titles, and ways of validation.

What is the difference between an epic and a user story?

Taking into account the definition of an epic and a user story, we have figured out that there is no significant difference between these two components of the software project as they correlate to each other. Epic is the larger part that is charged for a certain app feature (we mentioned some examples above) while the user story is the detailed description of how this feature will function within the system and what actionstasks should be done to make it work correctly.

What is a Theme?

The theme is used to structure user stories into appropriate groups that are related to one another. Each themed group of user stories is responsible for one feature or channel that is split into several different parts and applies different abilities and acceptance criteria. Each user story in this case is a separate activity with its own goals and tasks, however, it is still the single theme. Themes can intertwine when the user story can be related to different themes, meaning one user story can be used in several channels. 

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 address more holistic and complex goals than any of the separate epics can do themselves. Epics imply smaller amounts of jobs 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 the initiative’s nature.

How do the developers 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, the Product Owner constantly communicates and coordinates with the development team.

For the development team, all user stories that are to be developed in one sprint are placed on a “to-do list”. Or, using the Scrum terminology, we may say that user stories are product backlog items that 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. the 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 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 what the estimation process looks like at Altamira:

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 the web. The estimation for it might contain the following information:

What to consider when choosing a Development Team?

Commonly software development companies offer a similar range of services and project development cycle. 

The project development process is usually split into several consecutive parts:

• determining the business objectives and project value for your company;
• creating a list with specifications – detailed description of product requirements and plan on how to execute on them;
• design layout – initial visualization of your future product before making all intended product features functional;
• turning the design layout into reality – writing code where each sprint is responsible for a particular function of your solution;
• providing testing of your solution to monitor it in action and reveal any bugs and errors to fix them before the official release;
• implementing into your business workflows if it is a new solution and deployment of an updated version in case the developers’ team was tasked with modifying an existing software within your company;
• a maintenance program that implies supporting your product after deployment and providing improvements following your company’s demands and constant change and evolution of tech trends that are used for developing solutions in your industry.

We also recommend having a look at the maintenance packages that Altamira offers to its clients and learn which maintenance plan would be appropriate for your software project.

Additionally to the development flow, we described above, the software development company you are partnering with should offer a full and transparent package of documents where all project details will be written, approved, and signed from both sides.

We recommend acting responsibly when choosing the development team and learning about each specialist that will be involved in your project. Particularly, we advise you to check the next options:

• how long all of the specialists have been working in the software development industry and how long they’ve been with the development company;
• learn about the experience, meaning technical stack, previous projects and their success after the release, industries, etc.;
• check out Linkedin profiles to find out more about team members skills, proven experience in previous software development companies, reviews, and other activities;
• meet all team members in person and figure out the responsibilities and tasks of each specialist.

We are ready to provide you with all required information about our workflow with clients, clear documentation, get you acquainted with every professional who is going to work with your project as we know how vital it is to keep you informed about each development stage and take into account your feedback to know if we are moving in the right direction.

FAQ

Bottom line

In simple words, the main difference between a user story and an epic lies in the scale of the 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 epic. There are two main purposes of having two terms that 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 of your questions.