Software Estimation – Introduction

Software estimation is one of those skills that programmers usually avoid and don’t really care for. It’s not surprising. For majority of people it’s all black magic and a shot from nowhere. That may be the reason why Planning Poker has become so popular- the unpleasant feeling of uncertainty caused by picking up a number is suppressed here by a team work in a quite amusing form of a poker game.

Estimation equals obligation

One of the most important things that I learned few years ago while developing plans and estimations, could be expressed in the following sentence: ‘Giving an estimate is an obligation, always, regardless of what a client says’. In that project, a client wanted a 'rough estimate’ at a moment notice. They got it but after some time it turned out that many people weren’t happy with our work pace and we were allegedly behind the schedule (it seems that nobody cared that we kept sending updated and more detailed estimates as work progressed).

This fact is emphasised by both Steve McConnell (Software Estimation: Demystifying the Black Art) and Robert „Uncle Bob” Martin (Clean Coder). As professionals, we should be aware of our obligations, be able to manage them and above all we should fulfill them. Therefore, to commit yourself to work according to your estimates, we should be able to give numbers on which we can depend to such extent that we are able to meet our obligations.

To do so, it is necessary to delve into the subject of estimation.

Why should we estimate projects?

There are several ‘places’ in the process of software development where efficient estimation can be useful. It is probably the most important for the department dealing with preparing offers for new clients. Once requirements have been gathered and it is known what an application will be about, a difficult question arises: How much will it cost? Only few clients agree to collaborate on spec, knowing only an hourly rate of a team member (it happens though). They prefer to get a specified price for having their requirements fulfilled. This model of work is called ‘Fixed price’.

Time and quality of provided estimates proves your professionalism and may give you an advantage over competitors and their offers. So it’s always worth being done well!

Estimation – elementary process

Regardless of how estimation is done, some elements of a process don’t change:

Problem decomposition

Having a complex problem (project, epic etc.) we decompose it into smaller ones. There are many ways of decomposition: into modules, requirements, user stories, functions, tasks etc.

Counting

Having a lot of small problems, we deal with them individually. They are estimated individually and there are also several tools available: replacement units (points, stars, stories etc.), hours, GUI elements, charts and fields, code lines, function points etc.

Apart from the units, also the way of providing an estimated number is taken into consideration. Very often only one number being an estimate is given, but a better approach is to give a value range or include an uncertainty – for example using PERT method.

Reconstruction

A group of small estimates should be combined into a big one. What gives you an advantage is the law of large numbers. It turns out that very often errors can neutralize each other and an error after the reconstruction is much smaller than the sum of single errors.

Calculating

Often the estimation isn’t done directly in hours. In such a case, it is necessary to convert a reconstructed estimate into effort (usually given in ‘man’ units: man-hour, man-day etc).

To calculate them, it’s best to use historic data from other projects.

Planing

Having it all, we can try to set dates. It is necessary to take into consideration (at least) the volume of a team, scale inefficiency and the critical path of a project.

In the following posts I will present the methods constituting different parts of this process.