Releases, teams and member assignments

This page refers to Portfolio classic plans. If you are currently running Portfolio 2.0, please check this link to access the latest page version.

Portfolio for Jira can automatically suggest unoptimized, realistic schedule based on targeted release dates, people's availability and required/available skills. 

Working with releases and team assignments

Once you have defined estimates, your teams and releases, you'll see that backlog items will automatically be assigned to suggested releases and teams/members. 

Everything that is assigned automatically, is depicted by a blue highlighting in the table: 

Release assignments

In the drop-down fields, e.g. for releases, you can select a certain release and thus guarantee that it is scheduled for the current version. This also means that a release can getoverbookedif it has a fixed end date and several "must-have" assignments. 

The automatic assignment of releases is based on the priority ranking of the backlog and the available capacities. Items are only assigned dynamically into releases if a release has a fixed end date. In this case, the scheduling algorithm tries to fit in as many high-priority items as possible into the release, until the target release date is reached. See Timeline and scheduling for more details on the scheduling behavior. 

Choosing Calculate in the drop-down resets the assignment and a possible release will be suggested again automatically as soon as a recalculation is triggered. 

Team assignments

Following the same principle as the release assignment, teams are assigned automatically based on the skills needed for a particular epic/story. You can manually overrule the suggested assignment. 

However, in case the assignment is not realistic, like the team you assigned does not have members who can cover the required types of work, you'll see an error indicating which skills are missing in case of your assignment and the item will not be scheduled. 

 In case there is only one team, the team column is not visible at all, and you'll directly see the members column as a top-level column.

Member assignments

Expanding the team column allowsto seewhich members are assigned to a story. Theoptimizationalgorithm automatically assigns up to a certain number of people to work in parallel on a story (this number is configurable, see below). In some cases, it might be needed as one person does not have all skills needed to complete the full story, in other cases it might simply be preferable based on people's availability. 

Incaseof manual member assignment, you either make a fixed assignment to exactly oneperson,or assign multiple peopleasa "candidate pool".  The assignmentmeans,the scheduling algorithm can pick any one or multiple of the assigned members. It does not mean, that the effort is equally distributed among the assigned members. 

In the example below: George, John and Paul have been manually assigned to work on the story "I want to sign up and login". However, the scheduling algorithm determined that it is better that only George and Paul work on it (for example because John does not even have the necessary skills, or is on vacation at a certain time, or simply needed for other important items). 

Sprint assignments

When a team schedule is set to scrum,and has fixed sprints, you can assign these sprints the backlog using the Sprints menu, or set the sprints to be dynamically scheduled by selecting Calculate. For information on setting fixed sprints for a team, see Working with Teams and Members

Assignment settings

You can limit the maximum number of people that can be assigned to work simultaneously on a story. The default is 5 based on our experience, however, it depends on the granularity of your stories. Incaseof very small stories, it might still not be realistic that five people can do work in parallel.

This setting is essential, since it is one of the main reasons why capacity plans tend to be unrealistic. Taking a very blunt, exaggerated example: There might be 50 people available, and a story requiring 50 man days, but it does not mean the story can completed in just one day, since its unrealistic all 50 people work on the item in parallel.

To set the maximum number of resources:

  1. Go to your plan via Portfolio (in header) > View Portfolio > click your plan.
  2. Click more () next to the plan name > Configure > Scheduling.
  3. Set the maximum number of resources.
最終更新日 2019 年 4 月 4 日


Powered by Confluence and Scroll Viewport.