You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
I have the following set of tasks (tracking my own tasks towards a project I am working on).
As you can see, the first highlighted task has an estimate of three days and the lowest priority. The second highlighted task has an estimate of one day and has a higher priority (2) and a due date of 08/Apr. However the auto-schedule algorithm for some reason doesn't give me the correct schedule. It just needs to give more priority to the second task and I will have what i want.
Can someone explain what is going on? How do I force the scheduling algorithm to obey certain constraints about the start and end dates of a task? I know that the older UI had options to set earliest start/end date for tasks. I am looking for a way to enforce these in the new improved UI.
this is the normal behavior! The scheduler doesn't take the ranking into account with the highest priority. The ranking has some influence, but in case there are no further constraints like dependencies to other issues, it tries to schedule an issue as soon as possible considering the team capacity. This has some benefits, especially related to issues which are having other constraints like dependencies or fixed release start dates and are to be scheduled in the far future where the exact backlog sequence is not that important at the moment. So, you don't have to take care about the correct ranking at the moment, what you would have to do in case the scheduler would follow strictly the ranking.
But, this behavior has also some considerable disadvantages in the "near field", because as soon as the constraints are gone, e.g. blocking issues are closed, you observe the effect you see which causes then some troubles:
In the old interface (former Protfolio4JIRA, Live plans v2.x) you can work around these problems using the feature "Earlies Start Date" which prevents the scheduler to calculate an issue too early.
In the new planning interface (v3.x) this feature was removed. It is also killing for us!
There is a feature request to bring this feature back: https://jira.atlassian.com/browse/JPOSERVER-2563
Please vote for it if you are interested in this feature.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.