In the last post I talked about estimation points and why they can result in more accurate estimations. In short summary, relative estimation is simpler and more accurate. That's what estimation points are, relative size of one task compared to the other. How long it takes to complete each point needs to be approximated from several initial iterations. Today I want to introduce additional techniques to make estimation easier.

It's usually easy to see if one task is twice as big as the other. If another task is 1 point, the twice-as-big current task is 2 points. What if the current task is about 10, 20, 100 times larger? It's impossible to say if it's 100 or 101 points. It's hard to distinguish between 20 and 21 and even between 10 or 11. It's also not important because estimations are inaccurate. 10 or 11 are close enough for errors in estimation to make it possible for 11 points task to be smaller in reality than 10. By making a task 10 or 11 we are just guessing that it's somewhere in 8 to 15 points range.

To make things easier we can group different ranges to hold all items close in size. For example all tasks in 8 to 15 range will go into 10 group, 15-25 to 20 group and so on. Two series of groups are popular - based on Fibonacci sequence (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100) and on 2^n sequence (0, 0.5, 1, 2, 4, 8, 16, 20, 40, 100) or something along those lines. Around 20, groups become 20, 40, etc. in size. It doesn't really matter if it's 20 or 21, but it's easier for people to think in rounded numbers.

I tried to use this system with Sider. It was easy and fun. I didn't feel anxiety to say if something is 8 hours or 9 hours. Instead I just chose appropriate group. I also didn't have to guess if my hour is really an hour. I knew I can figure it out later.

The problem for me was that I couldn't really switch to thinking in points instead of hours and days. I almost automatically decided that 8 points is 8 hours - 1 work day. I ended up comparing each task to something that I thought would take a day or an hour.

At this stage I've no idea if my estimations are accurate and when I will complete the next Sider release. In several iterations I hope to have a better picture and a better idea when the release will happen.

I also want to mention teams. Most of the time people work in teams and they need to give estimations as a team. I usually work alone so I can't really share any experience or talk about related problems. I suggest you check out Planning Poker, a procedure and a game created to help people overcome frequent problems and give accurate estimation together with their team.

To learn more about estimation I highly suggest listening to Agile Estimation podcast.