RELATED IDEAS
This idea has been merged into another idea. To comment or vote on this idea, please visit APP-I-1092 As a developer, when I change a story's epic / fix version (i.e. Aha! feature / release) I want that change reflected in Aha! so that my Product Manager will know that a story or bug was pushed out to the next release.
When moving a JIRA issue from a linked fixVersion to another linked fixVersion, update Aha!'s release
Merged
In the mapping:
Feature -> User Story
If you create a new user story in a fixVersion that's linked to an Aha! release, Aha! reflects a new feature. If you move a user story from one linked fixVersion to another linked fixVersion it is not changed in Aha!
In the case where a development team determines they cannot finish a user story and need to move it out, this is problematic. When the Product manager ships that release, the unfinished features will be moved to another release of their choosing. It can cause confusion when the user stories they agreed belonged in a different fixVersion suddenly show up in another fixVersion (or on their Sprint board).
Dear Suzanne. I strongly agree with Cameron. How the planning process has been integrated within the organisation should not be enforced by the tool using a topdown approach as for instance our development process does not work that way. And a 2-way synchronisation of FixVersion vs. Release is a crucial technical requirement as the tools should never get out of sync on the most important data field for the planning as this leads to the complete mess.
For what it’s worth, we’ve been using Jira as our de-facto release management tool for years and only started using Aha! over the past couple of months, so it’s quite a paradigm shift for us to universally adjust our workflow where Aha! is the system of record for creating/managing product releases.
Overall, I think the tool is great, but this lack of synchronization is a detriment to our adoption.
Regardless of process, or the rightness/wrongness of development changing the release -- the bottom line is that Aha is getting out of sync with JIRA -- which is creating more work for me, instead of reducing my workload. Aside from that, since each sprint is supposed to result in shippable product, there just aren't that many times that a 'market release' spans multiple sprints. I appreciate your attempt to make lemonaid here, but if Aha can be out of sync with JIRA, it can't be trusted.
We recommend that when creating a release in Aha! you consider the market release, which is almost always comprised of multiple sprints. Send the entire release over to your development tool of choice and give the development team the flexibility to decide which sprint it belongs in -- and to move it out to another sprint. The main focus is that it's done by the time the market release is ready. And if it's not, this type of change should be part of the product management teams' domain in conjunction with engineering and so it should be moved in Aha! If you shift the approach I think you'll find both teams work together well and can handle shifts in schedule more easily.
This is absolutely killing my ability to productively use Aha!. Our QA team routinely moves stories to different releases -- right or wrong, its just the way it is. Seriously, I've all but given up on tracking stories in Aha -- we are mostly using the Idea portal right now.