Configuring team settings

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

This page discusses the usage of Portfolio for Jira live plans. If you're using the redesigned planning interface, see this page instead.

You can configure the scheduling methodology, and the velocity or the weekly capacity of the teams associated with your plan.

Configuring the scheduling methodology of a team:

  1. Go to your plan via Portfolio (in header) > View Portfolio > click your plan.
  2. In your plan, click the Teams tab to display the teams section below the timeline.
  3. In the Teams section, find the team whose settings you want to configure, then expand the team to view its details.
  4. From the upper-right section of the selected team, click the scheduling methodology menu.
  5. Select from one of the following methodology options:
    • Scrum, if the team works in sprints or fixed iterations, then specify the number of weeks that comprise a sprint. If you want to define the default value for your sprints, see Configuring scheduling settings.
    • Kanban, if the team works in a continuous schedule.
      (info) If your plan uses story points for estimation, the Kanban option won't be available. See Configuring scheduling settings to know more about changing the planning unit of your plan.
  6. Commit the changes back to your Jira Software instance.

Configuring team velocity

If you're using story points for estimation, you will see the following details about your team:

1Team velocity
  • The number of story points the team completes in each sprint.
  • You can set a value for team velocity if needed.
2Forecasted velocity

The team velocity that's forecasted for the next few sprints, based on:

  • the team's performance over past sprints
  • the availability of your team members

Note that the default availability of each team member has an impact on forecasted velocity. See the example below for more details.

3Past velocity
  • The team velocity over past sprints in gray bars, and the suggested velocity for the next sprint in a blue bar.
  • You can choose to use the suggested velocity, if it's a realistic value for your team.
  • To see past velocity, the issue source of your team must be a Jira board.

Configuring weekly capacity

If you're using time-based estimates, the weekly capacity of your team is the total sum of the weekly hours of each team member. You can configure the weekly hours of each member in your team, to get your team's overall weekly capacity.

To configure weekly hours of a team member:

  1. In the Teams section, from the Weekly hours column, click the row of the team member whose hours you want to configure.
  2. Enter the weekly hours for the member.
  3. Commit the changes back to your Jira Software instance.

Impact of team member's default weekly hour availability on forecasted velocity

For all the members in a team, their default availability of weekly hours will be used in distributing story points when the team's velocity is defined in story points.

Let's say, for example, your team is comprised of three members, and the team velocity is set to 100 points.

Note that in this example, this is how the equivalent story points are calculated:

Team velocity x (Individual availability/Total team availability)

Team memberDefault availabilityStory point equivalent
Alana40 hours

50

100 pts x (40h/80h)

Emma0 hours0
Will40 hours50
TOTAL80 hours100 pts


While planning work for this team, this is how individual availability is configured for sprints 1 and 2. Note that even if Emma has a default availability of 0 hours, she's available for 40 hours during sprint 2. Because of this, 50 pts are now distributed to each team member in sprint 2, and the total pts would now be 150 pts.

Team member

Sprint 1 availability

Sprint 1 SP equivalent

Sprint 2 availabilitySprint 2 SP equivalent
Alana40 hours50 pts40 hours50 pts
Emma0 hours0 pts40 hours50 pts
Will40 hours50 pts40 hours50 pts
TOTAL80 hours100 pts120 hours150 pts


Following the above example, if you lower the default availability of Alana to 10 hours, this will happen throughout sprints 1 and 2:

Team memberDefault availabilityStory point equivalent

Sprint 1 availability

Sprint 1 SP equivalent

Sprint 2 availabilitySprint 2 SP equivalent
Alana↓ 10 hours

20 pts

100 pts x (10h/50h)

10 hours20 pts10 hours20 pts
Emma0 hours0 pts0 hours0 pts40 hours80 pts
Will40 hours

↑ 80 pts

100 pts x (40h/50h)

40 hours80 pts40 hours↑ 80 pts
TOTAL50 hours100 pts50 hours100 pts90 hours180 pts

Because Alana's default availability dropped to 10 hours, Will's story point equivalent will need to increase to 80 pts. This is to compensate for the missing points that are needed to reach the team's velocity of 100 pts.

Consequently, even if Alana's hours dropped, the forecasted velocity will increase, which is a reflection of Will's story points increasing during the two sprints.


Following the above example, if you increase the default availability of Alana to 60 hours, this will happen throughout sprints 1 and 2:

Team memberDefault availabilityStory point equivalent

Sprint 1 availability

Sprint 1 SP equivalent

Sprint 2 availabilitySprint 2 SP equivalent
Alana↑ 60 hours

↑ 60 pts

100 pts x (60h/100h)

↑ 60 hours↑ 60 pts↑ 60 hours
↑ 60 pts
Emma0 hours0 pts0 hours0 pts40 hours40 pts
Will40 hours

40 pts

100 pts x (40h/100h)

40 hours40 pts40 hours40 pts
TOTAL100 hours100 pts100 hours100 pts140 hours140 pts

Because Alana's default availability increased to 60 hours, Will's story point equivalent can stay at 40 pts. Consequently, the forecasted velocity will decrease because Alana now has increased capacity and availability to work for 60 weekly hours.

Last modified on Apr 5, 2020

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.