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
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
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
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 |
---|---|---|---|---|---|---|---|
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
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:
Story points median
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:
Story points confidence
Confidence
If you are not using confidence, you can set this field to: “Don’t use confidence” as shown below:
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 |
---|---|---|---|
Story Points | How many story points would you estimate for this work, based on its complexity and effort? | A team might estimate an issue as | For the past 5 sprints, the team has averaged completing 23 points a sprint. The velocity would be |
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 | There are 5 team members in total, and each sprint lasts 10 days. Each sprint completes |
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 | If a sprint lasts 15 days, there are 15 “team work days” each sprint. The velocity would be |
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 | If a sprint lasts 15 days, there are 30 “half-team work days” each sprint. The velocity would be |
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 | If a sprint lasts 15 days, there are 3 “team work weeks” each sprint. The velocity would be |
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
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
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.