Innovate capacity planning and release planning - plan features to multiple releases

I can understand this. Your response has reached me (my bad) just now and that is after I have proposed this model using master features myself.

BUT: The trouble is not when you can upfront decide and plan, that a master feature will have to have three features that will be planned into release A, B and C, and MF remains in release F when it is delivered.

The trouble is that when you plan a feature into release R1 with capacity C1, it is not a super rare situation when after execution of that release (when collecting data from requirements as "work done" and "remaining effort"), the original estimate of the feature F1 being FOE <= C1, you end up with remaining estimate having FOE <= C1 < ROE. That when release is being wrapped up and next release R2 is being planned, you have to either

1) move feature F1 to release R2, which aha ALLOWS. But if you do that, tracked workload data like original estimate, remaining estimate and work done are not anymore tracked in R1 and R1 capacity evaluation is thus damaged and retrospective information is destroyed. Thus eliminating chance to look at several releases back and learn from past mistakes. Thus not exactly contributing to ability to "inspect and adapt". Thus effectively making life of AHA evangelists like me a bit complicated when I have to justify to agile coaches, scrum masters and others that "it does not matter".

or 2) after having to admin that this actually "matters". I need to keep feature F1 in release R1 so that I do not destroy R1 capacity tracking quality. I have to create feature F2 in Release R2 by copying and asigning new original estimate (which is fine, based on learning a bit by delivering F1 we can even use this opportunity to have better estimate for the leftover work on originally planned F1). But what about status of feature F1? I can not exactly keep it as "Shipped" if it was not actually deployed and I need to adjust feature workflow and add status "Unfinished" or "To be continued, stay tuned". OR I actually can put it into "Shipped" if the feature was indeed representing some kind of value and was indeed deployed as partial original scope of F1. Argument that I should have created F1 into R1 and F2 into R2 in first place when planning R1, is IMHO not valid.. as you simply might not know at that point and you might believe that F1 is the only F as F1OE<=C1. This is actually the "method" I have to be using.. but again .. some people using AHA are not so fond of thinking in letters and acronyms when I am explaining these concepts and they do not get it.. some agile coaches and senior managers coming from PM background say "if only we had simple gant chart.. so much manual work saved" .. again, "or 2" is solving the problem, but it is not helping to get me to a place where the whole company considers aha as "golden source" for product management and that makes me frustrated to a point that I get to a keyboard on Friday/Saturday at half past midnight after hard work week and write this comment with headache and impaired vision. Not mentioning work-life balance disruption caused by all these things when I try to go extra megamile with AHA evangelism...

So summary
1) capacity planning works well (at least for "time"..)
2) capacity tracking works semi-well (some issues with JIRA 2.0 integrations are making my journey to full aha adoption company wide a little bumpy...)
3) capacity review and closure of the release is lacking full feature journey design in its core and even promotes exploting the absence of solution by allowing easy drag and drop moves of F1 from R1 to R2. We have also case where such a feature goes to R3. And can get lost in parking lot for a while. Multiply this problem by 10+ products, 20+ product owners/managers, 45+ (normal ratio in our perfect agile world) of other managers and project-minded people, and ...

yes.. I understand, that I can use master feature.. and now I have to. But I hope I managed to demonstrate that design of capacity management is not complete and implemented in a usable way in "normal" scenarious when someone has real ambition to use it in enterprise environments with multiple business domains and IT components, multiple teams dislocated into multiple IT offices accross regions and continents.

P.S. I am sorry if I overstepped here a little and somewhere been less than "politically correct". But I am doing my best to make it all work and can not get my head around these things yet (after 2 years of gradually using aha more and more...)

P.S. 2 - as always.. thanks for your loveable product. It makes me happy. But sometimes I feel pain too :-).