Estimation as a process, not a promise

An Agile way to estimate

Andy Kimbrey
Jul 7, 2019 · 6 min read

Estimation is hard!

Imagine this scenario, and I promise this isn’t based on anyone I’ve ever worked with! A fictional client asks me how long it’ll take me to get from my office in Soho to their office in Pratt’s Bottom. I respond, “I don’t know, I’ve never been there before, I’ll get back to you with an estimate after I’ve done some research.”

They reply, “it’s in Bromley, can you estimate for me now?”

“Well, I've never been to Bromley, but I used to live in Croydon, so based on that I think it'll be about 40 minutes."

“Great! I'll see you in 40, don't be late.”

I came up with that example without checking the timings. In fact, according to Transport for London, it’d take me 1 hour 28 minutes to get to Pratt's Bottom. I would still be on the 358 bus when my client sits down in the meeting room wondering why I am so late and how my estimate could have been so wrong.

This is an example of how our far-out our estimates can be about something as simple as using public transport, an activity we do every day, so why do we expect developers to accurately estimate highly complex 9-month long projects?

When I ask developers and artists how long they think something will take, they never give me a straight answer. They say “I don't know, I've never done it before”, “let me investigate and get back to you”, “it depends how many changes you make”, “the spec isn't clear enough”. Sometimes it's because they’re worried that their first guess will be taken as a cast-iron promise. This is not good.

Even the most experienced developers who have been coding for 15 years still have reservations when giving estimates. Imagine the question “how long will this game of chess take to finish?” We could reasonably say “based on the many games of chess I’ve played before, this one should be over in about 20 minutes," but anyone who's played chess will know that this is far from a guarantee.

As an Agile project manager, I don't want to wait for a week for an estimate: I want a guess today, to start work tomorrow, and get an updated guess later once we have a better idea of the work involved.

I'm not asking for a promise, I'm asking for a process.

What is an estimate?

First let's establish what an estimate is not: if we already know exactly how long something is going to take, it’s not an estimate. Estimation happens when we don’t know exactly how long it will take.

The Cambridge English Dictionary defines estimation as “a guess of what the size, value, amount, cost, etc. of something might be”. I cherry-picked this definition which doesn’t use the word “calculation” because some tasks can't be calculated, for example, if it's something we've never done before. However, all definitions of estimation define them as guesses, not promises.

Estimation does involve some calculation, however. When guessing how long a new task will take, if a similar one took 2 days to complete, then this task should take approximately 2 days plus-or-minus a guess of some hours depending on the requirements. The more similar it is to previous tasks we’ve done, the more accurate the estimate will be.

Estimation is also a practice, which means we get better at it the more we do it. We build a mental database of the duration of previous tasks from our experience, and the bigger the database the more reference points we can use to estimate new tasks. Estimation is therefore part calculation from experience, and part guesswork.

There is an emotional component to estimation as well. When I was talking about this article to my friend and colleague Alex Omand, he added that developers may give different estimations on different days. I didn’t need to fact-check the research on this, it seemed patently true: a developer in the middle of a task that has been underestimated and running late is far more likely to overestimate the next one.

So what is estimation in software engineering? It's the practice of being good at guessing the duration of tasks depending on our current mood, which becomes more accurate with experience.

The Process

Because we're Agile, we don't want to spend months in planning meetings locking down every detail so we can provide accurate estimates from the get-go: we want to start right away with pencil sketches and prototypes. We also want to welcome change that makes the game sexier or creates better ways of communicating to the player.

We know it takes about 6 to 9 months from inception to release to make a slot game. Our mileage may vary depending on the product but whether we’re in the business of designing websites and apps, or constructing bridges and roads, we already have a fairly good grasp of the development phases and milestones of the project. We probably have a rough project template somewhere or could put one together pretty easily. This template is the starting point for our project plan.

Using this rough project plan, let’s hold a Weekly Status Meeting to find out a) if there’s any risk of not delivering the current phase by the estimated delivery date, and b) if there’s anything going on that might affect future phases. If the answer to either of these is "yes", we’ll re-estimate and adjust the timeline. This meeting shouldn’t take longer than 30 minutes: we're just checking in not trying to dig into the "why".

If our adjustments have moved any key milestones like the external demo or the release date, we can investigate where we can make savings to bring these dates back in. For example, assigning additional resources, simplifying animations, dropping some features, outsourcing, etc.

Now, rather than trying to estimate the entire project right at the beginning, we are constantly estimating based on the latest feedback and developments. This means several things:

  1. Estimates are more current. Because we're reassessing the situation every week, our estimates are always up to date.
  2. Estimates are more accurate. Because we are estimating more often, as more information comes in to the project we cut down on guesswork and use more calculation.
  3. Estimates are more flexible. Because we are estimating based on the current state of affairs, we don't make promises we can't keep if changes come in.

This also means the timeline is always in flux. However, because of the process, small fluctuations factor out over time: if animations are going to take 2 weeks longer than expected, we can reduce testing duration by doubling the QA resources assigned to the test passes.

Most importantly, our games are better. If we come up with a great idea halfway through the project, we can re-estimate and add it in. Change is built into the process, rather than something to push back on.

Get ahead of the game

Although the idea of timelines in flux and estimates not set in stone may scare some, I’ve found most clients are very receptive to this approach; after all, it means they can make changes to the project as it evolves. The reason it works is because it’s proactive: we are mitigating delays in advance and updating timelines on a weekly basis.

I once had a really aggressive timeline to deliver an entire Mobile Social Casino in just 3 months, which ended up taking 5 months. There were 2 major changes requested by the team: we added a Sprint for optimisation of the app to support lower-spec devices, and we added 2 Sprints for graphical flair to make the game really stand out. Because these changes and updated timelines were communicated so far in advance of the launch day, only one person responded to the project taking an extra 2 months: the Senior Vice President of Content, who said: “is there anything we can do to help?”

Adopting estimation as a process, not a promise, gives us more flexible, more current, and more accurate project timelines. It means we don’t make promises we can’t keep, and we adapt to change with ease. It means our developers aren’t scared to make guesses about timings, and I don’t get stuck on the 358 bus while my Client is waiting to start the meeting. It’s the Agile way to estimate.


Special thanks to Indika Herath and Aloka Kodituwakku for helping me build this process, Alex Omand for giving me valuable insight into the psychology of estimation, and all the guys at Electric Elephant Games Sri Lanka for making this process work, and making my job easy.


    Andy Kimbrey

    Written by

    Project manager and agile evangelist from London, UK. Also a gaming adept, armchair scientist, philosophy graduate, Star Trek nerd, and Oxford comma enthusiast.

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade