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

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


1 badge earned


Participate in fun challenges

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


Gift kudos to your peers

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


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!


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
Community Members
Community Events
Community Groups

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



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.



1 answer

0 votes

Hello Amine,

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

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:

Screen Shot 2018-07-05 at 3.44.27 PM.pngScreen Shot 2018-07-05 at 3.39.18 PM.png




@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 ?



@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? 

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events