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!!