show/hide this revision's text 4 anal retentive editing

EBS (Evidence Based Scheduling) is concerned with two important case states.

  1. Not worked on. (Time has not been logged)
  2. Worked on. (Time has been logged)


Not worked onWorked On
Changing the estimate when time has not been logged simply changes the estimate and is reflected in the EBS projected 50% date. To the extent updated estimates more closely match actual time worked the standard deviation of future EBS projections will decrease.


Worked onOn
When a case is worked on, even if only 1 minute is tracked, FogBugz locks the Current Estimate in a field called Original Estimate. Changing the current estimate after work has begun immediately impacts the EBS projected 50% date. However, the Original Estimate is locked in. To the extent updated estimates more closely match actual time worked the standard deviation of future EBS projections will increase.


Both scenarios are good as they give accurate insight into project completion in real time and increase the accuracy of EBS projections by using realistic velocities (Original Estimate / Actual Elapsed Time) in future modeling scenarios.

For me, knowing FogBugz locks estimates after logging time is an important insight. When implementing an agile development process where estimation is done up front and estimation accuracy needs to be reflected in future projections; FogBugz gets it right. Where EBS adds tremendous value is in providing real-time insight into the expected end date of the current sprint/milestone/project.

From FogBugz help Entering Estimates in FogBugz

You can change estimates as many times as you want, as you learn more about the work required for a task. However, as soon as you start working on a case (using time-sheets or the working on menu) FogBugz takes a snapshot of the current estimate and stores it permanently as the original estimate.

From FogBugz help How To Estimate Software Tasks

For each completed feature, EBS looks at the original estimate entered and the actual time elapsed. It divides estimate by elapsed to get the velocity of that feature's implementation.
show/hide this revision's text 3 Removed directional example and tightened up the answer.

For simplification I'll assume the change is to the estimate is an increase.

EBS (Evidence Based Scheduling) is concerned with two important case states.

  • Not worked on. (time Time has not been logged)
    • Changing the estimate when time has not been logged simply increases changes the estimate and increases the time to completion of the project. This is reflected in the Project ReportsEBS projected 50% date. To the extent increased updated estimates more closely match actual time worked, you'll want to increase your estimate before working on a case to decrease the standard deviation of future EBS projections will decrease.

    When a case is worked on, even if only 1 minute is tracked, FogBugz logs locks the Current Estimate in a field called Original Estimate. Changing the current estimate after work has begun immediately impacts the Project Reports the same as changing EBS projected 50% date. However, the estimate before work has begun (which Original Estimate is good for getting an accurate time to completion estimate)locked in. To the extent increased updated estimates more closely match actual time worked, you'll want to increase your estimate after work begins on a case to increase the standard deviation of future EBS projections will increase.

    Both of these     scenarios are a good thing as they give accurate insight into project completion in real time and increase the future accuracy of EBS projections by using realistic velocities (Original Estimate / Actual Elapsed Time) in future modeling scenarios.
    For me, knowing FogBugz locks estimates after logging time is an important insight. When implementing an agile development process where estimation is done up front and estimation accuracy needs to be reflected in future projections; FogBugz gets it right. Where EBS adds tremendous value is in providing real-time insight into the expected end date of the current sprint/milestone/project.

    (using timesheets time-sheets or the working on
    show/hide this revision's text 2 deleted 14 characters in body

    For simplification I'll assume the change is to the estimate is an increasevs a decrease.

    EBS (Evidence Based Scheduling) is concerned with two important case states.

    1. Not worked on. (time has not been logged)
    2. Worked on. (Time has been logged)


    Not worked on
    Changing the estimate when time has not been logged simply increases the estimate and increases the time to completion of the project. This is reflected in the Project Reports. To the extent increased estimates match time worked, you'll want to increase your estimate before working on a case to decrease the standard deviation of future EBS projections.


    Worked on
    When a case is worked on, even if only 1 minute is tracked, FogBugz logs the Current Estimate in a field called Original Estimate. Changing the estimate after work has begun impacts the Project Reports the same as changing the estimate before work has begun (which is good for getting an accurate time to completion estimate). To the extent increased estimates match time worked, you'll want to increase your estimate after work begins on a case to increase the standard deviation of future EBS projections.


    Both of these scenarios are a good thing as they increase the future accuracy of EBS projections.

    From FogBugz help Entering Estimates in FogBugz

    You can change estimates as many times as you want, as you learn more about the work required for a task. However, as soon as you start working on a case (using timesheets or the working on menu) FogBugz takes a snapshot of the current estimate and stores it permanently as the original estimate.

    From FogBugz help How To Estimate Software Tasks

    For each completed feature, EBS looks at the original estimate entered and the actual time elapsed. It divides estimate by elapsed to get the velocity of that feature's implementation.
    show/hide this revision's text 1