Agile Recipes: How to Write an Epic

Courtesy of Pixabay

What is an Epic

I guess there are many definitions and opinions about what an Epic should be. This itself doesn’t really help with clearing confusion around it, especially considering that it is a cornerstone of Agile Product Development principles and domains.

I’ve always been reluctant to give an Epic some sort of clear definition myself. probably because there are a lot of things to be taken into the consideration and therefore such epics might contain some things one wouldn’t recognize as something that is used directly by a user.

If I would be forced to formalize some sort of definition of an Epic, I would write something like that:

Epic specifies requirements to describe deliverables in a scope of a new user feature. At least one epic implements Topic/Theme/Initiative. It contains stories, dependencies, and links to different artifacts that are necessary to deliver it.

I know. It’s not one you expected, right? No worries, the next chapters will bring us all to a common understanding.

Who is it for?

It is:

• a smallest deliverable feature collection for a Product Team
• the smallest artifact for Delivery Managers
• smallest deployable and switchable Feature for Product Managers
• smallest User Scenario to be E2E tested by Tester
• smallest completely executable Flow for UX Engineers
• the largest Unit of Work that delivers against any Product Feature for Developers

Which information should it contain? (DoR)

• WHO is the actor, the user? There can be more than just one persona being targeted by the epic, but it needs to be known which one in order to write proper E2E test cases
• WHAT is it supposed to do? Describe the E2E flow as a direct result of the implementation. Make Acceptance Criteria clear to everyone on the team
• WHY? What is the value of the feature that epic delivers in regards to the Initiative it belongs to?
• Dependencies, Blockers. Which are all dependencies of any kind as resource, service, tool, another epic,… that make ultimate dependency which can turn into a blocker. There also needs to be a clear message about how and when it would be handled
• Links to UX-Flows, UI-Designs, Architecture Specs, and Artefacts of all kinds.
• Cross-cutting concerns beyond standard and documented. Make sure you have linked all the necessary information about such so that execution is seamless and developers do not overlook some things that particularly define special environmental to a particular topic. Even if all is standard. it cannot hurt to have a link somewhere to your Team Handbook with all the standards mentioned and defined.
• Compliance checked and resolved. Any kind of compliance, whether of general Privacy, Security, or company proprietary kind is supposed to be met and mentioned in an epic.
• Success/Business Metrics. This is a kind of compound of WHAT and WHY defined by metrics to be able to measure the impact of deliverables. For example, there is a drill-down link from a listed block of information to another one that is linked to it but also accessible from the menu. We could define that drill-down link to account as a starting point of linked page impressions for at least 20% of Monthly Active Users. That information would be later used as a reference value in usage analytics and further product discovery. Not only for the number of impressions but also to further dimensions, like Premium Active Users, etc…, reflecting partly also the monetary value of the feature.
• Any Labels and Classifiers. For reporting, discovery, and learning purposes we usually use some special classifiers. To ensure consistency of information search for any kind of purpose, we need to make sure these classifiers/labels are always properly set.
• T-Shirt size. Size matters. Always. That doesn’t necessarily mean you can estimate the size of an epic in any kind of useful way. But you can coarsely size it to understand its overall complexity. Why would this matter? It helps you to define potential quick wins at least, but first and foremost it can give you a rough idea about the resources required for its delivery. Still, any estimates in terms of time or even commitments to deadlines would be the wrong way to go.
• Testable Flow. We need to make sure that the outcome is testable E2E, meaning, the Epic delivers a clear user value/scenario.
• Mocks, Stubs. Do we have everything in place to stub and mock to eliminate waterfall between Backen and Frontend in E2E scenarios?
• Eventual Unknowns. It’s an oxymoron. Any potential Uknown should be mentioned in an epic. However, as long as a single one still exists, the epic is not Ready

Besides, the following pre-conditions have to be fulfilled, including and beyond already known Cross-Cutting Concerns:

• Integration & Deployment infrastructure is known and working all way through staging Environments
• DevOps support, responsibilities are known, including maintenance and scaling of apps
• All tools (development, test, integration, deployment, monitoring,…) are in place
• Deployment, Distribution, and Test strategy

Scope & Size

As mentioned in DoR, these are necessities, but by all means nothing intimidating.

The scope is relatively easy to find out. It simply needs to match an E2E User Flow, as we defined above.

Size is a bit harder thing to deal with, hence the importance of sizing them. Here are some tips:

• set at least 3 but not more than 4 T-shirt sizes. If you find out you have defined more, you are probably swapping epics for stories at the low end and epics with initiatives at the high end
• try to avoid aligning sizes with time units, like days, weeks, men/days, etc… The best is to find a baseline epic, give it a size and then size others relative to it. For example, an Epic could be 2-Factor Authentication. You size it as a medium. It could contain a single new web page, two API calls, and a modification of one. Comparably to this one, a Change Password epic with, let’s say, 5 web pages, and several new APIs could then be sized as large.
• don’t try to define team velocity through complexity sizes per sprint or quarter. In the longer term this would level out at some converging number, but using it for a shorter period, like to find out upfront, how many medium-sized epics can a team manage per quarter, is useless information. Complexity and resources needed are not directly related to the overall time needed to complete an epic. There are a lot of dependencies, management, and resourcing in between which can turn the tide one way or another. Complexity is better related to the type and number of resources needed as it is to time.

Avoiding blockers and dependencies upfront

This is probably the most challenging part to master. There is no easy recipe, like DoR. It takes time, experience, domain knowledge, and good cross-team communication experience to make this work.

A general rule applies: the bigger the epic, the more dependencies, the more blockers

But size itself is not all. Far from it. Actually, most of the effort to avoid them lies in things not very much obvious and have little to do with the epic itself, they are mostly dependencies from the outside of them:

• Architectural dependencies
• Complex DevOps setups
• No clear boundaries between problem spaces and domains that are assigned to teams
• Weak ownership of the team of technical platforms they use
• Too many technical teams create technical dependencies and silos
• … all other regular shared resources

Things above are not always to solve and are in the domain of engineering management. Still, there are plenty of things you can do within the team to reduce dependencies and any kind of stepped implementation of the epic, which is at the end of the day nothing less of a waterfall…

The key to success is slicing a big epic vertically by separation of concerns to the point of single and simple responsibility that still delivers against an E2E Scenario.

An example of an Epic:

Title: “Dashboard to collect data”

Subtitle: “… A Dashboard collects records from a source and makes them for users available to edit and update their header data…”

Split of the Epic in two

You could easily split this into 2 Epics:

Title: “Dashboard to collect data for viewing”

Subtitle: “… A Dashboard collects records from a source and makes them viewable and browseable for user…”

and

Title: “Dashboard to collect data for editing”

Subtitle: “… A Dashboard collects records from a source and makes them available for users to edit and update their header data…”

You can clearly see, that already the first epic delivers a powerful user functionality. This one collects data from other sources (databases, services, events) owned potentially by other teams and has a very minimal external dependency, usually, this would be events from the shared event bus, which according to good practices of enterprise architecture and apps, should receive an event with a payload of every data source update, after it occurs. Meaning, that this is a relatively small dependency, if teams follow a good architectural concept, this part is already working for the team building a Dashboard.

The second one is more complicated on the backed side and less on the front, since most of the UI elements have already been created in the first one.

On the backend, however, more things are happening:

• The dashboard needs to fire an edit event with the agreed structure,
• which a service, which owns the original data should receive,
• which triggers an update in its data source,
• which posts the update event,
• which is being picked by the Dashboard team, which confirms or in case of an update failure reverts the update and shows this to the user

You can see that the second epic is harder to integrate and has more dependencies, which would push back delivery of viewing functionality if this would all be the same epic.

Examples like that are many and there are also many different ones, but they will share the same cause of increased dependencies, which is the sheer size of an epic.

How to Write Them?

Well, almost everything is already written in terms of the content of an epic, meaning, what needs to be written and described, but to get a good epic, it is important to do it in the right way.

The following points should be considered:

• no single person writes them, it’s a work of the team
• start small, develop the idea, divide & conquer, down to the story level
• iterate at least a couple of times, groom, and refine
• members of different stacks should take part
• iterate until DoR is met
• make this a standard part of your teamwork, make sure this runs in parallel with development and other team activities

Antipatterns and Common mistakes

• Epic by technology layer. Database, backend, frontend. Functionality is not covered end-to-end, it only supplies parts of it.
• Epic by product version. The product version is a set of properties from different epics. Unlike the epic, the version has a timeline as well.
• Epic by a customer or any other stakeholder
• Size spilling over an E2E Scenario. This means epic would deliver more than a simple-to-understand feature. The Single Responsibility Principle applies here as well. For example, Epic could be “Placing an Order” and not “Placing and Editing an Order”
• Containing work that should be done by other teams. Do not assign work to the people from other teams. That should be managed as an external dependency.
• Containing dependencies which resolution is not known in terms of WHO and HOW at least. At least not before the start. That would be starting an epic with the blocker installed.
• Containing too many dependencies. If that is the case, then you have probably got it wrong when defining a User Scenario, which is probably too big and stretches over too many other interaction components, including too many different technologies and stakeholders
• The ultimate one: Not complying with the Definition Of Ready

Summary

In this short article, you could get a shortlist of a few important recipes about how to write epics, which are probably the most important scoped units of work that teams deliver in form of tangible and functioning software.

Don’t use it like a recipe you need to follow religiously. It’s about the collection of already known common sense topics that are not expected to be always applied 100%. What is important is a product and all its deliverables. To get there, we need to have a functioning system of well-described functional units corresponding to units of work within the applied development agile framework. This is where an Epic takes its epic place. 😀

How about a Story?

Yes. Most of all this here can be applied to stories, but there are some differences, which I will describe in my next article.