Sprint Burndown Chart - Different methods for measuring "Estimation" and "Time Tracking"

Question

Hi team,

I am really a bit confused by following paragraph from Atlassian documentation, please also see the attached screenshot:

"Many Scrum teams separate estimation—used for measuring the size of a backlog and calculating velocity—from tracking—often the burndown of hours used during the sprint to make sure that they are on track to complete the stories during the sprint period—and use different units for each. A common approach is to estimate tasks in story points, then track tasks using hours. Jira Software gives you the flexibility to set your estimation and tracking statistics differently, depending on what best suits your team."

Maybe it's because English is not my first language, I don't know.

So my question is:

Is the thought here really that teams estimate first in the backlog with storypoints and then estimate again in the sprint with time and then track time. I mean, if I want to track time, then I must have estimated it beforehand, or is there a conversion from story points to time that I don't know about?

That is really confusing me.

Thank you very much for your help.

Cheers!

Bill Sheboy · Accepted Answer

Hi @Florian Minterbauer

I hypothesize that documentation page is a hold-over from the original Scrum book's writings which show multiple estimation methods for "stories" and "sub-tasks".  The Scrum Guide hasn't described things that way for many years.  Regardless...some teams may still choose to work that way.

Jira supports Scrum teams to choose to one of several different methods to estimate their work sizes, normally focusing on story points or hours.  This sizing is the forecast teams can use in backlog refinement, sprint planning, and reporting to help them improve.

And...teams may also need to log work for time tracking.  Think of this logging for billing and HR functions.  That is an independent mechanism in Jira from sizing estimation.

Best regards,

Bill

Trudy P Claspill · Accepted Answer

Hello @Florian Minterbauer

You have it correct. Teams may choose to first estimate by Story Points to get a general idea of relative size of tasks without trying to figure out the actual hours needed to complete each task. This is typically done during Backlog Grooming.

The team may then choose to estimate the actual hours for a task at a later time. This might be done during Sprint Planning, or it might be done by the developer assigned to the task before they start working on the task.

Story Points should be a generalized and relative estimation technique. For example, Task 1 is estimated at 2 story points because the team consensus is that it is a "small" task that will take "less" time. Task 2 may be estimated at 8 points because the consensus is that it will take quite a bit "more" effort than Task 1. And Task 3 may be estimated at 5 story points because the consensus is that it will take "more" effort than Task 1, but less than Task 2. This sort of estimation is done during Backlog Grooming. It is a quick method for estimating when you are trying to review a larger list of Tasks and you don't want to spend time reviewing all the details of the task, which you would need to consider to determine how many hours the task would take.

When you then do your Sprint Planning, you select Tasks based on the Story Points to reach the number of Story Points you have determined is the Velocity for your team. You accumulate Velocity information as you complete sprints, seeing how many Story Points were assigned to the Tasks you completed.

You may choose to work out the time estimate for each Task in your sprint collaboratively in your team, or you may choose to have the developer assigned to the Task figure out the time estimate on their own.