JIRA Agile features are now available in the standalone application JIRA Software. Please upgrade to the latest version of JIRA Software to get all the latest and greatest features. Visit the Migration Hub for more information, or see the Administering JIRA Applications documentation.

Configuring Estimation and Tracking

(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.

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 the Backlog: (Note that the 'Estimate' field is editable when an issue is in the Backlog, but not editable once the issue moves into the Active sprints.)
  • 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 the Active sprints/Kanban board:
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. Navigate to the desired board, then click Board > Configure.
    (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 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.

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. Navigate to the desired board, then click Board > Configure.
  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.

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

48 Archived comments

  1. User avatar

    Laszlo Kremer

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

    22 Aug 2013
  2. User avatar

    randy chevalier

    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.

    29 Aug 2013
  3. User avatar

    Joshua Anderson

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

    05 Sep 2013
    1. User avatar

      Benjamin Hahne

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

      07 Feb 2014
      1. User avatar

        Dmitry Tsinin


        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?



        15 Apr 2014
        1. User avatar

          Benjamin Hahne

          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.

          15 Apr 2014
  4. User avatar

    Marko Majkic

    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.

    11 Sep 2013
  5. User avatar

    geoffrey emery

    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?

    16 Sep 2013
  6. User avatar

    Dan Fernandez

    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?

    08 Oct 2013
  7. User avatar

    Jonathan Horvath

    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".

    24 Oct 2013
  8. User avatar

    John Paz

    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?

    08 Nov 2013
  9. User avatar


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

    04 Dec 2013
    1. User avatar

      Andrew Lui [Atlassian Technical Writer]

      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.


      04 Dec 2013
      1. User avatar


        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!

        04 Dec 2013
  10. User avatar

    Mike Sorensen

    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". 

    07 Jan 2014
  11. User avatar


    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)


    11 Mar 2014
    1. User avatar

      Andrew Lui [Atlassian Technical Writer]

      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,

      11 Mar 2014
      1. User avatar


        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 ?

        11 Mar 2014
  12. User avatar

    Darren Pegg

    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?



    20 Mar 2014
  13. User avatar

    Matt Doar [ServiceRocket]

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

    15 Apr 2014
  14. User avatar

    Prashant Tajne

    We have 3 developers in the project, who can work on 40hours per week. If three issues of 40hours each are assgined to each developer, the sprint end date is still shown 3 weeks after sprint start date. Is there something i am missing in configuration?

    15 Sep 2014
  15. User avatar

    Stephan Raidt

    I seem to have a general problem with story points with JIRA Agile. I managed to be able to use estimation of story points for tasks. So for instance when i select a task in my backlog, information about it appears to the right of the sceen, where I can work on fields directly, such as  writing comments  for instance. Here I also can estimate story points. However when I open the menue where I can edit all fields, there is no possibilty to estimate story points. There are only fields to estimate time in days and hours.

    What bothers me more is that  I could not figure out how to estimate story points for subtask. The only thing I managed to estimate for subtasks is time. So I tried the same with stories instead of tasks and it works pretty much the same way. Still, if I define a subtask to a story there is no way to estimate story points for it.

    I ment to work with stories or tasks, that consist of subtasks. I planned to drag all subtasks belonging to a story or task from "open" to "in progress" to "done" on the Scrum board until all of them are done, and than drag the story to done as well. This works all right There is however no usefull information in the reports unless I estimate a time for each subtasks. If I dont, there is just no information about the work completed on subtasks, no matter how many subtasks I move to the done column. I hope to find sombody who could explain what is wrong.

    24 Sep 2014
  16. User avatar

    Stephan Raidt

    Very funny! I configured in Agile that for new subtasks, an estimation of story points is required. Just there is no field where I could enter any such estimation. This means I cannot open any new subtask with this configuration!?

    26 Sep 2014
  17. User avatar

    Grover Jackaon

    I'm having some issues with "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); "

    What determines "completed"?

    I've got two status (done and released) that I've grouped into the done column on our scrum board, but only one of those (released) is being treated as "completed" for burn down which is screwing with all my reports. How do you configure scrums idea of completed?

    Worse, the burndown chart report only treats one of the status as done, while the sprint report treats both of them as done.

    02 Oct 2014
    1. User avatar

      Andrew Lui [Atlassian Technical Writer]

      Hi Grover,

      Can I ask you to get in touch with support (see Getting Help)? Statuses that are in the 'Done' (i.e. right-most column) of your board should be treated as "completed" for the burndown chart (like the sprint report is doing).

      Kind regards,

      23 Oct 2014
  18. User avatar

    Suresh Kumar

    Is it possible to make "Estimate" field as  mandatory before an issue is added to a sprint?


    20 Oct 2014
    1. User avatar

      Andrew Lui [Atlassian Technical Writer]

      Hi Suresh,

      Unfortunately, this is not possible. You can raise this as a Suggestion in our issue tracker, if you like.

      Kind regards,

      23 Oct 2014
  19. User avatar

    Suresh Kumar


          Is it possible to make "Story Points" field as  mandatory before an issue is added to a sprint?

    24 Oct 2014
    1. User avatar

      Andrew Lui [Atlassian Technical Writer]

      Unfortunately, this is not possible either. Basically, when you add an issue to a sprint, you are setting the value of the Sprint field for the issue. It's not possible to configure JIRA or JIRA Agile to make a field mandatory before another field is updated.

      Kind regards,

      27 Oct 2014
      1. User avatar

        Suresh Kumar

        Thanks for reply Andrew.

               So what is the best way you are suggest to me achieve this one in JIRA or JIRA Agile.

        Either making JIRA field "Story Points" or JIRA Agile "Estimation" as mandatory before issue added into Sprint.

        Can I include any Post Function or Custom Scripts to validate unestimated issues?

        28 Oct 2014
        1. User avatar

          Andrew Lui [Atlassian Technical Writer]

          Unfortunately there really isn't any way of doing this in base JIRA, that I can think of. Post functions won't work, as adding an issue to a sprint is not a workflow function. You could try writing a custom script, but that's not really my area of expertise. You may be able to find further assistance on our forums at https://answers.atlassian.com

          30 Oct 2014
  20. User avatar


    Hello! Could you help me? 

    Is it possible in JIRA make Calculated Number Field as a Estimation statistic? It works fine with Number Field, but I can not do it with Calculated Number Field.

    18 Nov 2014
    1. User avatar

      Matt Doar [ServiceRocket]

      Which add-on provides the custom field type "Calculated Number Field"? Perhaps https://marketplace.atlassian.com/plugins/com.innovalog.jmcf.jira-misc-custom-fields

      I've created custom field types in the past in my own add-ons that extended the Number custom field type and that worked for Estimation I think, but that's another add-on.

      18 Nov 2014
      1. User avatar


        Yes, I use JIRA Misc Custom Fields. May be you remember which plugin you used, that alloweded you to use Calculated Number Field as Estimation Statistic?

        Actually the problem I try to resolve is to configure agile sprint for Design department based on "Design subtask" and "Analysis subtask" and Development sprint based on "Backend subtask", "Frontend subtask", "QA subtask".

        19 Nov 2014
        1. User avatar

          Matt Doar [ServiceRocket]

          It was a custom add-on written for a ServiceRocket customer, sorry. I'd take the actuall problem to answers.atlassian.com for more answers

          19 Nov 2014
  21. User avatar

    James Strangeway

    Does the burndown report only consider the fields at the issuetype Story level?  Is it possible to configure the  burndown to use the sub-task estimate?

    25 Nov 2014
    1. User avatar

      Mina Elnaccash

      I am curious about this as well. Does burndown take the story into consideration, or the sub-tasks or both?

      We have also been sizing sub tasks to get a sense of overall story size in some cases. When a story and its sub-tasks are sized, are we double counting points when all are marked done?

      02 Dec 2014
  22. User avatar

    Iain Smith

    Hi there, I have configured JIRA agile so that I have EPICS, STORIES and SUBTASKS. I have changed the tracking statistic to Original Time Estimates, but I would like this value to be ROLLED UP from the estimates of all the subtasks in the user story. At the moment, neither the user stories or the sub tasks are allowing me (or more importantly my team) to directly add subtasks with "Original Estimates". I can add remaining estimates, but I want them to add initial estimates to let me size the user stories for a sprint.

    At the moment I don't seem to be able to add this field to my sub tasks. How can I do this?

    I have experience of this working in Greenhopper, but have recently moved to a new company.

    27 Nov 2014
  23. User avatar

    Jennifer Bursack

    Ian - There is a longstanding enhancement request that continues to gather customer feedback without grabbing the attention of an Atlassian/JIRA product owner. With ongoing/active feedback, I live in hope that this will issue will get prioritised and addressed. Please add yourself to the 'Watcher' list, and comment as appropriate.  GHS-9167 - Sum estimates from sub-tasks in user stories Open

    17 Dec 2014
  24. User avatar

    Patrick Sittinger

    Hi there, i have a planing issue with JIRA that everyone has, i think.

    When planing the first sprint within the planing mode of an agile board, everthing runs smooth. I have all my stories, estimations (in hours! an agile gap, i know), i started the sprint and the team worked for 2 weeks. After 2 weeks we set the sprint to complete and some stories were not finished. Everything still fine because those uncompleted (but with work logged) stories are in my backlog.

    Here comes the issue: When planing sprint 2, i get only original time estimates but i need remaining estimates because some uncompleted stories have work logged.

    How to handle a list of stories where i can not see the real remaining time in planing mode? 

    27 Jan 2015
    1. User avatar

      Martin Jopson [Atlassian]

      Patrick Sittinger, it's possible to add Remaining Estimate (∑ Remaining Estimate for sum from sub-tasks) to the issue by Customising Cards. There is a Suggestion for this tracked at  GHS-5794 - As a user, I want to associate "Remaining Estimate" as the Estimation Statistic on an agile board Open  .

      Kind regards,
      JIRA Agile

      28 Jan 2015
      1. User avatar

        Dennis Guse

        Martin Jopson [Atlassian] I've tryed to work around that issue with setting up a scripted (using ScriptRunner) customfield, that uses the getEstimate() Method - unfortunately I only get a result in milliseconds, and in the end I realized that scripted fields are not appearing in the dop-down select list of my agile board's configuration. It rly looks like only standard number formatted fields are supported but those have a wrong datatype for my case; also no float datatypes are supported. I wonder how you brought this to work with the "Remaining Estimate" field ?? Perhaps you can put the suggestion GHS-5794 from above on the fast lane, would be rly nice.    

        28 Jan 2015
  25. User avatar


    I have 7 developers and 1 QA person and each can handle various hours per week but the burndown chart does not reflect this accurately.  Is there a way to make sure each developer is properly associated with the sprint?  How do I assign a total available hours to the sprint?  Basically, I would like to Configure Working Days by being able to add resources and available hours per week.  Is that possible?

    21 Apr 2015
  26. User avatar

    Susan Price

    When I import stories and epics into JIRA, I want to import into the Story Point field. Currently, I can only import into Original Estimate field which takes time as seconds. An reason that Story Points does not show up in the import mapping wizard as a field into which data can be imported?

    27 May 2015
  27. User avatar

    Grzegorz Reglinski

    Situation: I estimating in Story Points, I create task and estimating it for 10 SP. After 1 day of work I would to insert to "remaning" field a number "8", after another day I will put "5"

    is it possible to do that?

    09 Sep 2015
    1. User avatar

      Marion Rosner

      Hi Grzegorz Regliński, what we do is we estimate story points for the top-level story or issue, then when we break the issue down into sub-tasks during sprint planning, we assign estimated hours to each sub-task. When the developers work on a sub-task, they then use the "Log Work" functionality of JIRA to show how much time each sub-task has actually taken. We never change the story points. Does that make sense?

      09 Sep 2015
      1. User avatar

        Grzegorz Reglinski


        Why I can estimate story in SP but after kick off sprint i must changing my thinking conception to time unit? In my opinion it's wrong, becouse If I estimate story i.e. for 8 points and after that i must think in time (how much time is left to complete the story/issue/bug?)

        This is wrong idea and conception. If I choose to estimating SP I should be able to insert in remaining field also in SP (not in time)

        09 Sep 2015
  28. User avatar

    Christopher McGinnis

    I've read the blog post. I get that tracking is different from estimate.  I also get that estimation is moving away from being time based.  However, be it story points or time, aggregating sub task estimates into the parent task's original estimate is highly desirable.  Because sub tasks are more fine grained they can give a more accurate estimate of effort when compared to estimating the parent task alone.

    I can add the aggregate "Σ Original Estimate" for display on a per parent task level.  Users should be able to have the value specified by "Σ Original Estimate" show up in the estimation bubble and aggregate to the sprints estimation level.

    The point of the matter is this: After reading many posts and comments it seems that the users REALLY want to have the estimations of subtasks display in the estimation bubble.  Since there is already a fields option to display that information would it really be so hard or so bad to have that capability?

    11 Sep 2015
Powered by Confluence and Scroll Viewport