RELATED IDEAS
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.
-
ADMIN RESPONSESep 30, 2019
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.
19
MERGED
Add release template after release is created
When releases are added in the features board, there is no option to add a template. Once you go into the release view, there is no option to THEN apply a release template. It would be great to be able to put in releases as "place holders" and lat...
0
Shipped
21
MERGED
22
MERGED
change template for existing (placeholder) release
Once a Release has been created, there's no way to apply a template or change the Release to copy another Release. That makes us hesitant to create a Release until we know pretty well what's going to go into it, when other Aha! tools suggest that ...
0
Shipped
Fantastic! This idea is now live. ⭐️
Julie: I like your suggestion to have two options for how to handle release phases.
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.
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).
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
Thoughts?
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.
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.
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
or
2) Add new template in addition to existing template
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
or
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).
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?
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:
Anything currently in the release would remain as-is, such as any phases and milestones you added previously
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!
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.
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.
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:
Thanks!!
The workaround also causes problems when existing releases and features have been synched to JIRA.
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.
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.
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.
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.
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.