How I Finally Automated My Entire Project Planning in Jira — and Dodged the "Original Estimate" Trap

[#1]

There's a specific kind of frustration that only Jira power users know: you've got a perfectly structured project plan, linked epics, stories, sub-tasks — and then one deadline shifts. Suddenly you're manually cascading date changes across dozens of work items, wondering why you even bothered building the structure in the first place.

I've been there. Many times. And for a long time, I convinced myself this was just the price of using Jira for real project planning.

It's not. Here's how I fixed it.

---

The Problem: Cascading Date Changes Are a Silent Productivity Killer

In any non-trivial project, work items don't exist in isolation. Epics have stories. Milestones block other milestones. When a due date shifts on one item — which it always does — everything downstream needs to shift too.

The manual approach means:

• Re-opening every linked ticket

• Mentally recalculating the new dates based on estimates

• Hoping you didn't miss any dependencies

• Repeating this every time something changes

Sound familiar?

---

Why I Avoided "Original Estimate" for Smart Value Calculations

Before I get into what I built, I want to talk about what I didn't build — and why.

The natural instinct is to lean on Jira's built-in Original Estimate field for time-based smart value calculations. It makes sense on the surface: the field exists, it stores time values, and you'd expect smart values to handle it cleanly.

But if you've tried this, you've probably hit the wall. The "Original Estimate" field is stored internally as seconds and behaves inconsistently in smart value expressions. Calculations that look correct on paper produce wrong outputs — or fail silently. Community threads on this are long, painful, and unresolved. I spent more time debugging smart value math with Original Estimate than I care to admit.

My fix: I created a custom numeric field.

I added a new number field called something like Estimate and stored all estimates there as plain integers — 5 for a five-day task, 10 for a two-week task. No time formatting, no seconds conversion, no surprises.

This single decision unlocked everything else.

---

The Automation I Built: A Self-Healing Project Plan

The system works in two layers. Let me walk through each one.

---

Layer 1: Detect a Due Date Change and Cascade Start Dates

Trigger: Field value changed → Due date

The first automation fires the moment any work item's due date is updated. This could be an epic, a milestone, or any item that other work items depend on.

What it does:

Once the trigger fires, a condition checks whether the change is meaningful (you can filter by issue type, project, or other criteria here to keep things surgical).

Then it branches into a loop:

For: Linked work items — Types: All link types

For every work item linked to the changed item, it runs:

1. Edit work item fields → Start date
   Sets the start date of each linked dependent item to the new due date of the parent. This is the cascade: if your epic's due date slips to October 15th, every work item waiting on it now has October 15th as its new start date.

2. Re-fetch work item data
   This is a small but critical step. Before calculating the new due date, the automation re-fetches the current state of each work item — including the custom estimate field. Without this, you risk calculating based on stale data.

3. Edit work item fields → Due date
   Using the custom estimate field and the following smart value:

{{duedate.plusDays(Estimate)}}

This takes the new start date (now set on the work item) and adds the number of working days from the custom estimate field. The result is the new, correctly calculated due date — automatically.

---

The Smart Value That Makes It Work

{{duedate.plusDays(Estimate)}}

Let me unpack this:

• duedate is the field storing the due date in our istance

• .plusDays() is a Jira smart value function that adds calendar or working days to a date

• Estimate is the custom estimate field 

Because the field is a plain number (not a time-formatted string), the calculation is clean and predictable every time. No seconds-to-days conversion, no edge cases, no silent failures.

---

Layer 2: The Nested Automation — Cascading the Cascade

Here's where it gets really interesting.

Because changing a work item's due date itself triggers the first automation (remember — the trigger is any due date change), the system is naturally recursive. When Automation 1 updates the due date of a dependent work item, that change triggers Automation 1 again for that work item's dependents.

This means the cascade propagates automatically down the entire dependency chain. You don't need to write a separate "deep cascade" automation — the trigger handles it.

A word of caution: make sure your dependency graph doesn't have cycles, or you'll create an infinite loop.

---

What's Next: Intelligent Stakeholder Briefings

This is working beautifully in practice — but the system isn't finished yet.

The next automation I'm building will watch the project plan for meaningful deviations and automatically brief stakeholders when certain thresholds are crossed. Planned rules include:

• "Project is late by more than one month" → Send a summary email or Slack message to project sponsors

• "Three or more milestones have shifted in the last 7 days" → Trigger a project health report

• "Critical path epic is overdue" → Escalate to the project lead with context

The goal is to close the loop: not just a self-healing plan, but a plan that communicates its own changes to the right people at the right time — automatically.

---

Takeaways

If you're building date-based automations in Jira, here are the key lessons from my experience:

1. Avoid "Original Estimate" for smart value math. Create a custom numeric field for estimates in working days instead. It's more predictable, easier to read, and plays nicely with .plusDays().

2. Use "Re-fetch work item data" before date calculations. Always ensure your automation is working with fresh field values, not cached ones.

3. Let your trigger be the cascade engine. If your automation updates a field that is also a trigger, Jira will naturally propagate changes down the chain without you needing to write recursive logic manually.

4. Keep it modular. One automation per concern: one for cascading start dates + due dates, one (coming soon) for stakeholder communication. Easier to debug, easier to maintain.

---

The project planning problem in Jira has always been solvable — it just required stepping around one well-known trap and leaning into what smart values actually do well.

If you've been putting off this kind of automation because of bad experiences with Original Estimate, I hope this gives you a clear path forward. The setup takes an afternoon. The time it saves is ongoing.

[__ Jimi Wikman]

So you basically built a smaller version of the BigPicture Gantt chart :)

It sounds like a lot of automations, but I am confused about why you run it for all links rather than just dependency links?

There are many reasons to link things together, but not all of them imply a time dependency between them.

This also just pushes dates, but it has no function for verifying that moving data is actually feasible. Are people available, and can the budget sustain a delay, for example? When you work in project management, it is, in my experience, never as easy as replanning the dates automatically. Shift in timelines require manual adjustment where multiple factors are in play. 

Availability is one. Can I move this activity here if one of the people who is required is on vacation? 

Finance is another. Can I prolong this project, and what type of budget activities do I need to do to add more budget?

So while I admire and appreciate your technical solution, I think you solved the smallest problem to handle when plans change and need to be replanned ;)