Configuring team settings

Still need help?

The Atlassian Community is here for you.

Ask the community

You can configure the scheduling methodology, and the velocity or the weekly capacity of the teams associated with your plan. Scheduling methodology refers to the Agile methodology your team follows. It can be Scrum or Kanban and it will impact how Portfolio handles issues. Learn more about Agile

Configuring the scheduling methodology of a team

  1. Go to Portfolio > and select your plan.

  2. 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. In the upper-right section of the selected team, you see either Scrum or Kanban depending on your selection. The team type you have available (it can be either Scrum or Kanban), is based on the board type each team is connected to in Jira.
    • 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 Change your plan unit.
    • 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 Change your plan unit to learn more about changing the planning unit of your plan.
  5. Recalculate your plan and commit the changes to your Jira instance once you're happy with the changes.

Configuring team velocity

Velocity is a measure that shows the amount of work a team can complete during an iteration. In Portfolio, the team's velocity is calculated as an average of the amount of work the team has been able to complete in the past five work iterations.

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

1Team velocity
  • If the team has completed 5 sprints, the value shown will be the average velocity of these.
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.
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

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 team member.
  3. Press the calculate button to recalculate your plan.

If you add the same team member to multiple teams in a plan, you need to manually divide and specify their weekly capacity across the teams.

Example:

In the following case, Leo Ferragamo was working exclusively for the Android team and had 40 hours worth of work assigned to the team. When you add a member to a new team, Portfolio assigns by default, the sum of work hours each person has has available per working day. You can configure the default working hours and days by going to > Configure > Working hours and days.

He is now required to work across the Android and the iOS team. When we add Leo to the new iOS team, Portfolio has automatically assigned 40 hours to Leo to iOS on top of the 40 hours he already had in the Android team and for this reason, we've manually updated his available time in both teams so he can divide the 40 weekly hours between the two teams.


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 hours

150 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 Feb 6, 2020

Was this helpful?

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