RELATED IDEAS
Master Releases - For sub releases add ability for dependencies and different release dates (for visualization on Gantt chart)
After a morning playing with master releases here some initial feedback.
1. It would be great to be able to have no release date for a sub-release. That way the Gannt doesn’t look like the attached screen-shot.
2. It would be nice to have dependencies between sub-releases.
Great start though for this feature.
-
ADMIN RESPONSEMar 19, 2016
Master releases are meant to be used to manage a suite of products that are released on the same date. They contain phases and milestones, along with sub-releases (which are releases at the product level).
For releases which do not have the same release date, we would not recommend using a master release. Master releases provide the most value for organizations which a component architecture and all components are released as part of a single overall product. This makes it easier to manage changing release dates automatically at the master level (without needing to do so for each sub-releases with the same release date).
© 2024 Aha! Labs Inc.•All rights reserved
Can you please then address my points about capacity below and how we should solve them?
+1 to different sub release dates. One alternative would be creating a regular release for the feature in question and linking it's features to the sub release features
As capacity is only defined/tracked at the release level (from what I can gather), currently the only way you have for dealing with capacity planning for a phase is to use the master/sub release hierarchy. It's entirely reasonable for a single release to have multiple phases that require their own capacity planning and progress reporting. Unfortunately doing it this way renders the burn down charts and progress updates useless because the release date is used to estimate the average burn down. So while master releases may have been intended to support the purposes you allude to, it's not necessarily how customers are currently using aha and that is to in order to get around some other product limitations. This is a fairly significant issue for us at the moment.
Master releases exist to support multiple sub releases with the same release date. If your releases don't have the same release date then a master release is not necessary.
Master releases are designed to help organizations which have a component architecture and all components are released as part of a single overall product. The master release helps manage changing release dates by automatically keeping all sub releases with the same release date.
Our workflow matches the above. The assumption that sub-releases match the master release date does not match a multi-product release schedule. This should be a setting.
Sub releases need to have the flexibility to have independent dates within the Master release. In almost all projects these will be required to finish before the master release and the timeline should be associated with that timeframe.