RELATED IDEAS
Having flexibility around Release Dates being either inherited from Rollup release or manually populated
We rely on Rollup releases quite a bit, however, from team's Feature board perspective it's often helpful to track "product" releases info, especially dates and be able to expose those accordingly. At this point, since we're using Roll up releases product release dates is overwritten by the rollup release dates, which challenges our ability to be more agile in our planning/execution and get better alignment across stakeholders.
So, ability to control which dates are used for Internal Product release in particular is very important to us.
© 2024 Aha! Labs Inc.•All rights reserved
I agree with Steve and have some additional comments.
Aha! is promoting to use the Gantt chart to visualize how sub-releases related to each other and to their roll-up release. Even to the point that you can indicate with release depends on the other.
Following Steves third point, forcing the release dates to be identical to the roll-up release date makes no sense and makes it impossible to show the dependencies visually in the Gantt chart.
As an additional point: we are getting the actual release dates from Azure DevOps (target date). It would be ideal if that date could be synchronized with the Release end-date (while the Release start-date could be derived from the activated date in Azure DevOps). This way, we can let the target date be driven from our R&D team using Azure DevOps and monitor it in Aha!. But this implies that the roll-up release date would be set in Aha! as a deadline and reference point to check progress of all sub-releases. This last point affects the integration function, so I added another idea for that: A-I-16928
Completely agree with this idea.
There are a few additions I would make to this idea:
Roll-up releases need to be contributed to by releases from anywhere in the Aha! workspace hierarchy. It's too restrictive to say a roll-up release can only be contributed to by workspaces within that branch of the hierarchy. For example, the online team has its own strategy and therefore, hierarchy branch. The APIs team building a platform that can be consumed by any other part of the business have their own strategy and branch of the hierarchy. But the APIs team cannot contribute to a roll-up release run by Online. Why not?
Roll-up of dates need to be calculated by phases and features for sub-releases. This isn't possible because the roll-up release date acts as a milestone on the sub-release and always pushes the end date to be that of the roll-up release date (unless there's a phase or feature which extends beyond it). This gives an unrealistic view of the work in the sub-release.
As an extension of point 2, it's clear why the release dates function as they do today - the work of the sub-releases needs to be ready in time for the roll-up release to ship and so they should all be ready together. But forcing a date is not the way to solve this challenge. Sub-releases need visibility of but not forced compliance with the release date of the roll-up release. Perhaps showing the roll-up release date on the sub-release as a read-only field would help and/or making it optional for the roll-up release to force the date of the sub-release.
From my experience of Aha!, I suspect that not many organisations use roll-up releases and therefore, there isn't much feedback on how to improve them. I'd be interested in what the data shows.