RELATED IDEAS
Lock Release and Features
Once we have created a release and scoped all the items into it, it would be helpful if we could "soft lock" the features in that release. A soft lock could be an option on each release with a toggle and a message. Once the toggle is ON and a new feature is attempting to be added to that release, the message appears. The feature can still be added on clicking OK to the message.
An example of the text might be "The scope of this release was agreed on the xx/xx/xxx - please raise a change request before adding this feature"
-
ADMIN RESPONSEJan 20, 2016
Currently contributors and product owners can move items into existing releases, while reviewers and viewers do not have these permissions. Leveraging user roles and permissions is one way to "lock" releases so that some users cannot make changes. Another potential workaround is to enforce this offline that once a release has been set to a certain status, that users are no longer allowed to add new features.
At this time, we do not have plans to make changes to the user permissions model based on feedback from the community and current priorities. We hope you can understand.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- +2
6
MERGED
Ability to lock feature board
Merged
We have a platform product and our team is organized based on function. This means that a product manager and a release manager would have the permissions in Aha! at the product level. Occasionally, release managers will accidentally move a featur...
0
Unlikely to implement
4
MERGED
3
MERGED
lock ordering of features in a release
Merged
i would like the ability to freeze the order of features in a release so no one can accidentally rerank the features. our planning process is all features are ranked by their scorecard and then our product line executive gets to manually adjust th...
0
Unlikely to implement
The ability for contributors and product owners to change 'locked' Releases defeats the purpose of locking them in the first place. This is a poor overall user experience and lack of functionality in several ways:
There is no way to track 'planned vs. actual' with any sense of confidence ("Here is what we planned/committed to deliver in Release X and here is where it was actually delivered.")
This is further compounded by the lack of ability to report on audit trails for changes made to fields on a record. We have no way to create a view/report that shows "Here are all of the changes made to Release field, who made them and when".
If committed releases can be changed arbitrarily without any checks and balances, what is the purpose of creating and communicating a roadmap in the first place?
The "locking" of a release helps to prevent any accidental movement of the features from and to the release, especially if you are scaling Aha across numerous contributors, teams, geos, etc. Any change (add, delete, move) to a feature should require an "unlock + comment/reason for the change". Enforcing it offline does not prevent accidental changes to the release scope especially if you want to scale Aha.
I would definitely like and use something like this. I can understand this not being a big problem for external products, but if you're levering aha to build internal infrastructure where the product speed is way quicker, this will be a great way to control how the release is being managed.
Thanks for the workaround\solution. Totally understand :) After all, we're all product managers. Have a great day!