I have a Aha to JIRA integration set up which allows me to prioritise features in Aha by a combination of Rank and Score. We frequently re-prioritise cards in Aha (therefore changing the rank) but this doesn't trigger an update in JIRA. I rarely change the Score, as I don't wanted to use this to manipulate any change in priority.
I have been trialing Aha for my company over the last year, and have recently managed to convince the company of the benefits of Aha as a product management tool and to adopt for all our product teams across the globe. However, this is my number one gripe with Aha and the lack of support for triggering updates to JIRA (which all our dev teams use) is perceived as a problem.
This was raised under support request #312749 and was told that this could 'create a lot of traffic' with regards to JIRA updates. Well, I'm creating that 'traffic' today, and the only problem its causing is that I have to remember to 'resend all fields' for all cards below the card I've re-prioritised. Not a great use experience and one that causes confusion.
Also - there is a bug where the ‘history’ on the feature isn’t updated when the ranking changes for cards that aren’t moved.
Mapping an Aha release to a JIRA release is not an option for me, as these are 4 weekly releases, and I don’t want to map Aha features into 4 week windows.
I could really do with Aha supporting the ability to resend an updated priority to JIRA whenever a card priority changed.
Thank you for the idea. Currently, you can save the priority of features from the prioritization view to a custom field — then send the rank directly to your dev tool via an integration. This will allow you to have unique ranks for each feature, while the rank determined by the placement in a release can lead you to have multiple features with the same rank. Additionally, automatically updating the order in Jira when a feature is reordered within an Aha! release could unintentionally send a large number of Jira notifications without a user knowing.
Given the capability above for syncing rank from the prioritization view, we are unlikely to implement this idea. We hope you can understand.
I'm sad to see this one being rejected. The prioritisation view is not a solution for me, so I'm left having to remember to manually resync an entire release (which can be quite large) every time I change the order within it. Not good UX.
This issue causes a significant amount of stress during sprint planning. The team reviews the ranked priorities in JIRA but if something needs to get kicked out, they can't tell which of the three epics ranked 4 from Aha is truly the lowest priority. This needs to be resolved.
Yes, we really need this to keep engineering aligned with PM. And the funny thing is that the Rank does change for both of them (let's say 24 and 25), but only the one that you move yourself (25 to 24) gets updated in Jira, which leads to two epics with Rank 24.
Same here. The last comment from Kevin was nearly 7 months ago. Any updates or ETA to address this?
I have a similar issue. I'm using the Rank order in Aha! to guide the Dev team on priority. The Dev team view this through the Rank property in JIRA, so if Rank does not get updated in JIRA then Dev are working from incorrect information.
In my particular case I have Aha! configured to require all integration updates to be manually pushed through, so in that scenario I would expect the integration updates window to show me an entry for each of the Features that has had their Rank changed, even if it's an implicit change due to changing the Rank of something else.
agreed - can't believe there isn't a louder chorus on this one.. seemingly minor but causing huge headaches
as far as "creating traffic" it doesn't seem like the right solution to disregard features whose rank was update by virtue of getting bumped by other features added above them.
what "problem" are we trying to solve, anyway? (Product Management 101 to follow)
if the goal is to reduce traffic between Aha! and JIRA (or VSTS or whatever), then sure, simply NOT syncing this field is a great solution. However, the goal is to manage a product roadmap and for that we need the rank to be updated for the integration if it changes (regardless of how it came to be changed). Otherwise, what good is that field if it can't be trusted? So the current solution is obviously not acceptable.
One solution: always and immediately sync ever feature every time the rank is updated.
Alternate solution: buffer for a few minutes and then sync the updated rank for any feature whose rank hasn't changed in, let's say, 5 minutes. This keeps everything in sync and doesn't produce any additional traffic while you shuffle things around.. probably less traffic than would would be produced by the suggested workaround (resend all fields for each feature individually), not to mention less error prone