Skip to Main Content

Share your product feedback

108 VOTE
Status Shipped
Created by Guest
Created on Jul 27, 2017

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.

Release time frame 6 months
  • ADMIN RESPONSE
    Jul 12, 2023

    Release capacity can be updated to use features only, epics only, or both.

    Additionally, you can set which estimates are referenced in the visualization.

  • Attach files
  • Jean Miller
    Reply
    |
    Jul 13, 2023

    Hi Was anything actually released yesterday?

    Because to be honest, what you show already existed few months back, and it simply does not cover the expectations of the merged idea. As it is now, the Epic board is just not really usable in a convenient way: It does not have a capacity gauge: You could indeed, as you show, configure the gauge to display epics only... But you then need to go check the gauge on the Features board, while your cards are actually on the epic board,... I mean, it's quite clear that this is not really work-able unless you make the gauge visible on the epics board; right ?

    So basically: I need one gauge bar on the epic boards (showing epics estimates by default) and another gauge on the features board (showing by default the features estimates)... Sounds quite intuitive and reasonable, doesn't it ? :)

    Or you know what: Even smarter: A gauge bar that shows you both the epic & feature estimates at once, so you can actually compare them visually; because that's a super interesting comparison and you do have all the data readily available...

    1 reply
  • Ronit Binshtok
    Reply
    |
    Mar 28, 2023

    It would be really nice to have same functionality we have in features board, also in master features (epics) board - I would change the visual configuration we have today for a release to fit if we are configuring it under the feature board or under the epic board - this should provide progress bar and red line (capacity limit) also in epics board.

  • Jean Miller
    Reply
    |
    Mar 13, 2023

    Hi ! Just wanted to mention that I fully support the Merged idea of adding the "capacity/effort gauge" also on the 'master feature/epic' view. This is to me the missing link for enabling proper capability to switch between the mid-long term roadmap view, and the short-term refined planning.

  • Guest
    Reply
    |
    Jan 13, 2023

    Have followed a similar process at multiple companies and this would be such a huge improvement.

    It really makes sense to be able to do capacity planning at the Epic/Master Feature level to get initial pass of roadmap feasibility before an investment is broken down into more granular Features.

    Cannot vote for this enough.

  • Guest
    Reply
    |
    Mar 3, 2022

    Our use case is similar. We have one platform / product with 3 scrum teams. We use a single backlog and plan releases based on the aggregate capacity of all teams. The PM team works at the Epic level, defining inital estimates that are used for long term release planning (that fit within the release capacity). The Epics are not broken down to stories / feature cards until we approach the development timeline for that release. Given the current functionality, we would be using Features in Aha as our Epics in Jira. This is just confusing for those that are translating between the two systems (PMs and Engineers). For us, epics are not "too big" to complete in one release and we'd like to be able to use Epic records in capacity planning (for individiuals).

  • Sébastien Lievain
    Reply
    |
    Apr 5, 2021

    Building a product still in its early days, we often sign Clients which require complementary developments. It is a win-win situation where we can finance part of our strategic roadmap. Capacity planning is essential for us to meet our commitments. This is usually/always done before breaking down developments to stories thus our DESPERATE need to have capacity planning at Master Feature.

  • Mia McCroskey
    Reply
    |
    Feb 17, 2021

    I'll echo many others. We plan team releases based on features that we need to deliver. While each team prepares its own release, they often release related stories at the same time. That program/product level view is as important as the team-level view. Knowing the overall capacity of all teams involved in the release, and the overall required effort, is important.

  • Guest
    Reply
    |
    Jan 31, 2020

    is there a way we can prioritize this idea please - this would be very helpful for our high level demand / capacity management.

  • Shri Iyer
    Reply
    |
    Nov 12, 2019

    We need this on both master features and initiatives.

  • Guest
    Reply
    |
    Sep 4, 2019

    Reducing remaining capacity by using effort estimates at Master Feature would be extremely useful. We plan at the detail level by iteration so we know what we will push to Azure DevOps for engineering (push just ahead of the iteration starting ensuring the refinement has taken place already).  We plan 1Q in releases by iteration, then a 1Q ahead of that as a release for the Quarter, then a further 6 months ahead of that as a release also. The Master Feature is our Feature in Azure and then Aha! Features are added as the Stories in Azure. In this configuration the Master Feature needs to be able to show how much of the release capacity we are using and as most Master Features fit into an iteration that works at the iteration level and the Quarter ahead release. We understand the challenge that the Master Feature can span releases and therefore there needs to be a way of limiting the estimate to just reduce capacity against the release them Master Feature is added to - and also to determine if capacity is reduced by Feature or Master Feature but that flexibility of decision making ability would be great!

  • Mark Colbert
    Reply
    |
    Jun 23, 2019

    I'm hoping this is being considered soon.  Our company plans at the Master Feature / Epic level and without this, we are missing out on a major need.

  • Matthew Lynn
    Reply
    |
    Oct 30, 2018

    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.

     

  • Sam Richards
    Reply
    |
    Oct 12, 2018
    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.

  • Marc Robinson
    Reply
    |
    Oct 11, 2018

    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 :-)

  • Nate Dunlevy
    Reply
    |
    Sep 4, 2018

    We desperately need this.

  • Guest
    Reply
    |
    Aug 17, 2018

    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.

  • doug evans
    Reply
    |
    Jun 25, 2018

    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.

  • Angus Davis
    Reply
    |
    Sep 21, 2017

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

  • +11