Epic 1.0
Stetson Saenz
Epics are a helpful way to organize your work and to create a hierarchy. The idea is to break work down into shippable pieces so that large projects can actually get done and you can continue to ship value to your customers on a regular basis. Epics help teams break their work down, while continuing to work towards a bigger goal.
Maintaining agility when organizing large tasks, like epics, is no small task (pun intended). Learning how epics relate to healthy agile and DevOps best practices is an essential skill no matter the size of your organization.
From our example above, a theme would be increasing space shuttle launches, the roadmap would track towards increasing launches from 3 per quarter to 4, the initiatives would be to drive down costs and increase ticket sales, and each epic would roll up into the initiatives.
Breaking down an epic into more practical stories helps in understanding a project and maintaining momentum, but it can be a daunting task for the uninitiated. There is no one-size-fits all solution for creating stories from an epic, but there are a lot of good options to consider:
Burndown charts can be used to visualize epics, and serve to keep teams motivated and the executive stakeholders informed. A good epic burndown chart is where the agility of the organization really shines.
An epic burndown chart shows the actual and estimated amount of work to be done in a sprint or epic. The horizontal x-axis in a burndown chart indicates time, and the vertical y-axis indicates stories or issues.
Use a burndown chart to track the total work remaining and to project the likelihood of achieving the sprint goal. By tracking the remaining work throughout the iteration, a team can manage its progress and respond accordingly.
By monitoring a burndown chart, it becomes clear how the team is progressing and where the blockers are. Having these data points clearly visible keeps everyone on the same page and facilitates an open conversation about the evolution of the product and completion forecasts. Not to mention that transparency builds trust!
Once you have mastered the art of creating epics and stories, you might want to go one further and optimize using automation. Here are three of the most common automation rules used for sprints in Jira.
Epics are not the absolute foundation of an agile program, but they are the practical drivers for most agile and DevOps teams. Understanding where they fit into a healthy agile program creates context for your work, while breaking them down into stories creates momentum.
Summary: An agile epic is a body of work that can be broken down into specific tasks (called user stories) based on the needs/requests of customers or end-users. Epics are an important practice for agile and DevOps teams.
Portfolio epics are typically cross-cutting, typically spanning multiple Value Streams and PIs. To accelerate learning and development and reduce risk, SAFe recommends applying the Lean Startup build-measure-learn cycle for these epics.
There are two types of epics, each of which may occur at different levels of the Framework. Business epics directly deliver business value, while enabler epics advance the Architectural Runway to support upcoming business or technical needs.
SAFe discourages using the project funding model (refer to the Lean Portfolio Management article). Instead, the funding to implement epics is allocated directly to the value streams within a portfolio. Moreover, Agile Release Trains (ARTs) develop and deliver epics following the Lean Startup Cycle discussed later in this article (Figure 6).
Since epics are some of the most significant enterprise investments, stakeholders must agree on their intent and definition. Figure 2 provides an epic hypothesis statement template for capturing, organizing, and communicating critical information about an epic.
The LPM reviews the Lean business case to make a go/no-go decision for the epic. Once approved, portfolio epics move to the Ready state of the Portfolio Kanban. When capacity and budget become available from one or more ARTs, the Epic is pulled into implementation. The Epic Owner is responsible for working with Product and Solution Management and System Architects to split the epic into Features or Capabilities during backlog refinement. Epic Owners help prioritize these items in their respective backlogs and have ongoing responsibilities for their development and follow-up.
Analysis of an epic includes the definition of a Minimum Viable Product (MVP) for the epic. In the context of SAFe, an MVP is an early and minimal version of a new product or business Solution used to prove or disprove the epic hypothesis. Unlike storyboards, prototypes, mockups, wireframes, and other exploratory techniques, the MVP is an actual product that real customers can use to generate validated learning.
As Epics progress through the Portfolio Kanban, the LPM team will eventually need to understand the potential investment required to realize the hypothesized value. This analysis requires a meaningful estimate of the cost of the MVP, and the forecasted cost of the full implementation should the epic hypothesis be proven true.
Considerable strategic efforts often require collaboration with external Suppliers to develop Solutions. The MVP and the anticipated full implementation cost estimates should include internal costs and forecasted external Supplier expenses.
While it can be challenging to forecast the duration of an epic implemented by a mix of internal ARTs and external suppliers, an understanding of the forecasted duration of the epic is critical to the proper functioning of the portfolio.
After repeating these calculations for each ART, the Epic Owner can see that some ARTs will likely be ready to release on demand earlier than others. However, the forecasted duration to deliver the entire epic across all ARTs will likely be between six and eight PIs. If this forecast does not align with business needs, negotiations such as adjusting capacity allocations or increasing the budget for suppliers will ensue. The Epic Owner updates the forecasted completion once work begins on the epic.
The SAFe Lean startup strategy recommends a highly iterative build-measure-learn cycle for product innovation and strategic investments. This approach for implementing epics provides the economic and strategic advantages of a Lean startup by managing investment and risk incrementally while leveraging the flow and visibility benefits of SAFe (Figure 6).
Gathering the data necessary to prove or disprove the epic hypothesis is highly iterative. These iterations continue until a data-driven result is obtained or the teams consume the entirety of the MVP budget. In general, the result of a proven hypothesis is an MVP suitable for continued investment by the value streams. Otherwise, any further investment requires the creation of a new epic.
c80f0f1006