Capacity Planning by Master Feature Estimates

Often when new Feature requests come in they are at, what we consider to be the Master Feature level...basically an Epic. For future releases, we hold a Release Planning session where our engineers apply high level estimates to Master Feature that have been slated for a given future release. We usually don't break these Master Features into smaller Features/Stories until close to time to actually start on a given release. This allows us not to invest too much time in breaking out stories as our priorities are ever shifting. For budgeting purposes, it would be nice if a given Release could reflect the capacity using the Estimates on the associated Master Features rather than the underlying Features since many times for us, we won't break Master Features down into Features right away. When times comes to actually start on a given Release, it would make more sense to switch Capacity back to the Features themselves, unless Master Features had an option to automatically track/sum Estimates based on the underlying Features.

  • Guest
  • Jul 27 2017
  • Likely to implement
Release time frame
  • Attach files
  • Angus Davis commented
    September 21, 2017 17:57

    Or allow this on initiatives, as the only reason we considered master features was to get this costing functionality. 

  • doug evans commented
    25 Jun 18:23

    I would like to see capacity planning for epics mimic story capacity planning. Similar to the process described above, we will t-shirt size the epics (master features) and compare this to planned capacity looking forward multiple quarters. Matching the capacity we have against the capacity we need will help us determine whether or not we have the resources necessary to achieve our goals and initiatives. It would be awesome to get the same red line for the epics that appears at the story level.

  • Kevin Winn commented
    17 Aug 22:04

    This would also allow for organizations that have product-aligned Product Management teams, but functionally-aligned engineering teams.  We'd like to be able to have one visual board where long-range capacity planning can be done by Engineering Management at the Epic level without losing the primary roadmap benefits for Product Managers.

  • Nate Dunlevy commented
    04 Sep 12:26

    We desperately need this.

  • Marc Robinson commented
    11 Oct 14:11

    I agree with Nate.  Capacity planning is done at this level well in advance of it reaching the teams and you already have this for features so it shouldn't be a major addition :-)

  • Sam Richards commented
    12 Oct 18:55
    We usually don't break these Master Features into smaller Features/Stories until close to time to actually start on a given release. This allows us not to invest too much time in breaking out stories as our priorities are ever shifting.

    Yes and yes. This would be very useful. We always do preliminary capacity planning at the initiative/master feature level to avoid investing time and energy into planning for individual features when priorities often change along the way. This feature would be very useful.

  • Matthew Lynn commented
    30 Oct 21:14

    To echo many other comments, this would be great, and making Initiatives more useful for planning as well, as Angus suggests would be even better  Planning more than ~ 1-2 quarters ahead tends to be at the T-shirt size level, using Master Features. 

    I'd love to:

    - be able to put estimated points in Master Features and have this count against available capacity. Can this work in the same way as Features - Requirements, i.e. use Master Feature points until the Features have points in?

    - use initiatives for this type of planning further out, and be able to put points on them and count this against capacity. Right now we use Master Features, but these tend to multiply into many master features when we start breaking up the work into manageable Epics as we get closer (= Master Feature in our integration with Jira), so a Master-Feature-driven roadmap looks very front loaded.  The alternative is to have a flat structure of many Features when we break the work up, but this is hard to manage.