Often, you need to provide estimates for items of work that are beyond the size of a typical story, say an epic or a feature. For example, you might want to determine an overall roadmap of intent and need to line that up with a calendar which is only realistic if you have some kind of view of how long something will take. Or you might want to determine the Cost of Delay, which includes a sizing component in it, to determine what work you should schedule first to maximize the return.

The question therefore is “How do you go about getting size information for these bigger pieces of work?”

For the sake of discussion we are going to make a couple of assumptions:

• We are going to use the basic SAFe structure of stories (less than two weeks), features (less than a quarter), and epics (more than a quarter). While the discussion is related to SAFe, there is nothing SAFe specific here. The scaled estimation problem is the same.
• We are using a relative team sized story point based estimating approach.

In general there is a different focus in the “why” approach as we scale to epics and features. In general at the team level you are interested capacity to take on work. At the program level the main use is to prioritize the work. At the portfolio level its to help with overall budgeting. Pictorially this is represented as:

There are two basic ways that you can scale these estimates:

• Pure Feature and Epic points which are used as an estimate: With this approach you use a similar process that you would use with story points. In other words you would do a team based relative size estimate to generate “feature points” or “epic points”. You might choose to define a new scale so that it is clear you are talking about feature points or epics points. For example, feature points might be 10X a story point, with a sequence that looks like 10, 20, 30, 50, etc. In the same way that you track team velocity to determine how much you can get done, you can track closure of features and epics to reflect how much you can get done in these scaled environments.
  • Pros: In many ways, this approach is a "fractal" of the story point approach and benefits in a similar way.
  • Cons: The main downside of this approach is that it will take time to get useful (in terms of forecasting) data. Just like a team has to wait an iteration (a couple of weeks) to get their first data point, features will take a quarter to get their first real data point and epics will probably take longer still. Another weakness is if one class of work is significantly different from others. In these cases it is hard to get consistent estimates and interpreting capacity (based on feature velocity) is complex.
• Summated Story points to create Feature and Epic estimates: Based on a common understanding of the size of a story point, the idea here is that features are estimated in terms of the number of story points it would take to complete the work, and similarly for epic. So for example, if we look at a feature and as we do the estimating we would say “this feature is about the same amount of work as this 60 point feature, so we'll call this a 60 for the estimate.
  • Pros: One benefit of this approach is that you can start using data immediately. If, for example, you want to start managing epics at the portfolio level now, you can quickly create estimates and understand capacity even if you do not have all the teams in place.
  • Cons: The main downside of this approach is that to work it needs to have a common understanding of a point. Many start with “a day equals a point” with the result this can quickly turn into a pure duration based estimate with all the problems that entails. Another problem occurs when one teams velocity is significantly different (ie orders of magnitude different) from other teams as while each of the teams can work their own estimates and velocity, when you summate very large numbers from one team can completely swamp other team's numbers which means it is hard to understand capacity of the multi-team train.

In practice, the two approaches really are not that far apart from each other. What you will find is that even with the summated approach, you will end up with features in the 10's (ie 10, 20, etc) and epics in the 100's. The hard part is getting people to really do relative size estimates that include a view of risk and complexity at all levels. As a general note SAFe starts with the “Summated Story point” approach, but it is not that specific over the long haul. In fact SAFe assumes a relative size approach (not duration) as it says “Start with day is a point then never look back”).

Note: Thanks to Steve Sanchez for the graphic.