Evidence Based Scheduling - Joel on Software

http://www.joelonsoftware.com/items/2007/10/26.html

by luccastera • 19 years ago

36 21 19 years ago

joelonsoftware.com

joshwa• 19 years ago

Sounds a lot like FDD/Agile-- lots of estimation, and getting a good read on team velocity.

jkush• 19 years ago

...with an emphasis on helping management be rational.

Readmore• 19 years ago

Joel is an excellent salesman! Based on his article I totally want that feature now, and not only did he make it sound great he also made it sound in-depth enough that I would rather pay for it than waste time trying to re-create it. Very nice.

Goladus2• 19 years ago

I thought an evidence-based guess was called a hypothesis.

Anyway, my problem with scientific analysis of my work habits has always been the observation phase. I can keep timesheets, but that turns out not to be useful data because I only keep timesheets reliably when I'm full of energy. When I'm full of energy, I'm more productive at everything.

michaelneale5• 19 years ago

That would be consistent with my experience.

aston2• 19 years ago

Empiricism, yes.

qaexl• 19 years ago

I have the same experience too.

However, when I run though what Joel was talking about, you create a feature list with the estimate first. Keeping track of the time you spent on a feature means going down the list and putting down how much time you spent on it. Keeping track of time by just entering in a log has always been problematic for me.

And not having to keep track of interruptions is even better.

dpapathanasiou• 19 years ago

Past results are no guarantee of future performance

;)

Tichy• 19 years ago

Could work well in combination with Mylin: http://www.eclipse.org/mylyn/ (monitors how long you take for completing your programming tasks).

michaelneale5• 19 years ago

No Joel didn't mention mylin. So it can't be useful at all ;)

tx• 19 years ago

"P.S. Evidence Based Scheduling is built into FogBugz 6.0."

Ahh! Of course...

emfle• 19 years ago

Yes, he thinks evidence based scheduling is a worthwhile thing to do, so he builds the feature into his application, then blogs about it.

How dare he.

mhidalgo• 19 years ago

This method works for larger companies with lots of data. As a startup I find it hard to see this being implemented.

DougBTX• 19 years ago

The predictions are per-developer, so it shouldn't matter how many developers you have. I think it would work for any developer who wants to improve their ability to set deadlines, it just has some ramp-up time before the predictions become useful.

nikolaj• 19 years ago

of all the attempts i have made at estimating.. only one works pretty much spot on.

Essentially, take the gut feeling, double it, double it again, and add an increment.

Example1: gut estimate is "yeah, thats a five hour task".. so, 5 -> 10 -> 20 plus.. oh.. 2 hours, so 22. Seems absurdly large, yes, but factor in all those little thingsl, testing, deploying, etc, and lo and behold, two days plus some is gone.

Example2: Hmm, 2 weeks of solid (40hr week) dev time. So, 2->4->8 + 1 = 9 weeks. Woah, yeah that seems a bit large for project X.. but wait, client drags on assets, unforseen issues here and there, run into a snag for a couple days.. and boom!, almost two months have gone by.

I know it feels dishonest to so drastically overestimate what you Really think it will take, but the truth is the reason there is so much distrust of programmers by business people is that we so consistently miss deadlines. I know the estimate seems huge, but it needs to be, because ultimately it is very realistic, and if you beat it (doubtfully by much), everyone will be happy.

An oversized estimate finished early is better than an undersized estimate finished late. Always.

jsnx• 19 years ago

This approach should be sensitive to sample size, but I don't see any discussion of that. If he's tried it a lot, there should be some discussion of error on the first 10 hours, 100 hours, 1000 hours...

Evidence Based Scheduling - Joel on Software

Related Stories