Hi all,
A whirlwind of grant applications have kept me from doinag any programming on my own projects. Although writing a 25 pg R01 grant in 60 straight hours has to be at least a university wide record. During the handful of 5 min breaks I took to allow my brain to re-solidify I stumbled across the Joel on Software Blog. Specifically the post on Evidence Based Scheduling. This is implemented in the FogBugz software project management.
The concept is pretty simple. Create a list of tasks which have priorities, time-estimates, owners, etc. which are required for “completion”.
A list of tasks which must be finished for the current release.
A “back of the envelope” method to determine the potential release date for the project would be to simply add up all of the times. However, as everyone who’s ever actually programmed knows, some estimates are dead-on … some are horribly wrong.
Resolving this issue is the FogBugz secret sauce. If you can discipline yourself to put ALL tasks into FogBugz and use its “Working On” function to record the time spent on a task then it can work its magic. When a task is marked as “resolved” FogBugz will evaluate how well you (as a programmer) can estimate the task times.
My current estimation history
It then runs a monte-carlo simulation to determine a confidence interval for the project completion as a function of the date. You don’t need to guess wildly at an estimated date … if you have all of the data in FogBugz, the estimates should be reasonably effective.
The estimate for the release date
The part I like the most about FogBugz: they have a FREE account for students/start-ups … the only limit is that you can only have 2 users. I highly suggest you take a look at their website: http://www.fogcreek.com/FogBugz/.
Currently I don’t use FogBugz for actual bug tracking, I’m just not at that stage yet, but I’m sure it will come in handy. I can see endless possibilities for the usefulness of this tracking software!
-Will
Hi Will:
Glad you discovered FogBugz; now you just have to start using it!
If, in between all the furious grant writing, you want to read more of Joel’s stuff, I’ll send you a copy of Joel on Software–just shoot me an email so I can get your address.
Regards,
Dan
Fog Creek Software
This is interesting, I didn’t know that FogBugz can do that. What if the task is reopened (which is usual)? Will it learn from the current Project Manager estimation to give a better estimation when it’s used in another Project (by the same Project Manager)?
It seems (since I’ve already had to do this) that if you re-open the task it will just continue running the clock on that task. Then when you re-close the task it will update your estimation history and subsequent release estimations.
I think it would an interesting feature if it could also track bugs that come up in relation to specific tasks. That way you could see how long the task TRULY took, including all the work you had to do to fix it after you “finished”. Perhaps you could use that as an argument when your boss tells you to rush a feature … you could easily determine which features were rushed, how much time you had to spend fixing bugs afterwords.
[...] I had a thought about a killer feature for a website. In a previous post I talked a little bit about FogBugz. I’ve been using it for the past ~6 months and [...]