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!


Once you commit changes made in Portfolio into JIRA , how do you use Portfolio to re-simulate


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.

1 answer

1 accepted

0 votes
Answer accepted
Earl McCutcheon
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Oct 07, 2019

Hi Gil,

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.


Thank you Earl,

This is what was our understanding as well (and work like that with some groups)

It does raise couple of more questions on they way we could work and get specific reports, so I will open these in a different thread.

Thank you again,


Like Earl McCutcheon likes this

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events