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.
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
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:
@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?
Hello everyone, Hope everyone is safe! A few months ago we posted an article sharing all the new articles and documentation that we, the AMER Jira Service Management team created. As mentioned ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events