The various scaled agile frameworks make use of some common building blocks which many practitioners will be familiar with. Stories are often the most familiar, as they are the raw material of the SCRUM and Kanban practices which have been applied at the team/squad level for many years, particularly in technical teams. However, in the process of scaling these practices a need for larger aggregations of work was needed, and in response to this need, emerged epics.

Whilst best practice for writing user stories is well documented, the guidelines for scaling this practice to larger groups of activities is not. Having worked with teams using epics for some time, I have seen a range of examples of good epics and even more examples of anti-patterns. Getting epics wrong is probably the number one reason why teams perceive scaled agile to add less value than they expect.

What follows is a summary to serve as guidance for those embarking on backlog creation for a team or squad within a scaled agile organisation.

Epic?

An epic is a group of stories. Each story is a necessary stepping stone to achieve the objective of the epic.

• An epic can be relatively small or relatively large, but is bigger than a team can deliver in a single sprint. It should generally be a large piece of work, taking between 1-3 months.
• An epic should represent a concrete piece of deliverable value to the end-user. Having a backlog full of epics representing invisible enablers is an anti-pattern.
• Epics should articulated as an outcome. The purpose of the epic is to describe what we want our user to experience, not how to achieve that outcome. Having an epic which is overly prescriptive about how to achieve the outcome is an anti-pattern.
• It should be possible to prioritise all epics against one another. If it isn’t possible to meaningfully prioritise one epic against another, the planning process becomes overly constrained and complex.
• Epics should be mostly deliverable by a single team. Organisations are not perfect, and therefore this criteria is often a tough one. Some dependencies are OK, but if you find yourself in a position where most epics have dependencies to two or more other teams, it may be time to consider reorganising around your business domains and architectural ambitions. My recommended read on this subject is Team Topologies by Matt Skelton.
• An epic should materially improve an underlying KPI or key result (in the OKR framework, for example).
• A team should always learn something from delivery of an epic. Almost all perceived user value is a hypothesis which product teams should be seeking to test at the earliest opportunity.

Benefits of epics

Epics:

• Enable meaningful prioritisation across teams
• Provide transparency across teams
• Enable efficient evaluation of work against OKRs or KPIs – attempting this story-by-story is very time consuming
• Force product managers to work hard at breaking down long term product aspirations into chunks which deliver user value
• Enable meaningful dependency planning across teams
• Are a mechanism by which to communicate the value of a group of stories

Formulating epics

Epics, like stories, must start with the user. When faced with a blank canvas, the use of design thinking methods can lead to a better understanding of the problems the user faces. To better understand who your user might be, the use of personas will allow you to better empathise with the human beings who will ultimately use your product. Personas are also a powerful tool with which to communicate with your team, helping them to truly feel connected with why a given epic is important.

The process for writing an epic within a scaled agile context often begins with a process of slicing up a broader ambition. If you are working with initiatives, each epic is a “slice” of the larger initiative. Slicing is possibly the hardest task a product manager faces on a regular basis. There are several mechanisms by which work can be sliced. Most of these can be linked to an underlying principle of “shifting left”: always try to learn as much as possible as early as possible. By bringing learning forward in the roadmap, you mitigate the risk of committing too much time to endeavours which don’t deliver the expected value.

• Prototyping – can a prototype of a deliverable be developed before committing to a longer roadmap, in a way which meaningfully teaches you something about the underlying hypothesis you may have?
• Architectural slicing – can you deliver value without committing to an expensive engineering challenge, in order to shift learnings left?
• Segment slicing – can you offer products to subsets of users in a way which removes complexity from earlier epics, whilst enabling learning from those users who you do target? Try to think broadly about segmentation, as your existing predefined customer segments may not be the most optimal for this purpose. Experiment with slicing customers based on a broad range of characteristics to find pockets of opportunity to target smaller user groups with similar needs.
• Complexity slicing – can you strip complexity away from the target product in order to deliver value to some users earlier? This is an antidote to the anti-pattern of having too many enabler epics – rather than building a complete solution back to front, build a partial solution through all layers of the technology stack to enable delivery of value early on.
• Stubbing – can you measure interest in a feature by creating a link to the feature before you even begin working on it? Measure the number of clicks on the link to gauge interest before beginning an expensive development journey.

Documenting an epic

An epic, once you have sketched out its place in a backlog, must be documented in such a way as to be meaningfully discussed in a variety of forums, prioritised, and implemented.

Leadership must be able to understand the epic in the context of the overall value proposition for your product. Other product managers must be able to evaluate the priority of the epic against their own in order for you as a team to prioritise effectively. Teams must be able to understand the objective in sufficient detail to be able to get to work implementing and delivering the epic.

A four-step process can be followed to document an epic effectively:

1. Write the epic description. The description is a narrative, structured in a similar way to a user story. “As a who, I want to what, so that why“. The who, what, and why must be specific enough for the relationship between the work and the benefit to the user to be clear. Keep in mind that the user needn’t be a customer – it could be an internal team or stakeholder, a system, or a member of your own team.
   • “As a user…” is less desirable than “As a controller managing incoming invoices…”
   • “…I’d like to manage invoices…” is less desirable than “…I’d like to be able to control, reject, or comment on invoices…”
   • “…so that I can do my job quicker” is less desirable than “…so invoices can be quickly and accurately processed to ensure timely payment, increasing creditor perception of our company.”
2. Write a summary for the epic. The summary is a short and sharp name for the epic which can be used to unambiguously refer to the epic in prioritisation and status discussions. For example “Invoice controlling workflow”.
   • An anti-pattern for epic summaries is to use the “Feature: version 1” formulation. The summary should still communicate as specifically as possible what the outcome of the epic is.
   • The summary should not be the full description – avoid using the “As a user…” formulation.
3. Write clear acceptance criteria for the epic. The acceptance criteria, as for a story, are a critical tool for the implementing team to understand specifically what is expected from the user’s perspective.
   • See acceptance criteria as a checklist of requirements to act as guardrails for the team as they design the solution, and as a way for the team to know when they are done.
   • A common mistake is for acceptance criteria to be prescriptive about how to deliver the expected outcome – that is not the purpose, and can fundamentally undermine the autonomy of the team.
4. Evaluate the epic. An optional final step can be undertaken, to evaluate the epic using a framework which can be applied consistently across all epics as an aid to prioritisation. Examples of scoring methods which can be adopted include:
   • RICE scoring
   • MoSCoW method
   • Cost of Delay
   • Kano model

Next steps

Once a backlog has been defined and refined with epics of a high standard, three steps naturally follow. Depending on the cadence of the adopted scaled agile framework, these activities may happen periodically within a product increment (or “sprint of sprints”), or on an ongoing basis more aligned with individual development sprints.

1. Prioritisation. Leveraging the evaluation scoring performed in the final stage of epic definition, leadership and the broader product management community prioritise epics against one another to create the overall product backlog.
2. Story refinement. The product manager and team(s) working the backlog collaborate to break down the epic in to deliverable stories which ultimately deliver the expected outcome for the user.
3. Dependency management. With the deeper knowledge of what is needed to deliver each epic, the team can engage in a forum with other teams to highlight dependencies. The prioritisation across teams from point 1 is used as a reference when deciding whether a team should work on their own stories, or dependencies other teams have on them.
4. Estimation & execution. The team implementing the epic estimate the stories within an epic and begin working to deliver the stories in priority order.

Image credit: İrfan Simsar on Unsplash