Don't write back

[Phil]

Hi,

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,

Phil

[Earl McCutcheon · Accepted solution]

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.

Regards,
Earl

[Phil]

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?

Regards,

Phil

[Earl McCutcheon]

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.

Regards,
Earl

[Phil]

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?

Regards,

Phil

[Earl McCutcheon]

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.

Regards,
Earl