Decomposition - Epics

25 ap-decomposition-epics

Epics are a critical deliverable to provide alignment and allow decentralized decision-making; they articulate the vision and provide the context the teams need to create impactful solutions.

Explore More.

Related Mindset:



Agile Portfolio


The inputs for Epics are ideas and strategic themes.


The output of Epic creation is a well-crafted Epic that can be used to make funding decisions and connect the work done at the Program and Team levels to the enterprise’s strategic direction. It is a critical element needed by the programs and teams to understand why work is being undertaken and what success looks like.

Epics are the connectors between an enterprise's strategic themes and the collection of features that deliver value through working software.

Epics are similar to the concept of a project in the waterfall world, in that they have a start and an end date and usually represent a significant effort that may take months to implement. Unlike projects, they do not include a fixed set of requirements, nor do they have a dedicated team to execute it. Instead, they have scope boundaries and clearly defined success criteria, and are decomposed into features that can span teams.

A key component of Epics are success criteria. An Epic’s success criteria are used to determine when the Epic is done. Feature work can and should continue until such time that the Epic’s success criteria have been met. The success criteria are evaluated after every release to determine whether the Epic is done or not.

Since an Epic represents a significant investment, they require, at minimum, the following six elements:

  • Value proposition - A clear statement that explains how your Epic solves customers’ problems or improves their situation (relevancy), delivers specific benefits, and communicates the differentiation from the competition or the current state. You can use the following template to create the value proposition: value-proposition-template
  • Success criteria - Success criteria are specific and measurable criteria used to validate that implementation is complete and successful. They are used to drive decentralized decision-making and are evaluated after every release to determine if the work is complete or if more work is necessary. Success criteria should meet the S.M.A.R.T. criteria (specific, measurable, actionable, realistic, time-bound.)
  • Lightweight business case/ROI - Since Epics represent a major investment, a lightweight business case/ROI analysis should be created to support funding decisions.
  • Incremental implementation strategies - Epics must be implemented incrementally to allow for frequent customer feedback. Strategies for this incremental implementation should be considered as part of the Epic definition to help prioritize features down the road. This is a good opportunity to define MVP (minimally viable product) and dependencies.
  • Prioritization - Epics will be prioritized against each other; this prioritization should take into account cost of delay and implementation costs. Refer to the Final Portfolio Prioritization element for details on prioritization.
  • Epic owner - The person responsible for driving the individual Epic through the Portfolio Kanban system.

The work that goes into defining these elements and evolving the Epic from initial idea to approval is managed via the Portfolio Kanban system.

For more information on the use of Epics within the Scaled Agile Framework®, please review the following abstract:

Common Pitfalls

It’s not uncommon for organizations to make the following mistakes when defining Epics:

  • Value proposition doesn’t include a differentiator - Value propositions should clearly state how the future state is different from the current state and/or the competition.
  • Success criteria is not specific or measurable - Generic phrases such as “increased efficiency” should be avoided, as they won’t allow you to validate that the Epic is done. By how much does efficiency need to be increased? What does efficiency mean? Instead, use measureable criteria such as: “20% reduction in labor spend per order ”. When using criteria such as this, you need to know the current measurement and how you will measure it in the future. In this case, it’s important to know when defining the Epic that current labor cost per order is $10.61, and that when you measure it in the future you will take an average over a the same period used to calculate the baseline. Defining good success criteria takes time initially, but will help you decompose it into features and define implementation strategies.
  • Assigning groups or a committee as the Epic Owner - Not assigning a specific individual responsible for driving the Epic through the Kanban system will result in it lagging in each step and then ultimately being rushed through without the proper due diligence. The Epic Owner is not a job title, but a role assumed by an individual. It could be the program manager, product manager, project manager, business analyst, system architect, or some other stakeholder, but it must be a specific individual.
  • Defining features before properly defining the Epic - This is a classic mistake made by companies with a competitive culture. In an effort to move fast, Epic definition is either short-circuited or skipped altogether. While this gets the work to the team faster, it will ultimately result in wasted work as the team works to correct course (assuming they even do that) or a solution that doesn’t deliver the anticipated results of the executives.


The following tools are well-suited to define and manage Epics: