JIRA Portfolio : Why low Ranked epics are scheduled before high Ranked epics

[amine benali]

Hello,

I don't understand the scheduling logic of portfolio. Low ranked items (n#26 for example_) is scheduled to be developed before the high rank items (n#10). There is no dependencies no earliest dates no other constraints.

I have read all the documentation on Atlassian, they are very high level but I would like to understand how the algorithm makes the choices because many scheduling decisions don't respect our priority of backlog.

[Earl McCutcheon]

Hello Amine,

The Scheduling algorithm takes into account a few different input points to define the schedule covered in the documentation here:

• Scheduling behavior

Portfolio for Jira uses the following factors to create a sensible schedule of your team's work items:

• Estimates, and required skills and capacity
• Team schedules, e.g. working in either sprint iterations, or in a continuous flow of daily tasks
• Work stages, e.g. whether activities can happen either in parallel or in a specific sequence in the plan
• The sequence of work items, based on start and end release dates
• The ranking of work items in the backlog
• Dependencies between work items in the backlog
• Configurable constraints, e.g. how many people can work in parallel on a story
• The skills of each team member
• Availability of teams and people, taking into account holidays

And from what I can see in your screenshots I would say this is related to the releases.  Check if WPI-849 is set to use a Later Release but WPI-815 is set in a fixed release date.

If its not the releases check out the Scheduling factors on the Child issues in the epic for an indication of what factors are being weighed in for the issue.  i.e. In the scenario i believe is occuring the following screenshot shows an issue that is set to a higher rank but scheduled after lower ranked issues because of the Release, and the Scheduling factors displays Rank as the first suspect but we have already ruled this factor out and Release second so we know the Release is the item to focus on:

Regards,
Earl

[amine benali]

@Earl McCutcheon

Thank you for your time and support as it's becoming a crucial point for our factory of Dev

 Can we please schedule 1h call to show you the plan ?

regards,

Amine

[Kassi Hayden]

@Earl McCutcheon - Say your velocity is 15.  Tickets 1-4 are 3 points each, Ticket 5 is 5 points, and Ticket 6 is 2 points. 

The Portfolio algorithm will put Tickets 1-4 in the next sprint because they total 12 points, which the team has capacity to do;  however, it won't put Ticket 5 into that same sprint because that would put it at 17 (above capacity).  Instead it will put Ticket 6 in and save Ticket 5 for the sprint after that.

Is there a way to disable that behavior? Meaning, is there a way to enforce Ticket 5 to be put into the next sprint along with Tickets 1-4, perhaps to split the ticket across sprints (i.e. 3 points of Ticket 5 in this sprint, 2 points of Ticket 5 in the next)?  Alternatively, can Ticket 5 be assigned to this sprint and be flagged to indicate a risk of completing the work in the sprint given the team has a lower velocity than the total amount of story points per that sprint?