This book is not about how to estimate the very largest projects—more than 1 million lines of code, or more than 100 staff
Where you start will depend on what you want to get out of the book.
If you bought this book because you need to create an estimate right now … Begin with Chapter 1 ("What Is an "Estimate"?), and then move to Chapter 7 ("Count, Compute, Judge") and Chapter 8 ("Calibration and Historical Data"). After that, skim the tips in Chapters 10–20 to find the techniques that will be the most immediately useful to you. By the way, this book's tips are highlighted in the text and numbered, and all of the tips—118 total—are also collected in Appendix C, "Software Estimation Tips."
If you want to improve your personal estimation skills, if you want to improve your
organization's estimation track record, or if you're looking for a better understanding of
software estimation in general
You can read the whole book. If you like to understand general principles before you dive into the details, read the book in order. If you like to see the details first and then draw general conclusions from the details, you can start with Chapter 1, read Chapters 7 through 23, and then go back and read the earlier chapters that you
New Year's Day, 2006
Every effort has been made to ensure the accuracy of this book. Microsoft Press provides corrections for books through the World Wide Web at the following address:
To connect directly to the Microsoft Press Knowledge Base and enter a query regarding a question or issue that you may have, go to:
If you have comments, questions, or ideas regarding this book,
Attn: Software Estimation Editor
One Microsoft Way
Redmond, WA 98052-6399
It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers.
You might think you already know what an estimate is. My goal by the end of this chapter is to convince you that an estimate is different from what most people think. A good estimate is even more different.
Here is a dictionary definition of
: 1. A tentative evaluation or rough calculation. 2. A preliminary calculation of the cost of a project. 3. A judgment based upon one's
Does this sound like what you are asked for when you're asked for an estimate? Are you asked for a tentative or preliminary calculation—that is, do you expect that you can change your mind later?
Probably not. When executives ask for an "estimate," they're often asking for a commitment or for a plan to meet a target. The distinctions between estimates, targets, and commitments are critical to understanding what an estimate is, what an estimate is not, and how to make your estimates better.