RELATED IDEAS
Initiative dates should be based on linked features, not releases
We have weekly releases, so adding Initiatives and Goals to releases is too much overhead. As a result, I can't use the "Set Automatically" option for Start and End dates on Initiatives, since it's based on the individual linked releases for that Initiative. So, I don't have any usable timeline views for Initiatives, unless I manually adjust the dates, which is also not something I have time to manage.
But as a solution, I do consistently link Features to Initiatives (side note: we renamed Initiatives to "Epics" and use the Product Line Initiative as our "Initiative" level). When building Epic/Initiative timelines, I want dates to be based on when the underlying *Features* are being developed (ie. their respective release time frames). For long term planning, I'd rather drop a placeholder Feature in a future release than have to manipulate the Initiatives on every release and keep this updated over time, particularly since this value is not as visible to the user. When release plans change it normally means I'm just moving features, not updating release details. This is too much to maintain - Features are the center of our roadmap universe, and I'd rather timelines be driven by them.
| Release time frame | 1 month |
-
ADMIN RESPONSEJul 1, 2020
Just Launched! — Automatically Calculate Release Dates for Large Projects
Now you can automatically calculate when records in Aha! will start and end based on the date range of related work.
1
MERGED
Drive initiative dates by contained requirements rather than releases
I would like the Initiative start and end date be driven by the underlying master features and features rather than the releases that contains the MF/F.
Today if a development team moves a MF/F from one release to another, we need to manually upda...
0
Shipped
© 2024 Aha! Labs Inc.•All rights reserved
Even 3+ years later I strongly disagree with the Admin Response and fully agree with the user posts. Link features to an initiative, then derive the initiative timeline from the releases in which the features are scheduled. Fundamentally, initiatives are fulfilled by a collection of features - NOT releases. You've missed the whole point, Aha! and could take your automation to the next level, providing real value to roadmapping.
I agree with both comments above. This is getting unmanageable. I do not understand the value that Aha adds with initiatives if we are unable to roll-up features status, or start date or % complete (based on story points calculation). I wanted to remove this manual tracking in the first place. Jira Portfolio does this beautifully.
This is also a key issue for my team. We have a large roadmap and set of initiatives. Initiatives are driven by delivery of key features and to be able to best represent initiative progress the Initiative roadmap is a key tool. Having to manually adjust the roadmap as we move features between releases means we need to maintain a manual mental connection. This is prone to error. This is a key feature to making the Initiative roadmap a powerful tool.
This is unmanageable to have to keep release Initiatives up to date with the features in that release just to get a basic timeline view of how long an initiative will be in development. I'm not sure what value the release Initiatives provide when you can link Initiatives to the underlying features - they should roll up to the release automatically to avoid duplicate data entry.