/
Global Teams Configuration

Global Teams Configuration

Overview

The Teams Configuration lets you configure:

  • which fields are used to specify the dates and estimates of issues

  • how to configure a team’s velocity (so that percent compete can be calculated)

This configuration can happen on multiple levels:

  • Globally across all teams and issue types

  • Across all issue types for a single team

  • For a specific issue type for a single team

image-20250211-033259.png

How the Team is Selected

Each issue is mapped to a team value. The team value determines how values from that issue will be read. If the issue does not have a team value, then the issue’s project key will be used.

Date Form Controls

The following controls how Status Reports know when an issue starts and ends.

Start Date Field

image-20250212-220936.png

Set the Start date field to the Jira field that represents when the issue is expected to start.

Defaults to:

  • Start date

End Date Field

Status_Reports_for_Jira.png

Set the End date field to the Jira field that represents when the issue is expected to end.

Defaults to:

  • Due date

Estimate Form Controls

The estimate form controls help calculate the amount of work in days an issue might take. The following table provides some examples of the results of different values:

Estimate

Confidence

Adjusted Estimate

Velocity

Sprint Length

Tracks

Points Per Track per Day

Days

Estimate

Confidence

Adjusted Estimate

Velocity

Sprint Length

Tracks

Points Per Track per Day

Days

10

100%

10

20

10

1

2

5

10

100%

10

20

10

2

1

10

10

50%

18

20

10

1

2

9

Estimate Field

image-20250212-221556.png

The estimate field is a number field that provides some sort of estimate of the amount of work on the issue. This will be converted to days of work using the Confidence, Sprint Length, Velocity per Sprint, and Tracks fields.

Defaults to one of the following fields if they exist:

  1. Story points median

  2. Story points

Confidence Field

The confidence field adjusts the estimate using a log-normal distribution. Learn more about this here.

Defaults to the following fields if they exist:

  1. Story points confidence

  2. Confidence

If you are not using confidence, you can set this field to: “Don’t use confidence” as shown below:

image-20250212-221518.png

Velocity

How many “estimate units” are completed by the whole team every sprint. This number depends on how your team is estimating work. The following give some examples of what the velocity would be in different estimation approaches:

Approach Name

Description

Example Estimate Values

Example Velocity

Approach Name

Description

Example Estimate Values

Example Velocity

Story Points

How many story points would you estimate for this work, based on its complexity and effort?

Story points are an abstract unit of measure used in agile development to estimate the complexity, effort, and risk of a user story. They help teams focus on relative sizing (rather than strict time estimates), making planning and prioritization more flexible.

A team might estimate an issue as 8 points, using other issues and their points as a frame of reference.

For the past 5 sprints, the team has averaged completing 23 points a sprint. The velocity would be 23.

Combined Days

How many combined total days of work will the issue take across all team members?

The work will require 2 days of designer time, 5 days of developer time, and 1 day of QA time, for a total of 8 days.

There are 5 team members in total, and each sprint lasts 10 days. Each sprint completes 50 days of work. The velocity would be 50.

Team Days

How many days of work the issue will take if the entire team is working on the issue and is able to be fully utilized?

The work will take 12 days if the entire team is working on just the issue and nothing else.

If a sprint lasts 15 days, there are 15 “team work days” each sprint. The velocity would be 15.

Half Team Days

How many days of work the issue will take if half the team is working on the issue?

The work will take 24 days if the entire team is working on just the issue and nothing else.

If a sprint lasts 15 days, there are 30 “half-team work days” each sprint. The velocity would be 30.

Team Weeks

How many weeks of work the issue will take if the entire team is working on the issue and is able to be fully utilized?

The work will take 3 weeks if the entire team is working on just the issue and nothing else.

If a sprint lasts 15 days, there are 3 “team work weeks” each sprint. The velocity would be 3.

Sprint Length

How many days each sprint takes. This is typically a multiple of 5. For example, use 5 for a one-week sprint.

Sprint length defaults to 10 for a two-week sprint.

Tracks

Status_Reports_for_Jira.png

The tracks field specifies the average parallel tracks of work the team works on at once. For example, if the team works on about 4 stories at once, you should set the tracks to 4 for stories. Your team might have different values for epics and other issue types.

Tracks is used to calculate the number of days of work the issue might take. Consider the following values for an issue:

  • Story Points: 20

  • Velocity: 40

  • Tracks: 1

  • Sprint Length: 10

StatusReports will calculate the issue will take 5 days. It assumes the entire team is working on that issue. If instead, your team typically works on two of these issues at once (tracks = 2), then StatusReports will calculate the issue takes 10 days.

Spread Effort

image-20250213-031536.png

The Spread Effort toggle spreads the estimated effort across the start and end date timeframe. This is used to alter the Percentage Completion calculation.

For example, if Spread Effort is turned off, and an issue has a start and end date, then the amount of work will be the number of business days between the start and end date.

If Spread Effort is turned on, then the amount of work will be the number of days of work calculated using the Estimate, Confidence, Sprint Length, Velocity, and Tracks fields.

For more information read Percentage Completion.

Turn Spread Effort on if the other estimate-based fields are correctly configured for the team. This will typically provide the most accurate percentage completion information.

 

 

 

 

Related content