“How to win at estimations”, a Green Elephant story
Estimations are hard
Too many things to take into account: from unforeseen technical complexity hidden beneath “I need a button that…”*, to implications that are not understood by project owners, to unforeseen personal problems of team members.
It’s easy to shut down completely and proudly state that “estimations are impossible”. Or “precise estimations are impossible”. Or “reasonably accurate estimations for large projects are impossible”. There are many arguments that support these theories. What to do if, in practice, you really want to have a decent estimate for a project?
Classics that worked for us
Split projects into smaller, deliverable units (we work in sprints, so break it into 1-sprint or 2-sprints deliverables)
Communicate with project drivers to help them understand the various alternatives and their development cost.
Start with the unknown/hard/tricky parts (the things that can ruin your estimation). Test what you are not sure of, in a simplified context or manner: a prototype, proof of concept, or a script that is not integrated into production code.
Multiply with each person’s “optimism” factor. Most experienced developers should multiply their estimation by 2 or 2.5. Extremely optimistic people could go up to 5 (for familiar areas) or 10 (for venturing into unknown tech or business areas). It’s natural for this factor to evolve, as one gets more experienced, which takes us to:
Estimating as a long-term game
As a team, we took the “decent estimations” challenge and decided to get better at it, in time. And as the worse enemy of estimation is “unforeseen” changes (which most of the time, seem totally foresee-able, in retrospect), we needed an ally to help us win. We need to be able to see the Elephant in the room:
To help us be aware of what we miss when estimating, I decided to give it a physical appearance and a lot of.. room :). So here it is: the green elephant. Smiling proudly from its near-the-ceiling location, the elephant is our place to gather what we forgot to take into account, each time we mis-estimated something.
As we started with a new team on a large, legacy codebase, our collection of “ups, we also should have thought about….” started with rather basic things in 2016 (data migration, the admin dashboard, statistics, staging environment preparation, indexing data, error handling) and moved towards more functionality-oriented terms (launch, communication, changes to Terms of Service, A/B testing, planning an Analytics measurement strategy, updating the website, improving public assets) and more advanced technical terms (infrastructure and performance, planning feature and data rollbacks).
Is it working?
Yes. We are getting better and better, and we don’t repeat the same mistakes.
And we still learn: as we speak, the elephant is getting a new, significant addition: “even most benevolent users do not respect rules that are not enforced”.
