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:
- 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: