Set a default progress calculation

This would be of great use. We have integrations tied to JIRA so already use the estimate and log work feature and we want AHA to be able to show progress effectively off of this. While aha does this we have to manually change every single feature and epic that comes across the integration. This is becoming a hassle when you have thousands of features and epics across an entire IT organization coming into aha. There has to be a way to change the default of manual to a different option when tickets come in. PLEASE PLEASE PLEASE move this to development so you can fix this problem.

Would love an Aha response on this - seems to be a lot of interest.

As we expand our use of Aha, this will become a vital requirement to avoid human error and unleash some of the key advantages of Aha.

This would be great to be able to configure progress by work item, such as for Goals to apply "Calculate from Initiatives" for all Goals and/or configurable by workspace.

This would make the PM work just that little bit easier as we keep the same process for all our initiatives and features.

Would love love love to see this for not only progress, but for any fields where we have options on how to display a field

I'd love to configure the value myself therefore it could be applied to all epics/features.

Agreed. This should be configurable from a Workspace level with the power to inherit, just like layouts.

We would love this feature, working with ~20 pods and a few hundred epics over the course of a few months, manually setting all records to track progress a certain way invites a ton of room for human error and deflates the value of one of our main Aha use cases, automated progress tracking.

I am also looking for the ability to auto configure all Epics to use completed user stories as the metric to update Epic status

Every week, we have to remember to pull a report and manually add....this seems like a small win to address inefficiencies.

Having to manually update progress status calculation for every Feature diminishes the value this tool provides as an integration with our development tool (Azure DevOps). We have the ability to auto-calculate Feature progress in ADO, and this makes the road to adoption with our PO/PMs more difficult as we're requiring additional administration effort to get similar outcomes in Aha that are already available within ADO.

We cannot agree more on this feature. This is a pain for all our PMs to specify the calculation method for all the features...

We need this to be a workspace setting and allow to inherit from the parent workspace. Specifically we want to enable the progress calculation for Releases, Epics and Features. We want to ensure that Releases and Features are being calculated from the features and we want the Features to calculate manually so it receives the %complete from Jira.

We would save a lot of manual work and need of mental check every time we create a feature or release if we can have the ability to configure the progress calculation default option

Hi guys, would be great to see this feature live.

Thanks.

Would love this setting to be configurable at the Workspace level thereby giving each Workspace owner the freedom to deviate on their preferred Progress calc. method for each record type.

Definitely would like to have in order to provide consistency and efficiency across our portfolio (workspaces). Without it, manual intervention is required and reliability of data is suspect. We have to pull reports to identify what has been changed to calculate based on story completion and spend time then making those updates.

My only issue with inheritence from a configuration on a workspace is that for me personally is that with 500+ workspaces and enheritance can be a bit of a faff. If I could do it at the screen layout it would be easier for me. But setting it in the configuration make sense too. I has a similar experience as Rick. I took looked in the elipses hoping for the option to be available.

Setting the default in the layout editor would work for my use case, however I think I agree with Robert that it feels like it shouldn't logically be part of the layout, but rather part of the workspace configuration with inheritance.