What is exactly committed to an issue when assigning a different team in Portfolio?

[Rik Verstijnen]

At our company, we have several JIRA projects. A few teams work on all the projects together; they have boards which filter out the issues of one or more projects. JIRA Portfolio introduces the concept of a "Team", which does not explicitly exist in JIRA. We have entered our teams and connected them to their consecutive boards. Using Portfolio, we would like to manage the development capacity over time by moving issues from one team to another. We don't want to assign issues to individual people or sprints; we just want to move them to the backlog of another board.

If we assign an issue to a different team Portfolio wants to commit that change to JIRA, but what exactly is committed then? The issue still appears on the same board as before, because it still matches the filter criteria of that board.

[Konstantin Mitov [Botron]]

Hi Rik,

Commiting the change will change the assignee if the new team users can see the board, but it will not change the board the issue belongs to.

[Rik Verstijnen]

Hi Konstantin,

Thank you for your answer. In the situation I am referring to however, an issue was not assigned to anyone yet. In Portfolio, we only assign a team - not yet a team member. When committing this change, the activity trail on the issue in JIRA does not show any changes. It looks like this value is only stored in the Portfolio repository.

In that case, I am curious how this relates to the Agile pull-based development. As a portfolio manager, I only would like to do some load balancing between backlogs and releases. I still want the teams to be able to pull work from their backlogs each sprint within a release. How does your company do that?