Skip to Main Content
Status Future consideration
Categories Releases
Created by Olga Basman
Created on Aug 5, 2021

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.

  • Attach files
  • Steve Dagless
    Reply
    |
    Sep 28, 2023

    Completely agree with this idea.

    There are a few additions I would make to this idea:

    1. 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?

    2. 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.

    3. 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.