Master Feature / Epic Forecasting

Focusing on the bottom up from Features to Initiatives and thinking through Iterative Forecasting I can see a benefit to having flexibility in the automatic date range that Initiatives are able to be set on. Right now they are dependent on Releases and will contain one to many releases, and in normal agile sprint cadence does not directly orient to the organization of work. Meaning Features and Master Features will always be oriented around an Initiative but releases are targeted less at the Initiative and more at the planning and grouping of work. I would not expect Releases to tag each Initiative representing Features / Master Features within as this leads to double work and could easily be missed in the way less agile projects may be organized.

The request I would have is to allow the Initiative Automatic date range to either be selected as an aggregation of Releases (current) or Master Features (new). This would allow product manager to answer the question of “how many sprints would this Master Feature take?” and when do those sprint(s) begin and end. This would then push the initiative containing them to the same time range as if the releases (used as sprints) were tagged the same, but reduces the redundant record keeping. The product manager would be responsible for setting a date range on all Master Features for them to be considered in this date range. Something they may be doing to show a Master Feature roadmap, but would automatically create the initiative roadmap for an audience one step removed. This allows a product manager to plan and think strategically from the top-down, but to forecast and report status from the bottom up in a second flexible manner. Master features may span initiatives the same as releases and should be treated the same when calculating dates.

Attached is a cool excel file showing how this could get the same result in the initiative Automatic date, but would allow two methods of working.