The art of estimation – why do they sometimes go wrong and how to estimate better


Have you ever had a very simple feature request that turned into an abolute nightmare? Have you ever had a request from a client asking you to estimate a project which has almost no requirements? Have you ever been told just to build it like Facebook or Google does it? In software development it is sometimes very difficult to make correct estimations in the beginning of a project as it is basically guessing. The more information we have about the requirements, the better the estimation will become. But the secret to nailing estimates is not in perfecting the art of guessing. It's in perfecting the art of definition. When estimates go horribly wrong, it's usually not because the thing took longer than we thought. It's because the thing we thought we were estimating turned into something else entirely. Most likely, it was a lack of clarity on exactly what you were estimating. That might seem really obvious, but as software experts, it's really easy for us to overlook things, or assume clients know what we know. It was clear to you and your team, and it was clear to your client, but "it" was completely different for each of you. In this session I'll review some of my good and bad estimations to arrive at simple strategies for how to result in a better project with a happy team of developers and most important a happy client at the end of the project. This session is aimed at anyone involved with estimating things, whether you're a Project manager, a developer, company owner, or a client who wants to better understand what it is about.