My estimation is usually fairly accurate since I've been doing the same thing for over two years now, the one thing I can't handle is outside requests and changes in priority. So I usually estimate things as "will take 2 days of uninterrupted development time", which usually means it will take a week sharing between tasks, or in worst case two weeks. I'll convey both the 2 day and 1-2 week number to project/program management, such that they are aware the task isn't hard, I'm just doing a lot of things at once.

I'd be interested in other systems people have for dealing with estimates as they relate to multi-tasking. My organization usually has 5-6 ongoing projects that affect me at any one time.

Some folks I know have resorted to a priority queue system, and this works fairly well, though it can be hard for some to accept. Essentially you maintain a list of ordered priorities, and then when some one comes in with a request you let them know where it is in your queue. Thus a relatively simple item may take a month to get accomplished.

Currently, I'm on the "cooperative multitasking" model of estimation. For those that play with OS's, you will know this doesn't work very well. You have to let everyone know there is a very good chance their "process" will be delayed indefinitely.

A similar method of setting an estimate is reported in this article.

A dependency is when you have two tasks, one of which must be completed before the next one can begin. I've found that with software, the dependencies are so obvious that it's just not worth the effort to formally keep track of them.

Usually, I like what joel writes. Not 'cause i agree or disagree, but because he usually thinks things out.

I've also been known to be proven wrong.

Why to use MS project or something that has equivalent functionality.

• Dependencies are dependencies. They are on resources, which are time and people. You can't make them vanish.
• Tracking them are of the utmost importance. For instance, take a simple junior-senior level programming relationship. One may do the architecture and API type functionality. The second, may do more interface programming and code maintenance. Yes, the dependencies are more obvious, but when it gets beyond these two people, what happens then? How do you keep track of who can do what?
• Time is a resource. When people take vacations and what not, you must make good estimates. Even if you don't factor in the warm-up time after a vacation, you are better off than if you never counted it in. You have things like holidays as well to worry about. What if one of your team-mates is jewish, and needs to take other holidays? It's a pain in the ass to do in excel. Especially when you wish to tell QA something will be ready, and your deployment team as well.
• Time estimates are hard to do when you don't do them often enough. I know in an ideal time situation, it will usually take me n*3 to complete something. If something is really hard, n*5. Good software schedule management programs will take estimates and remember how on track you usually are.

While it may be a little more complex than excel, learning how to use the tools, especially when it's not just one developer doing something and nothing else, it becomes invaluable.

Sorry Joel, but you are wrong.


I used to be a funny character, now I'm just 4 bits.

A few thoughts on timelines:

1. Always let people know right away that spec changes are going to cost in time or money, and sometimes both.
2. Always remember the Good-Fast-Cheap triangle (pick two). It's a law that you can't change.
3. Most importantly, always remember that letting someone bully you into changing an estimate/schedule w/o paying more in time or money, you're ultimately screwing both you, the developer and he, the customer, even if he doesn't realize or acknowldege it!

Do everybody a favor, and be a bastard about it.

What really gets me is the fact that (here, at least) I get told off for booking time on things like 'learning' (== keeping up to date on techniques etc. ), and told I should book it all on a project of some sort.. Fine by me, but that means I then need to over-estimate (which I cant, cos the current project got estimated by someone else, and there are no extra days, stupid tight time budgets), or run out of time and look bad.

Luckily, no UIs in this one, but some 'unknown techniques' which Ive had to learn first, those are the real pains..

(I should start doing re-estimates tho.. tho Im absolutely terrible at estimating time at all, or indeed remembering how long other similar things took me.. time to start making notes I guess..)

C.

If your organisation’s culture isn’t amenable to this level of scrutiny, then you’ll probably have a hard time with it.

The problem I have with the type of scrutiny you describe (and I've been there before) is that the information flow is entirely too much of a one-way street. Information gets extracted and shovelled into the gaping maw of Microsoft Project, with little feedback other than "hurry up!" to the troops. This serves the interest of the top-level stakeholders, but fails to help me recognize patterns in my estimation behavior.

Without seeing these patterns, how can I improve? It does me little good for a spreadsheet somewhere to say "When Dave says X, add 30%". There's little instructive value in that number. Is that 30% on all estimates? On some? Am I more accurate when estimating some classes of tasks than others? Are there patterns I need to know to recognize, so that I can avoid the "just another day, i'm almost there" trap?

The last time I looked at O'Connell (a few years back), it seemed that he was good on the planning and execution side, but had big gaps in the individual improvement area. If that's changed, I'll revisit his site.

These are all valid points. I think this estimation technique does not apply to all projects, but I would like to offer the following feedback:

"When Dave says X, add 30%." Using the above methodology, the tasks are broken down to a reasonably fine granularity. You certainly want Dave's input, but basically, you run a report against the database and you see how long Dave took last time he did the same task.

Detailed time recorded in a database allows you to query estimated vs actual time, by person by task, so revisions to the estimation process can be made over time. It also helps when answering your question: "Am I more accurate when estimating some classes of tasks than others?" as you have metrics that will tell you. (I think this is why O'Connell feels that estimates based on past experience only works if you have hard data.)

RE: "Information gets extracted and shovelled into the gaping maw of Microsoft Project..." To be honest, I'm not a big fan of MS Project. It does help to get an overview of dependencies, and shows what tasks can be done in parallel with the available resources. But I find it unwieldy and cumbersome. So while we use it, it isn't the guiding tool in the project. (I also think that some project managers -- particlularly those who have fallen into the role from non-technical backgrounds -- use it as a crutch in lieu of actual project management. Hey, if you're fiddling with charts then you're justifying your income, right?)