My Favourite Estimation Technique

Estimation is a dark art to start with and is often missuesed and abused to the detriment of the development team. As any valuable project has a level of uncertainty, estimates should never been seen as promises.

If I were to ask for an estimate of the walk from the DiBi Conference venue at The Stage to Newcastle Central station, most people would say 15 minutes. With this information, would you leave the venue 15 minutes before your train departs?

No, you would take that 15 minute estimation as a rough approximation of how long it should take for an average person if no problems arise. You would still need to factor in issues like hills, waiting for bridges if they are raised, carrying heavy luggage that will slow you down and so on.

So estimation gives you an assumption to work with, which you can evaluate and review throughout the project to be able to understand all the reasons why your estimation was wrong.

My favourite estimation technique

Estimation in a project should be a challenge and something that is valued as no more and no less than an educated guess, dependant on the facts at hand.

If you use estimation as a rod to beat up developers, they will eventually learn to give longer and longer estimates, refuse to give time frames or in extreme cases just leave for a quieter life!

In the worst case, estimation can seem easy because you don’t understand the full range of challenges ahead of you, those challenges that will lead the project to fail, over-run or not deliver the value they promised.

If estimation is easy because you have done the same kind of project many times before, then you should consider why you are doing the same project again. What added value will the project give to the stakeholders and organisation you work for?

So estimation is just an educated guess based on the understanding of the current situation, the confidence a team has in its own abilities and the forces that will act on the team from project stakeholders and the wider organisation. Trying to assign actual dates and times to estimations seem a very risky strategy.

T-Shirt sizes

Rather than get hung up arguing and blaming people for estimates based on time, use S,M,L,XL,XXL t-shirt sizes to describe the size and complexity of your project work (scenarios, user stories, use cases).

Tshirt sizes allow you to quickly estimate work relative to all the other work for the project, including the work that has already been done.

Tshirt sizes allow you to keep estimations as assumptions, so you can get on with the work and learn how well you understood that piece of work. As the project progresses the relative sizing of the work becomes less of a challenge as you have gained experience from all the pieces already completed.

You can even get planning poker cards with tshirt sizes.

Smaller pieces of work
The most effective way to estimate a project is to make it very small or make all the pieces of work in the project very small. This helps the development team estimate with less uncertainty due to the smaller scope.

A focus on understanding the complexity of a project and an appreciation of the most valued aspects will help the team have a more open and meaningful discussion with the rest of the organisation.

Thank you.

---

This work is licensed under a Creative Commons Attribution 4.0 ShareAlike License, including custom images & stylesheets. Permissions beyond the scope of this license may be available at @jr0cket