What's the point of points?

One of the earliest changes we tried out that got the agile snowball rolling was estimating using points rather than hours or days (or weeks...)

Estimating in points though is a weird thing. It doesn't seem to make a lot of sense at first. It's really quite hard to explain and has a rather abstract quality about it. Look at some of the things you hear or read when you go looking for an explanation:

"Points are a measure of effort more than duration"

"Points are relative, not absolute"

"Points aren't a measure of time, don't think of them in hours"

"Whatever you do, don't set up a conversion rate like 8 hours = 1 point"

And this "estimating in points" idea is meant to help?

When I started to read about points and their advertised benefits I sort of thought I got it. I wasn't certain, but I found myself ready to try them out and take a leap of faith.

Initially I was skeptical. After all, it's pretty easy to pick away at some of this stuff and claim that it's just another pointless (pun intended) change as one sees so often in software development. (Software development is, after all, partly a fashion industry.)

Take the claim that points are relative. Well so can hours be. For instance, if "feature X" took 100 hours and is estimated by me as approximately twice as hard as "feature Y" then, relatively speaking "feature Y" is gonna come out at 50 hours. So big deal.

However, here's the thing. Points alone are not that special. They do address some of the issues of estimation such as it tending to be fractal, i.e. at some point the more detail you break down your work into the more complexity you unveil and less less accurate your estimates turn out. But by themselves they are not going to solve any major problems.

Points + team based estimation + tracking team velocity on the other hand is very powerful.

Together these concepts work like the legs on a three-legged stool: it'll fall over if any one of them is missing, but together it's rock solid.

So how do these three things work in concert? Easy...

• Points really do provide a nice simple unit that discourages over-analyzing things and are very easy to to perform math on (twice as hard, half as hard etc.) They're very quick so there's no need for tedious marathon estimation sessions.
• Team based estimation encourages full understanding and participation by the whole team. It also limits the likelihood of the most experienced people providing unreasonably low estimates that other team members have to abide by. It also equalizes the understanding of effort between software and QA engineers.
• Finally velocity, that is the measure of total points of work completed per iteration, provides a team with an easily understandable measure of their capacity, i.e. how much work they can get through in an iteration. This is incredibly useful because it allows a team to guard against being asked to complete an unreasonable amount of work in a certain period of time. Moreover, with a list of features estimated in points one can now easily predict how many sprints are likely needed to get them all done. Much easier than estimating in hours...

Those three points (pun intended, again) are pretty good for me already. But there's more. We now have a much more customer friendly language to speak in. It makes for easier negotiations. It turns the conversation away from "can you just get it all done by June" to more of a dialog where they understand capacity and can make comprises over features to hit their preferred deadline.

And that, for me, is the point of points.