**FUN With Points!**

Over the last few months I’ve been getting some teams up and running with Scrum, and one area I always seem to have “fun” with is introducing people to the points-based system of estimating. So much fun in fact, that I’ve decided to write this very blog post about it! See how much fun it is already? No? ok.

When we do our estimating (during the planning sessions) we look at each story (work item or task) and guess how big it is in terms of effort. But we don’t just think about how long it’ll take, we also consider the following:

- Complexity
- Amount of unknowns

So for our teams, the size of a story represents how much effort it’ll take, how complicated it is, and how unsure we are that we know *everything* we need to know about getting that task done.

**But Why Not Just Use Hours?**

I get this question quite a lot. There’s a couple of reasons why hours don’t rock my world in quite the way that points do. Firstly, they’re an *absolute* measurement, rather than a relative measurement (more on relative measurements in a bit), and also because they encourage us to focus on how long something will take, and discourage us from thinking about complexity and unknowns. When estimating in hours, we naturally think primarily about the actual amount of time it would take to do that task, and hey presto, we have an answer. This answer quite often doesn’t take complexity and “unknowns” into account – but why? Basically it’s because we’re human. If were asked to think in hours, we naturally just think about how *long* a task will take, not how difficult it is or how many unknowns we should consider.

So when we’re all finally agreed that hours just doesn’t cut it, I go straight into the whole “points” concept. Unfortunately, for some people this basic concept is far too similar to hours, and they get confused. I was talking about this with Matthew Skelton (of London Continuous Delivery group fame – aka @matthewpskelton), and he suggested that I start off by getting people to use completely abstract objects to do their sizing, such as dinosaurs for example. I think this is a great idea for an exercise to get people away from thinking in terms of hours, but I’m not sure how well it would work in an actual sprint – you might need a team of people who are dinosaur fanatics! Anyway, I’ve mentioned this dinosaur idea a few times, in order to demonstrate that our points are completely abstract and not directly related to hours, and it has worked nicely (cheers Matthew!).

**Relative Sizing**

Next we move on to the exciting topic of relative sizing. Once the team have got their heads around the idea that a story shouldn’t be estimated in hours alone, it’s time to teach them a new way of measuring how big a story is.

There was a paper published in the American Journal of Psychology in 1967 called “Size-Estimation of Familiar Objects under Informative and Reduced Conditions of Viewing” by H. Richard Schiffman (vol 80 pp229-235 for those that are interested) which revealed that humans are better at estimating the size of an object when they had another familiar object to compare it to. We use this method of “relative sizing” when we estimate the sizes of our stories or tasks. We start off by picking the easiest (and usually the smallest) story of all, and give it a number – if we think this really will be just about the smallest sized story we ever want to record, we can give it the size of 1. I call this our “starter”. Some teams have given their starter a score of 2, because they often get stories which are much simpler, but not *that* frequently. I have no problem with this idea.

After we’ve defined our starter, we size all our other stories in comparison with it. So if our starter is 1 point, and our next story is 3 times bigger than our starter, we give it a 3! Simples.

**Fibonacci Sequence**

Some people use the Fibonacci Sequence as an additional rule in their estimating. The Fibonaccci sequence goes 0, 1, 1, 2, 3, 5, 8, 13, 21…. etc and so forth. There aren’t many things more boring in life than people who are obsessed with the Fibonacci sequence. The only interesting thing about it is that male bees ancestry follows the Fibonacci sequence (has 1 parent because he came from an unmated female, 2 grandparents, 3 great-grandparents, 5 great-great-grandparents, and so on). Bees aside, the Fibonacci Sequence is fairly dull. One reason why some people use it in agile estimating is because they argue that if a story is bigger than a 3, then the sheer size alone should account for an additional increase due to the potential “uncertainty” factor. Suffice to say, I don’t agree.

**Group Consensus**

I read a book called The Agile Samurai by Jonathan Rasmusson (I really should do a book review of that at some point) and I came across a section explaining “The Wisdom of Crowds”. The Wisdom of Crowds, it explains, happens to be another book (by James Surowiecki) which, bear with me here, tells a story about a British scientist called Francis Galton. In 1906 Francis Galton did an experiment at a fair where people had to guess the weight of a butchered ox. Francis expected a professional butcher to provide the most accurate estimate, but to his surprise, the crowd of villagers actually came up with the best guess! In short, experts are often trumped by a crowd.

This concept has been adopted in agile estimation, where we use group consensus to help us agree what our estimate should be for a particular story.

**Conclusion**

That’s about it from me when it comes to points. So remember, hours are bad, dinosaurs are good, butchers are stupid and male bees have no fathers!!

Ok here’s my problem with the Fibonacci sequence in agile: If 1 point happens to be quite small, which for me it tends to be, then a 4 point story isn’t exactly very complicated to estimate. If we’ve used relative sizing to work out that a story is a “2”, and a task is twice the size of that, then 4 seems to be a perfectly reasonable estimate.

The Fibonacci sequence works well if your 1 is a fairly large story. When your 1 is any bigger than about 1 “ideal days” worth of effort, then Fibonacci is OK.

Also, there’s no 0.5 in the Fibonacci sequence, yet planning poker cards ALWAYS have a 0.5 card. So people who claim to follow the Fibonacci sequence don’t do it properly anyway!

It works pretty well for us. When we first started scrum, we groomed our backlog and looked for the smallest story on the backog. We then set that story as a 2 – that way if anything came along that was smaller, that would be 1. If anything is 21 or above we treat that as too big, and should be broken down more.

I understand what you are saying, but is your potential 4 pointer exactly twice the size of the 2 pointer? I doubt it. This is why using the Fibonacci sequence works quite well. So say you accept your 4 pointer is really a 5 pointer and move on to sizing the next story – maybe you think this is a 2 pointer, but actually when you do it there is some unknown that makes it a 3 pointer. And your 5 pointer really is a 4 pointer as you first thought. Your commitment after the planning is based on the points when you estimated so you make your commitment and everyone is happy.

The sizings are relative so i wouldn’t get hung up on whether one is twice as big, just that it’s bigger or a lot bigger.

Planning poker cards don’t follow Fibonacci entirely. The ones i’ve used also have 20, 50, 100 not 21, 34, 55, 89… It is just an approximation. Maybe 0.5 is used as a lot of people put 1’s against their small tasks and something comes in smaller and they don’t have anywhere to go, luckily there’s a 0.5 card in there for when this happens.

I’ve actually found that 4 is a fairly common size for our tasks, simple as that really. I understand the whole point in the Fibonacci (or the F word, as it has come to be known in my team) sequence, I just don’t think it works at small scales.