Need the ability to apply an updated Release Template to an existing release

Currently, the Release Template for Phases and Milestones only applies to new releases created and there is no way to apply a Release Template to an existing release, or to update an existing release with a new/updated Release Template.  This would be extremely helpful, as we have created our release Road Map, but are still defining the Phases and Milestones for our processes.

  • cheryl fetchko
  • Mar 7 2016
  • Shipped
Release time frame
  • Sep 30, 2019

    Admin Response

    Thank you for the idea!

    It is now possible to apply a new release phase template to your existing releases from the menu in a release drawer.
    You can select between:

    • Add to existing: keep all existing phases and milestones and add the ones from the new template

    • Delete and replace existing: Delete all existing phases and milestones and replace with the ones from the new template.

  • Attach files
  • Guest commented
    May 26, 2016 17:58

    The workaround described here makes it difficult if not impossible to maintain tracking of status updates for releases, which we'd really like to have throughout the lifecycle of our projects to measure and improve on that lifecycle.

  • Guillaume Etorre commented
    October 19, 2016 13:03

    Feature is vey much necessary so that process and product people can work in the same timeframe.

  • Sharif Alvis commented
    February 18, 2017 17:32

    Agreed that this is an imperative feature. The lack of it severely decreases the ease-of-use of Aha!

  • Thomas Dhollander commented
    July 13, 2017 11:52

    We got started with Aha some time ago and defined quite some releases, that are synced to work in Jira. Our processes are maturing and we are planning to use different release phases / milestones. However, applying these to existing releases turns out to be impossible. It would already help a lot to get the ability to override the full schedule of the release. 

    Thanks for considering this

  • Tom G commented
    October 24, 2017 09:54

    This is the first 'issue' I've come across during my trial of the software. It makes modifying/testing release template changes very painful. I have to remove all features from a release, delete the release, make a new one and put all the same features back in.

  • Ellen Sutton commented
    February 27, 2018 18:02

    Agreed. This is def a pain point for myself as well.  Especially since I sync my releases with Aha, generating Versions.  So to do this workaround, I have to create a new release, sync with JIRA, move features over, delete the other version in JIRA, make sure all the JIRA tickets also move over to the new Version.  All the while trying to not confuse the dev team working off things in JIRA.

  • Julie Edwards commented
    March 06, 2018 14:48

    The workaround is not suitable.  If you follow this workaround, you also need to recreate Comments assigned at the Release level via Copy/Paste. re-add attachments, re-populate release fields etc. which is cumbersome and ultimately impacts the credibility of the audit trail of Comments.


    It would be far better to be able to update a release template and have the choice as to whether the updated template is cascaded to existing in-flight releases or just applicable to new releases.

  • Julie Edwards commented
    March 23, 2018 12:08

    Another reason why this workaround is unsuitable is that where Aha is integrated with JIRA, this will mess up the integration as the JIRA elements will continue pointing to the "original" Release - so everything would also need to be Sent over to JIRA again and remapped.

  • A Hill commented
    September 29, 2018 01:43

    This workaround does not work as we create multiple linkages prior to a parking lot becoming a release.  We use aha to simplify our workflow and eliminate a lot of busy work.  This makes things much more complicated.  Also, we are now seeing the possibility of two different templates (major vs minor releases) and the ability to swap them out would be tremendous. 

  • Julie Edwards commented
    October 01, 2018 15:42

    The workaround also causes problems when existing releases and features have been synched to JIRA. 

  • Sherri Netherby-Cox commented
    November 07, 2018 22:25

    Need this capability most urgently.  My users are not happy with the workaround I have for this item.  Our releases are basically populated with bogus dates in order to have the phases and milestones that we EVENTUALLY need - I am pasting the support ticket that I filed today (11/7/18)   below:

    Hi There,
    I have been trying to figure out how to accommodate my team’s request to simplify our current release template until the release has been approved and committed to by teams that track their work outside Aha.   Please see the attachment named  “current_release_template.png”    Please note the text in red in that particular image. 
    Currently, when a release is created, the full release template is pulled in.  Initially, any dates contained in the phases and milestones from the Design Phase through the Transition Review Gate are completely bogus.   A release may sit in this state for a couple of months or more.  As a part of the Strategy Review Gate milestone, the viability of the project is confirmed, and only then do those dates become real and get changed to the appropriate entries.
    This causes many issues with my team and the use of Aha as my team is only in control of the phases and milestones shown in the “simplified_template.png” .    My team doesn’t take the rest of the dates seriously, as they should not, until the Strategy Review Gate milestone has been satisfied.  Human nature being what it is – and they are busy folks – they don’t always take the time to note whether or not a release has passed through that gate,  so I get the complaint “None of the dates in Aha are right !” and “Why do we need dates in Aha that are completely fabricated?”. 
    And now for my support question.   Is there a way to use multiple release templates in a single release?   My team really likes the one shown in “simplified_template.png” for a couple of reasons.  The first is that there is an immediate recognition of where a proposed release is at, less noise in Aha, greater confidence in the release schedule and so on.   And once the release is “real” we would then want to add the rest of the phases and milestones shown in between the red lines in  “current_release_template.png”
    If I cannot use multiple release templates in a single release, I am hoping for a suggestion as to how I should handle this in Aha.  Unfortunately this isn’t something that can be handled via a feature.  We do not have traditional features like a development org would – we offer user training.  Our features are used to denote delivery method and NOT the actual course content.   There are 10 ways of delivering each course – we almost never select all 10 ways, but if we did then there would be 10 Stock “features” attached to the release.  Ie Cisco Teaches Me v1.0 – Instructor Led  would be a “feature”.
    Hopefully this all makes sense.   If not please reach out to me and I will gladly hop on a call and explain further.

  • Rob Allen commented
    11 Apr 14:18

    This is a very important improvement request. It's essential if you have a high volume of releases. For example: I will import or mass load planned releases for the full year (upward of 100 releases). So they can be made visible to the product teams. We need to be able to amend release phases (and their attributes) and push the update through to all planned releases that haven't started. And potentially releases that have started but not shipped.

  • Carlene Nicol commented
    16 May 05:31

    With any Jira integration, it makes the workaround difficult. I have to add a new release and spend time with PO to make sure Jira matches. Very time consuming.

  • Admin
    Julie Price commented
    20 Aug 18:17

    Hi! I'm Julie from the Aha! product team. We are considering a possible solution that I wanted to run by all of you first.

    You would be able to add a release phase template to an existing release. The following would occur:

    1. Anything currently in the release would remain as-is, such as any phases and milestones you added previously

    2. The phases and milestones configured for the new template would be added to your existing release

    This would ensure that you have the opportunity to update your release phases and milestones as you see fit.

    Looking forward to your feedback!

  • Emma Hatto commented
    21 Aug 08:26

    Hi Julie, Couldn't you give both options when adding the template? One to overwrite, which would remove the old template and replace with the one added and one to update which would leave the release as is and allow users to add to that? I can see where both would be required and if we only have the ability to add to the existing release, you'd still have to manually delete all the previous stuff if you did need to add in a new template. An example could be where the tier of a release changes due to change control so your release activities change completely?

  • Julie Edwards commented
    22 Aug 12:36

    Hi Julie,  I agree with Emma - it would be preferable to have the choice whether to:

    1) Remove existing template completely and replace with new template


    2) Add new template in addition to existing template


    The reason for 1) is that we create our releases quite far ahead and assign the current template at point of creation; as we fairly frequently update our release template, the use case is to ensure we are using the latest template when it comes to work on that release.  (NB.  Storing these releases in the parking lot doesn't align with how we work).

  • Dan Jeffery commented
    27 Aug 08:49

    We have the same way of working as Julie decribes above, so I support the request she has made for the choice of either

    1) Remove existing template completely and replace with new template


    2) Add new template in addition to existing template

  • Admin
    Julie Price commented
    30 Aug 14:38

    Thank you for your feedback! I agree that both options would be ideal. I will work with our engineers to see what we can do to support each case.

  • Matthew Monahan commented
    30 Aug 19:30

    I also concur that both options (replace or add) for applying the new release template would be valuable.  Julie, how do you envision phase dependencies working?  For example, if I have two phases (build, test) with test dependent on build and both of them two weeks long, then I apply a new template which also has phases build and test (but each are three weeks long).  It seems that the dependency mapping would be confused with which "build" phase is the dependency of a "test" phase.  For this reason, I think it will be more logical to implement the new template as a replacement for the existing phases.

  • Admin
    Julie Price commented
    30 Aug 21:11

    Thanks for sharing your feedback, Matthew!

    I would envision:

    • Add to existing: This would add the phases and milestones from the new template in addition to what you already have. You could then decide which ones to keep and set dependencies going forward.

    • Replace: This would remove all existing phases and milestones and add the new template instead, starting from scratch. You would need to then create new dependencies as needed


  • Daniel Dolinov commented
    17 Sep 12:32

    Having the options to either replace an existing release with a brand new template or to add the phases of a new template to an existing release would be great (replacement makes more sense to me, but we don't have JIRA integration going yet).

  • Jörg Kortmann commented
    25 Sep 09:17

    I also fully support this feature request (for some reason I don't seem to be able to vote this time...). You should see the release template functionality also as a means to propagate changes to releases "top down" similar to the way lower-level products (below product lines) inherit templates defined on the higher level. This would make structural changes to releases easier which are inevitable - you come up with new learnings and want to update structures but if every change means you have to go back to every release just because you didn't think of it in the very beginning it simply slows down innovation in your product development process.

  • Matthew Monahan commented
    30 Sep 15:20

    Julie: I like your suggestion to have two options for how to handle release phases.

  • Admin
    Julie Price commented
    30 Sep 20:47

    Fantastic! This idea is now live. ⭐️