Yes, the current mapping is not enough, we need more granularity. for example, when a idea is converted to a feature that does not mean that it is in progress, i need to leave the idea status as is, until work actually starts.
Yes, +1 on this! As we're using this more and more and seeing the value of the ideas portal, this is huge. A classic example for us is something like "Reviewed and Waiting". This is an important piece of the communication loop back to the original requesters. Thanks to the Aha! team for considering this for future implementation.
Going to throw another comment at this. The idea status updates driven by the feature status updates as currently implemented are not nearly as useful as they could be. To communicate with idea submitters effectively, we need to be able to map the updates from features to ideas.
This is one of the main impediments to using the Ideas Portal for us. Nobody knows where their ideas are, and it's too much for the POs to keep the features and ideas lists in sync.
+1 I would really like to encourage my "idea community" to go in an test on our DEV/QA regions when something is ready... I'd like it to follow the same model as a feature (+ Will not implement).
Agree this would be a very useful feature for the system.
This is one I think would be a nice easy one to address provide big value to product managers and customers. We need to take the manual work out of this process by allowing more mappings to keep our customers updated.
Are we asking for this improvement since 2014 ?
Wow, I really can't believe this isn't already a thing! I'm not being grumpy, I just assumed it would be a must-have experience of tying an idea to a feature. I wonder, does the Aha! team manually update the status of an idea in this big ideas forum when, for example, it changes from "Likely to implement" to "Planned" or from "Planned" to "Shipped"?
Totally agree that this would be of tremendous value both as a communication mechanism and as a major time save for not having to manually update idea status based on what is happening with the feature.
It is worth noting that idea statuses do update automatically based on feature status to a limited degree. This is described here: http://support.aha.io/hc/en-us/articles/206688256-How-feature-status-drives-idea-status
This idea is still relevant, but I wanted to point out the existing functionality since some of the comments here imply there is no relationship between idea status and feature status.
Chris. Understood that there are some relationships (well 2 anyway) that drive idea status relative to a feature. That is very useful. It would be much more useful of there were more. It’s actually surprising that there isn’t given that there are 4 status categories and only 2 of them (In Progress and Done) relate to any automated status change action. It’s unclear what if anything the other 2 status categories (Already exists and Will not do) are used for.
Thanks for the update Chris. I'll echo Jeremy & David's comments that while the ability to automatically trigger "planned" and "done" is there, it doesn't really map to our usage. When we promote an idea to feature, it just means it's valid and in the backlog where we can prioritize against other features. It still make take weeks or months to be committed. It would be good to be able to update stakeholders when it is approved, planned, then actually in development, Anyway, we've moved on and aren't using the ideas portal to update stakeholders, but just wanted to pass the feedback along. If we had this, it would get more usage.
Now that I have voted on this and brought the total count of to 75, let's get moving on it. :)
This is an important capability for us to fully utilize the Ideas portal status within our workflow.
In an organization with 1000 SE submitting idea you cannot live without this feature.
I'm glad that I'm not the only one to see the improvement! We can make the Ideas Portal a better aligned with flexible linkages to promoted features. Definitely +1! Thanks!
We desparately need this idea to be implemented. In our flows we need to make sure an idea submitter realizes that the feature has been abandonned/will not do.
Totally agree with this ! This also has a huge influence on JIRA -> features integration. I want to only show my idea in progress AFTER a JIRA story development starts. With the current Aha design this is not possible. Moving an idea to a feature automatically marks that as 'in progress'. (I created another status to avoid this).
When is this item going to be released?
In the default workflows, once an idea is promoted to a feature, its status changed to "planned" , but on the feature workflow at this time, it's not really assess and there is a chance that it will be determined to not implement this feature, so the status of the feature can be set to "will not implement". At this pint the idea status is NOT changed, and it keeps dangling in the "planned"status.
Therefore this enhancement request makes a lot of sense, because
I ditto the necessity to have this functionality. This is a manual hole in the process of Idea/Feature synchronization and knowledge. Please add this to your next release.
It is upsetting this was submitted nearly 3 years ago, but has not been implemented yet.
As with other posters, when an idea is pushed to a Feature, it doesn't mean that it is in progress. We need more status updates since the majority of our stakeholders will only be accessing the Ideas portal. Without more status updates, we will be tasked with more reporting to keep individuals updated on their ideas they submitted.
+1 too.. need to be able to better sync status between ideas and features, so the idea has an accurate representation of current status.. Accepted, is fine, but I want to be able to update when the idea is scheduled for release and also once development starts...
What does 'planning to implement mean'? Is there a timescale for this yet?
Agree. As we expand the use of Aha and force more ideas and requests through the process this is a major gap. Ideas raisers are left wondering where their ideas are as there is a large gap between promotion to a feature and delivery
You won't be notified about changes to this idea.