The Robot analogy for understanding 'relative complexity' in Estimation

We were doing some story estimation in one of the teams I work with the other day. There was a debate about the various methods of ‘sizing’ cards which followed a common pattern.

“We should use story points” said one person. “What’s a story point?” Said a relative newcomer, “Is it a measure of time?”. “well, that depends, of course, some people think it should be”

We went on like this for a while, talking about the merits or otherwise of some common techniques, Ideal days, Relative effort, relative complexity etc etc. I’ve certainly used all these measures and more in my time in teams, but I tend to settle on the measure of complexity as a good starting point. I think estimation, as a practice, is not specifically about knowing how ‘long’ something will take (that is important, but not the ONLY thing). Estimation is as much about the discussion that takes place during the activity.

Assume, than, that we’e talked about building shared understandings etc. What I would like to talk about is a way of understanding ‘relative complexity’ using a method we used to use at LP. However, I since expanded on it in a way that seemed to work really well with the guys I was talking to.

At LP, we used a little mental  game to try and stop people thinking about how LONG something would take by giving our ‘values’ silly analogies. As a measure we would ask people to think in Robots, rather than points, as in, this story is 3 Robots, this is 1 Robot. A useful tool, but we never really went further than switching the word ‘point’ for the word ‘robot'. So, in our discussion the other day we went this way. 

Imagine you have some robots. Each Robot is different, but each robot is composed of 8 pieces, which are reasonably obvious to assemble (like a Mr Potato Head for instance). When thinking about complexity, imagine 1 disassembled Robot in a box. No instructions. You tip the box on the table and put the 8 pieces together, pretty easy right. 

So, for a 2 Robot story. You get two different robots, drop all the pieces in a box, mix them together and tip the pieces out. Now you have to, first sort the pieces out and than assemble the 2 robots correctly. Assume you use a fibonacci scale. 3 Robots, tip them bits in a box, sort them out, 5 Robots… So, whilst 1 Robot may take 5 minutes to do, 3 Robots is probably more the 3 x 5. 

Software complexity is very like this. The more relatively simple things you stick into the box, the higher the complexity. It struck a chord with me and the team. It’s probably the basis for a good agile game. The best thing about it, is it helps people strip away the ‘time’ aspect (well apart from, the more complex, the exponential the increase in time).