best-practices Questions - FogBugz Knowledge Exchange

Ongoing "General stuff" type tasks

2012-02-01T09:04:18Z

In my work place I need to log in 8 hours a day to whatever tasks I'm working on. We actually use Redmine officially but I use Fogbugz and then port the information across.

When I'm working on a well defined, specific bug or feature, that's easy and I can be "Working on" that item in Fogbugz.

However I have found myself creating tasks like "General Project Stuff" with an estimate of 1000 hours just as the default thing to fallback on when I'm not working on anything that specific. Maybe I'm helping a colleague with some problem, or in an unplanned meeting, or writing some thoughts down on some topic.

Is this a good idea or not? It seems too much work to create tiny little tasks for every little thing I'm working on, but I worry that I'm abusing the system somehow.

How does everyone else deal with this kind of 'miscellaneous' time?

What level of granularity is appropriate for tasks?

2011-11-30T17:58:21Z

I've recently started using FogBugz. I've used it to design my application (more or less along the MVP design pattern), and now I've started working on the actual tasks.

I've run into an issue where it seems that my tasks are too spread out. For instance, I have a task to create function X in the presenter, but that requires that I have a Model (and accompanying interfaces), and then I need a view to show it in. So I've got to go find out where the tasks are that relate to those other pieces are and charge time to them.

I could create tasks based on desired behavior, e.g. "Create a new message" - but that requires several pieces - a message model, a data-transfer version of the model, etc., etc. but I worry that I will miss requirements so I'll estimate low, or that I'll estimate requirements in one task, but end out creating them while I work on another task.

What seems to be the ideal level of granularity when creating tasks?

How to Estimate Software Tasks

2010-09-15T19:24:51Z

What are your best practices for estimating software tasks?

Best Practices: What's the best way to record root causes ("Fix it twice") cases?

2011-10-25T05:17:40Z

Hello,

reading articles like "Seven steps to remarkable customer service" or this we decided in our team to also raise root causes/"Fix it twice" cases.

However, question from some members was raised - what is the best way to track such cases? So far, we created dedicated area and milestone in the project, but still have an open question how to link first case (incident) to the root cause/"Fix it twice" case. Should it be raised as subcase? or just put a reference in the text?

Thanks, Alexander

Best Practices for Using Autosort

2009-09-10T17:37:29Z

It's not immediately clear what one should be doing.

When should I create global milestones?

2009-12-27T12:22:32Z

When global milestones should be used?

How do they affect the EBS?

I think that should be explained in more detail than in current docs. The global milestones report isn't completely clear.

How does EBS handle multiple projects in global milestones (i mean developer multitasking)?

Best practices for organizing FogBugz?

2011-07-12T12:32:48Z

We've got a couple of products. Each product has a backlog of features waiting to be built. Each feature has a UI design doc (usually a drawing in PowerPoint), some design notes, and implementation notes. Once the dev work is underway, there are questions and answers, status updates, and release schedules.

What's the best way to use FogBugz to manage this kind of stuff? We tried putting the design docs into cases, but that meant the only way to see the current state of a design was to read all the notes in the case.

We tried putting the Q & A into a case, and the design docs in a wiki, but the wiki doesn't show diffs of attached files (the PPT designs). At least when everything was in one case, you could easily see all the past versions.

Has anybody got a better idea?

How much database expertise do I need to host FogBugz myself?

2011-07-07T18:29:57Z

I'm considering running FogBugz myself, but need to know how much I need to know about SQL Server or MySQL to do so safely.

Best Practices for Wiki Structure

2011-04-25T17:50:00Z

I've just started using the FogBugz Wiki and I wanted to get feedback from people who have used it on what has worked and what hasn't in their structuring of the Wiki.

We have several projects going on. They sometimes overlap, but not often. So I could create a Wiki for each project. Or I could create one Wiki and have the projects as entries in the one Wiki.

What are the pro's and con's of these two approaches?

Are there any other ways to do it?

Any tips, gotchas, etc?

All feedback is appreciated.

Feature Request: Migrating mails into FogBugz

2010-02-01T17:48:50Z

I unfortunately have some customers which have the bad habit of sending support mails to my personal address instead of FogBugz.

So my currect approach is to either manually open a case or mail FogBugz myself - both are not optimal.

Therefore, it would be great if I could just forward the mail without editing it to the FogBugz address, and FogBugz would figure out that this is a mail that needs to be imported:

The sender (forwarder actually) is a known FogBugz user
The mail has an empty body (or just whitespace) before the forwarded mail body - just as FogBugz now already recognizes the forwarded parts to be hidden
Valid header information can be inferred from the Subject, To, CC and From lines

In this case, FogBugz could just "remove the envelope", so that the originally forwarded mail would be inserted along with the correct correspondent. The one which forwarded the mail could be set as case opener.

Since I don't see how I could implement this via plugin I'm posting it as feature request.

EDIT: Now that we have IMAP support, the preferred way of doing this is to simply move the message into the FogBugz mailbox for pick-up.

Does public case submission have spam autosorting?

2010-02-05T03:46:27Z

Hi,

I am having trouble getting my Autosort to work. It seems that the jobs come in form the user interface assigned to a current project, because the projects allow public submisison. Is best practices to allow submission only to the Inbox, and then sort them by project from there?\

Thanks

Mark

Can clients be educated about not reactivating closed Cases?

2010-01-05T20:50:32Z

We have email templates that specifically request clients not to reply unless they have additional info for a case. We specifically (politely) contact repeat offenders to explain what that means, but still clients reply to final resolution emails with a courtesy "thanks" or "great" or "finally!".

The result is that after we have set a Case to CLOSED (Responded), we continually get replies from clients that reactivate the Case in question. That's just one more thing to deal with on a case that we thought was closed for good. It's small, but it's annoying.

Is there any way that anyone has found to avoid this problem?

:)
Please only post answers with additional information. Courtesy non-answers will extend the life of this question or otherwise result in unnecessary time being spent. thanks
:)

EBS shows a lot of work left for testing Virtual User

2010-12-31T13:22:31Z

I'm having real trouble getting anything useful out of EBS. I think our current process doesn't support EBS properly and would like some advice on how to fix this.

Once a bug fix or feature request has been implemented by a developer, our process is as follows:

Dev changes the status of the case from "Development" to "Testing" (we're using the Workflow plugin and have set up a number of different active statuses to denote stages in our process).
Dev assigns the case to Virtual User called "Testing User".
Dev deploys the software somewhere and advises the tester (who is typically a business user who isn't on FogBugz, hence the Virtual User) to test the software.
If the case passes testing the dev deploys the software to the live environment and resolves the case, which is then closed by the case originator.
If the case fails testing the dev assigns the case back to himself/herself, changes the status to "Rework" and we go round the loop again.

My Completion Date (Probability Distribution) always looks like there is more work left in the project than there actually is.

My Per-User Completion Dates show that the bulk of the work remaining is to be done by the Testing User.

I'm guessing what is happening here is that changing the status to Testing and assigning the case to Testing User is doing nothing to tell FogBugz that the development work on the case is now finished. Therefore EBS is telling me (based on remaining time on the cases and variations based on estimating history) that the Testing User has a lot more work to do, which they can only do in series based on their working schedule.

Any advice on how to help would be greatly welcome. Some specific questions I have are:

Are my guesses on what is happening here correct?
Is there any way for me to tell FogBugz that the work on a given case is done, even though it's at an active status?
Should we be resolving cases when the feature is implemented and tracking the resolved case through the testing and deployment stages (which will be very difficult without being able to change its status)?
How do other people manage a User Acceptance Testing phase performed by people who aren't FogBugz users?

Will EBS support lots of individuals adding work and booking time to a case?

2010-12-31T11:12:31Z

We use FogBugz for tracking bugs and features through their entire life-cycle, which includes requirements gathering for a feature or replicating a bug, development, testing and deployment to live of the feature or fix.

We use the Workflow plugin to give us relevant FogBugz statuses for these steps in our process, resolve a case when it's implemented to live and close it when the originator is happy that the feature or fix is live and working (all textbook stuff I hope).

A number of people need to work on any given case: * A Business Analyst to define requirements for a feature or App Support to replicate a bug. * A developer to actually implement the feature or fix. * A tester. * A sysadmin to deploy to live.

Ideally I'd like each person involved in the process to estimate their time and book time against the case so we can properly charge customers for the full effort spent on a piece of work, not just for the development. I suspect this would mean each person who works on the case would need to increment the estimate by the amount of time they anticipate spending on it, as well as book the time they actually spend.

My concern is about how EBS (particularly the estimated completion dates, burn down charts and per user completion dates) might handle this. Will it "just work" as intended, or is this going to give me funny results?

I have thought about having different cases for each of these tasks (perhaps with 1 parent and a subcase for each person) but keeping those all in sync will be a huge admin headache I'd really like to avoid.

What's the recommended workflow for requesting additional information?

2011-01-10T23:49:38Z

Frequently, before work on a case can be completed, additional information has to be gathered from another user -- usually, but not always, the case opener. (Note that in the following scenarios, the cases are both opened and resolved internally.)

The trouble is, even if a user is subscribed to a case, or that user is 'notified' with the slick new Notify plugin, adding a question as a comment to the case is often insufficient, because it doesn't show up in the asked user's work queue (so it can be easily forgotten), leaving a case in a sort of limbo, where the implementer is waiting on the opener and the opener is waiting on the implementer.

This problem can be solved by actually assigning the case to the user who must answer the question. Simple enough.

Unfortunately, this has the nasty and unintended side effect of also instantly affecting reports and load balancing results, since FogBugz reports assume that the current assignee is the one working on the case.

Some bug tracking solutions solve this ambiguity by separating the concept of Implementer from the concept of Assignee, which really are two different things, but FogBugz recognizes no such separation.

How have other users solved this problem? Does Fog Creek have a recommendation?

Linking bugs with email inquiries: use subcase?

2010-10-21T08:48:49Z

Hello,

We've been using the Inbox of FogBugz to manage customer support for a relatively short time. It works great. Now, we've created a new project for a product and have started entering bugs in it. For one bug in the product project we have three email inquiries in the Inbox that discuss the bug. What's the best way to connect or link the bug report with the email inquiries? Should we add them as subcases?

I noticed that someone in the following question is using subcases to link bug reports with email inquiries. Is this common practice? http://fogbugz.stackexchange.com/questions/5087

Thanks, Chuck

Tactics for not letting cases slip through the cracks

2011-01-13T00:14:12Z

I manage a distributed team of Software Developers who aren't the best at keeping their cases up to date. There are a couple of aspects to this problem:

For a variety of reasons, which can be summarised as "nobody's perfect", sometimes someone overlooks a case which is assigned to them. It falls between the cracks, goes stale and never gets finished.
Dependant on how you choose to use FogBugz, there can be a few different bits of case metadata you need to update and keep in sync as a case progresses, otherwise you effectively leave the case in an inconsistent state. As an example, the step of our workflow which transitions a case from "Awaiting Development" to "Development" includes a developer having to do all of the following things:
- Assigning the case to themselves.
- Changing its status from "Awaiting Development" to "Development" (we use the Workflow plugin and have multiple active statuses to denote these different steps in our workflow. We also let workflow drive the default assignee for a case transitioning to a given status, but it doesn't solve all these problems, e.g. it can't pick which of our developers is going to work on it).
- Removing the case from the Backlog (we use the Project Backog plugin).
- Start booking their time to the case.

I've lost count of the number of times I've spotted that a developer has assigned a case to themselves, but not updated its status to "Development" or some other minor oversight.

Clearly there are procedural and cultural aspects to this problem (which I'm working on!). Any responses on this problem will be welcome, but specifically:

What tactics have other people employed to spot those odd cases which get overlooked when someone gets distracted by something shiny or gets reassigned to a new case before finishing their old one?
Does anyone else find that, unless everyone is being really careful, its easy to end up with cases which aren't 100% correct, meaning that it's difficult to know exactly what their status is? If so, what do you do to manage them?

Best Practices for managing multiple mailboxes and autosort with fb7

2010-04-07T21:49:30Z

Hello,

We recently began using the mailbox feature in fb7 for one of our customer support areas. As what appears to be the popular and sensical practice, have setup autosorting to the inbox project and have found this to work quite well.

We are looking to add a second mailbox to our fogbugz install, but was wondering if anyone could make any recommendations for how they would setup autosorting. I'm somewhat new to this feature, but I was thinking that adding a second mailbox to autosort into the Inbox could be a littel confusing, especially since each mailbox is managed by different people.
My initial thought was to create a new project named "inbox 2" (or something like that) and create Undecided, spam, and non-spam areas in the same manner the inbox project is setup. However, I am not sure if the autosort would understand this configuration and treat mail as it would if it was going to the "inbox".

Does anyone have experience with handling multiple mailboxes and would share any suggestions.

What's the best way to handle small, quick, multi-step chained workflows involving multiple people?

2010-12-03T15:11:32Z

We do primarily web development, but have very segregated roles within our group, so to make even a fairly small graphical change to a page at least 3 different people all have to do some portion of the work, and what they do is strictly dependent on the person before them in the "chain".

In the past (and sometimes still) people talk about this process in terms of "passing" things from one person to the next, sort of like an assembly line.

A typical (as in, daily) conversation about what is going to happen with a small project goes something like this: Person X will design the screen, and then pass the design to person Y to lay the design out as a web page and chop up the images as needed, and then pass that layout to person Z to program the page up and deploy it.

Graphic designer creates a "screenshot" of what it will look like
Layout monkey takes the screenshot and turns it into a static web page
Programmer takes the static page and puts it into the site, attaching any code for content generation and functionality that might be needed, as well as adding the images and changing the HTML of the existing page if needed
Same programmer deals with deploying the changes up the server chain from their Sandbox -> Dev -> Demo -> Production.

Thus far, we have been having a lot of trouble mapping this sort of a workflow into FogBugz. We have tried to use a series of sub-cases to lay this out, but the backwards nature of putting the sub-cases together seems to just cause more confusion.

Implement layout for feature A
1. Layout design for feature A
  1. Design screen for feature A

One of the things that often trips us up, even when we do manage to get the tasks laid out properly, is that there is no way for the Layout case to know when the Design case has been completed other than for the person closing the Design case to leave a comment or change the status (from a custom status of Awaiting Dependencies to Active).

We've also considered using milestones, but that seems to be an even worse fit because there are a large number of small "chains" that happen all the time, and about the only way to do it that we can see would be to have a Graphics, Layout, and Programming milestone.

So, what do you, the FogBugz community, think is the best way to handle a chain-style workflow?

How do we setup FogBugz for very large projects?

2010-12-29T23:07:51Z

Hi, I have tried to get some answers from the forum, but I was not able to get a proper answer.

We are currently evaluating FogBugz to see if it can replace a fairly decent home grown Issue Tracking System (mostly to allow us to focus resources on our core business). We are also interested in trying to use FogBugz for an Agile methodology. Some stats: - Over 300 engineers in three sites - All building the same multi-million line product (hundreds of modules) - Two main releases a year, plus a few service packs per release - I don't know how big MS Office is, but thinking of developing MS Office will be a good example In our existing issue tracker, we don't have the concept of a Product (as everything is the same Product), but we have the concept of a TryToFixBy which is basically a given release. We also use "Module" to help us characterized the different Issues (similar to Areas in FogBugz, I think).

Ideally, I would simply have "Projects" representing the released Products, and use "Areas" to represent either the modules or likely a higher level abstraction (e.g. Word Vs. Excel). I would then create about four to six Projects a year, and then some 30 to 40 Areas per Project.

Problem is that all the scheduling features don't seem to then allow me to have smaller sub-teams use FogBugz to track their Agile tasks. With the setup described above, I would only be able to generate reports on the very large project, which is good from the top management side, but will not be able to have smaller sub-teams to also use it to manage their Agile tasks. If I could only generate scheduling reports on a Parent Issue, that could work, but I don't see a way to do that.

Are there any best practices in how to use FogBugz and its project management capability within very large organizations working on a single product? Should we accept that we will only be able to use FogBugz for simple Issue Tracking (which after all, is what we are most interested)?

Thanks

Customer Support with multiple products?

2010-08-31T22:04:43Z

Background: I'm new to FogBugz. I'm using one support email address and have three products to support. There will be 1 or 2 people providing support. In general, most of the support questions are related to product usage and registration issues rather than bug reporting. I'm expecting to start with using the InBox project only. Eventually, I expect to add a project for each product. Is this an okay initial approach?

Question: What are my options for marking a case for being related to a specific product? I'd like to have the ability to use a saved filter or something like that to list all cases for a specific product. Would a Custom Field be a good solution? Could it allow two products to be associated with one case? Would using a tag with the product name be recommended (that seems strange for some reason)? Any other approaches?

I also need to decide what Areas to create and learn about using a virtual user. The "Projects and Areas" help page recommends to start by using one area called Miscellaneous. It that in addition to the Spam, Not Spam and Undecided Areas?

thanks, Chuck

In terms of proper use of EBS: How should we handle cases between the developers and the QA team?

2010-11-24T15:09:54Z

Again, the goal is to properly use EBS so we want to have an accurate representation of how well someone estimated. How can we make sure we have a good read of peoples' estimates?

For example:

If someone factors in time to their estimate for fixing bugs they may make the estimate 12 hours. If, however, they manage to code it near perfectly and there are very few bugs and it only takes them 8 hours, then their estimate looks like it was bad. However if there were many bugs and it hits exactly 12 hours, then their estimate is good. Obviously we don't want someones estimation skills being bad because they wrote perfect code!

Another scenario that we want to avoid:

If we make a new case for every bug, then someone could force perfect estimations (though we aren't going to assume foul play). They estimate 5 hours for a feature, work 5 hours and send it to the QA guy. He opens a new case for a bug, the programmer estimates 2 hours to fix the bug, works two hours, and submits it... etc etc, this is obviously not the way to do it.

So, is there some recommendation for how to properly use EBS with QA?

Another important consideration:

Should I factor in the time for my QA guy to work on a case when I make my estimate? Then we would have two people working on one case, going against MY estimation history, right?

Best Practices for managing a long schedule

2010-11-05T20:09:20Z

I'm trying to get an understanding of how the EBS works for a project with a longer time frame, say roughly a year or more.

In this question, and elsewhere, it is stated that developers should estimate their own time, and that tasks should be broken down to the level of "write this function", estimated in hours, not days. This makes sense when you're about to start working those tasks immediately.

However, say you have several large features you want to get done over the course of your year. Nobody uses the waterfall model of development; your developers are not going to break down an entire year's worth of work into which individual functions to write before getting started on any work. So what is the best-practice for entering and maintaining your schedule in FogBugz when you don't (yet) have that level of granularity? I'd like to get a feel for the process of planning and revising that you would use as the project first starts and as it progresses.

How to get a reluctant team to use FogBugz?

2010-03-19T11:22:39Z

This isn't a specific support request, so much as just a general request for advice or blog posts or knowledge base threads you might suggest I read.

I work on a team of web application developers and we've been using FogBugz for I think about four years. And yet, we've only begun to scratch the surface of all that FogBugz can do. We don't take advantage of EBS, we don't click the "working on" links, we don't use discussion threads or wiki's for anything outside of documentation some of our own team's assets. We don't use RSS threads. We don't integrate with our Subversion repository. We don't encourage customers to use the screenshot tool. We don't organize our projects into phases or milestones. All of our developers have administrator rights, so projects often overlap, with no consistency in categories, status, etc. Probably 80-90% of our currently open cases have just been forgotten about.

We really don't do much more than just accept cases emailed to our popmail account and close the case, without really associating the case in any way with a bigger picture, timeline or agenda.

I've tried hard to educate the team on all that FogBugz can do and I do happen to use EBS reporting and many of FB's more advance features, but usually only for an audience of myself. Management is always asking for pretty much exactly what EBS gives you. But there's nothing to look at because my colleagues aren't populating it with data by being disciplined about making estimates, writing good cases, and clicking on "working on"...

The excuses range from "I don't need Big Brother watching me all the time" to "that's not the way we work around here"... Just wondering whether anyone can suggest something I might get my colleagues to read, a webinar to watch, maybe on-site consultation services from Fog Creek... I know my problem is really just cultural. But I was hoping others could share insights on getting a reluctant team to organize their workflow around this fantastic tool.

PS I realise the http://fogbugz.stackexchange.com/faq advises "Avoid asking questions that ... require extended discussion. This is not a discussion board, this is a place for questions that can be answered!" But I don't know where that place is...

Does project milestones report take into account other projects work?

2009-12-26T15:08:02Z

Hi there.

Just started to use fogbugz in our organization.

Our dev team (5 programmers, flash dev, designer, html coder) works on many different projects simultaneously (in order of priority).

Currently, i've created one global milestone named "In development" (ala current sprint in SCRUM).

What i'd like to do, is to create per-project milestones to use EBS for realistic per project due dates.

But it seems to me (after doing some tests) that when i look at per-project report the EBS assumes that people will only do tasks of selected projects, even if they are assigned higher priority tasks in otherprojects.

Am i right? How this is supposed to work (how can i predict per project due dates for a team working on many projects in order of global priority)?

A later edit:

Okay, i've conducted more tests and i believe i found a bug in EBS. I've reproduced the situation at itcd2.fogbugz.com (eval. version).

Let's take an edge case. 1 user set up, 2 projects (project 1 and project 2). Each project has one per project milestone. Plus one global milestone.

Two cases assigned to one user. A 100 hour case in project 1, per project milestone with priority 2. And a 1 hour case in project 2, per project milestone with priority 5. It seems reasonable in that case, that EBS should tell that project 2 milestone ship date should come after project 1. But EBS tells us the opposite, ignoring the priorities.

But here is the magic: if i change per project milestone of 100 hour task to a global milestone, EBS starts to produce correct results.

Even more, now if i change the 100 hour task priority to 7 (telling it should be done AFTER 1 hour task) the EBS behaviour does not change.

It seems like when calculating case order EBS always sorts by milestones (even when they don't have any dependencies / startdates / enddates assuming they are all of same priority) and only after milestones goes priority sort (like "order by milestone, priority"). And as side effect of such ordering global milestones work always preceding per project milestones.

I guess there is a need for "milestone priority" editable column? Or smth like that?

Priority vs Due Date

2010-10-06T19:17:33Z

I am still new to fogbugz and would like to know what others have found works best. We are using fogbugz for tracking helpdesk issues, programming tasks and network/infrastructure type tasks.

Up to now we have been using Priority as the main way to indicate what needs to be worked on. The problem is that we are constantly adding Priority 1 assignments and then moving moving what were Priority 1 things down to Priority 2 and then Priority 2 stuff down to 3 or up to 1. This is too much work so I am looking for a more practical approach.

I am thinking that using due dates might work better. Anyones thoughts or experiences are welcome.

Thanks Very Much for any insights,

Eddie

What are the best practices for structuring Projects, Areas, Categories and Tags

2009-12-11T02:16:07Z

I would like to find documentation on the best practices for using Projects and Areas in FogBugz. I notice a few questions around about this but maybe a tutorial that explains how the Fog Creek team envisioned FogBugz to be used and what are some examples of how a software development effort could be divided up into Projects, Areas, Categories and the use of Tags etc.

We have been using FogBugz for about a year now and it has proven to be an invaluable tool. We are planning to re-organize projects a bit next month and I thought that this is an appropriate time to ensure that we are actually getting th emost out of this tool.

Best practice for sending new (non-reply) emails

2010-09-02T19:54:36Z

I'm trying to determine the best practice for composing new (outgoing) emails from FB. I get why it's important to keep incoming messages in a single project, but does the same apply for new (non-reply) messages?

By "new" messages, I mean non-replies. We're a web dev shop. We use FB for support: maintenance and change requests on existing sites, but also for project management for new projects under development. More background: Our clients do not have access to FB. We have standing projects for each client. Five staff members working across all clients/projects. We're using the On Demand version, 8.0 beta.

Oftentimes we'll need to query the client about a task. I've done this in two ways:

By hitting the "Email" link at the top of the specific case being worked on. I like this method because it's easy and clean. It keeps everything in one nice package. This goes against the best practice of using an "inbox" project because client replies can get lost in the shuffle and it doesn't help train the spam filter. (I was thinking of creating a saved filter so that my 'inbox' link is a combination of the inbox project and open correspondences.)
By hitting the "Send Email" link in the main navigation and setting the project to my "inbox" project. I then set the Parent Case to the specific case I needed the input on. This way is less desirable. It feels like Case Spaghetti. It also requires that I remember to enter the Parent Case, which I tend to forget.

What are you doing?

Do developers need to estimate their own time?

2010-09-20T22:57:34Z

Does ESB care who estimated a task? Joel writes that developers should estimate their own cases, which I agree with, but I'm wondering whether ESB enforces that, and will ignore any cases not estimated by the same developer who works on it.

How should I manage sharing work in one case amongst multiple users?

2010-09-08T00:10:39Z

when looking at a series of bug assignments/reassignments found here : http://www.fogcreek.com/FogBugz/docs/70/topics/basics/Thebasicsofbugtracking.html

the first person that sets the time estimate gets the time 'billed' to them when work starts [right?], but when cases get passed around and reassigned to various groups [dev, test, etc], should time estimates or 'working on' even be used?

note: the image at the url above doesn't have any time estimates.