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|
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.
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.
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).
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.
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.
is there a way we can prioritize this idea please - this would be very helpful for our high level demand / capacity management.
We need this on both master features and initiatives.
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!
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.
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.
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.
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 :-)
We desperately need this.
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.
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.
Or allow this on initiatives, as the only reason we considered master features was to get this costing functionality.