Our experience within IT projects and particularly within ITSM projects revolves around the time critical nature of projects and the need to have everything immediately (whether this is true or not is up for discussion).

The rush to jump through process gates can lead to different behaviours, both circular in nature. ‘The Business’ believes that project workstreams overestimate and those within projects almost invariably believe that whether a realistic Estimation is provided or a pessimistic one, the estimated time will be cut.

The circular nature of this particular issues hits those of us in Testing two-fold. Firstly, with testing seen almost as a ‘nice to have’ or a bureaucratic exercise, insufficient time and resources are planned and budgeted for, whatever the Approach taken.

Secondly, as testing is often solely towards the end of a project, already sparse timelines are further truncated and as we all know, on the project pyramid, something must give – namely cost or quality.

Perhaps we should start working differently. You’ll find other blog posts written by us about the ideal point to engage testing (hint:at the beginning not the end). But what if we started to change the way projects and workstreams approach estimation. If we were a bit more realistic about estimation and applied both experience and a little mathematics could that help? I think so.

One of the things I took from my PMP training that has stuck with me (and that was now some years ago) was the following formula

(1x+4y+1z)/6

x is the best case scenario a task can/has taken
y is the typical time a task takes or has taken
z is the worst case a task has taken

this allows us to account for both optimism bias, pessimism bias and normal operation. It should give us a reasonable estimation rather than the scenarios above. Obviously, it is not perfect, but if we could use this approach might it give us a better shot at estimating? We think so.