show/hide this revision's text 2 added 1 characters in body

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 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 ands 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?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 thier 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?
show/hide this revision's text 1

Effect on EBS of changing Assigned-To and Current Estimate

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 ands 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 thier 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?