This is part of my series about writing cards for software development. See the introduction and my previous posts on stories and bugs.

Agile Cards - Epics

Epic’s are a catch all for large features and projects. These can span multiple codebases, and may extend into multiple weeks.

In this context, a “feature” can mean the adddition of a feature to an existing program, or an entirely new product.

Epics show up in several contexts, that may or may not overlap.

  • A feature that can be broken down into pieces that can be built or executed by more than one person.
  • A feature or change that will have a significant impact on more than one bussiness concern.
  • A set of components that have specific dependencies.

Epics may appear to have a large amount of detail that is difficult to comprehend, but having detail gives developers the background to make decisions without needing to involve Business Analysts, Management or Product Owners in every decision.

Filling in this detail also means that pointless work can be avoided. For example, if a feature is being built solely for a potential client, and that client has gone out of business, then the background means that anyone can see the work is no longer required.

Cheat Sheet

Title (six works or less)

---

Summary that expands the title into a complete sentence.

# Background
General background on business goals for this piece of work. This should be at least a paragraph and provide sufficient
 context to a new starter reading the epic a year after it was written.

# Business Goals
What value is created or enabled by this epic. Common themes are 'new feature for marketshare', 'improve reliability',
 'decrease costs of X'

# Acceptance Criteria
A list of specific capabilities that need to be in place at the end of the epic. This might be a specific complete
 customer facing feature, an approved accreditation, or an internal engineering capability such as touch-free CI/CD.

# Roadmap
A list of the order that stories need to be done in. Interspersed with this can be milestones where business value is
 realisable before 100% completion of the epic.

Extended title or Summary

Like with stories, this doesn’t need a heading, as it’s just the first entry in the description field of an epic card. This is a single sentence to expand on the title. Where a card title drops words to be concise, the summary fills in all the words to add the necessary detail.

Background

The background section needs to lay out the drivers for this work. Depending on the gap between an epic being proposed and started, and the size of the organisation, this section may be quite long. In a company of a hundred people, with a twelve month delay between projects being proposed and started, it’s incredibly likely that the reader does not have the complete context for this work. There should be enough here that a new comer to the company can understand at a broad level why this work is relevant.

It’s also worth talking about the general scope of the epic, which helps set expectations of what is, and what is not being done in the work. This can be referred back to when writing story cards for example.

If this is part of a wider business strategy or iniative (eg, moving to cloud, enabling a new geographic market), then it’s imperative to link to that strategy or iniative here. Likewise, if there’s market analysis or customer feedback that indicates the need for a feature, link or include it here.

Business goals

This section serves as a means to communicate the purpose of the Epic to all stakeholders, including non-technical individuals and management. To keep this section concise and to the point, focus on the business value provided by the epic. Common themes are ‘new feature for marketshare’, ‘improve reliability’, ‘cost reduction’, ‘efficiency gains’, ‘compliance’, and ‘security’.

Examples

  • “Creates a new chargable feature that competitors do not have to expand marketshare and increase revenue from existing customers”
  • “Implements data controls on PII data to help us get SOC2 complience”

Acceptance Criteria

  • What abilities or capabilities will the software or business have at the end of this epic? ie; What things have to work to make sure the right thing has been built.

Examples

  • “Platform users can see set the frequency and delivery method for all security alerts.”
  • “Client Users with an organisation configured Microsoft or Google Workspaces account can login via SSO.”

Milestones

Most features and other large pieces of work are made up of multiple stories that need to be done in a particular order. The roadmap iterates this work to stakeholders the work that needs to be done to achieve milestone and epic completion that would not otherwise be visible. However, epics frequently do not need to be complete to realise some form of business value. A milestone is point where enough of an epic is complete to deliver value if released. Depending on the work in question, it’s entirely reasonable for an epic to have many milestones - or no milestones if there’s no intermediate incomplete-but-still-useful stage.

Examples of good Milestones

  • “Milestone one: Users are notified at their default email address where to receive security alerts.”
  • “Milestone two: User is able to set how they receive security alerts.”