Epic vs. Story: What's the Difference and How to Use Each

User Story 101

As promised, let's start with the very basics—by covering user stories.

What's a User Story?

We can say a user story—or simply story—is the smallest unit in agile planning. It represents a piece of functionality that, when delivered, will help the user/customer achieve some goal, generating value.

In its simplest form, a story contains a title and a description of the functionality needed. It's common to use a template for the story's description. The typical template looks like this:

AS A __________ (user)

I WANT___________(functionality)

SO THAT__________(business benefit)

The user in the template above represents a real user of the system. Functionality means ... well, the piece of functionality that is to be implemented. And the business benefit bit refers to the valuable outcome that the user will get from that feature. By using this template, teams can remain focused and never lose sight of the business motivation behind implementing a feature.

Let's see an example of a user story according to the template. For the context, imagine you have an online education platform, where instructors can manage their lessons and courses:

AS A instructor

I WANT to be able to include modules in my courses on the web app

SO THAT students benefit from the better course organization

It's important to bear in mind that this initial description isn't a replacement for detailed requirements. The story above, for instance, leaves many questions open:

• Should it be possible to create a module with no lessons in it?

• Are modules mandatory? Or can I have a course without modules?

• Can modules be marked as optional?

Such questions and the discussions they initiate are valuable. During software development, it's so tempting to start adding things we think will be valuable for the user, without the actual evidence of this being the case. This is anti-agile: in agile projects, one should always remember the YAGNI (You Ain't Gonna Need It) principle.

The discussions originated by the story description will act as a primer for the complete and more detailed requirements to emerge.

How Do User Stories Work?

The details of how stories work differ according to the specific agile methodology used, the size and preferences of the organization, and so on.

In broad strokes, we could probably summarize how it works like this:

• During spring planning, the stakeholder who is the proxy for the client (e.g., the scrum master in scrum) prioritizes the stories for implementation.

• The development team estimates each story, probably using story points or another form of estimation.

• Stories are broken up in tasks—unless they're too small—and developers sign up to implement them.

• Details can be added to a user story by adding conditions of satisfaction or, alternatively, by performing user story mapping.

How Granular Are Stories?

This is a crucial point in understanding how stories differ from epics. Stories can be small or big, simple or more complex. That's why we have techniques such as story points estimation, after all. A story worth 2 points is certainly easier to complete than one estimated at 11 points.

However, no matter its complexity, a story must fit within a single iteration. After all, stories are the blocks of functionality that developers implement during an iteration.

Of course, different factors affect the size and complexity of the stories that will fit within an iteration. Your team's capacity is such a factor, and the length of your iteration (e.g., one week vs. two weeks) is another one.

If a story can't fit within a single iteration, you can divide it into several smaller stories. If it's possible to implement them simultaneously, different developers can sign up to each of the smaller stories and complete all of the pieces without a single iteration.

However, what do you do when it's not possible to decompose a big story into independent pieces? That's where the "epic" concept comes in handy.

Epic to the Rescue

An epic, as we've said earlier, is like a large story. More specifically, an epic is a big portion of work that spans multiple iterations. It's composed of regular stories that are interdependent and all relate to the same goal.

Since epics are larger than regular stories, they're also fewer in number. A team that delivers dozens of stories a month would typically work on three or four epics a quarter.

Considering the user story of the previous example, an epic from the same company could be: "Develop the functionality to allow instructors to manage their courses and lessons." It makes sense such an undertaking is too big for a single iteration.

However, what do you do when even epics aren't big enough?

Initiatives

Initiatives are the next step in agile planning. They reside in one of the highest levels possible. Initiatives are a collection of epics that all relate to a common business goal.

An example of an initiative in our online education platform could be: "Increase the number of paying users by 25% by the end of the year." Then, inside this initiative, we'd have epics that somehow support this goal—for example, epics related to performance and user experience improvements, or the creation of features that are present in competing products.

Themes

Finally, themes reside at the highest possible level of agile planning. Themes are organization-spanning goals that usually refer to the company's quarterly or annual goals. With agile themes, you can track those goals with a collection of initiatives.

Epic vs. Story: The Verdict?

After covering all of these agile concepts, did we arrive at a verdict about them? What's actually the difference between epics and stories and how you use each?

Firstly, as you've seen, epics are stories. They're simply bigger stories that don't fit inside a single iteration and that can't be divided into independent bits.

How do you use each?

• Use regular stories when they're simple enough to fit inside an iteration.

• If you find out there's a relationship between a bunch of stories, group them together using an epic. (Otherwise, it's fine for a story to not belong in an epic.)

• If a story is too large or complex to fit within a single iteration, that's a sign it should be an epic.

"Epic vs. Story," Themes and Initiatives: Focus on What Matters Most

As an organization, going through an agile/DevOps transformation isn't easy. Some obstacles seem insurmountable at times. Jargon and buzzwords abound, and it's often hard to separate the valuable, enduring concepts from the ones that are merely passing fads.

In this post, we've helped you by clarifying the whole "epic versus story" dilemma. You've also learned about initiatives and themes, and how they all fit into the overall big picture of agile planning.

Before closing the post, here's some food for thought. Sometimes, organizations miss the forest for the trees. They get too focused on the sheer number of stories, epics, and tasks they finish and lose sight of what matters the most: the customer getting value in their hands.

That's why Value Stream Management (VSM) is so important. VSM allows you to focus on actual results by giving you insights and metrics that inform your decision-making, allowing you to prioritize the areas that need more attention and generate better results. If you want to learn more about how VSM can help your organization achieve more and delight your customers, take a look at Plutora's e-book Mastering Software Delivery with Value Stream Management.