Real World Estimates

Introduction

Estimates are created in software development for two very simple reasons – to determine how much a project will cost and how long it will take to complete. The process typically follows these high-level steps:

• Before project development starts, identify a perfect set of requirements.
• Break those requirements down into parts and assess a level of effort for each part.
• Sum these efforts up and you have an estimate of the project’s total cost and duration.

While this seems straightforward, traditional waterfall estimates are notoriously inaccurate. Why might this be, and are there any alternatives?

Deviation Factors

A variety of factors can cause even a thoroughly constructed estimate to miss the mark. For one, estimates are often created in a vacuum of optimal conditions - not considering imperfect requirements, priority conflicts, or unexpected blockers. In reality, any unclear user story can lead to scope creep and thus take additional time to complete. Or, a user story could simply evolve after being estimated, based on changing business needs. Another x-factor is padding – a mostly arbitrary amount of cost/time that is added or removed to an estimate to the make it fit within a desired range.

Who is the Creator?

Traditional estimates are often not created by the same team that will do the actual development. Instead, the estimates are produced by an outside party, using measurements calculated in arbitrary "developer days". The true development effort can be vary widely by team composition – how long a group has been working together and the specific skillsets of the members in relation to the particular work that needs to be done.

The Alternative

One alternative to traditional estimation is to use agile road mapping. Road mapping is a flexible planning methodology that anticipates change by leveraging a known throughput for a specific team, not an arbitrary or theoretical one. This throughput – known as velocity – can be calculated as the average amount of work that the team completes in a specific duration of time. By making relative comparisons of small units of work – future planned work versus recently completed – it is possible to approximate the duration of time it will take the team to complete future roadmap items.

Advantages

This method is advantageous in that the projections are based on tangible historical achievements made by the same team that will implement the new feature. Agile is also more realistic about inevitable changes in business needs, embracing evolving priorities. The Product Owner manages the road map throughout the product life cycle, and thus determines how much time the team spends on any roadmap item. This approach reduces costs, eliminating work identified as not necessary as the project progresses.

Conclusion

Bypassing traditional estimates in favor of road mapping requires a culture that genuinely embraces agile. It is essential to have a high level of trust between project stakeholders, the Product Owner, and the development team. For newly constructed or less inexperienced teams it might be better to stick with the traditional estimate model. However, under the right conditions, agile road mapping offers a modern approach that is more adaptive and better aligns expectations with project outcomes.