Auto-scheduling items sequentialy based on dependencies does not work as implied in Advanced Roadmap

[TimothySchmidt]

Im testing out Jira with the intention of migrating my company to using it on future projects so I have admittedly minimal experience with Jira and Advanced roadmaps but im getting some scheduling behaviour that doesnt make sense to me.

When trying to auto schedule I have found that the option to schedule sequentialy does not make sense. It does nothing for Kanban Teams and for Scrum Teams it is not enforcing that tasks are completed one after the other, it is enforcing that they are completed in sequential sprints. This does technically force them to be sequential but not in the way it is implied. Im not sure if I am just not understanding the intended design or if this is not working as expected. At the moment I cannot see how forcing dependant tasks into sequential sprints would be benficial, especially if they are small 2h tasks that just need to be done in order.

It seams like this is an unintended result of the issues being allocated to take the entire sprint duration for scrum teams (which is another thing that I dont understand the point of, as this makes it impossible to view dependency based scheduling issues within an active sprint). But if this IS the intended design, I feel like the menu needs to explain this better as currently it just says it will force them to be one after the other, there is no mention of it forcing them to be in sequential sprints.

In my following example images i have 6 issues as children of "initiative 1 epic 1" with dependencies set up. I also have more issues set up inside other epics but the problem I am experiencing is noticable with the child issues of "initiative 1 epic 1".

• Task 1 depends on task 6
• Task 2 depends on task 1
• Task 3 depends on task 2
• Task 4 depends on task 3
• Task 5 depends on task 4

When changing the "configure" settings for advanced roadmaps, in the Scheduling tab there is the option to schedule dependent issues either concurrently or sequentialy.

If the team is set to Kanban, this has no effect.

When the team is set to scrum the concurrent mode still orders them sequentially but allows multiple dependant issues in the one sprint so long as they all fit within the sprint. The sequential option on the other hand forces each issue to be completed in sequential sprints.

[Mykenna Cepek]

I'm relatively new to Advanced Roadmaps too, but it looks to me like your examples are, in fact, consistent with the documentation.

And I agree with you that it's not really making real-world sense. I believe the sequential/concurrent choice is only relevant for when Sprints are being used (which is why that setting has no effect in Kanban).

Even with Sprints, though, one can wonder how this feature is intended to have practical value. I can definitely see a use-case for a series of issues that have to be done one-after-another (scheduled sequentially). And I can see other use-cases where maybe that strict approach isn't what the team or organization or project needs (thus "concurrent"). But having that as a whole-plan (verses dependency-specific) attribute seems ... unhelpful.

In short, I think it's "working as documented", and you're seeing the limitations of Advanced Roadmaps as they are currently implemented. I'd be happy for someone to educate me where I have this incorrect.

[Dave]

It's worth bearing in mind the history of the auto-schedule function and it's origins from the "Calculate" scheduling algorithm in the previous interface (known as "Live Plans").

So for Live Plans the scheduling algorithm took a lot more factors into consideration and was a lot more complex to configure, see this screenshot from for setting the equivalent settings:

As well as the scheduling algorithm taking few factors into consideration in the new interface, there is also a change in behaviour which is to indicate on the roadmap when issues with dependencies have scheduling conflicts (which can result from manually assigning dates or dragging issues on the timeline).

The sequential / concurrent configuration also has an impact here as to when the dependency badge will update to indicate a problem.

Issues are auto-scheduled to start and end on for the duration of the sprint because it is expected that scrum teams want to plan at the sprint level (and not at the granularity of individual days) so whilst dependent issues can have the same start and end dates if assigned to the same sprint this will not be shown as an scheduling error when concurrent dependency scheduling is allowed.

The scheduling algorithm also works on the assumption that only one team member will work at a time on story level issues (i.e. there will be no "swarming" on a single issue) so this is why you might want to use the concurrent dependency configuration setting so that work can be scheduled to complete as quickly as possible.

In the new interface we know (from analytics) that the auto-schedule algorithm isn't heavily used (as opposed to in Live Plans were it was essential to use it to generate a roadmap) so this reduces the priority of working on it (i.e. if our customers are achieving success without it there is no necessity to enhance it) however we recognise that this is a somewhat self-fulfilling prophecy and would like to make some enhancements to it in the near future to increase usage.

We also recognise that the reasoning behind how issues are auto-scheduled is somewhat opaque and it's not obvious why things are scheduled where they are. This is also something we'd like to improve but it is again not an immediate priority for us to do.

Regards,
Dave

[Mykenna Cepek]

Thanks for some more clarity on this, Dave.

It would be helpful for many of us (power) users to have a deeper understanding about the "reasoning behind how issues are auto-scheduled". It's pretty challenging to train others when us admins have to just accept "opaque" behavior.

The auto-schedule algorithm incorporates certain aspects of a plan and issue data (rank, team assignment, releases, some configuration settings, etc). But how they interact is unclear.

Examples of the additional clarity desired:

• Release start dates, when specified, are invariant.
• Issue ranking is always invariant.
• Issue start/end dates will always be revised by auto-scheduling.
• Auto-scheduling start by looking at ... and then considers ... followed by accommodating the ... and makes final adjustments based on ...

Currently, it's very difficult to educate a business leader to use this (when they are not at a Jira-admin level). When a leader makes a change in their plan, and something changes in the plan they don't expect, they will turn to us admins for a definitive explanation.

Also, please remember that a lot of your user base (like me) does not remember...

the history of the auto-schedule function and it's origins from the "Calculate" scheduling algorithm in the previous interface (known as "Live Plans").

Those of us coming to Advanced Roadmaps fresh would really be served well by providing more clarity about how auto-scheduling works (algorithmically).

ObLink: Here is the current documentation.