Software estimation tips

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 figuring out how to hit a target.
Tip #3   When you see a single-point “estimate,” ask whether the number is an estimate or whether it’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.
Chapter    2
Tip #5   Don’t provide “percentage confident” estimates (especially “90% confident”) unless you have a
quantitatively derived basis for doing so.
Tip #6   Avoid using artificially narrow ranges. Be sure the ranges you use in your estimates don’t
misrepresent your confidence in your estimates.
Tip #7   If you are feeling pressure to make your ranges narrower, verify that the pressure actually is
coming from an external source and not from yourself.
Chapter    3
Tip #8   Don’t intentionally underestimate. The penalty for underestimation is more severe than the
penalty for overestimation. Address concerns about overestimation through planning and control,
not by biasing your estimates.
Tip #9   Recognize a mismatch between a project’s business target and a project’s estimate for what it is:
valuable risk information that the project might not be successful. Take corrective action early,
when it can do some good.
Tip #10   Many businesses value predictability more than development time, cost, or flexibility. Be sure
you understand what your business values the most.
Chapter    4
Tip #11   Consider the effect of the Cone of Uncertainty on the accuracy of your estimate. Your estimate
cannot have more accuracy than is possible at your project’s current position within the Cone.
Tip #12   Don’t assume that the Cone of Uncertainty will narrow itself. You must force the Cone to narrow
by removing sources of variability from your project.
Tip #13   Account for the Cone of Uncertainty by using predefined uncertainty ranges in your estimates.
Tip #14   Account for the Cone of Uncertainty by having one person create the “how much” part of the
estimate and a different person create the “how uncertain” part of the estimate.
Tip #15   Don’t expect better estimation practices alone to provide more accurate estimates for chaotic
projects. You can’t accurately estimate an out-of-control process.
Tip #16   To deal with unstable requirements, consider project control strategies instead of or in addition
to estimation strategies.
Tip #17   Include time in your estimates for stated requirements, implied requirements, and nonfunctional
requirements—that is, all requirements. Nothing can be built for free, and your estimates
shouldn’t imply that it can.
Tip #18   Include all necessary software-development activities in your estimates, not just coding and
testing.
Tip #19   On projects that last longer than a few weeks, include allowances for overhead activities such
as vacations, sick days, training days, and company meetings.
Tip #20   Don’t reduce developer estimates—they’re probably too optimistic already.
Tip #21   Avoid having “control knobs” on your estimates. While control knobs might give you a feeling of
better accuracy, they usually introduce subjectivity and degrade actual accuracy.
Tip #22   Don’t give off-the-cuff estimates. Even a 15-minute estimate will be more accurate.
Tip #23   Match the number of significant digits in your estimate (its precision) to your estimate’s
accuracy.
Chapter    5
Tip #24   Invest an appropriate amount of effort assessing the size of the software that will be built. The
size of the software is the single most significant contributor to project effort and schedule.
Tip #25   Don’t assume that effort scales up linearly as project size does. Effort scales up exponentially.
Tip #26   Use software estimation tools to compute the impact of diseconomies of scale.
Tip #27   If you’ve completed previous projects that are about the same size as the project you’re
estimating—defined as being within a factor of 3 from largest to smallest—you can safely use a
ratio-based estimating approach, such as lines of code per staff month, to estimate your new
project.
Tip #28   Factor the kind of software you develop into your estimate. The kind of software you’re
developing is the second-most significant contributor to project effort and schedule.
Chapter    6
Tip #29   When choosing estimation techniques, consider what you want to estimate, the size of the
project, the development stage, the project’s development style, and what accuracy you need.
Chapter    7
Tip #30   Count if at all possible. Compute when you can’t count. Use judgment 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 models such as average effort per defect,
average effort per Web page, average effort per story, and average effort per 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.
Chapter    8
Tip #35   Use historical data as the basis for your productivity assumptions. Unlike mutual fund
disclosures, your organization’s past performance really is your best indicator of future
performance.
Tip #36   Use historical data to help avoid politically charged estimation discussions arising from
assumptions like “My team is below average.”
Tip #37   In collecting historical data to use for estimation, start small, be sure you understand what you’re
collecting, and collect the data consistently.
Tip #38   Collect a project’s historical data as soon as possible after the end of the project.
Tip #39   As a project is underway, collect historical data on a periodic basis so that you can build a data-
based profile of how your projects run.
Tip #40   Use data from your current project (project data) to create highly accurate estimates for the
remainder of the project.
Tip #41   Use project data or historical data rather than industry-average data to calibrate your estimates
whenever possible. In addition to making your estimates more accurate, historical data will
reduce variability in your estimate arising from uncertainty in the productivity assumptions.
Tip #42   If you don’t currently have historical data, begin collecting it as soon as possible.
Chapter    9
Tip #43   To create the task-level estimates, have the people who will actually do the work create the
estimates.
Tip #44   Create both Best Case and Worst Case estimates to stimulate thinking about the full range of
possible outcomes.
Tip #45   Use an estimation checklist to improve your individual estimates. Develop and maintain your
own personal checklist to improve your estimation accuracy.
Tip #46   Compare actual performance to estimated performance so that you can improve your individual
estimates over time.
Chapter    10
Tip #47   Decompose large estimates into small pieces so that you can take advantage of the Law of
Large Numbers: the errors on the high side and the errors on the low side cancel each other out
to some degree.
Tip #48   Use a generic software-project work breakdown structure (WBS) to avoid omitting common
activities.
Tip #49   Use the simple standard deviation formula to compute meaningful aggregate Best Case and
Worst Case estimates for estimates containing 10 tasks or fewer.
Tip #50   Use the complex standard deviation formula to compute meaningful aggregate Best Case and
Worst Case estimates when you have about 10 tasks or more.
Tip #51   Don’t divide the range from best case to worst case by 6 to obtain standard deviations for
individual task estimates. Choose a divisor based on the accuracy of your estimation ranges.
Tip #52   Focus on making your Expected Case estimates accurate. If the individual estimates are
accurate, aggregation will not create problems. If the individual estimates are not accurate,
aggregation will be problematic until you find a way to make them accurate.
Chapter    11
Tip #53   Estimate new projects by comparing them to similar past projects, preferably decomposing the
estimate into at least five pieces.
Tip #54   Do not address estimation uncertainty by biasing the estimate. Address uncertainty by
expressing the estimate in uncertain terms.
Chapter    12
Tip #55   Use fuzzy logic to estimate program size in lines of code.
Tip #56   Consider using standard components as a low-effort technique to estimate size in a project’s
early stages.
Tip #57   Use story points to obtain an early estimate of an iterative project’s effort and schedule that is
based on data from the same project.
Tip #58   Exercise caution when calculating estimates that use numeric ratings scales. Be sure that the
numeric categories in the scale actually work like numbers, not like verbal categories such as
small, medium, and large.
Tip #59   Use t-shirt sizing to help nontechnical stakeholders rule features in or out while the project is in
the wide part of the Cone of Uncertainty.
Tip #60   Use proxy-based techniques to estimate test cases, defects, pages of user documentation, and
other quantities that are difficult to estimate directly.
Tip #61   Count whatever is easiest to count and provides the most accuracy in your environment, collect
calibration data on that, and then use that data to create estimates that are well-suited to your
environment.
Chapter    13
Tip #62   Use group reviews to improve estimation accuracy.
Tip #63   Use Wideband Delphi for early-in-the-project estimates, for unfamiliar systems, and when
several diverse disciplines will be involved in the project itself.
Chapter    14
Tip #64   Use an estimation software tool to sanity-check estimates created by manual methods. Larger
projects should rely more heavily on commercial estimation software.
Tip #65   Don’t treat the output of a software estimation tool as divine revelation. Sanity-check estimation
tool outputs just as you would other estimates.
Chapter    15
Tip #66   Use multiple estimation techniques, and look for convergence or spread among the results.
Tip #67   If different estimation techniques produce different results, try to find the factors that are making
the results different. Continue reestimating until the different techniques produce results that
converge to within about 5%.
Tip #68   If multiple estimates agree and the business target disagrees, trust the estimates.
Chapter    16
Tip #69   Don’t debate the output of an estimate. Take the output as a given. Change the output only by
changing the inputs and recomputing.
Tip #70   Focus on estimating size first. Then compute effort, schedule, cost, and features from the size
estimate.
Tip #71   Reestimate.
Tip #72   Change from less accurate to more accurate estimation approaches as you work your way
through a project.
Tip #73   When you are ready to hand out specific development task assignments, switch to bottom-up
estimation.
Tip #74   When you reestimate in response to a missed deadline, base the new estimate on the project’s
actual progress, not on the project’s planned progress.
Tip #75   Present your estimates in a way that allows you to tighten up your estimates as you move
further into the project.
Tip #76   Communicate your plan to reestimate to other project stakeholders in advance.
Chapter    17
Tip #77   Develop a Standardized Estimation Procedure at the organizational level; use it at the project
level.
Tip #78   Coordinate your Standardized Estimation Procedure with your SDLC.
Tip #79   Review your projects’ estimates and estimation process so that you can improve the accuracy of
your estimates and minimize the effort required to create them.
Chapter    18
Tip #80   Use lines of code to estimate size, but remember both the general limitations of simple
measures and the specific hazards of the LOC  measure in.
Tip #81   Count function points to obtain an accurate early-in-the-project size estimate.
Tip #82   Use the Dutch Method of counting function points to attain a low-cost ballpark estimate early in
the project.
Tip #83   Use GUI elements to obtain a low-effort ballpark estimate in the wide part of the Cone of
Uncertainty.
Tip #84   With better estimation methods, the size estimate becomes the foundation of all other
estimates. The size of the system you’re building is the single largest cost driver. Use multiple
size-estimation techniques to make your size estimate accurate.
Chapter    19
Tip #85   Use software tools based on the science of estimation to most accurately compute effort
estimates from your size estimates.
Tip #86   Use industry-average effort graphs to obtain rough effort estimates in the wide part of the Cone
of Uncertainty. For larger projects, remember that more powerful estimation techniques are
easily cost-justified.
Tip #87   Use the ISBSG method to compute a rough effort estimate. Combine it with other methods, and
look for convergence or spread among the different estimates.
Tip #88   Not all estimation methods are equal. When  looking for convergence or spread among
estimates, give more weight to the techniques that tend to produce the most accurate results.
Chapter    20
Tip #89   Use the Basic Schedule Equation to estimate schedule early in medium-to-large projects.
Tip #90   Use the Informal Comparison to Past Projects formula to estimate schedule early in a small-to-
large project.
Tip #91   Use Jones’s First-Order Estimation Practice to produce a low-accuracy (but very low-effort)
schedule estimate early in a project.
Tip #92   Do not shorten a schedule estimate without increasing the effort estimate.
Tip #93   Do not shorten a nominal schedule more than 25%. In other words, keep your estimates out of
the Impossible Zone.
Tip #94   Reduce costs by lengthening the schedule and conducting the project with a smaller team.
Tip #95   For medium-sized business-systems projects (35,000 to 100,000 lines of code) avoid increasing
the team size beyond 7 people.
Tip #96   Use schedule estimation to ensure your plans are plausible. Use detailed planning to produce
the final schedule.
Tip #97   Remove the results of overly generic estimation techniques from your data set before you look
for convergence or spread among your estimates.
Chapter    21
Tip #98   When allocating project effort across different activities, consider project size, project type, and
the kinds of effort contained in the calibration data used to create your initial rolled-up estimate.
Tip #99   Consider your project’s size, type, and development approach in allocating schedule to different
activities.
Tip #100   Use industry-average data or your historical data to estimate the number of defects your
project will produce.
Tip #101   Use defect-removal-rate data to estimate the number of defects that your quality assurance
practices will remove from your software before it is released.
Tip #102   Use your project’s total Risk Exposure (RE) as the starting point for buffer planning. Review
the details of your project’s specific risks to understand whether you should ultimately plan for
a buffer that’s larger or smaller than the total RE.
Tip #103   Planning and estimation are related, and planning is a much bigger topic than can be
addressed in one chapter in a book that focuses on software estimation. Read the literature on
planning.
Chapter    22
Tip #104   Document and communicate the assumptions embedded in your estimate.
Tip #105   Be sure you understand whether you’re presenting uncertainty in an estimate or uncertainty
that affects your ability to meet a commitment.
Tip #106   Don’t present project outcomes to other project stakeholders that are only remotely possible.
Tip #107   Consider graphic presentation of your estimate as an alternative to text presentation.
Tip #108   Use an estimate presentation style that reinforces the message you want to communicate
about your estimate’s accuracy.
Tip #109   Don’t try to express a commitment as a range. A commitment needs to be specific.
Chapter    23
Tip #110   Understand that executives are assertive by nature and by job description, and plan your
estimation discussions accordingly.
Tip #111   Be aware of external influences on the target. Communicate that you understand the business
requirements and their importance.
Tip #112   You can negotiate the commitment, but don’t negotiate the estimate.
Tip #113   Educate nontechnical stakeholders about effective software estimation practices.
Tip #114   Treat estimation discussions as problem solving, not negotiation. Recognize that all project
stakeholders are on the same side of the table. Everyone wins, or everyone loses.
Tip #115   Attack the problem, not the people.
Tip #116   Generate as many planning options as you can to support your organization’s goals.
Tip #117   As you foster an atmosphere of collaborative problem solving, don’t make any commitments
based on off-the-cuff estimates.
Tip #118   Resolve discussion deadlocks by returning to the question of, “What will be best for our
organization?”

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 figuring out how to hit a target.

Tip #3   When you see a single-point “estimate,” ask whether the number is an estimate or whether it’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 #6   Avoid using artificially narrow ranges. Be sure the ranges you use in your estimates don’t  misrepresent your confidence in your estimates.

Tip #7   If you are feeling pressure to make your ranges narrower, verify that the pressure actually is coming from an external source and not from yourself.

Tip #8   Don’t intentionally underestimate. The penalty for underestimation is more severe than the  penalty for overestimation. Address concerns about overestimation through planning and control, not by biasing your estimates.

Tip #9   Recognize a mismatch between a project’s business target and a project’s estimate for what it is:  valuable risk information that the project might not be successful. Take corrective action early,  when it can do some good.

Tip #10   Many businesses value predictability more than development time, cost, or flexibility. Be sure  you understand what your business values the most.

Tip #11   Consider the effect of the Cone of Uncertainty on the accuracy of your estimate. Your estimate cannot have more accuracy than is possible at your project’s current position within the Cone.

Tip #12   Don’t assume that the Cone of Uncertainty will narrow itself. You must force the Cone to narrow by removing sources of variability from your project.

Tip #13   Account for the Cone of Uncertainty by using predefined uncertainty ranges in your estimates.

Tip #14   Account for the Cone of Uncertainty by having one person create the “how much” part of the estimate and a different person create the “how uncertain” part of the estimate.

Tip #15   Don’t expect better estimation practices alone to provide more accurate estimates for chaotic projects. You can’t accurately estimate an out-of-control process.

Tip #16   To deal with unstable requirements, consider project control strategies instead of or in addition to estimation strategies.

Tip #17   Include time in your estimates for stated requirements, implied requirements, and nonfunctional requirements – that is, all requirements. Nothing can be built for free, and your estimates shouldn’t imply that it can.

Tip #18   Include all necessary software-development activities in your estimates, not just coding and testing.

Tip #19   On projects that last longer than a few weeks, include allowances for overhead activities such as vacations, sick days, training days, and company meetings.

Tip #20   Don’t reduce developer estimates – they’re probably too optimistic already.

Tip #21   Avoid having “control knobs” on your estimates. While control knobs might give you a feeling of  better accuracy, they usually introduce subjectivity and degrade actual accuracy.

Tip #22   Don’t give off-the-cuff estimates. Even a 15-minute estimate will be more accurate.

Tip #23   Match the number of significant digits in your estimate (its precision) to your estimate’s accuracy.

Tip #24   Invest an appropriate amount of effort assessing the size of the software that will be built. The  size of the software is the single most significant contributor to project effort and schedule.

Tip #25   Don’t assume that effort scales up linearly as project size does. Effort scales up exponentially.

Tip #26   Use software estimation tools to compute the impact of diseconomies of scale.

Tip #27   If you’ve completed previous projects that are about the same size as the project you’re  estimating – defined as being within a factor of 3 from largest to smallest – you can safely use a ratio-based estimating approach, such as lines of code per staff month, to estimate your new project.

Tip #28   Factor the kind of software you develop into your estimate. The kind of software you’re developing is the second-most significant contributor to project effort and schedule.

Tip #29   When choosing estimation techniques, consider what you want to estimate, the size of the project, the development stage, the project’s development style, and what accuracy you need.

Tip #30   Count if at all possible. Compute when you can’t count. Use judgment 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 models such as average effort per defect, average effort per Web page, average effort per story, and average effort per 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.

Tip #35   Use historical data as the basis for your productivity assumptions. Unlike mutual fund disclosures, your organization’s past performance really is your best indicator of future performance.

Tip #36   Use historical data to help avoid politically charged estimation discussions arising from assumptions like “My team is below average.”

Tip #37   In collecting historical data to use for estimation, start small, be sure you understand what you’re collecting, and collect the data consistently.

Tip #38   Collect a project’s historical data as soon as possible after the end of the project.

Tip #39   As a project is underway, collect historical data on a periodic basis so that you can build a data-based profile of how your projects run.

Tip #40   Use data from your current project (project data) to create highly accurate estimates for the remainder of the project.

Tip #41   Use project data or historical data rather than industry-average data to calibrate your estimates whenever possible. In addition to making your estimates more accurate, historical data will reduce variability in your estimate arising from uncertainty in the productivity assumptions.

Tip #42   If you don’t currently have historical data, begin collecting it as soon as possible.

Tip #43   To create the task-level estimates, have the people who will actually do the work create the  estimates.

Tip #44   Create both Best Case and Worst Case estimates to stimulate thinking about the full range of  possible outcomes.

Tip #45   Use an estimation checklist to improve your individual estimates. Develop and maintain your own personal checklist to improve your estimation accuracy.

Tip #46   Compare actual performance to estimated performance so that you can improve your individual estimates over time.

Tip #47   Decompose large estimates into small pieces so that you can take advantage of the Law of Large Numbers: the errors on the high side and the errors on the low side cancel each other out to some degree.

Tip #48   Use a generic software-project work breakdown structure (WBS) to avoid omitting common activities.

Tip #49   Use the simple standard deviation formula to compute meaningful aggregate Best Case and Worst Case estimates for estimates containing 10 tasks or fewer.

Tip #50   Use the complex standard deviation formula to compute meaningful aggregate Best Case and Worst Case estimates when you have about 10 tasks or more.

Tip #51   Don’t divide the range from best case to worst case by 6 to obtain standard deviations for individual task estimates. Choose a divisor based on the accuracy of your estimation ranges.

Tip #52   Focus on making your Expected Case estimates accurate. If the individual estimates are accurate, aggregation will not create problems. If the individual estimates are not accurate, aggregation will be problematic until you find a way to make them accurate.

Tip #53   Estimate new projects by comparing them to similar past projects, preferably decomposing the estimate into at least five pieces.

Tip #54   Do not address estimation uncertainty by biasing the estimate. Address uncertainty by expressing the estimate in uncertain terms.

Tip #55   Use fuzzy logic to estimate program size in lines of code.

Tip #56   Consider using standard components as a low-effort technique to estimate size in a project’s early stages.

Tip #57   Use story points to obtain an early estimate of an iterative project’s effort and schedule that is based on data from the same project.

Tip #58   Exercise caution when calculating estimates that use numeric ratings scales. Be sure that the numeric categories in the scale actually work like numbers, not like verbal categories such as  small, medium, and large.

Tip #59   Use t-shirt sizing to help nontechnical stakeholders rule features in or out while the project is in the wide part of the Cone of Uncertainty.

Tip #60   Use proxy-based techniques to estimate test cases, defects, pages of user documentation, and other quantities that are difficult to estimate directly.

Tip #61   Count whatever is easiest to count and provides the most accuracy in your environment, collect  calibration data on that, and then use that data to create estimates that are well-suited to your environment.

Tip #62   Use group reviews to improve estimation accuracy.

Tip #63   Use Wideband Delphi for early-in-the-project estimates, for unfamiliar systems, and when several diverse disciplines will be involved in the project itself.

Tip #64   Use an estimation software tool to sanity-check estimates created by manual methods. Larger projects should rely more heavily on commercial estimation software.

Tip #65   Don’t treat the output of a software estimation tool as divine revelation. Sanity-check estimation tool outputs just as you would other estimates.

Tip #66   Use multiple estimation techniques, and look for convergence or spread among the results.

Tip #67   If different estimation techniques produce different results, try to find the factors that are making the results different. Continue reestimating until the different techniques produce results that converge to within about 5%.

Tip #68   If multiple estimates agree and the business target disagrees, trust the estimates.

Tip #69   Don’t debate the output of an estimate. Take the output as a given. Change the output only by changing the inputs and recomputing.

Tip #70   Focus on estimating size first. Then compute effort, schedule, cost, and features from the size estimate.

Tip #71   Reestimate.

Tip #72   Change from less accurate to more accurate estimation approaches as you work your way through a project.

Tip #73   When you are ready to hand out specific development task assignments, switch to bottom-up estimation.

Tip #74   When you reestimate in response to a missed deadline, base the new estimate on the project’s actual progress, not on the project’s planned progress.

Tip #75   Present your estimates in a way that allows you to tighten up your estimates as you move further into the project.

Tip #76   Communicate your plan to reestimate to other project stakeholders in advance.

Tip #77   Develop a Standardized Estimation Procedure at the organizational level; use it at the project level.

Tip #78   Coordinate your Standardized Estimation Procedure with your SDLC.

Tip #79   Review your projects’ estimates and estimation process so that you can improve the accuracy of  your estimates and minimize the effort required to create them.

Tip #80   Use lines of code to estimate size, but remember both the general limitations of simple measures and the specific hazards of the LOC  measure in.

Tip #81   Count function points to obtain an accurate early-in-the-project size estimate.

Tip #82   Use the Dutch Method of counting function points to attain a low-cost ballpark estimate early in the project.

Tip #83   Use GUI elements to obtain a low-effort ballpark estimate in the wide part of the Cone of Uncertainty.

Tip #84   With better estimation methods, the size estimate becomes the foundation of all other estimates. The size of the system you’re building is the single largest cost driver. Use multiple size-estimation techniques to make your size estimate accurate.

Tip #85   Use software tools based on the science of estimation to most accurately compute effort estimates from your size estimates.

Tip #86   Use industry-average effort graphs to obtain rough effort estimates in the wide part of the Cone of Uncertainty. For larger projects, remember that more powerful estimation techniques are easily cost-justified.

Tip #87   Use the ISBSG method to compute a rough effort estimate. Combine it with other methods, and look for convergence or spread among the different estimates.

Tip #88   Not all estimation methods are equal. When  looking for convergence or spread among estimates, give more weight to the techniques that tend to produce the most accurate results.

Tip #89   Use the Basic Schedule Equation to estimate schedule early in medium-to-large projects.

Tip #90   Use the Informal Comparison to Past Projects formula to estimate schedule early in a small-to-large project.

Tip #91   Use Jones’s First-Order Estimation Practice to produce a low-accuracy (but very low-effort) schedule estimate early in a project.

Tip #92   Do not shorten a schedule estimate without increasing the effort estimate.

Tip #93   Do not shorten a nominal schedule more than 25%. In other words, keep your estimates out of the Impossible Zone.

Tip #94   Reduce costs by lengthening the schedule and conducting the project with a smaller team.

Tip #95   For medium-sized business-systems projects (35,000 to 100,000 lines of code) avoid increasing the team size beyond 7 people.

Tip #96   Use schedule estimation to ensure your plans are plausible. Use detailed planning to produce the final schedule.

Tip #97   Remove the results of overly generic estimation techniques from your data set before you look  for convergence or spread among your estimates.

Tip #98   When allocating project effort across different activities, consider project size, project type, and the kinds of effort contained in the calibration data used to create your initial rolled-up estimate.

Tip #99   Consider your project’s size, type, and development approach in allocating schedule to different  activities.

Tip #100   Use industry-average data or your historical data to estimate the number of defects your project will produce.

Tip #101   Use defect-removal-rate data to estimate the number of defects that your quality assurance practices will remove from your software before it is released.

Tip #102   Use your project’s total Risk Exposure (RE) as the starting point for buffer planning. Review the details of your project’s specific risks to understand whether you should ultimately plan for a buffer that’s larger or smaller than the total RE.

Tip #103   Planning and estimation are related, and planning is a much bigger topic than can be addressed in one chapter in a book that focuses on software estimation. Read the literature on  planning.

Tip #104   Document and communicate the assumptions embedded in your estimate.

Tip #105   Be sure you understand whether you’re presenting uncertainty in an estimate or uncertainty that affects your ability to meet a commitment.

Tip #106   Don’t present project outcomes to other project stakeholders that are only remotely possible.

Tip #107   Consider graphic presentation of your estimate as an alternative to text presentation.

Tip #108   Use an estimate presentation style that reinforces the message you want to communicate about your estimate’s accuracy.

Tip #109   Don’t try to express a commitment as a range. A commitment needs to be specific.

Tip #110   Understand that executives are assertive by nature and by job description, and plan your estimation discussions accordingly.

Tip #111   Be aware of external influences on the target. Communicate that you understand the business  requirements and their importance.

Tip #112   You can negotiate the commitment, but don’t negotiate the estimate.

Tip #113   Educate nontechnical stakeholders about effective software estimation practices.

Tip #114   Treat estimation discussions as problem solving, not negotiation. Recognize that all project stakeholders are on the same side of the table. Everyone wins, or everyone loses.

Tip #115   Attack the problem, not the people.

Tip #116   Generate as many planning options as you can to support your organization’s goals.

Tip #117   As you foster an atmosphere of collaborative problem solving, don’t make any commitments based on off-the-cuff estimates.

Tip #118   Resolve discussion deadlocks by returning to the question of, “What will be best for our organization?”

From Software Estimation by Steve McConnell (Microsoft Press, 2006)

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: