Software project estimation will never be an exact science, there are too many variables - technical, human, environmental, political - that can affect the effort required to develop software. However, with a series of systematic steps reasonable estimates can be achieved with acceptable risk.

The techniques employed during iteration planning use simple decomposition to divide each requirement into a collection of tasks. The effort required to complete each task is then estimated based on a comparison with similar historical tasks and their corresponding metrics. Over time, as experience increases and historical metrics accumulate, the estimates will improve.

Units of software estimation

Traditionally, task estimation is performed in units of calendar effort, i.e. the number of people multiplied by calendar time. eXtreme Programming, an increasingly popular agile methodology introduced the concept of ideal time as the time spent programming without interruption, where full productivity is achieved (by definition this unit should really be termed ideal effort). Measuring and estimating in ideal time allows tasks to be compared without considering peripheral activities such as meetings, pair programming assistance, etc.

Loading an iteration

It is important to load an iteration with the correct amount of work so as not to over commit resources, or indeed under commit resources. The correct amount of work is determined using a simple rule called Yesterday's weather, it states:

Assume you'll do as much this week as you did last week

Since the work assigned to an iteration is measured in units of ideal time, at the end of the iteration a simple addition of the actual work completed will yield the total number of weeks of ideal time that fit into an iteration - this figure is termed the velocity. The amount of work assigned to the next iteration will therefore be equivalent to the number of weeks of ideal time in, or the velocity of, the previous iteration.

The combination of ideal time and the application of the Yesterday's weather rule enables estimates to automatically track changes, for example changes to the team, technology, or product direction. Consequently, during estimation explicit consideration of non-programming time is not necessary. In addition, since estimations are ultimately based on previous actual accomplishment, habitual overestimation is prevented.