In my organization we need to sync features and releases in Aha to two different Jira projects.
One project receives 100% of the features and releases - perfect 1:1 sync.
But the other project is only for features that rely on the design team. So we only sync a subset of features to this Jira connector.
We have observed that if I create a release that is unsynced, fill it with unlinked features, and sync the release... then the release is synced as are all of the child features.
This is a great time-saver for sure.
However, this results in features getting synced to the Design Project in Jira that we don't want to.
The idea is this:
When a release sync is triggered, surface a modal dialog that asks, "do you want to sync all features as well? [Yes] [No]
Thank you for your idea. One suggestion that could help to improve this workflow would be to use bulk edit to send features to your design team. This would allow you to select all the features you need to send and send them all at once.
Sending the features rather than the release will give you more control over which features are sent to the design team's project.
Given the option above and historical feedback in this area, we are unlikely to implement this idea at this time. We hope you can understand.
Here is the primary challenge - there are 30+ product managers all using Aha on a regular basis. They will receive training on how to use the tool properly, and 95% of the time, the tool does exactly what you want it to when you sync a release or a feature.
We will soon be rolling out a new process which will require all PMs to begin syncing their releases to Jira. There are over 100+ releases across all of these projects that will be impacted. When we sync the release, all the features will be synced as well, which will create a large headache for the design team who will need to go through and remove jira tickets created by Aha that are not relevant to them (remember - we don't want to sync features into our design projects in Jira unless a UX resource is required for the corresponding feature).
The only way to avoid this that I can see is as follows:
Create a new and empty release (effectively a copy of a release you want to sync into Jira).
Sync the empty release.
Move the features in the original release to the newly created release.
Delete the old release.
Then manually sync features as needed.
We are prepared to take on this work to make this transition to a new process successful. However, in the future I see a high likelihood that PMs will forget about the order of operations.... maybe forget to sync a release entirely. Then they fill the release with features, and realize at the last minute, "oops, I forgot to sync the release." Then they sync, and all the features get synced, a ton of emails get fired off by Jira, and now we find ourselves having to manually delete jira tickets again.
To resolve this problem training will be super important. But I know from experience that despite our best efforts, PMs will not reliable execute the process.
Having at least a warning that says, "you about to sync 30 features to this project and this project, are you sure you want to do this?" will at least give PMs pause before they proceed and perhaps remind them that they should proceed carefully.
Thanks Byrne. I can see the issue you are running into. Can you share a bit more background on the use case for sending just the release? I know this does not completely solve the issue, but one option would be to select a single feature and send that in these cases. This will also send the release, but not the other features.
I would like to point out however that your current implementation has a logical discontinuity. One hand your syncing logic clearly is built around the idea: "we only sync what you explicitly tell us to sync." But in this one instance, you break that model and say, "but here we will sync everything for you, whether you want us to or not."
I get the rationale. I really do - customers want the convenience of syncing a whole release in one fell swoop. But in making this exception, you break the logical model/contract all the other syncing features clearly reflect.
This is just my 0.02.
Again, the problem is NOT that I can't sync features, or selectively sync features. I know how to do that. The problem is that when I sync a release, ALL the features get synced when that is not my intent. Nor is it ever made clear to me that this will happen.
An alternative would be to issue a warning, e.g. "By syncing this release, you will also sync 13 features via the Integration Name connector." That would at least give me the choice to cancel before making a mistake that is difficult to fix after it has been done.