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!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Don't write back


is it possible to prevent JIRA for Portfolio from writing back changes on Sprint/Release allocation to JIRA? (except of the assignee field)

Thanks and regards,


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.
Jan 31, 2019

HI Phil,

Partially yes but overall no.  You can deselect specific issues with changes to push back via the commit, but you cannot itemize which changes are committed.  All changes to a single issue are pushed in a single update event as an all or noting commitment to the changes.

Say you select an assignee for an issue on one issue and change story points on a second issue you can deselect the issue that is updating the story point so that only the change to the assignee is pushed on the commit, but if you make a change to the assignee and story point on the same issue both changes are committed in the update value, as a single update event for that issue.

If your looking for a way to finalize partial information commitments as you go, say you know that 'User_A' is defiantly going to do the work but you have not decided on the release or sprint or story points yet its best to do the assignment of the user as a one off update directly to the issue.


Hi Earl,

thanks for the reply.

So I can play around with releases for an issue or the team-allocation in my Portfolio Plan without committing these changes to JIRA. Pressing the "calculate" button changes the schedule of my plan but not the values in the JIRA project, right?



Earl McCutcheon
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Feb 01, 2019

Hi Phil,

Thats Right, calculate will update the data in the scope in Portfolio, but will not push any changes back to The Jira issue that was modified in the plan until you commit.

One more thing that may be useful for you if your making periodic changes as well is Multi Scenario Planning, where you can make multiple sets of changes to compare the results then commit the changes of the scenario that gets the optimal schedule.


Hi Earl,

thanks for the reply.

If I change the target and start date in my Portfolio Plan manually (e.g. for issues that are not assigned to releases) and commit these changes: how will this influence the issues in JIRA?



Earl McCutcheon
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Feb 15, 2019

Hi Phil,

Target dates are portfolio specific fields acting as a visual indicator for high level estimation comparison to the calculated schedule, and do not directly impact the start dates but are used to compare the actual schedule to the estimate to see how close the actual is to the target.  With Target dates the only visual change you would see in the main schedule is that unestimated issues without a release will show up as Light blue work items in the schedule, but this will not affect the date used to calculate the schedule and are calculated as unestimated items without a defined Scheduled Start Date.

As for the schedule Adjusting Earliest start date can push the calculated date to the later date, Earliest start dates do have manual adjustments and will have impact on the schedule date.  When calculating in Portfolio it will always start the algorithm from the point the calculation was run and adjust on the modifiers that have been applied (the items listed in Scheduling behavior), so even if you have earliest start date as yesterday and calculate today the calculation runs from today as the issue is not considered started until the sprint starts. If you want to set fixed dates, you can adjust the earliest start to a later date to define a future sprint for the issue to be added to at the earliest point But if you want to set an earlier date you create a sprint on your agile board with a custom start date so that the calculation pulls in the fixed dates before it starts to calculate the remainders at that point forward.


Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events