Auto-Scheduling for dependend issues Portfolio 3.0

[Nina Kullmann]

Hi,

we are using the new version of Portfolio (3.0 of higher). I have planned some issues with dependencies, but unfortunately Portfolio does not schedule them correctly if i choose auto-scheduling. The only thing that happens is the dependencies are marked with a blue or red bubble in the schedule next to the bar.

In the old version Portfolio replanned the issues due to the dependencies so that the bars were moved and the start and end date were corrected by Portfolio. Now it seems that Portfolio only highlights problems, but i have to correct them by myself. Is that correct or have I set up some configurations in the wrong way?

Thanks a lot for your help.

Best regads

Nina

[Earl McCutcheon]

Hi Nina,

Thanks for reaching out, in the Live plan view (2.X versions) the dependency values would alter the order when you calculated to update the scheduling algorithm post change (Details on how the algorithm was weighted in live plans here),  and in the new planning experience, the dependencies will be flagged in the current location, Blue for no violation and red meaning that an issue is scheduled before it should start, prompting for a manual adjustment.

However, the error you are encountering seems to be occuring at the auto schedule portion, as the auto schedule should push out the dependent issue after the issue it is dependent on unless there is other criteria preventing the move.  Details on the Auto-scheduler calculation behavior can be seen here.

My suspicion is that there is another item such as one issue being added to a open sprint or future sprint or set release date preventing the auto-scheduler from adhering to the dependency so that it errors and requires a manual review to make a decision on which criteria is needed to complete.  But as covered in the auto-scheduler document linked above the criteria to look at are:

When auto-scheduling the issues in a plan, Portfolio for Jira considers several factors to come up with the ideal schedule for your teams:

• how your teams work, i.e. in sprint iterations (Scrum), or in a continuous flow of daily tasks (Kanban)
• for Scrum teams, the sprint assignments of the issues in the plan
• the sequence of issues, based on start and end release dates
• the ranking of the issues in the backlog
• the dependencies between issues in the backlog
• the number of members in your team, which determines how much work can be completed in parallel

As an exe in the following screenshot the Issue scheduled before PROJA-19 is in the current active sprint and then the PROJA-19 issue is added to a future sprint without parallel sprints enabled so the dependency is skipped in the auto schedule to prevent causing scope creep by moving an issue in an active sprint to the next sprint, flagging the issue for further manual review to see where the conflict exists.:

Regards,
Earl