Points vs Hours

The pains of task estimation. It makes that warm feeling of starting a new project disappear completely. No matter what's your method, Waterfall or Agile, you have to tackle that features list at the beginning of the project and estimate like there's no tomorrow. It's always too big and all those estimations will enable the team to scope. And so, you get to it. It take all of your team days to get through it and a the same time you know you'll have to re-estimate all of those features throughout the entire project.

I got tired of that. Not fast enough, but after 16 years of estimating with hours I couldn't face another project like that. That's when I gave a good try to the Story Points system. It appeared a bit suspicious so I 'googled' away on the subject. My goal was to find THE reason that would convince any programmers on my team to switch to a points estimation. Lucky me, I found one and here it is:

Behold the one reason to use points over hours when estimating.
>> If you show two different features to two programmers, chances are they will not agree on how long, in time, it would take to code it. They will, on the other hand, always agree on which task is bigger than the other one. <<

It takes us now 2-4 hours to estimate what took us a full week before. Here are the easy steps:
1) Put all the possible stories in a spreadsheet.
2) Create a second spreadsheet that will contain, in the end, your estimated backlog (aka the list).
* In this list, the big stories will be at the top and the small ones at the bottom.
3) Copy the first story into the list. Since it's the first item, just drop it at the top of the sheet.
4) Copy the next story into the list by doing an insertion sort based on the simple question “Is this new story smaller or bigger?”.
5) Repeat step four for all the stories.
6) Giving points to the stories starting at the bottom of the list, by giving the first one 1 point.
7) Using the Poker Planning scale (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100), ask yourself if the story above the last one is in the same scale.
* If it is: Give it the same estimate.
* If it's bigger: Give it the next increment in the scale.
* If it's smaller: Move it down until it fits.
8) Repeat step 7 for the entire list.

Tips:
- Try to make most of the list fit between the included values 1 and 13.
- Sometimes micro stories are at the bottom of the list. Give them the value ½.
- At the top you will probably find some Epics of values 20, 40 and even 100. those will have to be broken down into sub stories latter.

Those stories will never have to be re-estimated unless the descriptions changes dramatically. The velocity of the team can be calculated by the total of points they can burn in one sprint and that velocity normally stabilize after 2-3 sprints. With that value you can also predict how many sprints it will take to complete the backlog.

Go points!