Add a configuration on how dates are handled between parent and child records.

I am so excited to have this back!! Thank you so much!

The product team for my company strongly relied on the automated ability to link the initiative and master feature dates based off the features.

I know everyone I've talked to at my company (so far about 20 people,and I expect this has impacted hundreds for us)

I already spend upwards of 5hrs a week updating and moving features around to keep the feature forecasts accurate, and loosing the ability for the parent cards to automatically adjust to this has just killed me.

We utilize the feature dates for higher-level reporting at the master feature and initiative level, and needing to manually update these dates on top of the features takes so many hours of work.

It's frustrating, aggravating, and very easy to mess up.

I'm told by support that I must make all my roadmaps at a feature-level in order to show timelines for capabilities, initiatives, and goals.

It absolutely baffles me that this seems like a good fix since we really don't want or need this level of detail for a lot of audiences. And the main purpose of Aha for us is to plan and report expected work.

Yet we've made it entirely difficult, bordering impossible, to view work at a high level.

The change to decouple these was a bit of a surprise for us, as we thought the whole point of Initiatives being linked to releases was that the the start date of the earliest release and the end date of the latest release effectively dimensioned the start and end of the initiative that those releases contribute to. So having to manually sync between initiatives and releases is going to be a massive manual overhead. I suspect this will be the case for any org with a non-trivial number of initiatives and release.

It gets even more complex if you have releases that contribute to multiple initiatives, as this means you have to remember and manually examine what is connected to what when setting the initiative duration.

In our business this also helps make clear the impact on the overall org initiatives of dates slipping in a release - showing the knock-on effect. Otherwise this will be hidden if they aren't in sync.

Definitely support the idea of making it optional to couple/decouple the dates, this would support both the need for ad-hoc and more formal planning.

The ability to digest changes from Jira in this way would be super powerful for our product management. Similar to Michael's suggestion below; having a way of being notified of how Jira changes have impacted master features and initiatives and then accepting the dates to the parent, or equally manage the impact across the teams. 

I agree. I think this would also be essential when you work on the Project type workspace. 

I would see a feature where you could see the baseline and then you could accept to change the dates. I am using JIRA integration for several initiatives at the same time, linked to several schedule. Driving the dates automatically is essential to allow the visualization of the impact of an activity/feature delay or reprioritization.

It would also allow me to have a dynamic view of the "actual' release date of each initiative in the reporting section.