TL;DR: More of a reference book than a read-through book. Goes through a lot of software estimation techniques. Meat of the book was in the first section.
Note: taken from the “tips” appendix mainly, with context where appropriate
- Estimate: prediction of how long a project will take or cost
- Target: statement of a desirable business objective
- Commitment: promise to deliver defined functionality at a specific level of quality by a certain date
- Estimation should be treated as an unbiased, analytical process; planning should be treated as a biased, goal-seeking process.
- 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 4: When you see a single-point estimate, that number’s probability is not 100%. Ask what the probability of that number is.
- Tip 6: 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 10: Many businesses value predictability more than development time, cost, or flexibility. Be sure you understand what your business values the most.
- Tip 18: Include all necessary software-development activities in your estimates, not just coding and testing.
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.
- Tough to apply just by reading all of these techniques. Major takeaway is that everyone needs to be on the same page, and in general people underestimate the amounts of time and resources.