How can you estimate time for something you've never done before? It could be a feature you've never written before or one which you are not sure is even possible?
Yesterday I was asked to integrate Sendgrid with our analytics server over cURL in a cronjob.
Not only had I never used Sendgrid before or even seen the codebase for our analytics server, I've never used cURL Multi before - so I was walking in knowing nothing.
I said it would take me "about 2 days", which seemed "fair" to my manager, in the end it only took me about 5 hours, so they were happy to get it early and I had all the debug time I needed.
I try to overestimate, but then I worry that I may be seen as wasting time or being grossly inefficient. Obviously there is a balance. This is something I worry about much.
My problem is that if I say it would take me 2 weeks and my colleague says he can do it in just one - though I am overestimating, he will most likely seem a better, more efficient employee.
If they consistently estimate less effort than you do AND they consistently delivers on those estimates, then they ARE more efficient. However, you will find in most cases that the people who give lower estimates, tend to miss deadlines more often too.
How did you decide that it would take you about two days? Was it just a number or did you try and break down the task into sub tasks and decide how long each would take?
Well, I took a look at the Sendgrid api page, and decided whether to use their built in API or their web API over JSON, and since I had used cURL quite a few times, it seemed a simpler task to implement it myself.
I then took a look at the analytics and the database makeup and a break down of tasks which I needed to accomplish were as thus (I was told by my manager to make product_name work with Sendgrid - that's it):
- Connect to the database
- Query recently added "leads"
- Grab lead email information and funnel_id
- Grab template and cache it (multiple emails can use the same template, and there are standard templates, making a query for every single template would make database IO a real issue)
- Build up the emails in to an Array, complete with template reference and replaced [TAGS] (full name, etc) required by each individual email
- Actually initialize cURL, create the multi_curl_init objects and loop through, check each request for the {success} JSON object returned by Sendgrid and reschedule / show an error in our logs for that email funnel
- Clean up after ourselves, rinse and repeat 10 minutes later for the next lot of leads.
- debug
In all honesty, the only way I knew the length of time required was breaking down an estimate for each individual task and then adding them all up and doubling it. It was an "intuitive guess".
It's a complicated business. More than anything I'm very honest about the uncertainty these days. I also try to give ranges for things - instead of saying it will take about 2 days (which cements a specific deadline), say, 2 - 4 days.
As you get older (more experienced) you become less concerned with overestimation. When you're young and ambitious you think that a) you can do it faster than you really can and b) it's bad to say it'll take 2 days when really you think you can do it in 1. a) you can't and b) people don't normally question your overestimates.
Also, try to think things through. Ask questions. Discover those subtle missing requirements that haven't been communicated yet. Try to picture how it will fit into the system and imagine why that might go wrong. If it's a bigger feature break it into parts and (over)estimate each of those.
Be thoughtful, overestimate and be honest (especially with yourself).
I use a very simple version of function point analysis. Write down all the different things you know you need to do, beside each one write easy, medium or hard. easy takes 0.5 to 1 day, medium 2-3 days, hard 3-5 days. If you think any bits are very hard then break it down - if you can't then you've found something you don't know - and you have to focus on that - this is a risk and flag it as such.
If it's a big project then chop it up into deliverables, so you can monitor your estimates along the way.
..there's a lot more but something to get you started.
(if you have to deliver on your estimate - double it :-). When you double your estimate - make sure you don't work to your doubled estimates - otherwise you'll have to double it again :-) )
Break it into smaller pieces that you can estimate. Is there something that is similar? You can always say let me research a little bit to get you answer. In engineering/technology it better to under commit and over deliver. In business it's better to over commit and work your ass off.
I work at an agency using ASP.NET, so I find myself regularly estimating for projects and small jobs. The biggest issue with our clients is that they will always argue how long things will take. One of our large clients has a SEO guy in one of their offices that has "11 years web experience" (despite not programming professionally for the best part of three years, and seemingly knowing very little about programming or how the Internet works) and he will frequently argue every small cost. We quoted two hours to modify a form used across eleven country-specific sites for one specific use case on a single site, and he went crazy, stating that it'd take him "twenty seconds in PHP". A bit of Googling shows that this guy hacks a bit of PHP in his spare time, but can't code for shit, and given his position at the company it's not really up to him to dictate price.
Anyway, the only way to give a valid estimate is to break down the task as much as you possibly can and to assign risk to each small task. Build a spreadsheet and break down every task into the smallest possible unit, and assign a risk rating to it. Any tasks that are high risk should be estimated as a range, rather than a fixed time. Even with this advice you'll still get things wrong, but it's impossible not to. It's the nature of estimating.
The best advice I can give you is to stick to your guns and estimate for how long it will take YOU to do a task. If people still argue, then tough. As rightly pointed out by adios, more experienced devs/pm's will happily overestimate and will fight their corner to say that this is how long a task takes. If you are honest with yourself on how long a task will take then you will find it much easier to stick to your guns when someone complaints that "an easy task" shouldn't take as long as you've said.
Never gather it, until you know how it's going to be used.
Who is asking you to estimate, and what are they going to do with those numbers?
Until you explore and understand the answers to those kinds of questions, it's irresponsible to try to satisfy the request.
If you like the answers you get, then give the best data you can. If the answers you get suck, then you need to try to change how people are behaving. If you can't, then maybe you need a new job.
14 comments
[ 2.7 ms ] story [ 10.5 ms ] threadYesterday I was asked to integrate Sendgrid with our analytics server over cURL in a cronjob.
Not only had I never used Sendgrid before or even seen the codebase for our analytics server, I've never used cURL Multi before - so I was walking in knowing nothing.
I said it would take me "about 2 days", which seemed "fair" to my manager, in the end it only took me about 5 hours, so they were happy to get it early and I had all the debug time I needed.
I then took a look at the analytics and the database makeup and a break down of tasks which I needed to accomplish were as thus (I was told by my manager to make product_name work with Sendgrid - that's it):
- Connect to the database
- Query recently added "leads"
- Grab lead email information and funnel_id
- Grab template and cache it (multiple emails can use the same template, and there are standard templates, making a query for every single template would make database IO a real issue)
- Build up the emails in to an Array, complete with template reference and replaced [TAGS] (full name, etc) required by each individual email
- Actually initialize cURL, create the multi_curl_init objects and loop through, check each request for the {success} JSON object returned by Sendgrid and reschedule / show an error in our logs for that email funnel
- Clean up after ourselves, rinse and repeat 10 minutes later for the next lot of leads.
- debug
In all honesty, the only way I knew the length of time required was breaking down an estimate for each individual task and then adding them all up and doubling it. It was an "intuitive guess".
As you get older (more experienced) you become less concerned with overestimation. When you're young and ambitious you think that a) you can do it faster than you really can and b) it's bad to say it'll take 2 days when really you think you can do it in 1. a) you can't and b) people don't normally question your overestimates.
Also, try to think things through. Ask questions. Discover those subtle missing requirements that haven't been communicated yet. Try to picture how it will fit into the system and imagine why that might go wrong. If it's a bigger feature break it into parts and (over)estimate each of those.
Be thoughtful, overestimate and be honest (especially with yourself).
If it's a big project then chop it up into deliverables, so you can monitor your estimates along the way.
..there's a lot more but something to get you started.
(if you have to deliver on your estimate - double it :-). When you double your estimate - make sure you don't work to your doubled estimates - otherwise you'll have to double it again :-) )
[1] http://en.wikipedia.org/wiki/Hofstadter%27s_law
Anyway, the only way to give a valid estimate is to break down the task as much as you possibly can and to assign risk to each small task. Build a spreadsheet and break down every task into the smallest possible unit, and assign a risk rating to it. Any tasks that are high risk should be estimated as a range, rather than a fixed time. Even with this advice you'll still get things wrong, but it's impossible not to. It's the nature of estimating.
The best advice I can give you is to stick to your guns and estimate for how long it will take YOU to do a task. If people still argue, then tough. As rightly pointed out by adios, more experienced devs/pm's will happily overestimate and will fight their corner to say that this is how long a task takes. If you are honest with yourself on how long a task will take then you will find it much easier to stick to your guns when someone complaints that "an easy task" shouldn't take as long as you've said.
Never gather it, until you know how it's going to be used.
Who is asking you to estimate, and what are they going to do with those numbers?
Until you explore and understand the answers to those kinds of questions, it's irresponsible to try to satisfy the request.
If you like the answers you get, then give the best data you can. If the answers you get suck, then you need to try to change how people are behaving. If you can't, then maybe you need a new job.