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
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.
The following controls how Status Reports know when an issue starts and ends.
Set the Start date field to the Jira field that represents when the issue is expected to start.
Defaults to:
Start date
Set the End date field to the Jira field that represents when the issue is expected to end.
Defaults to:
Due date
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 |
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
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:
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 |
How many days each sprint takes.
On average, how many parallel issues of this type the team will work on at once.
Projects can be set up completely differently across a Jira instance. The fields that represent dates can also vary across issue type.
In order to report on dates, the tool needs to know which date fields it should use.
In order to calculate percentage completion, the tool needs to know which field holds the estimate, the team’s velocity per sprint, and how long a sprint lasts.
⁃ It also