nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How do I prevent portfolio predicting schedule end dates in the past

Nicole Downes

I have ordered the epics in the order that the team has prioritised after our quarterly planning session. For the first few epics, it has predicted the scheduled end date will be in the past even though there is estimate left on the epic/stories. That is, today is Dec 29, and portfolio shows scheduled end date as Dec 13.

How do I make the top priorities (and those that follow) show the estimated end date based on the estimate left today, not based on when the stories were scheduled to start. Surely I don't have to set/reset schedule start dates?

Any tips greatly appreciated.

Comments

Nicole Downes

I managed to fix this issue by adding scheduled start dates in the future for ALL the epics using later start dates for the lower priority ranked items and then calculating. This moved all the dates forward. I then removed all the scheduled start dates and calculating again so the system could work them out. While this solved the problem, it is not a long term solution as having over 70 epics in the plan, this was a time consuming exercise.

Would be happy to learn if there was a better way to fix this, or if I setup something incorrectly that caused the problem in the first place.

Thomas_rff8bi

Hi @Nicole Downes,

If the epics are estimated or, more likely in your case, the stories are estimated then clicking the calculate button should let Portfolio come up with new "Calculated Start" and "Calculated End" dates for those issues based on the story points/remaining time estimate of the issues and your team velocity.

If an issue is assigned to a sprint then the sprint start and end dates will be used which could be a reason for issues to show in the past (Issues assigned to a past sprint that was never closed or legitimately still in progress).

If issues are not assigned then, by default, Portfolio will try to schedule the item based on sprint, release assignment or the "Target start" and "Target end" fields.

You can read more on the scheduling behavior and the scheduling configuration in the documentation.

Hope that helps!

Cheers,

Thomas

Nicole Downes

Awesome tip. I will look there first in future. Thanks.

Nicole Downes

@Thomas I am experiencing the same issue where scheduled end date is in the past.

Epic is No.1 in the plan. New sprint runs from 20 Jan to 3 Feb. Remaining tasks are estimated with just over 1.5 days. Release date is set to 26 Jan.

Planning units is set to Days.

Unestimated item scheduling is set to Base on Default Estimates

There are no dependencies, no skill settings and all issues in our plan are set with the same priority.

I have pressed the Calculate button multiple times, but this Epic (and about 7 more) have been given the scheduled end date of 15 Jan, (schedule start of Jan 2) today is 20 Jan. Please note all issues for this epic were carried over from Sprint 1, this is Sprint 2. The only way I can make the Schedule end move is to change the Schedule start date. This is not a workable solution given how many epics and plans I am monitoring.

Is there a different config setting I should have, or some other process I should be using? I am expecting that the Scheduled end date should be calculated by portfolio automatically to Jan 23 or Jan 24.

Thomas_rff8bi

Hi @Nicole Downes,

If you can impact the schedule by changing the Target Start / Target End dates then your issue (or its children) may not have estimates or the children containing the estimation were filtered out.

If the Epic or some of its children have estimates then it's possible that your Sprint 1 was not marked as completed in the relevant Jira board, you can read more about this here.

If this is not the case I'd suggest sharing some anonymized screenshot of your plan in this thread or reaching our to support here.

Cheers,

Thomas

Lewis Cook_s7h5mc

We've literally just run into this problem today and the resolution appeared to be an issue with overlapping sprints which once resolved fixed out dates which were in the past.