Fixed start date requirement in auto-scheduling

[Dan Dodson]

It is very important to be able to specify a start date on an issue as a fixed constraint when using auto-scheduling. Everyone needs this, I guarantee it. Advanced Roadmaps auto-schedule does not seem to be able to respect both this and issue dependencies at the same time.

Example: a plan with just two tasks. Make the first one block the 2nd. (Awesome ability to specify and visualize this in the Advanced Roadmaps UI - love it!) But the first one cannot start until day X, because the world says so. Perhaps it's an externally-driven deadline, perhaps internal that can't be represented in Jira. Either way, the schedule won't be useful without retaining such a constraint.

If you enter an estimate for both issues and auto-schedule, the start date will be overridden. Does not seem to matter whether Target Start or Start Date is specified, or which one of the two is configured for visualization on the roadmap. The issue dependencies, however, will be respected, with the 2nd task starting after the first. But the start date of the first will be overridden to start on the current day, and there is no way to constrain this.

There is handling of unestimated issues. One idea would be to remove the estimate for the 1st issue, since this doc says that unestimated issues will not have their dates changed. So indeed, removing the estimate allows the dates to remain fixed, but then the scheduler does not respect the "blocks" dependency, and will schedule the blocked issue to start right away, on the current date. This seems like a straightforward bug in the scheduling algorithm. But really, it should respect the "start date" field as a fixed constraint when the issue has an estimate.

To make this crystal clear, here are demo screenshots.

Simplified team setup to illustrate scheduling problem:

Issue setup with estimates, and a fixed start date requirement (here June 1; as I write today is May 20):

Failure mode - moves target start to current date. But not only that, shifts the entire dependency chain ahead.

And it should move the dependency chain ahead - you want it to schedule things as soon as possible. But this magnifies the severity of this lack of respect for a fixed date, because when it schedules the entire dependency chain ahead of where it would be given the 1st issue fixed start, none of the schedule estimates for dependencies can be used. Does not matter if we switch to using Start Date as the roadmap visualization. I get that this redesigned product is meant to offer full control of the roadmap, so that one can manually make adjustments when not satisfied with the calculated schedule. That's great! But it doesn't work here, because if you have a long dependency chain, dragging the first issue is blocked, it does not shift the entire chain forward. It's nearly impossible to drag a big dependency sequence around while preserving it.

Try using an unestimated issue so that the scheduler won't change the dates:

Failure mode:

Oops! This just seems to be a bug, rather than a sorely needed missing feature as may be in the 1st case. I can't imagine some sort of design constraint would require it to behave this way to fail to account for the blocks relationship here.

[Huy · Accepted solution]

Unfortunately auto-scheduling doesn't respect the fixed start date supplied and I have opened https://jira.atlassian.com/browse/JSWCLOUD-22406 in relation to this thread.

[Kelly Arrey]

Thanks Huy.

[Kelly Arrey]

@Dan Dodson Sadly my "answer" is +1.  Almost 2 years later, same problem. I'm opening a ticket, will let you know the outcome.

[Arthur Lee]

Sadly, this issue is still not fixed as of October 2023.

As a workaround, for my Kanban plan, I used blocker issue (in the parlance of Mateusz Skalski). The blocker issue has an estimate for the duration of how long you need to delay your starting task. I also create an outgoing dependency from the blocker issue to the first start task. When I use auto-scheduling, it then shifts everything over as I need it.

[Mateusz Skalski]

In case this is needed to define external blockers, I think I've found a workaround:

1. Create a separate "Blockers" board based on a filter that only captures external blocker issues.
2. Create a "Blockers" team (can be plan-only) and assign the "Blockers" board as an issue source and set sprint length to 1 week.
3. Assing the "Blockers" team to all external blocker issues.
4. To set a date for a specific blocker, do the following:
   1. Create a 1-week sprint in the "Blockers" board and manually set its dates to the preferred ones.
   2. Give some minimal estimate to the blocker issue.
   3. Assign that sprint to the blocker issue.

This way external blocker issues will be planned for the chosen sprint with specific dates. Remember to set the "Sprints" radio button to the "Empty values only" option in Auto-schedule.

The "Blockers" board can be used separately only to create new blocker sprints. Thanks to it being a separate issue source, assigned only to the "Blockers" team, the artificial sprints won't be suggested for issues with a different team assigned.