If there’s one consistent source of confusion and controversy among the agile practices that LitheSpeed’s clients utilize, it’s estimation. Should it be relative or absolute? Should it be standardized or unique to each team? What the heck is a story point again?
Software Estimation Without Guessing by George Dinwiddie is an erudite, practical and comprehensive take on the subject. Full disclosure: George is a long-time friend and colleague of mine. While we see each other all too rarely of late I always seek out his company at conferences, and he has done many wonderful things for the agile community (ever heard of the “three amigos”?). That said, no friend bias is necessary to get value from this book.
George utilizes three types of companies as exemplars throughout: Empire Enterprises, a traditional large organization with an IT shop; Riffle & Sort, a medium-sized company doing custom software development for external clients; and TinyToyCo, a small game app development shop that’s considering a move into toy manufacturing. A key point of the book is that estimation can be a means to many different ends, and that the right approach for a given question in one situation is often quite inappropriate in others. So, knowing your goals when estimating and fitting the techniques to your own situation are critical. Each chapter ends with exercises that resemble thought puzzles.
The book consists of nine core chapters which hit the problem of estimation from different angles:
- Starting Something New
- Comparison-Based Estimation
- Decomposition for Estimation
- Checking Progress
- Model-Based Estimation
- Estimating Milestones
- When Estimates and Actuals Differ
- Planning for Incorrect Predictions
- When People Clash
Several common scenarios of new product launches are introduced to illustrate which approaches work best in each: developing a fixed-price bid such as for an RFP, determining if a project is worth starting or viable, figuring out how much something will cost, and using estimation to select among different solution options. Aside from the parables he weaves using his three prototypical companies, George also provides many anecdotes from his own rich personal experience, which are a high point of the book and are of such variety as to likely find resonance no matter what your situation.
The exercises at the close of each chapter serve as ways to think through the lessons conveyed within your own context; for instance:
“List the different types of needs for estimates that you’ve encountered at the start of your projects. Consider the accuracy, precision, and probability distribution of error to suit those needs. How many different sorts of estimates have you needed (whether or not that’s what you received or provided)? How many times was the desirable accuracy, precision, and error distribution estimate unknown?”
A few highlights are the examples he offers for how to split particularly complex stories, tips for dealing with reporting from many different angles, improving teams’ ability to estimate over time, and the review of cognitive biases and how to deal with them that closed the book. Many of the problems of estimation are less flaws in technique and more issues of perception and communication. If you can figure out how estimates are meant to be applied and engage with stakeholders properly your battle is half won. He gives several excellent and practical examples of how you can combine ideas like burn-up charts, linear estimation, stochastic projection and affinity clustering into simple but effective visual management systems.
I think George does an excellent job of covering the many facets of estimation that you need to consider, and if you internalize the lessons that he conveys you’ll be well equipped to design appropriate estimation systems yourself. I would caution that there is a lot to digest here, and George hesitates to call out any particular techniques as those that should always be chosen in different circumstances, so he’s hoping you’ll think for yourself and design a system that works for your particular situation, no more or less complex than it needs to be. That’s agile thinking for you! Check it out.
Arlen Bankston is the cofounder of LitheSpeed and a Certified Scrum Trainer.
