Configuring estimation and tracking
Before you begin
To configure the board and any of its settings, you must be either:
- a project administrator for the location of the board
- a board administrator for the board itself
See Permissions overview for more information.
Note that you can only configure estimation and time tracking for Scrum boards.
Setting estimation statistic and time tracking
- Go to your board, then select more (•••) > Board settings.
- Click the Estimation tab.
In the Estimation Statistic field, choose one of the following options:
Estimation will be based on the number of story points per issue. This is the most commonly used option.
By default, the 'Story Points' field is only available to issues of type 'story' or 'epic' (not 'bugs' etc). If you want to change this, do the following:
1. Associate the 'Story Points' field with other issue types, see custom field context (Jira admin documentation).
2. Specify the screens that the 'Story Points' field should be displayed on, see Defining a screen (Jira admin documentation).
Original time estimate
Estimation will be based on the Jira 'Original Time Estimate' field (see Logging time on issues for more information). By default, this is specified in minutes, but you can use hours, days, or weeks, depending on your Jira system configuration. See Configuring time tracking (Jira admin documentation).
Issue count Estimation will be based on the number of issues in the sprint. The 'Estimate' field will not be editable. <Custom field>
Estimation can be based on any numeric custom field in your Jira system.
In the Time tracking field, choose one of the following options:
Tracking will be based on the estimation statistic that's selected.
Remaining estimate and time spent
Tracking will be based on the remaining time and time spent fields (see Logging time on issues for more information). By default, these fields are specified in minutes, but you can use hours, days, or weeks, depending on your system configuration. See Configuring time tracking (Jira admin documentation).
This is fundamentally different from using the estimation statistic for burndown, in that values don't burn down when an issue is completed. Instead, values only burn down when users enter time spent or set the remaining estimate to a new value.
More information about estimation and time tracking
Product teams often need to be able to estimate how long a product will take to deliver. This is difficult because the backlog may stretch many months into the future, so the team can only provide a very rough estimate in conditions of uncertainty without wasting days breaking the work down. However, from sprint to sprint, as they work through the stories, the team will develop a cadence of completing <x> units of work they had roughly estimated—their velocity.
This means they can accurately estimate how long portions of the backlog will take to get done with simple, rough estimates. However, to make this work, the team needs to estimate stories with a consistent level of uncertainty. The team also needs to track the amount of estimation units they have actually fully completed from sprint to sprint, because this number tells us with relative certainty how much we can fit into each future sprint.
How the estimation statistic and tracking statistic affects your project
In Jira Software, you can choose which type of units (story points or time, for example) will be used for estimating and tracking issues. You do this by choosing an estimation statistic, then choosing to either use the same units for your tracking statistic or to use time tracking. Each board can have a different type of estimation statistic and tracking statistic.
The type of estimation statistic you choose affects the estimate field that appears above show more in the issue details view.
- Selected issue: Choose an issue to see its details on the right side.
- Estimation field: Enter Story points or Time estimate depending on your estimation statistic.
The issue estimate appears in the bottom left of each issue in Active sprints:
Issue cards have three layers of information that are stacked on top of each other, and are always stacked in the same order:
- Issue summary.
- Custom fields added to the card.
- Other related issue information, including issue type, priority, assignee, and estimate.
How you can view your velocity and burndown
A team's velocity is based on the estimation statistic— for each sprint, the velocity is the sum of the estimation statistic for completed stories. Velocity is shown in the Velocity Chart and on the Sprint Report, in the Estimate Statistic column header of the Completed Issues table (for example, "Story Points (12)" means that 12 story points were completed in that sprint).
Values for each issue are recorded at the time when the issue moves into the sprint. Changing the estimate value afterwards won't be reflected in the Sprint Report, but will be shown as scope change in the burndown. Velocity is also used in the Version Report, to predict release dates.
The Burndown Chart is based on the estimation statistic. If you're using story points as your estimation statistic, the Burndown chart shows the story points per story (stories burning down the estimation statistic are only burnt down on the graph as they are completed). If you choose the time-tracking option, you're shown partial burndown (the number of hours currently used and remaining each day).
When using the Burndown Chart, note that subtask behavior can vary, depending on whether or not remaining estimate and time spent is enabled for your board.
|Subtask behavior when remaining estimate and time spent is enabled||Subtask behavior when remaining estimate and time spent is disabled|
If you add a subtask to an issue that's already in an active sprint, the subtask is treated as scope change.
The scope change is also indicated in the Burndown Chart.
If you add a subtask to an issue that's already in an active sprint, the subtask is also treated as scope change.
However, scope change is not indicated in the Burndown Chart for the subtask.
Time estimates of subtasks are rolled up to the parent task.
This means that the parent task will have the total sum of all remaining estimates of the subtasks.
|Time estimates are tracked individually across the subtasks and the parent task itself.|
See Burndown Chart for more details.
Getting help. Need help? If you can't find the answer you need in our documentation, we have other resources available to help you. See