I ask because we are looking at Pivotal Tracker, which I believe is a very popular tool for management of Scrum projects, and:

  • There is no ability to add estimates for Tasks
  • They don't seem to have a Sprint Burndown Chart, certainly not one that tracks hours remaining

If using Tasks and updating Tasks with estimated hours remaining is Scrum best practice - why would it be left out of one of the most popular Scrum management tools and why would they not support a Sprint Burndown Chart?

  • Tasks shouldn't exceed two working days unless blocked. On a team of 7 (+/- 2) why would you need to track hours for the task? It's an anti-pattern.
    – Todd A. Jacobs
    Jun 10, 2017 at 17:31

2 Answers 2


I think the answer to your question is a disagreement with your basic premise: updating tasks with estimated hours is not necessarily a "Scrum best practice."

Part of the point of Scrum is to use accurate and empirical data to provide accurate estimates of the amount of work that can be accomplished. In my experience, the best practice is to use User Story Points -- at my firm we use a modified Fibonacci sequence (1/2/3/5/8/13/20/40/100) to estimate each User Story. After a few Sprints, you get a pretty good feel for the velocity of the team.

We use Story Points because they are accurate but not necessarily precise, whereas estimating in hours tends to be the opposite -- teams attempt to put a precise estimate that usually ends up not being very accurate on a task. For a long while, we attempted to estimate stories with points and tasks with hours but the amount of time we spent attempting to put accurate and precise hour estimates on each task was costing us more than it ever got us. Who needs a precise hour estimate when a team can confidently say "We're going to get 35 user story points done this Sprint"?

With regard to the Burndown chart, you have a few options:

  1. Use a Story Point burndown chart which should be provided by a good tool (not sure about Pivotal Tracker, but JIRA does this)
  2. Hand-draw an hours burndown -- we've done this in cases where clients have a very strict budget and we have to keep within a certain allocation.
  3. If you're really stuck on using hours, JIRA gives you the option to make time your primary estimation tool and can give you an hours burndown -- try a different tool.

My strong recommendation is to rethink how you estimate things and switch over to a story point, or relative sizing, method.

The best part about Story Points is, once you get a reasonable amount of time-tracking data, you can start to figure out your median and std deviation of time values for each discrete Story Point rating (e.g., the median 2-pt story takes n hours with a standard deviation of x). While I would never endorse using these measures as metrics or KPIs, I do use a method with these values to baseline estimates for Scopes of Work, in conjunction with other data and analysis of a project.

  • 1
    I believe Pivotal Tracker offers project burnup charts. Burnup charts could be seen as more suitable when the scope is dynamic. Regarding sprint burndown charts, I feel you have offered an excellent rationale. Jun 8, 2017 at 6:46
  • Sorry, I just noticed I didn't mention stories in my question. We start with stories and story points, but the suggestion is we go further and break stories into tasks as per this "common practice":pm.stackexchange.com/a/17499/21483.
    – Dave
    Jun 12, 2017 at 3:56

The Scrum guide says nothing about tracking and updating remaining-hours, nor does it force you to use a burndown to monitor progress. Actually hour-burns is the worst indicator of progress, as it looks good, but does not show uncertainty. You think you are on track, until you miss the mark and see there is a lot of extra work and now you are behind.

Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decision-making.


At the Agile evangelist day in Amsterdam some years back, Jeff Sutherland (founder of Scrum) said if he has to use a tool it would be PivotalTracker, but better would be no tool at all. Also he dislikes tracking hours a lot, calling it time-tracking anti-scrum. He suggest it is the first thing to ban from a company. He suggest tracking hours costs 10% of your development-time as developers hate it, because it is used to steer the wrong signals if used at all.

When talking about deciding on tools for a process I always say: Build processes around (existing) tools, do not find tools for your ideal process, because you will not find it. If you try as a development shop you might even say, the tool does not exist, lets build it ourselves! And now your are in for years of trouble.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.