Scrum Epic vs Story in Agile

Scrum Epic vs Story: The short answer

An Epic is a way to group related User Stories. Within the Agile methodology, User Stories should be small enough to be completed within a single sprint, which is typically one or two weeks. Epics on the other hand are allowed to span multiple sprints. So for example, if we wanted to build a house using the Agile Method, we would create an Epic called “Build a house”, under this we would create child User Stories for “Lay the foundation”, “Build the walls”, “Build the first floor”, “Build Roof”, “Doors”, and “Windows”.

It should be noted that while many organisations successfully use the Agile method with just Epics and User Stories, many Agile Teams have additional levels in the Agile hierarchy. For example, Themes, Epics, User Stories and Tasks.  If your organisation is new to Agile then why not just start with User Stories and form these into sensible Sprints. As you and your team gain more experience you will soon start to see how grouping User Stories into Epics can be helpful. 

Here is the longer explanation if you would like more detail.

What is a Scrum Epic

As I have said above, Epics are high level and a way to group User Stories. How do they get created and who creates Epics? While this will vary from company to company, I generally see Epic’s being created by either a Project Manager, Product Manager or Product Owner. 

For those from a PRINCE2 background, an Epic is of a similar scale to a Work Package in PRINCE2.  As an example, the Project Manager might create an Epic called “Build House” and within the Epic outline the high-level requirements, like the size, number of bedrooms, budget, timescale and any other important requirements. 

Once the Epic has been created it can then be given to the scrum team (the builders in this case) to break down into more detailed User Stories which then become product backlog items.

Putting the Epic into Context: Seeing the big picture

For now, we will assume that you are operating a simple Agile process consisting of just Epics and User Stories for a Product you are building from scratch or enhancing. One of the problems with User Stories is they can lead to developers losing sight of the bigger picture or the strategy for the product.

A User Story can be thought of as a piece of a jigsaw puzzle. Each piece on its own is perfectly described, perfectly formed and perfectly delivered but if those implementing the puzzle don’t have the final picture in mind completing the jigsaw will be inefficient and not very satisfying for the team. It is therefore important that the Product Owner / Project Manager set out the vision for the Epic in sufficient detail so that the project team can refer to this for context when reading each User Story.

Parallel and Simultaneous Sprints from the same Epic

It should be noted that while all the stories in an Epic are normally grouped into sprints that are delivered by the same scrum team, it is possible to have two or more scrum teams working on the same Epic. This is usually called Parallel sprints and it enables multiple active sprints that are running in parallel with each other. For example, if you have two teams working from the same backlog, each team can work on their own active sprint simultaneously.

I would use this with great care as you will need a lot more coordination between the sprint teams and there will be more merging of code. While parallel or simultaneous sprints sound like a way to get more work done in less time, you will find there are diminishing returns. 

I certainly would not recommend trying this until you have two scrum teams who are both well established and practised in the art of Agile. This is well supported in Jira now.

Do we need to create Epics?

No, you can start simply with just User Stories. If all your User Stories can be delivered in a single iteration you may never need Epics. In my experience, it would be unusual these days for large projects not to have several epics.

Epics represent a large chunk of work and generally senior management are happy for you to report on progress at the Epic level rather than bother them with the details of individual sprints or user stories. This is also a sensible level at which to secure funding / budget.

Agile Themes

We won’t go into too much detail here as we are focused on Epics vs Stories, but it’s worth saying that as you become more practised with agile software development you may want to group Epics into Themes. Essentially Themes are Projects in the traditional sense, whereas Epics are projects being delivered in phases.

What is a User Story

In Agile the work items get broken down into User Stories. A User Story should be a piece of functionality that is small enough to be completed within a single sprint. Of course, sometimes you’ll get this wrong and you won’t be able to quite finish the User Story. That’s fine, you are getting learning from this which will help you improve your estimates in the future.

When a User Story isn’t quite finished it should be put back into the product backlog and re-evaluated with all the other stories to see which stories deliver the best value for the next sprint.

In most cases, an unfinished story can be quickly discussed and put straight into the next sprint as an easy decision. If this starts to happen on a regular basis you need to try and write smaller user stories.

Some people will keep User Stories non-technical so that they focus on what is needed rather than how it should be implemented. When working this way it is common to decompose User Stories into multiple child tasks. 

Another approach is to have the User Story at the top of the work item and then under another heading detail the technical specification. The choice is yours and really depends on the complexity of the User Story and whether or not it is a task that could be shared between two or more team members. My advice is to avoid decomposing User Stories into specific task lists unless it really helps the team deliver the User Story; if it doesn’t add value, don’t do it.

Note: User Stories are sometimes known as Use Cases.

Who should write the User Story?

This will depend on the size and nature of your business. In a small business, the User Story will often be written by the end-user. If this is the case then I recommend running some short workshops on the art of writing a good User Story as it’s not something that will come naturally to most end-users in your business.

In my experience, the typical end user lacks precision in their use of language when trying to describe requirements for software development teams.

I always encourage the use of simple language in User Stories so that they are accessible by a wide range of readers.

More often new features will be written up as user stories by professional product team members who will be aware of the strategic initiative and how best to articulate it. This then forms part of their standard product development process. 

I recommend that you have a formal process for submitting new user stories. This should allow you to reject any really large user stories before they enter the process and waste the team’s time, better to ask for them to be rewritten straight away.

How do you estimate a User Story?

In the Agile method, we like to assign each Story a number of story points. You can simply go with a number between say 1 and 100 but most teams like to use the Fibonacci sequence (1, 2, 3, 5, 8, 13 etc) as it forces you to debate and really consider your estimates for how much development work is required.

I have spent many hours in meetings debating if something is an 8 or 13. I personally like planning poker, an Agile game where all the scrum teams have cards with the Fibonacci numbers on them and you all reveal your sizing at the same time. The person with the highest and the lowest scores then articulate their reasoning for the scores to the rest of the team after which the team vote again.

When estimating if you encounter a large user story that is too big to estimate or too big for one sprint you should return it to the product owner and ask for it to be broken into two or more stories.

Why do you use story points rather than hours or days?

This is an often-debated question. To be honest, if people were perfect, and if you re-estimate every story in the backlog on a regular basis, you could probably get away with just using hours or days to estimate how much time. is needed for each story. This has the advantage of being well understood by everyone, especially senior management and those not trained in Agile.

The problem with using units of time to estimate User Stories is that it fixes a timescale or more accurately a resource estimate. If items then sit in the backlog for a period of time you have to ask if the estimate is still right in six months’ time or twelve months’ time. 

For example, the first time I swam a mile in the swimming pool it took me ages. After months of training and practice, I can now swim a mile in less than half my original time. What I am saying is that it doesn’t matter what you or your scrum team do, as you do more of it you will get better and faster at it.

So maybe initially your team take two weeks to deliver a 13 point story, but six months from now as they know the codebase better and gain efficiency in working together they may be able to do 13 points in 5 days or less.

Different teams have different capacities. This isn’t a reflection on how hard each team works as there are many parameters that affect the efficiency/velocity of a sprint team. For example, teams with more multi-skilled and fewer specialists tend to be more adaptable and outperform teams where there are one or two specialists who then become bottlenecks.

How do I calculate sprint capacity?

Sprint capacity is the number of points the sprint team (Agile development teams are known as sprint teams or scrum teams) can deliver in a single sprint. As we’ve seen above, this will improve over time. Therefore, the question is where do you start?

My advice is to go with the number of people in the scrum team * 2 initially * weeks per sprint. So 7 people, in a two-week sprint would be 7 * 2 * 2 = 28. The chances are this will either be too high or too low, but don’t worry. You should set the expectation with management and the team that the first few sprints are for learning and calibration.

After each sprint, you can see how many points you managed to deliver and just try and do a little better in the next sprint. So say initially while we thought we could do 28 we only manage to do 21, next time only plan for say 22.

In general, it’s better to achieve everything you plan to do and have a little slack time than to try and do too much and risk burning out people and the team. The slack time can always be used to refine backlogged user stories in preparation for the next sprint planning meeting.

User Story Format?

You should create your own template for user stories which includes the Use Case, functional requirement, acceptance criteria, space for technical tasks and should detail the benefit and business value.

I hope you have found this article helpful. I write widely on agile project management as well as traditional project management. If you have any questions please don’t hesitate to leave a question below and I will get right back to you. I often find your questions inspire new articles!