AMA: Time Estimation

Paul asks…

What is your stance on time estimation (involved people, granularity/level of detail, benefit)?

My response…

I’d like to start by stating that I’m by no means an expert on this topic; so please take what you will from what I write.

Time and effort estimation for any software development activity is very difficult to do so often we get our estimates very wrong. I believe this is because we try to do up-front time and effort estimation without fully understanding the domain or the extent of the problem we’re solving; we still have many unknown-unknowns.

We can still do detailed/granular planning, but we should try to delay the detailed estimation of these until we have more information.

What I prefer is detailed planning  up front, which involves breaking large lofty goals down into small goals. These small goals are broken down further into the smallest possible manageable unit of work that delivers something, however small that something is. It’s important to break things down to this level as this enables continuous delivery, and flexibility in scope as a project progresses.

Once these small units of work are detailed, before trying to estimate these, I think there’s validity in starting work and delivering some of these units of work. This will mean it’s possible to more accurately estimate the remaining work based upon real delivery experience.

As soon as you begin working on each unit you should get a feel for the size and effort that is required for each unit, and over a period of time (say a fortnight) you can start to work out how many of these units you can achieve (your velocity).

If you’ve got the detailed plan of how many units total you’d like to achieve, it is probably at this point where you realise that what you wanted to achieve is going to take too long or cost too much. This realisation means you need to prioritise all remaining work, and focus on what is high priority.

I’ve never seen a project finish with the same intentions as when it started, so as you progress you will find some items get completely de-prioritised (no longer in scope), some things become higher priority so they get delivered sooner, and some completely new ideas/pieces of functionality may be decided upon and included in your plan.

Since you understand what you’ve been able to deliver you can then have sensible conversations about what is feasible given the resources available.

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

1 thought on “AMA: Time Estimation”

  1. Each Story or Subtask of a story is given a value of 1, 2, 3, 5, 8, 13.

    I try to think: “Given with my usual amount of meetings I have per day, and investigations of failing tests, when could I get this task done? How complex or time consuming is this?”

    1: “In a Jiffy!”
    2: Maybe half-a-day?
    3: Oh, that’s a days worth of work.
    5: It’s going to take a few days…
    8: It’s half a week.
    13: It’ll take a week!

    In a two week sprint, I usually have a velocity of 20 to 25 story points.


Comments are closed.