Add Development Lead as a Role

We have been successfully using Aha! for some time, and as we've grown into multiple product teams and added product managers we've added contributors to our license. However, we are also finding the need to have the Dev team leads update statuses on requirements (and sometimes features). We're actually trying to move away from 3rd party tools to manage the development workload (letting each team self-organize and track/manage as they desire) and use Aha as the central tracker for customer-facing deliverables.  It would be great if Reviewer roles (or a new role) could update the status 

Hi Suzanne -- I've not used Rally myself, but my understanding is that it does not have Requirements... It has User Stories and Tasks, each of which can be hierarchical.  We have a fairly complicated product, and particularly there are many variations when it comes to desktop compatibility.  So a feature can be expressed as a capability, but many requirements exist around compatibility.  For example, we have browser plugins that work on 6 OSes and with 3 browsers; and when cross-compatible with Mobile, about a dozen more.  There is a "long tail" when it comes to valuable combinations, so we prioritize them as requirements, even though eventually want to support them all.  It would be incredibly messy to add each one as its own feature, especially since many are closed in waves.  Happy to discuss with you on the phone since this is getting pretty long for a comments thread, but the short answer is that there's no consistent way to define 1 feature in Aha that maps to 1 user story in Rally that won't screw up their burndown charts.  More here:

https://help.rallydev.com/manage-unfinished-work

Having requirements updated would not satisfy your need? We'd actually recommend that you create features within a release that are going to be completed in that release. If there's a "feature" that will take multiple releases, it typically belongs as an epic so that it can span multiple releases. Currently this means manually updating the progress, but we plan to add additional capabilities around reporting on this in the future.  

Hi Suzanne -- close, but not quite. :)  Engineering is using the timeboxed iterations, so it's common to have features partially complete in any given iteration. Unfortunately, Rally does not like incomplete User Stories, so their process of splitting, zeroing out effort, and copying items is quite arduous. To manage tasks and effort in Rally's preferred method requires breaking up Features into myriad chunks of "doable" content that often only satisfies one or two Requirements from an Aha perspective, which gives Engineering rational burndown charts and velocity planning, but disconnects from our feature planning.  So, ultimately, we have no one-to-one translation from Rally's item hierarchy to our original Features and Requirements.

Hi Matt -- It does clarify things. You are using one of the few systems for which we cannot create a two-way integration to allow for automatic updates to status. This is because Rally doesn't have a Webhook available. However, they are going to make one available and as soon as they do, we'll be able to work on adding the two-way integration. We are hoping this will be soon, but expect it to be this year. In the meantime, you could use Import capabilities to make this easier. You could export the feature ID, name and status from Rally and import into Aha! once a week. If you create a filtered list in Rally this should be relatively painless, although still requiring some manual effort. The idea state is for our integrations to provide the status updates because our permissioning requires Contributor roles to update status in Aha!

Hi Suzanne -- Engineering is using Rally, which has some nuances and doesn't support auto-updating, as far I as I last knew.  Rally relies on nested user stories to convey features, but from an effort management standpoint it gets painful in that system to manage and report on user stories that span multiple releases, because it defers in burndown charts and progress per release.  So, our goal is to leave the Dev processes entirely in Rally, and PM processes entirely in Aha.  Of course, progress still needs to be conveyed, but our Engineering division is overseas, so we're stuck with odd-hour meetings to coordinate which Rally User Stories and Tasks close which Aha Features and Requirements.  Ideally, the Engineering lead could log into Aha and update status or comment on only things that are "In Development" and not make any other changes.  Then we could eliminate a lot of back-and-forth via email or calls.  Does that help clarify the need?

Hi Matt -- if you're using an integrated development system then status will be updated automatically from that system. If your developers are working alongside product management in Aha!, they would need to be Contributors in order to edit features (although Reviewers can comment on features). You should reach out to support@aha.io to get some consultation on the best plan for you. We'd like to hear more about your specific use-case. Thanks!