Add a new idea Subscribe
Status Unlikely to implement
Created by Guest
Created on Jul 21, 2014

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.
image001.png
image001.png
Open full size
image001.png
  • ADMIN RESPONSE
    Mar 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).

  • Attach files
  • Guest
    Reply
    |     Apr 14, 2016

    Can you please then address my points about capacity below and how we should solve them?

  • Guest
    Reply
    |     Sep 1, 2015

    +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

  • Guest
    Reply
    |     Aug 6, 2015

    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.

  • Admin
    Chris Waters
    Reply
    |     Jul 29, 2015

    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.

  • Guest
    Reply
    |     Jul 29, 2015

    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.

  • Guest
    Reply
    |     May 22, 2015

    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.