Through-out 20 years of development experience I have encountered many approaches to effort estimation. In more recent times, there has been a general move away from talking in person-days to using more ambiguous terms such as story-points and T-shirt sizes (S,M,L,XL). Although these are more an indication of complexity than effort, there is often a pressure to approximate story-points and sizes into an equivalent number of days of effort to help who’s tasked with planning and budgeting the project.
Humans are only any good at estimating when they have a wealth of empirical evidence against which they are able to compare and calibrate their approximations. An experienced bricklayer may be able to quote the cost and time of a building project to within an hour and brick, but only because they have experience of many like projects.
One way to consider project estimation is via the types of factor that vary from project to project. There are those that affect the scale of the project and those that affect the nature. Building walls of different widths, heights and depths can be calculated with relative ease because they only change the scale of the project; they are just multipliers in the calculation. Even changing the type of brick and the labourers involves can be factored in, given sufficient information. But change the specifications too far from normal and the calculations start to become less trustworthy. What if instead of manufactured bricks the customer wants to use natural stone that comes in all manner of uneven sizes. What if the labourers are new to the project/industry to their level of skill and rate of production is unknown.
In software development there seems to be a school of thought that, because the tools remain the same, we (may) start with a quantifiable number of requirements and we may be able (with a degree of experience) to evaluate the scale and complexity of the feature required to address each requirements, that projects can be systematically estimated. A primary driver for this is, I suspect, an innate lack of trust between engineers and managers. There is a suspicion that engineers always over estimate to include contingency for the worst case scenario. A counter suspicion that managers with always present the best possible outcome given their priorities of time and budget. I also suspect both suspicions are well founded so why should be continue to battle them? Enter stage-left the agile methodology, but that’s another story.
In theory – Push the numbers into the model and out comes a trustworthy plan for the project board to beat-up the project manager with, and for the PM to beat-up the engineers with. Over the years this belief has led to models such as COCOMO and methodologies like COSMIC, but my experience is they all fail for the same reason. They are based on the assumption that the only numbers that matter are those that affect the scale of the project and those that affect the nature can somehow be quantified.
I have devised an approach I have yet to test; based on the nursery rhyme Old MacDonald had a farm! My theory is that is the scale/complexity of a task (story) is sufficiently obscure we might be able to make their conversion into an estimate of effort virtually impossible. T-shirt sizing is an attempt to achieve this approach but I would like to take is one step further. In my next estimating task I am going to use the following scale: mouse, sheep, horse, elephant and whale.
OK, the last two are unlikely to be found on a farm but stick with me here.
- Mouse: simple and short task, easily (lift-able) achievable by one person.
- Sheep: complex or large task (but not both), difficult but still manageable by one person.
- Horse: complex and large task but not manageable by one person alone, but easily manageable by two or three developers.
- Elephant: Of such size and/or complexity that further investigation is needed to break the problem down.
- Whale: With the bulk of the object obscured from sight, such as task is unmanageable by the team. The task needs considerable investigation (almost a project in its own right) to bound the task and bring it back to land.
I think these definitions help with one of the issues with estimating software tasks of how’s doing it. One person’s 5-day task could be another’s 3-day, entirely down to the difference in experience and/or skill. “I will use the same tools are I used for the previous task”, “I have done this on another project” etc. This approach will help us consider the problem rather than the potential solution.
A quick thank you to KF for the perspective of ‘how easy is it to lift the animal’ relates to a task’s ability to be managed by a single developer.