Is Microsoft Project–style auto‑scheduling possible in JIRA Plans?

[ruben_puente]

Hi all,

I’m trying to replicate Microsoft Project–style auto‑scheduling in JIRA Plans and wanted to check if anyone has achieved something similar.

The challenge:
While JIRA supports dependencies, it doesn’t automatically adjust start/due dates when upstream tasks shift—so updates are manual.

What I’m aiming for:

• Automatic propagation of delays across dependent tasks
• Recalculation when dates, duration, or dependencies change
• Cascading updates across multi-level and parallel dependencies
• Epic Due Date updating dynamically based on the latest task

Example behaviour:

• If Task 1 is delayed or extended, all downstream tasks shift accordingly
• If duration increases (e.g. +2 days), dependent tasks move by the same amount
• New Start = Upstream Due Date + 1 business day
• New Due = Start + Duration (excluding weekends)

Question:
Has anyone implemented this kind of dependency-driven scheduling in JIRA Plans (natively or via automation/plugins)?

If yes, what approach worked best—and what limitations should I expect?

Thanks in advance!

[Tomislav Tobijas]

Hi @ruben_puente ,

I did try to build this once, but the implementation wasn't user-friendly. It was mainly because you would need to rely on a couple of automation flows + the biggest challenge was the fact that Plans are actually a 'sandbox environment,' meaning you need to save changes first to trigger automation and then most likely refresh the page/plan to see the changes that automation did. 🫤

Question - Did you try to work with auto-scheduler feature, or have you only been editing issues manually through the plan?

Note that there's a feature request for this: JRACLOUD-88193: Advanced Roadmap - automatically shift blocked tasks when changing end date 

What worked in the end (if you want to look at gantts and MS Project parity) are Marketplace apps such as BigPicture and/or WBS Gantt-Chart. These apps do support gantt-style scheduling of tasks and their dependent work items 👀

Hope this helps.

Cheers,
Tobi

[ruben_puente]

Hi @Tomislav Tobijas 

We’ve tried using the auto-scheduler feature, but it mainly assigns work based on team capacity and doesn’t update task dependencies the way we’d expect. Because of that, we’ve been managing tasks manually within the plan.

It’s good to see there’s a feature request in place—this feels like a fundamental capability that should be built into the planning tool.

I’ll also take a look at the suggested apps. If you’ve had any hands-on experience with them, I’d be keen to hear your thoughts.

[Constantin Kireev - Be On Time]

The short answer is: not natively. Jira Plans (Advanced Roadmaps) handles dependencies as 'visual indicators' rather than 'scheduling constraints'. It tells you that something is blocked, but it won't automatically push the successor's date when the predecessor slips - which is the core of MS Project's auto-scheduling logic.

In my experience managing large-scale portfolios, the 'Jira way' is designed for Agile fluidity, whereas MS Project is designed for deterministic scheduling.
If you try to force Jira to act like MS Project using only native tools, you usually end up with a massive manual update nightmare every time a date changes.

The best approach is to keep Jira as your 'execution' engine and use a dedicated scheduling layer for the 'planning' engine. There are several apps in the Atlassian Marketplace that solve this specifically by adding a real scheduling engine to Jira. Some of them are quite good and can handle true critical path logic and auto-scheduling, allowing you to sync the resulting dates back to your Jira issues.

I'd advise looking for tools that specifically mention 'MS Project interoperability' or 'Critical Path Method (CPM)', as those are the ones that actually replicate the auto-scheduling behavior you're looking for.

[ruben_puente]

Thanks @Constantin Kireev - Be On Time —really appreciate the detailed perspective, it aligns closely with what I’ve been observing as well. In our case, the limitation becomes quite pronounced given the nature of our current delivery scope. We’re operating with tightly sequenced activities, multiple dependency chains, and fixed approval windows, which makes reliable end-date forecasting critical for stakeholder communication. The current “visual indicator” approach in Jira Plans doesn’t quite provide the level of confidence we need, particularly when upstream changes don’t automatically cascade through the schedule. We’ve been trying to strike a balance between maintaining Jira as the execution engine while reducing the manual overhead of constantly recalculating downstream impacts. As you pointed out, attempting to replicate MS Project behaviour natively has proven difficult and often leads to frequent manual re-planning.

Your suggestion of introducing a dedicated scheduling layer (with CPM and auto-scheduling capability) is something we’re actively exploring. The ability to maintain a true critical path and have dynamic date adjustments—while still syncing back into Jira for execution—would significantly improve planning stability and transparency.

If you’ve come across any specific tools or integrations that have worked well in practice, I’d be keen to hear your recommendations.

[Constantin Kireev - Be On Time]

Hi @ruben_puente ,

I completely understand. When you have fixed approval windows and tight  sequences, "visual indicators" aren't enough—you need a scheduling engine that treats dependencies as hard constraints.

Since you're looking for that specific MS Project-style confidence for your stakeholder reporting, I'll be transparent: I work for the team that built MSP Planner for Jira. We actually developed it specifically to bridge this gap.

While Jira Plans is great for capacity and fluidity, MSP Planner implements a deterministic scheduling engine. It handles the cascading updates you mentioned— if an upstream task slips, the downstream dates shift automatically across the entire chain, which gives you the reliable end-date forecasting you need for those approval windows.

If you're open to it, you can check out the Marketplace page to see if the logic matches your delivery scope. I'd also be happy to show you how it handles the specific dependency chains you're dealing with.

Hope this helps you get that forecasting confidence back!

Cheers,
Constantin

[Joshua Brock _ Seibert Group_ GmbH]

Greetings @ruben_puente 

Tomislav's summary is spot on. Jira Plans' auto-scheduler assigns work based on team capacity, but it doesn't propagate dependency-driven date shifts the way MS Project does. That gap is tracked in JRACLOUD-88193, and there's no native solution today that I know of.

One angle worth considering: the reason this gap is so visible in Plans is that dependency tracking in Jira tends to work best when it's treated as a planning constraint across teams, not just a link between individual tasks.

If your dependency picture is growing because multiple teams need to coordinate work across a planning horizon, that's a different problem than Gantt scheduling; it's closer to what happens in scaled agile planning across Release Trains and Program Increments.

 
If your team is heading in that direction, Agile Hive approaches dependencies differently: they're surfaced as cross-team constraints during PI Planning, visible to all ARTs on a shared dependency board, and tracked through to delivery — all inside Jira, no separate system of record.

The dependency model is built for coordination across release trains rather than cascading individual task dates, so it's a different fit than BigPicture, but it's relevant if the underlying challenge is multi-team coordination at scale. A free trial is available on the Atlassian Marketplace.

If your dependency challenge is really about cross-team coordination at scale, that's worth a separate look.

In full disclosure, I work at Seibert Group, the team behind Agile Hive.

Hope this helps and best of luck!

Joshua
Content Writer & US Representative
Agile Hive and Aura Apps (products of Seibert Group GmbH)

[ruben_puente]

Thanks @Joshua Brock _ Seibert Group_ GmbH . The root cause of the project delays—and the need to update plans frequently, often on a daily basis—is largely due to non-persistent resourcing within projects. Some team members are working across multiple initiatives, while others have limited domain knowledge, which is also contributing to delays.

To address this, we’ll need to establish more stable, persistent squads and invest in capability uplift. In parallel, we should explore tools that better manage task dependencies within teams. This is particularly important as we need to provide stakeholders with reliable target end dates, while navigating multiple business approval stages with fixed windows.

The current ways of working are quite complex, and while there are clear opportunities for improvement, any changes will need to be carefully managed to avoid impacting people and delivery outcomes.