How to sync time estimation between plans and projects?

[Yoav Ben Arie _Zynga_]

Hello,
I have been working with Jira for a long time and have experience with BigGantt. I want to deepen our usage in plans.

What is the connection between original estimates, Time remaining, and estimates (d)?

I understand what Atlassian tried to implement, but in the end, how can I reflect the work estimations in the plan? Or how can I plan on the project level and see the estimations sum up in the plan?

I don't care about using Automation and hacks to make it happen, but it can't be disconnected. Plans must reflect the estimations made by the teams in their projects (original estimate), And when estimations are done in the plan (estimates (d), they should be assigned to the tasks.

[Walter Buggenhout · Accepted solution]

Hi @Yoav Ben Arie _Zynga_ and welcome to the Community!

Since Plans (as the name subtly hints at) is a forward looking, planning tool, the estimates that get pulled in from Jira's issue sources are the remaining estimates. When you add an original estimate on a Jira issue, it automatically gets copied over into the remaining estimate field and as soon as you start logging work (or update the remaining estimate itself), your original estimate does not tell you anything anymore about the remaining work. To get a good idea of how long it will take your team(s) to complete the remaining work, it is that field that matters.

So, in summary: the estimates (d) in plans reflect the remaining estimate in Jira - unless you set your plan to use story points instead. And as soon as your work starts progressing, original estimates only remain relevant to see how much you progressed in comparison with original estimation from the team. That is a metric that mainly tells you how good your team is at estimating stuff, it does not give you much additional information on how much time is still needed to complete the remaining work.

Obviously, that information is valuable (for other purposes than planning remaining work). It can be disclosed in Jira dashboards, through Jira's work ratio field or through reporting tools. It is not part, however, of plans feature set.

Hope this helps!

[Yoav Ben Arie _Zynga_]

Thanks Walter,

I get your point, but my plan and project are set to schedule by time, and the remaining estimate isn't reflected in the plan.

This is my pain; it seems the projects are not synced with the plans. Am I missing something?

[Yoav Ben Arie _Zynga_]

To be cleared, 
I want developers to estimate their subtasks and see the time estimation summing up in the plan to the Stories and Epics.
This is how the estimates (d) field in the plan works but is disconnected from the estimating fields in the project.

Thanks

[Michel van de Wiel]

@Yoav Ben Arie _Zynga_ @Walter Buggenhout 

To achieve what you're aiming for—having developers estimate subtasks and automatically see those estimations sum up into Stories and Epics in Jira Plans, while maintaining synchronization between the plan's Estimates (d) field and the project's time-tracking fields (like Original Estimate and Remaining Estimate)—you can configure Jira as follows:

1. Configure Subtask Estimation Roll-Ups

Jira Plans supports rolling up estimates from subtasks to parent issues, provided the subtasks have valid estimation values. Here’s how to set it up:

In Jira Plan Settings:

• Open your Plan.

• Click the Settings (gear icon).

• Go to Hierarchy Configuration:

  • Ensure subtasks are part of your hierarchy.
  • Check that the hierarchy structure includes Subtasks → Stories → Epics.

• Go to Estimation Settings:

  • Select Time-based estimates (e.g., hours/days).
  • Map the estimation field:
    • Choose Original Estimate (or Remaining Estimate, depending on your workflow) as the source field for time-tracking data.

Enable Roll-Up Values in the Plan:

• Open your Plan and click on the column settings (gear icon above the columns).
• Add the Roll-up column for Original Estimate or any other relevant field.
• This will display aggregated estimates for each parent issue (Stories, Epics).

2. Sync Estimates (d) with Original Estimate

The challenge lies in synchronizing the Estimates (d) field used in Plans with the project's Original Estimate field.

Option A: Manual Sync

• When changes are made in the Plan, ensure they are published back to Jira via the Review Changes option.
• This will update the corresponding issues in Jira, including their Original Estimate or Remaining Estimate fields.

Option B: Automation Rule for Real-Time Sync

Create automation rules to keep the two fields synchronized.

Rule 1: Update Estimates (d) when Original Estimate changes

• Trigger: Field value changed (Original Estimate).
• Condition: Issue is in the Plan.
• Action: Copy the value from Original Estimate to Estimates (d).

Rule 2: Update Original Estimate when Estimates (d) changes

• Trigger: Field value changed (Estimates (d)).
• Condition: Issue type matches subtasks, stories, or epics.
• Action: Copy the value from Estimates (d) to Original Estimate.

3. Ensure Subtask-Level Estimates Aggregate Properly

• When developers input estimates for subtasks, make sure the Original Estimate field is used consistently.
• Verify that subtasks are linked to their parent Stories, and Stories are linked to Epics.

4. Verify the Roll-Up in Jira Plan

• Open your Plan and check that:
  • Subtask estimates are aggregated into the parent Stories/Epics.
  • The roll-up total matches the sum of subtasks' Original Estimates.
• Use the Sum Up feature in the Plan to visualize this aggregation.

5. Advanced Workflow Using Automation and BigGantt/BigPicture

If using native Jira features still feels disconnected, tools like BigGantt or BigPicture provide enhanced Gantt chart views that directly integrate with time-tracking fields. You can:

• Visualize roll-ups from subtasks to Epics without custom automation.
• Sync estimation fields seamlessly between Plans and Jira projects.

[Walter Buggenhout]

Hi @Michel van de Wiel,

Great that you want to help out, but please do not post AI generated answers (that are not at least properly validated). There's quite a few things in that post that read nicely, but are not even referencing existing Jira features.

@Yoav Ben Arie _Zynga_ - I'll answer your request below and immediately, but allow me to advise against estimating on subtasks, especially if you work in sprints. That will cause quite a bit of inconveniences by the way Jira handles this. We could have very long discussions about the topic, but there's a good article that explains most of the key concepts in Atlassian's support documentation.

Apart from that, if you want to roll up your estimates from sub-tasks all the way up to Epics (and above), there's a simple toggle that just triggers that automatically. The only thing to be aware of, is that it is rolling up the remaining estimates values and not original estimates. The Original Estimates field can't be added to Plans. Referring back to your last remark:

I want developers to estimate their subtasks and see the time estimation summing up in the plan to the Stories and Epics.
This is how the estimates (d) field in the plan works but is disconnected from the estimating fields in the project.

semi-true. Estimates (d) is linked to remaining estimates. At the start of your project (and before any time spent has been logged), this is the exact same value as your original estimate. Once the work actually start, the original estimate is no longer traceable in Plans. Hence my earlier reference to dashboard gadgets and other reporting methods.

[Walter Buggenhout]

From a sample plan:

Key settings:

• In Plan Settings > Scheduling make sure that estimation is set to days
• In your plan's View Settings make sure to check the box next to roll up > others

Then you should get the above result.

[Yoav Ben Arie _Zynga_]

Thanks Walter,
I will read about estimating sub-tasks. We are playing with our methodology, and this is the current process we will start with, so it is interesting to learn.

I played with what you suggested in the first answer and got everything working as expected. 

Thanks