Scrum teams often 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.
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 months
into the future, so the team can only provide a rough estimate in conditions
of uncertainty unless they work for days breaking the tasks down.
However, from sprint to sprint as they work through the stories, the team
will develop a cadence of completing
Story points estimations work well to follow a Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21
Story points are numbered this way to account for the fact that the longer an estimate is, the more uncertainty it contains. If a developer wants to estimate a 6, he’s forced to reconsider that some of the perceived uncertainty does not exist (and play a 5), or accept a conservative estimate which accounts for the uncertainty (and then play an 8).
|How Much Work?
|This is trivial.
|This is small.
|This is 1-2 days of work.
|This is could take half of my week.
|This is a full week’s worth of work. We should probably break it down into smaller tasks.
|A week or two. This should probably be an epic, break it down.
|Seriously? This is going to take at least a month!
Purists would argue that I shouldn’t describe story points in relation to days or weeks, but I think it’s important to start off by relating points to time. Eventually, and very quickly, you’ll be able to think abstractly about how many points of effort are involved without going though a time-to-points mental translation.