Question

Hi, all of our cases move between departments (Product Support -> Development -> QA) as they are worked on. We would like to start relying on the Per User timeline reports for projects and the Evidence Based Scheduling that it and other reports are based on. I'll frame my question in the context of this scenario:

• a customer sends an email to bugs@ourCompany.com and an Inquiry Case is created. The Product Support group picks it up and enters an initial estimate for the Case (it will take me half an hour to process this Case). The Support person uses FogBugz to indicate that he is Working On that case
• within half an hour he has duplicated the issue in the Inquiry. He changes the Case to a Bug and assigns it to a developer.
• the developer adds half a day to the Current Estimate and starts Working On it. When he is done he changes it to Resolved (Fixed) and assigns it to QA

• QA sees there are a lot of border conditions to test and bumps the Current Estimate by another half day, but the status of the Case does not change from Resolved (Fixed)

  My general question is "how does the change in Assigned-To and Current Estimate affect the statistics for each persons ability to estimate?"

  In order to use FogBugz to tell us when a given milestone will be delivered, every Case's Current Estimate has to include time for all phases - but those estimates aren't available at the beginning of a Case's life, in fact the Current Estimate for any case won't be complete until it gets into the hands of the last person doing work on it... which is too late for planning purposes. Anybody have any recommendations? Does anybody:

• create new subcases for every phase of every issue? (seems pretty onerous)
• get Developers to pad their estimates with some time for QA? (seems inaccurate)

• keep QA time out of estimates and let the EBS algorithms adapt to the fact that even perfect Developer estimates will be short, due to extra time added to the Case by QA?

  Lastly - we are thinking of tracking statuses by creating Active (fixing) and Active (testing) or perhaps Resolved (fixed) and Resolved (tested) (for Bugs... plus other for Features). How will the new statuses be used in the EBS algorithms?

Answer 1

If I'm following correctly, I think the following would work for you.

Have the original case (C1) assigned to a virtual user. You can put an estimate in there if you want.

The support person should create a child case (C2) to C1 to track their work. You can even create a specific category to show that the case is for this activity. This case should have estimate and elapsed time entered by the support person. (This activity is a task separate from the development and testing work. Tracking it separately allows for EBS to learn how to forecast for the support person)

Once the support person duplicates the issue he should resolve C2, create a new child case (C3) to C1 as a bug and assign it to the developer. The developer should enter the estimate and elapsed time. Once the work is complete, the developer should resolve C3 and open a new child case (C4) to C1 and assign to the tester. (Reasoning is the same as above)

The test would follow the same pattern outlined until now. Once everyone is done with their work, someone could close the parent case and force closure of all of the other cases - possibly after some kind of verification.

If you want to do EBS on an individual basis, you have to create a case for each person.

Answer 2

A separate approach would be to make sure the same user always enters the estimate. If you pass it from person to person, it will still use the estimate history of the original person. The EBS for that person will actually be based on how the team does as a group over time. This is probably the easiest way to get what you're looking for but it hinges on the same people working together very often.

Answer 3

For what I now to use EBS you have to create a new case for every person because EBS only works if the user that creates de estimate is the one that is adding the time info.

Answer 4

This is becoming a fairly wordy entry!! As I researched EBS I think my original question morphed into "can a single Case be used to track comments and time for different roles working on an issue". The unstated root of our problem is that we really like tracking all progress (emails, replys, comments, etc) in one place. Thanks to Marc and Spooky for their ideas.

The final answer is if you use EBS rigorously, you have to have a separate case for every role working on an issue. The Case/Sub-case feature will help you group related cases, but there is no way to combine estimates and comments and track time for ProductSupport, Development and QA in a single Case.

If you want to make compromises in your process to reduce your Case count and re-assign cases between roles, you have to interpret the end-date probabilities EBS gives you accordingly. Keep in mind these three facts about EBS (which initially caused me some confusion so I'm including them here):

1 - In the workflow plugin, some Resolution Statuses are identified as "Used for calculating estimate history in EBS". This really means "Cases with this resolution qualify as "EBS-worthy". Only EBS-worthy cases are used to calculate "velocity" as described below".

2- The "velocity" of a feature is the estimate (original or current) that was active at the time the first person started working on a Case divided by the value of Elapsed at the time the case is CLOSED.

3- Although the estimator's history is key to the simulation of future completion dates, the other key ingredients are the assignee, how much work is left to do, and how much the assignee is working on the case. So, EBS still works even though a case gets reassigned during its life, as long as the estimator anticipated the work the new assignee does.