What process do you use to estimate how long a (significant) programming task will take. Do you use one or more of the following:
Take a guess.
Then double it. :-)
My bill is $5000. Please make cheques payable to IainMH Consulting.
This is an interesting question, one that I would definately like to follow due to my level of experience (or lack of!)
For me, as a relative n00b, I tend to think about my task and break it down into the series of smallest tasks possible. This then allows me to get a better handle of the tasks at hand..
Some of these tasks I may be uber-confident in, and have estimates as small as 15 mins, while others I may have no idea and book a half or whole day out to research it.
While most of the time I over-estimate (better to be safe than sorry right?) My estimation is slowly improving.
Joel Spolsky did a great piece on estimating. He also did an in-depth post on Evidence-based scheduling which basically says "over/under estimating is fine, so long as you are consistent with it".
My boss knows I will probably finish early, but he always knows I don't commit to a deadline I cannot meet. So if I ask for time, he tends to accept my estimates without too much persuading. Maybe I am lucky.
I do feel however I need to be better at estimation. I would like to knock together a little app or something to perhaps emulate Joel's idea(s).
Apparently Microsoft are using a technique based on guessing the weight of an Ox
We try the to follow the Wideband delphi approach but don't follow it rigidly. Basically what we do is
Much of the estimation is down to experience of how long certain things take to do but seems to work for us. Discussing the individual tasks helps broaden our understanding of what is needed and find the better solution.
The next step depends on whether you have traditional BDUF or Agile
BDUF: multiply every estimate to get a figure that you're 95% sure you can be done by. That way you won't fail to hit targets.
Agile: stick to your best guess, but update it every day that you work on a task so that it gets more and more accurate as you get closer to finishing.
Something I rant about all the time (inc on my blog) is that all estimates are only ever guesses (even when good).
By all means use them in planning but when they're used as absolutes they get inflated and gamed, every time.
Depends on the problem and the size of said problem.
In terms of actual methods, most of what previous users have posted do go a long way towards giving a realistic estimate for timeline.
I've always just used my intuition and based the estimate on previous tasks/projects, then pad some time on as a safety measure. I don't really have a lot of set deadlines here anyways though, so if one gets missed nobody is going to say anything.
I also used Planning Poker for a while, thinking that it was nothing more than a joke... then I found that it was a very good way to make and share estimates - in the end we made an intranet version of the tool.
But the very important pre-requisite for this to work is that someone has to break big tasks in smaller, more practical, tasks; and then discuss them, the Planning Poker "game" being only the mean.
So what is making the real difference here is... experience, and a checklist like the one (already mentioned) from Joel Spolsky.
I like the scrum approach, where the tasks are broken down to items that can be accomplished inside of 2 days. This allows you to report on your work remaining and allows you to adjust your estimate based on your burndown.
My technique is:
I've done a lot of "break down the task and estimate small pieces" methods, but surprisingly the most accurate method I've used is to base it on past history of similar efforts.
The most important part of using past history is to use actual historical data. Do not guess what it took to do something, but record how long it actually takes you and use that data to estimate new efforts. I do this at a fairly high level (efforts that take several months, not days or weeks) and it works, but having a critical mass of accurate historical data is key.
I think the reason small task breakdowns don't work all that well is that they don't take into account all of the other stuff that causes delay. In my experience I've seen process changes and unforeseen risks far outweigh the error of simple historical comparisons. Therefore should spend more of your estimating time forecasting known process changes (e.g. introduction of a new type of code review) and anticipating risks or uncertainties rather than breaking down the tasks to a minute level again. Multiply your estimates by a factor for risk, complexity, or change in order to account for these other items.
Good estimates take some time. If somebody wants an estimate now, let them know you'll get back to them. It's better to give them a better estimate later and make them squirm a bit now, than give them what they want, and fail to deliver because you failed at estimating.
Break the task down into smaller tasks. Large tasks cannot be estimated effectively. If you are measuring these tasks in days, break them down further. Tasks should be measured in hours (and no, don't just measure in hours...if a task will take more than 16 hours, think about it some more and split it up).
Compare to previous similar situations.
Use some of that programmer intuition, without being arrogant or optimistic about your abilities and give a buffer for potential problems (analyze potential problems and try to come up with estimates 'if this happens').
Always give a range: 10 hours +/- 2
Avoid compromising your estimate. If a manager says that's too long, don't just reduce your estimate for the same amount of work. Compromise: if they want it sooner, they'll have to cut scope or similar.
Take into account vacation of people you might have to work with if possible if the main task is a big one.
Practice. Even if you don't need to give an estimate to anybody, estimate for yourself, and see how accurate you were. Try to find out why you were off if you were.
As others have mentioned, we use relative estimates - story points. We find a baseline task to call a "1", and then everything gets based off of the relative difficulty from that story - 1, 2, 4, 8, 16, 32, etc. We use an iterative approach, and teams can't sign up for stories greater than 4 units - they need to break them down with the business.
However, at Agile 2008, Joshua Kervisky of Industrial Logic present his microreleases strategy. This is similar to the Kanban pull style. Basically there are no estimates - everything is done based on a gut feel. He claims to have had good success with both experienced and not-so-experienced teams.
The key for us is that our estimates aren't just code complete - they are code complete, QA and business verified. So when we say, done, we mean, done. This helps a tremendous amount if you can do it - some customers/business people simply don't want to be involved at that level.
I'd highly recommend the book Agile Estimating and Planning and User Stories Applied both by Mike Cohn. It has helped me and everyone I've recommended it to tremendously.
A technique an old manager of mine used for large tasks was to get everyone on the team (only a few people) in a huddle, count 3-2-1-go and on go everyone had to give their estimate. The highest was then used.
the scary part was how extrodinarily accurate it was!
Once you've come up with that list of little tasks and tacked estimates on to them, take a copy and look at it some time down the line. How many went as expected, how many didn't need to be done at all and what turned up that you hadn't thought of?
When you're embarking on a new software project, by definition you're about to do something that's never been done before. So you don't - can't - know how long it's going to take. If you're telling this to someone who doesn't get it, pity them - they're in a job where every day is the same and they must be dying of boredom.
So estimate by all means but don't spend an eternity on it. And revise your estimates regularly. Agile practises are a good starting point for this.
If you're being given a fixed time to deliver, that's OK. Just explain that they can dictate under these conditions: fast, cheap, good - pick two
It's worth mentioning with breaking down tasks that the more finely detailed your estimates get, the more time you estimate for the whole project.
This can lead to some scary differences between your initial back of the envelope calculation, and your very detailed estimate based on really understanding the problem in hand.
Of course, it should go without saying that the longer estimate is usually more accurate.
It's also really important not to forget the customer's role in all of this...
We are almost obsessional (and sometimes we seem to be in a tiny minority here) about doing what we said we would by the time we said we would. But I've lost count of the number of times that it's the customer who holds things up.
I love using parts of agile methodologies in our projects, but it's a rare (commercial) customer who will play their full part in the project. Many customers want fire and forget. When it comes to making design decisions, or providing basic information about their business, or signing off on things, or paying on time, or ordering hosting or... you find they've taken an extended 2 month break in the Carribean.
You have two choices - you can either factor this in, or make clear from the start that they have a role to play too and if they don't meet their obligations the deadline may well have to move.
As for actually using your lovingly crafted application in the future (and I'm mainly talking web based CMS / e-commerce type applications here), they usually haven't allocated staff to it and expect the fairies to step in and help out...
Cynic, moi?
I've had the most success with a combination of functional size metrics, coupled with historical data. I've used LOC (lines of code), use case points, and function points (IFPUG), with the latter working the best for business applications.
By using historical data, you reduce the bias (systematic optimism, usually). By using a sizing metric, the resulting estimate holds up better under pressure. It also give you a way to quantify scope changes.
Contrary to common belief, a requirements analyst who knows what they're doing can come up with a rough but good enough function point count very quickly. It doesn't take weeks. They also really help you spot gaps in your requirements.
Independently, we would also run a planning poker session, and then compare the two. We set up target-budget, variable-scope, iterative-delivery projects this way.
I ought to write up some of my other Stupid Estimation Tricks. www.ufunctional.com
Improving my estimating was the reason why I started reading up on the Scrum idea of burndowns, velocity and story point planning. My estimates were terrible.
Basically, you give each piece of functionality a relative size (in story points), where a feature that has a value of 4 is twice as much work as a 2. Which is nice and generic, and will work on any project.
So for example, if you do 10 points of work in a 2 week iteration, you have a velocity of 10. If you have 50 points worth of work, you can expect to be done in 4 more iterations, or 8 weeks. As you progress along in the project, you get a more and more specific idea of how long it will take.
If you use those size values, with time-boxed iterations, your burndowns will give you realistic estimates of when you will be done, on any project you come across.
See these books for more information about how to do the topics I talk about above.
Steve McConnell's book Software Estimation: Demystifying the Black Art covers this. It won a Jolt award and StackOverflow loves Steve McConnell.
best would be to account for enough time for your testing/debugging and your forecast of the first round of polish. theres nothing more aggravating to deal with Quality Checks that you cant accommodate in a fixed deadline given the design of your application.
If you've never done the particular task before it's quite hard to estimate how long it will take. Even if you have, atleast for me, you often fall prey to a small issue that can extend the estimate by 2 days.
The "think of your estimate and double/triple it" works fairly well, but if you completely over-estimate and end up with a 2/3 days spare you look like you've just over-estimated so you can sit and surf the web for 2 days.
Good seniors/project managers will give you plenty of time to do a task (and double the time if they don't know what is involved), rather than ask you for an estimate.
In my experience, the most successful approach has always been to break down the task into smaller and smaller parts until I feel comfortable giving a time estimate on each individual piece.
Then I add up the total time -- and double it. I find that even with this micro-estimating technique I give myself a little extra on a few things, and WAY too little time on most things. Forcing myself to double the estimate actually turns out to provide a pretty accurate picture of how things will turn out, because there are ALWAYS unforeseen factors and complications in every project.
The other benefit of this approach of course is it gives you a detailed roadmap to follow as you proceed with the project, and if you track your progress on each task using a good project management suite, you're better prepared to answer the question in the future.