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
Once you commit the changes made in Portfolio Plan into JIRA, each story is assigned a sprint.
To my understanding this prevents Portfolio from moving these stories in its next plan simulation (sandbox). so we are left with a fixed plan that only way to re-plan it is by moving back all stories from Sprints to Backlog.
How should you use Portfolio to re-simulate after the first Plan commit?
Note: we are working with the non-improved interface.
A commit finalizes that the values and sets them on the issue. Once you commit a value to the sprint field the sprint is set and as you noted needs to be cleared to make changes to the plan as the scheduling algorithm is using the sprint field as one of the weighted items to calculate the issues position in the scope. So once the sprint is set it anchors the issue to that committed sprint location.
If there is not an active or future sprint avaliable to add an issue too, Portfolio will populate a logical placeholder sprint that will not anchor the issue to that committed sprints location and use the alternate scheduling factors in the schedule.
So if you are looking to have more leniency in the sprint commitment you can set up your sprint planning more ad-hoc by only having the current sprint created then only create future sprints where the resources commitment can be confirmed, so that portfolio will place issues into the logical place holder sprints when running the calculations based on the other scheduling factors vs using the committed values of the sprint for the scheduling factors.