Agile Development Blog

Traditional teams estimate all of their work in one unit type – regular time.  These teams then spend a lot of time wondering why their estimates are off and struggling to get more accurate estimates.  Many teams are able to bypass this struggle by estimating on two different estimation scales – points and hours.

User Stories in your product backlog should be estimated in terms of their relative size. Imagine writing your product backlog out on index cards, and sorting them in order, least effort to most effort.  It should be relatively easy to apply a simple numeric scale to represent relative size.  If your first story is at a size of one, and the next one seems like it would take twice as much effort, you’d score that one a 2.

Once you’ve numbered your product backlog like this, you can measure how many of these units you’re getting done each iteration by adding up the numbers for each accepted story. Over time, if you keep your team together, this “velocity” number should stabilize.  If your velocity has been about 15 in the past, you can predict that if the team stays the same, you’ll get 15 done each iteration moving forward.

Whether you call these units “days” or “points” or “tomatoes” is irrelevant, as long as you track how many you’re getting done.  I like calling them “points” because it’s politically useful to do so.  If a 5 person team is getting 10 days worth of work done each week, management might wonder why they’re only 40% efficient.  If they get 10 points worth of work done, the efficiency discussion doesn’t come up in this way.

Why use hours for tasks then? Story estimates are basically numbers you pull out of the air, after a couple of minutes of discussion.  But when you’re planning tasks at the start of the iteration, you know a lot more – the detailed acceptance criteria, the detailed task list, and maybe even who’s doing the work.  Estimating tasks in hours reflects the precision of the estimate (although I try to stick to 1, 2, 4, 8, and 16 hours because you really can’t be more precise).

• Politics lead to management questioning estimates (Points are less questionable)
• People are spending a lot of time worrying about estimation accuracy

• Teams are unstable and your velocity varies wildly (use T-shirt sizes instead)