An Agile Release Train prepares for PI Planning. They have both Features and Program Epics among the desirable items for this PI. However, Product Management is stuck because some Epics are too big…

Question

Options

• APick only those Epics that have clearly defined success criteria and might fit into the PI.
• BSplit Epics into Features and prioritize the Features to determine what should go into the PI.
• CSplit Epics into Features and use capacity allocation to determine what should go into the PI.
• DInstead of planning just the upcoming PI, plan for a longer period to cover the full duration of the

• A
  8% (2)
• B
  76% (19)
• C
  12% (3)
• D
  4% (1)

Explanation

In SAFe, PI Planning operates at the Feature level - teams cannot directly plan or commit to Epics because they're too large and abstract. Splitting Epics into Features is the required decomposition step, and then prioritizing those Features (typically via WSJF) determines what actually fits within the PI's capacity.

Why the distractors are wrong:

• A is wrong because selecting Epics with good success criteria still doesn't solve the sizing problem - Epics remain unplannable at the PI level regardless of how well-defined they are.
• C is wrong because capacity allocation governs types of work (e.g., innovation vs. technical debt percentages), not how to choose among Features from a decomposed Epic. Prioritization - not capacity allocation - answers "which Features go in?"
• D is wrong because extending the planning horizon to fit an Epic defeats the purpose of time-boxed PI Planning and violates the cadence principle in SAFe.

Memory tip: Think of the flow: Epic → Features → PI. Whenever an Epic is "too big," your job is always to decompose first, then prioritize - never skip the decomposition step or try to plan the Epic directly.

No community discussion yet for this question.