Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,458,383
Community Members
 
Community Events
176
Community Groups

Fixed start date requirement in auto-scheduling

Edited

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:

team_setup.jpg

 

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

FireShot Capture 060 - Schedule fail plan - Portfolio for Jira - Jira - climatecentral.atlassian.net.jpg

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

oops1.jpgAnd 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:

unestimated_setup.jpg

Failure mode:

oops2.jpg

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.

 

3 answers

1 vote
Huy Atlassian Team Mar 09, 2022

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.

0 votes

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.

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

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
TAGS

Atlassian Community Events