Decoupling calculation of actual effort setting from initial and detailed estimate

Dear aha, could you please decouple the settings of actual effort field from initial and detailed estimate?

Scenario I am having>

1. teams handle estimations differently on requirement level in JIRA (stories, bugs, spikes..)

   1. they do estimations either in story points

   2. or MDs (just one or two teams)

   3. or they do no estimation on requirements level at all (#no-estimate)

2. all teams do log their effort in time unit in JIRA on requirement level (stories, bugs, spikes..)

3. 1+2 => to unify on feature level in AHA we estimate Initial and Detailed estimate (we call it Current MDs estimate) in MDs

   1. feature is synced with Epic in JIRA

   2. PROBLEM

      1. WHEN "actual effort" calculation is set to be based on requirements in aha, that aha consumes data from requirements being synced with our JIRA (stories, bugs, spikes..)

      2. THEN our estimates within "detailed estimate" is affected by non-existent values in JIRA ...

      3. OR we don't base feature estimates on requirements and thus we don't have the benefit of having actual effort calculated automatically as well

         1. => need to manually input it from other BI tools or JIRA reporting.. which is definitely no lovable... :-)

      4. ALTERNATIVELY aha could decouple these settings from each other providing us with agility we need
         

Sharing fields from feature custom layout to demonstrate, that we are currently work-arounding the whole thing with custom set of fields.. which is not very ideal at all. Please consider my idea.

Native fields

• Initial Estimate

• Detailed Estimate

• Actual Effort

Custom fields

• Initial MDs Estimate

• Current MDs Estimate

• MDs spent

• A

P.S. As you can see, we have a dimension to initial estimate for signalizing, that the overall estimate has changed. That is BTW something we would not get from detailed estimate hence we are going to keep it.

Edit:

Just thought of a workaround.. final setup of my layout fields will be like:

• .... all the preceding fields in the layout

• Initial Estimate (native .. it does not change based on requirements actually..)

• Current Estimate (custom)

• Actual Effort (native)

• .... all the following fields in the layout

• Detailed Estimate (native.. but having it here just so that we have the ability to turn on "autocalculation of actual effort based on requirements synced with JIRA).

  • there is a potential to play with Story point settings .. does it affect actual effort? going to experiment..

  • edit 2: will not work.. as it would prevent using Initial estimate in MDs? This is becoming too complex. Decoupling the setting seems inevitable.

  • edit 3. actually swithing to story points estimate in capacity settings seem to be NOT WORKING AT ALL as aha still uses time for estimation when creating new feature. Valid for 2022-10-01 12:38 CEST

EDIT 3: Solution idea: separete feature and requiement estimation / capacity fields so that it's ready to stand the test of time and further evolution.

• feature level

  • Initial Estimate

    • option to calculate from requirement level independently from other fields

  • Refined Estimate

    • option to calculate from requirement level independently from other fields

  • Actual Effort

    • option to calculate from requirement level independently from other fields

• requirement

  • Original Estimate

  • Remaining Estimate

  • Work logged

    • add worklog description (jira has it)

    • AndAnd worklogworklogs datedate (jirajira hashas itit)

for all fields DoD

• can be edited manually

• retain historical revisions / who updated + when it was update

• don't create any functional dependency between fields on different level (feature vs estimate), only parent level option to calculate based on related child item level field.

• enable all for synchronization

• create "update button" to resync all on feature and also on separately on requirement level

• announce aha to the world as the only complete and most flexible cross entity, cross tool capacity management.