show/hide this revision's text 3 how not to include

Where possible, don't use buffers

If you are working in an environment where your milestone's EBS schedule isn't displacing any others, my preferred method is to not use any schedule items. The clock starts ticking when the specification is done and the cases are estimated. Then if you're talking about adding a feature, you just add it, estimate it, look at the graph and say "Okay, if we add this feature, it slips our completion distribution by about this much. Do you want it that badly, or not?"

% working time is a good way to get around the need for a "Meetings" buffer, and charging bug fix time against the original feature (or creating a little "BugFix" subcase against the original case) is a good way to get around the need for a BugFix buffer.

When you do need buffers, make the likely primary source of the delay estimate them

Make the guy who is most likely to be the source of added features create and estimate the Schedule Item for the buffer for those features, whenever possible. Then when you are creating a feature that takes its estimate from that buffer, you have a choice: either charge time against the buffer Schedule Item or subtract the new feature's estimate from the estimate of the schedule item. Both approaches have problems; if you subtract the estimate time from the buffer, then EBS doesn't get better for the buffer estimator. If you charge time against the buffer, then it doesn't get better for the person doing the work.

How to keep schedule items from affecting a user's estimation history

You can resolve cases with a status that is not included in EBS (see the setting in Workflow. See this post about being able to exclude certain categories from affecting history.
show/hide this revision's text 2 Spacing

Where possible, don't use buffers

If you are working in an environment where your milestone's EBS schedule isn't displacing any others, my preferred method is to not use any schedule items. The clock starts ticking when the specification is done and the cases are estimated. Then if you're talking about adding a feature, you just add it, estimate it, look at the graph and say "Okay, if we add this feature, it slips our completion distribution by about this much. Do you want it that badly, or not?"

% working time is a good way to get around the need for a "Meetings" buffer, and charging bug fix time against the original feature (or creating a little "BugFix" subcase against the original case) is a good way to get around the need for a BugFix buffer.

When you do need buffers, make the likely primary source of the delay estimate them

Make the guy who is most likely to be the source of added features create and estimate the Schedule Item for the buffer for those features, whenever possible. Then when you are creating a feature that takes its estimate from that buffer, you have a choice: either charge time against the buffer Schedule Item or subtract the new feature's estimate from the estimate of the schedule item. Both approaches have problems; if you subtract the estimate time from the buffer, then EBS doesn't get better for the buffer estimator. If you charge time against the buffer, then it doesn't get better for the person doing the work.
show/hide this revision's text 1

Where possible, don't use buffers

If you are working in an environment where your milestone's EBS schedule isn't displacing any others, my preferred method is to not use any schedule items. The clock starts ticking when the specification is done and the cases are estimated. Then if you're talking about adding a feature, you just add it, estimate it, look at the graph and say "Okay, if we add this feature, it slips our completion distribution by about this much. Do you want it that badly, or not?"

% working time is a good way to get around the need for a "Meetings" buffer, and charging bug fix time against the original feature (or creating a little "BugFix" subcase against the original case) is a good way to get around the need for a BugFix buffer.

When you do need buffers, make the likely primary source of the delay estimate them Make the guy who is most likely to be the source of added features create and estimate the Schedule Item for the buffer for those features, whenever possible. Then when you are creating a feature that takes its estimate from that buffer, you have a choice: either charge time against the buffer Schedule Item or subtract the new feature's estimate from the estimate of the schedule item. Both approaches have problems; if you subtract the estimate time from the buffer, then EBS doesn't get better for the buffer estimator. If you charge time against the buffer, then it doesn't get better for the person doing the work.