Scott Rosenberg writes about the new evidence-based scheduling feature in FogBugz 6.0. FogBugz has long supported enabling developers to enter estimates for how long it will take to resolve issues, and to enter the time spent resolving them as well. The problem was that once you did that, there were no really easy ways to mine that data and make inferences based on that information. The other problem is that it’s difficult to get developers to enter estimates for bugs and even more difficult to get them to enter the elapsed time. (Most developers I know don’t even keep track of their time on a per-issue basis.)
The only way to get developers to enter estimates is to demand that they do it. FogBugz 6.0 makes it a bit easier to keep track of elapsed time, though, by including a time tracking feature. We’re rolling out FogBugz 6.0 at work, and I’m finding that I actually like the time tracking. For one thing, it’s a tool for focus. When you kick off the timer on a task, you don’t want to jump around and multitask because it will just throw off the timer. The timer feature itself is pretty easy to use. We’ll see if I can stick with the habit of using it, but I am going to make a concerted effort toward doing so.
I’m finding more and more that accurate estimation is a key part of the job of software development, and it’s hard to get better if you don’t track your performance over time. Building things faster is obviously an important goal for any software developer, but being able to guess how long tasks will take before you start them is nearly as important.
I’ll report on how it goes with FogBugz 6.0 as I use it more.
October 12, 2007 at 10:51 am
Rafe,
Do you guys currently use an older version of fogbuz? if what did you use? I’ve been relegated to bugzilla hell because my employer is too cheap to pay for anything else and somehow it won out over trac.
October 12, 2007 at 4:46 pm
Lucky!
I’ve been waiting fo FB 6.0 to release, but they’re a little behind in getting the PHP version out the door.
I always thought the time-tracking feature mostly sucked, because there was no easy way to report on time-elapsed. It would also be helpful to have a duration measurement for various statuses (we hacked FB to allow ‘Resolved: Waiting’ for all of the various types of tickets, to indicate when there were external dependencies). It would be nice to see how long we were spent waiting versus working. 🙂
October 12, 2007 at 4:52 pm
@Jeff: FB is only $129 per seat (internal user). Any external user can submit a bug without having an account.
October 29, 2007 at 11:34 am
“The only way to get developers to enter estimates is to demand that they do it.”
Uh, have you worked with developers? They don’t really respond well to that sort of thing. In fact, I quit my last job over a similar issue. Took me about 5 minutes to find a new one. Sure, probably most devs don’t feel quite that strongly, but they’re likely to be pretty unhappy with that kind of demand.
October 29, 2007 at 11:39 am
You make a good point. I should have said, “provide them with an incentive to do it.” The incentive in this case would seem to be that if you enter estimates and track your time on a task-by-task basis, you’ll get bugged less for status updates.
I’m a developer, so I’m usually in the position of having demands made of me rather than of demanding things from other people, for what it’s worth.
That said, I don’t think it’s unreasonable to demand things of employees, whether it’s demanding that they use version control properly, or that they mark bugs resolved when they finish them, or that they enter estimates. If you find that having estimates on how long it will take to finish tasks makes your development group more productive, then you need to hire developers who are willing to enter estimates.
November 11, 2007 at 1:55 pm
“Uh, have you worked with developers? They don’t really respond well to that sort of thing. In fact, I quit my last job over a similar issue…”
I don’t know but when I hire a developer I hire him because I have some particular task need to be solved (btw I am a developer also), so there can be various requirement in that task, one of them is to give feedback and information to the project manager. So if you don’t want to do that… thats fine, but in that case you are not suitable for the task I need to solve. So it is better for you and better for me if you find another job somewhere else. Business is not about pleasure, business is about meeting customer needs (demands) and one of your customer as a developer is the project manager. And when you successfully solve your task and get paid for it, then you are free to have fun but while you are at work, please be at least so mature to know that you are not the center of the world. Thank you.
And of course if the manager ask you to do stupid things, then you will find another job (I would), and that way the stupid manager and the stupid company will suffer, but making estimations is not a stupid thing, it is essential for product delivery and the job of the developer is to ship products so giving estimation is good for you it will make you more effective, more productive, it will get you more money.
February 11, 2008 at 12:34 am
OK, so here we are about ~3 productive months since the original post…
Are you still tracking your time? Is anyone else doing so who doesn’t personally see a benefit from entering this data? Has anyone flat rebelled?
February 11, 2008 at 12:37 am
We haven’t had any projects that suit themselves really well to testing the system, sadly. I used it on a project I worked on alone and found it quite useful (although I didn’t use it to predict release dates), but I’m still waiting on the right project to really work the system.
That said, the uptake of people using the system to track time has not been what I’d hoped it would be.