Skip to end of metadata
Go to start of metadata

(info) This page only applies to Scrum boards.

About Estimation and Tracking

Many Scrum teams separate estimation (which is used for measuring the size of a backlog and calculating velocity) from tracking (which is often the burndown of hours used during the Sprint to be sure we're not way off the pace necessary to complete the stories in the Sprint timebox), and use different units for each. A common approach is to estimate tasks in Story Points, then track tasks using hours. JIRA Agile therefore gives you the flexibility to set your estimation and tracking statistics differently, depending on what best suits your team.

Product teams often need to be able to estimate how long a product will take to deliver. This is tough 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 'rough estimated', i.e. their velocity. This means that they can relatively accurately estimate how long portions of the backlog will take to get done with simple rough estimates that the team can produce way before they even consider doing them. 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 is the one that tells us with relative certainty how much we can fit into each future sprint and have conviction that they will all be completed.

On this page:

Related pages:

Choose your own Estimation Statistic and Tracking Statistic

In JIRA Agile, you can choose which type of units (e.g. Story Points, Issue Count) 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 select affects which units are used by the 'Estimate' field, which appears at the right of each issue in Plan mode: (Note that the 'Estimate' field is editable when an issue is in Plan mode, but not editable once the issue moves into Work mode.)
  • The type of Tracking Statistic you select affects which units are used by the 'Remaining' field, which appears at the bottom right of each issue in Work mode:
View your Velocity and Burndown

A team's velocity is based on the Estimation Statistic — ie. for each sprint, the velocity is the sum of the Estimation Statistic for completed stories. Velocity is shown in the Velocity Chart and also on the Sprint Report, in the Estimate Statistic column header of the "Completed Issues" table (e.g. "Story Points (12)" means that 12 Story Points were completed in that sprint). Please note that the values for each issue are recorded at the time when the issue moves into the sprint. Changing the Estimate value afterwards will not 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 Sprint Burndown Chart is based on the Tracking Statistic. If you are using Story Points as your Tracking Statistic, then the Burndown Chart shows the Story Points per story (ie. stories burning down the Estimate Statistic are only burnt down on the graph as they are completed); whereas if you choose the Time-tracking option you are shown partial burndown (ie. the number of hours currently used and remaining each day).


Setting the Estimation Statistic

To set the Estimation Statistic for a board:

  1. Select Agile > Manage Boards from the top navigation bar, then click the Configure link corresponding to the board of interest.
    (info) Note that only the administrator of a board (or a person with the 'JIRA Administrators' global permission) can configure a board.
  2. Click the Estimation tab.
  3. In the Estimation Statistic field, choose one of the following options:

    Estimation Statistic:


    Story Points

    Estimation will be based on the number of Story Points per issue. This is the most commonly used option.

    ((info) Note that, by default, the Story Points field is only available to issues of type 'Story' or 'Epic' — you can change this as described in JIRA Agile - JIRA Configuration.)

    Business Value

    Estimation will be based on the Business Value of each issue.

    Original Estimate

    Estimation will be based on the JIRA 'Original Estimate' field (for details see the JIRA documentation Logging Work on an Issue). By default this is specified in minutes, but it can be hours/days/weeks depending on your JIRA system configuration (for details see the JIRA Time Tracking documentation).

    Issue CountEstimation 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.

Screenshot: the 'Estimation' tab (click to enlarge)


Enabling Time Tracking

If you enable time tracking, you will be able to view the remaining time estimate for an issue (and its sub-tasks), when viewing an issue.

To set the Tracking Statistic for a board:

  1. Select Agile > Manage Boards from the top navigation bar, then click the Configure link corresponding to the board of interest.
  2. Click the Estimation tab.
  3. In the Time Tracking field, choose one of the following options:

    Tracking Statistic:



    Tracking will be based on the Estimation Statistic.

    Remaining Estimate and Time Spent

    Tracking will be based on the JIRA 'Remaining Estimate' and 'Time Spent' fields (for details see the JIRA documentation Logging Work on an Issue). By default these fields are specified in minutes, but you can use hours/days/weeks depending on your JIRA system configuration (for details see the JIRA Time Tracking documentation).

    Note that this is fundamentally different from using the Estimation Statistic for burndown in that values do not 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.


  1. Why does Sprint Report ignore Bug estimation changes although Story Point field is added?

  2. regarding the above question "Why does Sprint Report ignore Bug estimation changes although Story Point field is added?"

    You want your sprint report to show progress against your plan of committed stories (i.e. story = incremental value). Bugs are a tax on progress (bug fixes do not equal incremental value). As such, you don't want your sprint report to report progress on bugs as delivering value. You get the value from delivering the story (not bugs) according to your definition of done.

  3. As a user, bug fixes certainly add incremental value.  In fact sometimes more value than a new feature...

    1. Resolving the defect restored value that has already been accounted for, so no value was added.

      1. Benjamin, 

        I would also vote for that there is a misconception here.

        Adding an estimate to a bug means we keep the velocity consistent between teams and over time. This is not only a matter of bringing value. This is about the notion of the velocity.

        I hope Mike Cohn will be a good reference for you and others who think bugs should not be estimated noe calculated as a part of team's velocity. Please read:

        Another link:

        As for our teams, we definitely need the ability of calculating the velocity in the correct way.

        So please, how do we enable this?



        1. Hi, Dmitry!

          Value and effort are not the same thing, which I guess I haven't really called out in my above post.

          I checked one of our boards and adding points to bugs and putting them in the current sprint causes a scope change to appear on the burndown chart, so I can only guess you need to check your project and Agile Board's configurations to find out why it's not working for you.

  4. Can I have both estimates tracking - in time and in story points? We usually estimate user stories in user story points, but when split to tasks, we use time (hour) estimations for our own benefit. It is useful to have user story points burndown, as well as remaining time burndown.

  5. My Team estimates points for a story and hour breakdown for subtasks. 

    The tasks aggregate the hours to the story level.

    Is there a way to the aggregate of the now story hours at the epic level?

  6. I have 4 developers who can each handle 40 hours per week but my burndown chart shows our total hours available at 80 for the week.  How do I make sure each developer is properly associated with the sprint and how do i give them a total time they can work for that sprint?

  7. Joshua — if your "bugs" are adding more value than a new feature it is likely that you are incorrectly categorizing "enhancements" as "bugs". Be definition a bug only fixes something that is broken in the implementation or something that was missing in the implementation thus helping the feature provide the value originally intended. If it goes beyond that it is not a "bug".

  8. Is there a way to limit a Sprint from starting or to limit a story getting added to sprint backlog until it has a storypoint estimate?

  9. JP

    I don't see "<Custom Field>" as an option in the Estimation Statistic drop down any more.  Was this feature removed?

    1. Hi JP,

      We haven't removed the ability to use numeric custom fields as an Estimation Statistic. If you are having problems with this, please contact support, see: Getting Help.


      1. JP

        Thank you.  I see my problem:  I had to create a new Custom Field of type numeric first, and then it appeared in the Estimation Statistic!  *Sadly, the Estimation Statistic does not automatically add sub task Estimation numbers into the parent Estimation number!

  10. If a team fixes bugs immediately after the bad code was written then the bug fixes don't add value, it's the feature being worked on originally that adds the value. If the bugs are left alone, they grow a life of their own and we start to consider fixing them as adding value also. 

    Bugs from a previous version are an exception and should be considered "Features". 

  11. Is there a way to configure a SCRUM board to consider Resolved tickets as "complete" ? Right now, it considers Closed ones only as complete. According to "purist" Scrum, this is correct, but in our case we want to use the burndown chart for development velocity only (and do not want to include QA)


    1. Hi Lucian,

      I think this is what you want: Configuring Columns. You will want to map the 'Resolved' status to the 'Done' column.

      Kind regards,

      1. Hi Andrew, thanks for your prompt response.

        In my case I have the following flow : 

        (Done is renamed to Complete). So given this workflow, how can I do the map you are mentioning above ?

  12. Hi all,

    Quick Q...

    1. I have an EPIC with no time estimates etc
    2. I have a story that has time estimates related to this EPIC
    3. When that story is resolved is it possible to represent this time in the EPIC?



  13. It seems that Story Points added to an Epic are not counted towards the estimate shown in the Plan board. Is that as intended?