Last edit
Summary: Some of the best tips from the excellent book /Software Estimation: Demystifying the Black Art/ by Steve McConnel . . .
Changed:
< Some of the best tips from the excellent book /Software Estimation: Demystifying the Black Art/ by {{{Steve McConnel}}} ([[http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351|amazon]]):
to
> Some of the best tips from the excellent book //Software Estimation: Demystifying the Black Art// by {{{Steve McConnel}}} ([[http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351|amazon]]):
Some of the best tips from the excellent book Software Estimation: Demystifying the Black Art by Steve McConnel (amazon):
- Tip #1 Distinguish between estimates, targets, and commitments.
- Tip #2 When you're asked to provide an estimate, determine whether you're supposed to be estimating or figureing out how to hit a target.
- Tip #3 When you se a single-point "estimate", ask whether the number is an estimate or whether is's really a target.
- Tip #4 When you see a single-point estimate, that number's probability is not 100%. Ask what the probability of that number is.
- Tip #5 Don't provide "percentage confident" estimates (especially "90% confident") unless you have a quantitatively derived basis for doing so.
- Tip #30 Count if at all possible. Compute when you can't count. Use judgement alone only as a last resort.
- Tip #31 Look for something you can count that is a meaningful measure of the scope of work in your environment.
- Tip #32 Collect historical data that allows you to compute an estimate from a count.
- Tip #33 Don't discount the power of simple, coarse estimation modelse such as average effort per defect/web page/story/use case.
- Tip #34 Avoid using expert judgment to tweak an estimate that has been derived through computation. Such "expert judgment" usually degrades the estimate's accuracy.