I like nice…

So, I’ve been fairly slack in updating this blog, but lots of things have been changing lately; so that’s probably why! I’m now working for a large company in a tech department. The company’s main line of business isn’t software, but it has a large requirement for technical solutions, which is where we come in…

We mostly use agile project management methodologies, for example; Scrum. This reminded me of a story that someone told me at my last place, which illustrates both one of the issues surrounding project management, and a solution too. The example was ‘counting trees’…

So the story goes; there was a person, employed by a company to count trees in forests. They’d be flown over a forest and look at it, then note down how many trees they could see. Obviously this was an estimate, and the other point was that the person was never told if they were right or wrong or how many trees out they were, and the number that they supplied to the company was really very useful. The reason it was so useful was that the company had this person fly over forests with a known number of trees – say, 2000 – and then the tree-counter would give their number – maybe 3000. Doing this a couple of times, the company could work out how much this person was out; maybe 50% extra. So they would take the number given, and subtract 50%. The person wasn’t told how much out they were as then they’d start to compensate and the numbers would change.

The important part of this story though, in terms of project management of software projects, wasn’t that the person was estimating, but it was that the estimate was used in an effective way. The number wasn’t taken as gospel, and the number was used to calculate the real number. This number was the amount of trees, or the time it would take to complete a bit of software.

There are a couple of problems with estimating software projects; the estimate given is often used as the definite time to deliver and people’s estimates are different. The first issue that it’s often used as a definite is because the language used is flawed. It is an estimate, but if we’re estimating time, then it sounds fair to use that time to work out when you will deliver. If we use ‘complexity’, then this problem is removed. Also by using complexity, you can work out pretty easily how much time person x will take to deliver complexity y…. Something like:

(complexity * person_factor) + contingency = time to deliver.

So the ‘estimate’ given by the person would be the complexity, or ‘how hard I think this is’. By using feedback from other deliveries, you can work out how long it would take that person to deliver that complexity task, without asking for a deadline or a time estimate. By using a baseline, you can work out a standard person_factor, and then improve that for a particular person or team. In fact the person_factor could also include information about their experience too, so a junior programmer, or one new to a system, would take longer than a senior or someone that wrote it in the first place.