It’s Points All the Way Down!

TurtlesAllTheWayDownBertrand Russell once gave a lecture on astronomy, and how the earth rotates around the sun, and how the solar system is part of a vast galaxy, etc and so forth… At one point he was interrupted by an old lady, or so the story goes, who said “What you’re saying is rubbish, the world is a flat plate resting on the back of a giant turtle”. When Bertrand Russell questioned her as to what’s below the turtle, she replied “Another turtle”. Bertrand persisted with “And what’s below that turtle then?” to which the lady replied “It’s no use – it’s turtles all the way down!”

I was reminded of this story recently when I was in discussion with a colleague about sprint planning. My colleague was explaining to me that they use story points for sizing and estimating stories, but they then break their sprint stories down into smaller tasks and use hours to estimate these tasks, rather than continue to use points.

I had never come across this particular practice before. Of course, I’ve seen teams who do everything in hours, I’ve just never worked with a team which used both points and hours. I’ve always worked in points for story sizing, and when the stories need breaking down, I would break them down into smaller points: It’s points all the way down! I’ve never had any problems with this approach, so I was curious as to the advantage of switching to hours.

My first port of call, as always, was Google. When that came up empty I turned to Twitter, and got a friendly response from none other than Mike Cohn.

 

Now, I never thought I’d find myself disagreeing with Mike Cohn, indeed his book “Succeeding With Agile” has been something of a bible for me for the last few years, but on this issue I am still not convinced.

Mike has written a really interesting blog post on why he uses hours rather than story points for sprint planning (you can find it here). One of his reasons is because he feels hours are better short-term measure than points. In some circumstances I would agree with him (perhaps if your stories are MASSIVE, and you need to break them down into much smaller tasks), but in my experience it doesn’t generally appear to hold true. I use points for both stories and tasks – the only difference is that when we get around to task estimation & sizing, we expect to be a little more accurate than when we estimated the stories in the product backlog. Quite often we will take a story of say 5 points, and break that down into two 3 point tasks. So 3 + 3 doesn’t add up to 5. Who cares? the 5 was an estimate anyway, and I always push to make everyone understand that estimates are just guesses, and the further out we make the estimate, the more approximate it’s going to be. By the time we get around to doing our sprint planning i expect us to take a much deeper look into these stories, and benefit from additional analysis, so naturally I expect our estimate to change.

I usually do everything I can to steer away from hours, because it can often be too confusing for people outside of the team to understand why the total hours don’t add up to the total available resource hours. I’d rather just not have this conversation sometimes! Also, after explaining to everyone the key benefits and purpose of using points, I can imagine they’d be confused as to why we were suddenly ditching all the advantages of points, and switching back to hours for the sprint planning. By the way, I’ve covered the reason why we use points over hours in my previous blog post here.

Anyway, I just thought I’d write this post to show that both approaches are common, and I guess it’s just a matter of “whatever works best for you”. But I’m still not convinced with the whole hours thing!

Advertisements

What’s the Point in Points? Agile Estimating with Dinosaurs and Bees

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?

clockI 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.

dinosaurSo 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

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