FogBugz Technical Support

A forum for technical support discussion related to Fogbugz.
The current FogBugz Knowledge Base can be found at

Posts by Fog Creek Employees are marked:

Release Notes
Network Status

Time spent on a case - prior, during, after

Hello everyone!
I've got a question regarding the "working on" time measurement system. Fogbugz ensures that one cannot work on a case without estimating the time one would need to solve the case. In a way, this misses our daily workflow.

Often, a customer (internal or external) will call to report a bug or a feature request. These call can be rather lengthy sometimes... After that, I need some time to go through my notes and create from this a case that our developers can understand and use to create the feature/find the bug without having to ask for additional information. Up to this point, I often spend about one hour on a case just to create it. This is time that I cannot book *on* the case, because I would have to give an estimated time (and I shouldn't do that, because our developers should make their own estimates).

So what do I do with "my time"? It is important to document all time related to a case--- both for forecasts and to ultimately review the costs assoziated with it.

Also, developers often need time to analyse a case (and the code related to it) before they can give an educated guess how long it will take them. Without prior analysis, most estimates are wild guesses and useless. This is more time that needs to be booked on the case somehow.

Last point with this: Now our developers made their estimates and solve the case. Then the case is forwarded to the testers. The developers cannot/should not estimate the time the testers need.

Just some thoughts. ;) I know that there won't be a quick solution for these problems, but perhaps someone has a workaround? How do others handle this?
Would be interested in your comments.

Best regards,
Robin Schmidt Send private email
Friday, December 12, 2008
We do a few things that might provide you some ideas.

First, we have a "specifications" task that is open for a given project that time spent analyzing requirements (and finding bugs, etc.) can be billed against. This is a planning, or pre-implementation task for the project manager and developers.

Second, we have a "changes" task that is open after a given project has been released and is closed. This task is opened for time spent on small tasks that really are big enough to be their own task. The changes task collects the time post-implementation that would signal that the specifications were not clearly defined enough, or that we should open a new task because we're missing some functionality for the end-user.

It seems to me, if I understand you correctly, that you could bill your time against an open "changes" or "specifications" task that has no real estimate. Then you create the task to open up for the additional developers.

Here's some can't resists names for the task:

Project Management (PM)
Project Coordination (less-used than PM, easier to sell)
Project Efficiency Optimization (PEO, strange acronym)
Overlording (give it up for Starcraft!)

Okay, maybe I've taken too much liberty with the names, but I think it's solid concept.

Good luck!
Jason Td Send private email
Friday, December 12, 2008
I use a schedule item named "Customer support" that is used to represent all the customer interaction and bugfixing for customers during a release cycle.  Often it is on the order of a couple weeks.  Then, when the release is over, I close the schedule item with whatever time I spent on it, and hopefully improve my estimates for customer support for the next release!
Jacob Krall Send private email
Friday, December 12, 2008
Jason, Jacob, thanks for your input! I will definitely use your ideas (esp. the Overlording!) in my bigger projects!

However, there's still one rather strange project that's causing me trouble. We developed a large logistics-system for a customer and are still adding to and changing it, following all our customer's wishes. It's a very good and close relationship, and he's paying us per hour. So often times he'll call, describe a new feature on the phone, play some idea-ping-pong with me. I open the case, summarize the feature, give it to the developers. Later, when the case is closed, I look into the case, see that it took e.g. 7 hours (most feature requests are rather small), and send the customer a bill for this time.

I consider it "Overlording-Overkill" to create a separate planning-task for every small feature request / bug report. I would prefer to bill (and later: see) all the time spend on a feature in one place.

Again: I do absolutely agree with your suggestions for larger projects, where you have distinct phases for design, implementation and rollout. This is a rather special case, where development happens while the customer designs the program as he's using it. :)

Thanks again! If you have further ideas, please let me know!

Best regards,
Robin Schmidt Send private email
Monday, December 15, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz Bug Tracking and Evidence-Based Scheduling.