Estimating Development Work


Hi all, long time no see, I know…! 🙂

I’ll be blogging today about a common problem for most development teams: estimating your development work.

My team has been having some discussions on how to improve our estimation process and I’ve decided to share my experience with that particular aspect.

First, we should try to understand why some estimates are a bit off the target (either under-estimations or over-estimations).

As James Shore explains so clearly in this blog, “Part of the reason estimating is so difficult is that programmers can rarely predict how they will spend their time. A task that requires eight hours of uninterrupted concentration can take two or three days if the programmer must deal with constant interruptions. It can take even longer if the programmer works on another task at the same time. Part of the secret to good estimates is to predict the effort, not the calendar time that a project will take. “

It is a common malpractice to estimate based on “having it ready by the weekend”. Also, don’t worry too much about when the product will be delivered or how to manage the priority of the different tasks that will be assigned to you. That’s the Development Manager’s job! 😉

Therefore, the first tip for good estimations is : 1) Estimate the number of days a task would take to complete if you focused entirely on it and experienced no interruptions.

Another tool that isn’t used too often by developers when estimating is retrospective. Ask yourself: do you monitor how long you take to do any given task? If you don’t, you should. If you do, then that’s a very reliable source for estimations, because you can look up similar tasks you done in the past that are similar to the one you are estimating now and can infer what is the effort involved in the new task from the activities you did in the previous task.

So, then you’ll have 2) Compare the task you are estimating with tasks you’ve done in the past, whenever possible.

Also, think a little bit about what is it that you, as a programmer, do on a daily basis. Where do you spend your time? And how much time you spend on each task you do daily? When you are assigned a new task, what do you usually do? Preparation for the task, planning & designing for the task, development testing and deployment are part of what you do but are often left out of the estimation.

Hence, keep this in mind:

  • 3) Include the following in your estimation
    • a) Preparation (reading the spec, checking if you have all inputs required, etc.);
    • b) Planning & Design (before writing any line of code, think about how you will implement the feature);
    • c) Development Effort (the actual coding, refactoring, debugging, etc.);
    • d) Development Testing (a considerable amount of time is spent around testing it, fixing it, then testing it again, and so on);
    • e) Deployment (after you developed something, you’ll have to deploy it to test, right? That takes time!).

Another very sensitive thing to do is to discuss the task with a colleague. Two heads think better than one and your colleague can highlight issues that you mightn’t have thought of when producing the estimate.

So, another simple tip is 4) Discuss the task and your estimate with your colleagues.

Finally, please do add some contingency, because “Anything that can go wrong, will go wrong.” – Good Ol’ Murphy.

Some people think you shouldn’t have contingency when estimating. I’m of the opinion that a bit of estimation is helpful, as long as you don’t exaggerate, as it allows you to cater for unpredictable stuff that (always) happens on a daily basis.

However, be careful with contingency. Just multiplying your estimate by 3 (or whatever number) doesn’t work. Will not work. The best source for contingency is… your previous work! So, when you are looking at your previous tasks, as discussed in tip 2), take the time to check how much you had estimated initially and how long it actually took. You’ll probably see a pattern of 10, 20, 30% or whatever percentage of difference between the original estimate and the actual effort involved in finishing the task.

To finalize: 5) Introduce a sensible contingency to cater for things that may go wrong.

Below you can find the TL;DR version:

  • 1) Estimate the number of days a task would take to complete if you focused entirely on it and experienced no interruptions.
  • 2) Compare the task you are estimating with tasks you’ve done in the past, whenever possible.
  • 3) Include the following in your estimation
    • a) Preparation (reading the spec, checking if you have all inputs required, etc.);
    • b) Planning & Design (before writing any line of code, think about how you will implement the feature);
    • c) Development Effort (the actual coding, refactoring, debugging, etc.);
    • d) Development Testing (a considerable amount of time is spent around testing it, fixing it, then testing it again, and so on);
    • e) Deployment (after you developed something, you’ll have to deploy it to test, right?).
  • 4) Discuss the task and your estimate with your colleagues.
  • 5) Introduce a sensible contingency to cater for things that may go wrong.

If you wish to read more about this particular subject, this blog post from Manfred Stienstra is also good and simple read.

Happy estimations, folks!

Cheers.

Pedro

Leave a comment

Your email address will not be published. Required fields are marked *