Successful organizations have portfolio management procedures in place to ensure that large new work items, represented by Epics, are properly evaluated before being selected for implementation by one of the Portfolio's Programs.
Among the criteria needed to make a Go/No-Go Decision on an Epic are a rough estimate of the work involved, and a high-level implementation plan including an assessment of teams’ capacity for doing the work.
In the past, estimating new work often meant exhaustive requirements analysis and story decomposition, with team-level sizing exercises that could take days or weeks. This level of estimation is overkill if the goal is only to determine whether a particular Epic’s value proposition is sufficient to send it to teams for implementation. Is a particular Epic something that can be done with existing teams in a month? A quarter? Or is it a year-long effort that might require substantially new staffing?
A better way to answer these questions is to use relative “t-shirt sizing” to compare Epics against each other for the purpose of prioritization using Weighted Shortest Job First or similar methodologies. The same way Story Point estimation allows for capacity planning at the Sprint level without requiring detailed work breakdown estimates, relative point sizing can be done at the portfolio level to help provide guidance on level of effort.
As with teams at the Sprint level, relative size metrics like points are not necessarily helpful unless they can be correlated with a particular capacity metric like velocity. At a program or portfolio level, historical velocity data can also be used to determine how long an Epic with a particular t-shirt size might take for a team of a given size, by rolling up stories and features from past Epics to come up with rough guidelines for new Epics.1
For information about high-level estimation within the Scaled Agile Framework®, review the following abstracts: