Estimating software development often produces more angst than value, but it doesn't have to. Identify the needs behind estimate requests and determine how to meet those needs simply and easily. Choose estimation techniques based on current needs and available information, gaining benefit while reducing cost and effort. Detect bad assumptions that might sink your project if you don't adjust your plans. Discover what to do when an estimate is wrong, how to recover, and how to use that knowledge for future planning. Learn to communicate about estimates in a healthy and productive way, maximizing advantage to the organization and minimizing damage to the people.
In a world where most developers hate estimation and most managers fear disappointment with the results, there is hope for both. It requires giving up some widely held misconceptions. Let go of the notion that "an estimate is an estimate" and estimate for the particular need you, and your organization, have. Realize that estimates have a limited shelf-life, and reestimate frequently if it's important. When reality differs from your estimate, don't lament; mine that disappointment for the gold that can be the longer-term jackpot.
Estimate in comparison to past experience, by modeling the work mathematically, or a hybrid of both. Learn strategies for effective decomposition of work and aspects of the work that likely affect your estimates. Hedge your bets by comparing the results of different approaches. Find out what to do when an estimate proves wrong. And they will. They're estimates, after all. You'll discover that you can use estimates to warn you of danger so you can take appropriate action in time. Learn some crucial techniques to understand and communicate with those who need to understand.
Address both the technical and sociological aspects of estimation, and you'll help your organization achieve its desired goals with less drama and more benefit.
A surprisingly interesting book that has the opposite approach of When Will It Be Done?. The author collected a wide range of approaches you can take to estimate. He explains the problems you may have and how you can mitigate them. The goal of this book is to reduce the cost of your estimates and still be able to answer the questions your project sponsors have. Putting the advice in practice is not an easy task, but we should try.
The book is nice, but only if you have plenty of time because you are not working on something. I think it does guide us towards software estimation without guessing, but after around 6-8 years of experience, people have learned quite lot of things.
Not a must read, definitely. The positive side: It gave me check list of questions in majority of cases.
A book that compiles a lot of industry wisdom around estimation into a few chapters with made up mock-examples. I personally found the examples hard to relate to and the overall delivery quite dry and difficult to get through. There are a few points being made about how estimation becomes more useful as it keeps getting revisited with more information and how it might not be worth to estimate at all when talking about small units of work that all need to be done anyway. The book curiously never talked about estimation as a prioritization tool in ongoing development for an existing product. All examples are around projects - finite deliverables that have a defined start and finish. If this is not your situation (and its not mine), the value you get from this book will be limited.
Initially was going to rate it 3 stars due to things mentioned above, but the last chapter deals with the human psychology part of software estimation and delivery, which was a refreshing change of pace. It's not exceptionally novel or anything like that, but it felt different and more interesting to read than the rest, so props for that
I guessed I would learn what is really to estimate from an expert. But I guessed wrong.
You will learn mainly the common "good sense" knowledge about the nature and shape of estimations you are asked for and how to give them.
The most advanced ways to estimate described are either expensive proprietary software with massive historical database (and you should hope that this database is relevant with your context) or what the #noestimate people tends to propose (like Monte Carlo computation).
The book is also filled with "stories" (which I always find a bit boring) and lacks of diagram and in depth examples of how to make good estimation.
Good part: it's mainly "neutral" around the topic and give an up to date global view on "how to estimate" with even good tips for "Agile" estimation.
Strangely the best parts are how to manage the human communication around estimations :)
This book is full of common sense and fluff. I'm not sure who is the audience, as from one side the author assumes a lot of knowledge of XP/Scrum/Agile, but at the same time a lot of his examples/case stories are pretty basic. And he spends more time on telling how his mother was frustrated when he came back home at 12:04 am vs. why he recommends "BurnUp" chart instead of Burndown.
Definitely a beginner book that takes the reader on a whirlwind tour of various methods and aspects of SW estimation, but not enough to satisfy in any area (but points to bibliography). I'm taking half a point of for style as I found the writing disengaging.
This is an insightful book that I really enjoyed reading. There are lots of useful hints and explanations include, although nothing really new to me. My key takeaway is the idea how a vision should be drafted without any talks to tech, just to prevent tech from shooting it down.
This book gives a nice overview of different ways to think about project estimation. It gives an overview and comparison of estimation techniques without prescribing a silver bullet.
Even if you're not a software developer, or a product manager and so on, you can get the full picture of software estimation through George Dinwiddie's job in this book.
It starts with an example of three different projects managed by companies in a different budget-scale and goes along the sections using examples of daily challenges and situations they might face on the development of the estimation of the tasks related to their product.
If you doubt if you've been doing the things well, or even if you just want to have another perspective about software estimation, give it a try. The good thing is it's intended for any kind of people, it doesn't matter if you're starting your new product, a senior developer or an undergraduate CS student looking to know more about what's your future. Hints, war stories, and advice on this work are more than worth.
This book is terrific. Let me start by saying George’s wit and intelligence really shine through in these pages. The examples and descriptions are thoughtful and though provoking. Each section of the book is well written and carefully considered. Every section is thoroughly researched and documented. George does a wonderful job of collecting, organizing, and describing the various aspect of estimating. He closely examines the impact of the factors and context of an estimate and how it can effect your efforts. In addition to talking about methods and factors as they relate to estimation, George takes particular care to discuss the human factors of estimates. I think this is one of the most important and overlooked aspects of estimating and he covers this area with particular care and consideration. I very strongly recommend this book, it’s a keeper.
If you expect this book to be a magic recipe formula to apply and give accurate estimates of software projects, it may not be what you're looking for. This book provides strategies for those situations that are commonly faced by those involved in estimating software projects. It also involves the issue of communication and the human factor that are critical to achieving the objectives of a project, I liked this book, and I recommend it for the practicality in which it addresses the topics and the sections of questions that make you reflect in each chapter.
I’m really glad I took the time to read this book. It validated some of my beliefs about estimating, challenged others, gave me some great ideas about what to do in my current projects, and emphasized the human aspect of software engineering and estimating. Strongly recommend this book!