How are Program Epics typically handled in SAFe?

• A. They require a separate budgeting process that slows agile delivery
• B. They are implemented directly as a single feature in the solution backlog
• C. They are discarded if not aligned to a PI plan
• D. They are split into features in the program backlog. May require budget approval and lightweight business case

Answer: (D)

In SAFe, a Program Epic is a large initiative that spans multiple Agile Release Trains and PIs, so it isn’t handed to teams as a single unit of work. Instead, it’s analyzed and then broken down into smaller, implementable pieces and placed into the program backlog as Features (with Enablers as needed). Those Features are what teams actually plan and deliver within a PI, while the Epic stays at the higher-level tracking and funding view.

A lightweight business case is often created for the Epic to capture expected value, costs, and impact, and it may require budget approval to fund the work. This keeps governance lightweight but still gives decision-makers visibility into trade-offs before committing resources.

So the reason this approach fits best is that breaking Epics into Features enables cross-ART collaboration, incremental delivery within PIs, and a practical funding path that aligns with SAFe budgeting practices. It also avoids treating Epics as a single, indivisible unit, which would be too large to plan and deliver iteratively.

The other options don’t fit SAFe practices because a Program Epic isn’t implemented as one feature, nor discarded if not aligned to a PI plan, and budgeting isn't an always-separate, bottleneck process—it’s handled through the lightweight, ongoing Lean Budgeting approach.