Why you should write good epics

As a project grows, soon enough a big list of stories can become overwhelming. To organise this work we often turn to epics as a way to group similar stories together.

Done well, epics can help:

• Reduce the cognitive overhead of trying to hold every story in your head at once
• Give the team a clearer understanding of priorities
• Provide a language to talk about different parts of a project
• Make it easier to communicate progress with stakeholders
• Open discussions around launch milestones

But there is an art and science to the epic, and done badly they can add overhead while providing little value to your team and stakeholders.

Reduce cognitive overhead

You’re starting a new project, you’ve reviewed the requirements and the designs and now you’re creating stories. It starts out simple enough but by the end of the session you have a list that goes below the fold!

It becomes impossible to hold all of them in your head, plus if you squint they all start to look the same.

Grouping the tasks brings calm to the chaos. It helps satisfy our working memory limits and makes it easier to locate that task you’re looking for.

🍔 Let’s take a look at an example. Our delectable side-business, thoughtburgers (home to the tastiest and most thought-provoking burgers!), needs to change their payment provider because their current one is having too much downtime. They spin up a project team and start planning out the work:

List of stories as they start planning the project. Can quickly feel chaotic… 😳

- Make payment using new provider
- Handle 3DS
- Use saved payment method
- Refund orders from Admin
- Save payment method (during payment)
- Ability to switch between old and new provider
- Transfer tokens from old to new provider
- Automated refunds
- Remove saved payment method
- Payment reliability metrics
- Notify on Chargeback
- Save payment method (standalone, from account area)
- Ensure old compatibility once tokens migrated

Grouping the stories into epics. An orderly calm… 😊

Clarity around priorities

Epics give you and the team a clearer focus on what should be done first. It allows you to have easier conversations when priorities get blurry.

“We’re focusing on One-off Payments right now and this refunds task we’ve decided to work on doesn’t really fit. Maybe we should deprioritize it so we can complete the epic first.”

Common language

In the spirit of DDD’s Ubiquitous Language, epics give us a common language to talk about various parts of a project. They map a project out into its core components.

Plus, abstractions make for easy shorthand: Saved payment methods is a great shortcut for referring to all the stories within it without having to list them all every time.

Communicate progress

Ever start talking about the progress of stories with a stakeholder and see their eyes glaze over? Typically this occurs because we’re not modifying the level of detail to fit the audience.

Tasks and stories are noisy and contain a lot of detail. But epics provide a great way to communicate progress at a higher level. A level that leadership & stakeholders care about and can easily understand.

❌ Bad: “We need to handle 3DS and reliability metrics, then we’ll look at saving payment methods, using saved payment methods, being able to remove saved payments methods and being able to add a new payment method from your account.”

✅ Good: “We’re on track to complete One-off Payments this week, then we’ll move on to Saved payment methods.”

Here’s another example which shows two ways of representing the same data:

1. Stories (or tasks) represented on a Kanban board

• Audience: Project team
• Frequency: Daily

2. the same data represented as epics

This is an aggregated view of the progress shown for the Stories.

• Audience: Stakeholders, leadership, and the project team itself
• Frequency: Weekly

Discuss launch milestones

Epics are a great lever to discuss what should be in or out of a launch. Coming back to our friends at thoughtburgers, they want to switch payment providers fast because downtime means no burgers in bellies and that’s not a world we should live in.

What do they really need to launch? They need some way to process refunds but does it need to be automated? And do they need a slick chargeback notification at launch (the payment provider will let them know about them anyway)? Let’s refactor their epic.

From the original:

- Refunds
  - Refund orders from Admin
  - Automated refunds
  - Notify on Chargeback

Let’s split it in two so we can launch earlier:

- Refunds Phase 1
  - Refund orders from Admin
- Refunds Phase 2
  - Automated refunds
  - Notify on Chargeback

I couldn’t think of a better name, so I went with the basic “Phase 1” and “Phase 2”. Don’t be afraid to make the change even if you know the name isn’t great. It’s still progress.

After a good night’s sleep and a flash of inspiration we settle on some clearer common language:

- Manual Refunds
  - Refund orders from Admin
- Automated Refunds
  - Automated refunds
  - Notify on Chargeback

Separating the epics gives a concrete name to each decision that needs to be made. It makes it easier to talk with stakeholders and agree what’s in and what’s out. “We definitely need Manual Refunds and we’ll work on that soon, but do we really need Automated Refunds for launch?”

But let’s not stop there. What about the epic to Migrate saved payment methods from old provider? This is certainly a usability delight, but do we need it? Is it such a hassle to ask users to re-enter their details one time? Perhaps we leave this till last with the option to drop it completely if we want.

Groups are epic

Within the complexity of any project there lies a tool to bring order. Group things, then give that group a name. It’s epic!