What do you think?
Rate this book
Predicting the Unpredictable
You’d like to estimate your project’s cost or schedule accurately. So far, none of your approaches have worked. It’s time to consider how you can create an accurate estimate.
You might not be able to develop an estimate at the beginning of a project that is good until the end. Few project teams can. Instead, learn a number of ways to see your project and how to address your uncertainties in ways your managers will accept.
You might not be able to develop an estimate at the beginning of a project that is good until the end. Few project teams can. Instead, learn a number of ways to see your project and how to address your uncertainties in ways your managers will accept.
90 pages, ebook
First published February 5, 2014
3 people are currently reading
165 people want to read
About the author
Johanna Rothman
45 books109 followersPeople know me as the “Pragmatic Manager.” I offer frank, practical advice for your challenging product development problems.
I help leaders and teams see their current reality. Because one size never fits all, we explore options for what and how to change. The results? Leaders and teams learn to collaborate and focus on outcomes that matter.
My clients and readers appreciate both my trademark practicality and humor. I've written 21 books, hundreds of articles, and thousands of blog posts. See all my writing and monthly newsletters at www.jrothman.com and www.createadaptablelife.com.
I write in all genres except for horror because I need my sleep, and horror gives me nightmares. My short fiction has appeared in Pulphouse Magazine, Fiction River, and Heart’s Kiss in addition to several other anthologies.
I help leaders and teams see their current reality. Because one size never fits all, we explore options for what and how to change. The results? Leaders and teams learn to collaborate and focus on outcomes that matter.
My clients and readers appreciate both my trademark practicality and humor. I've written 21 books, hundreds of articles, and thousands of blog posts. See all my writing and monthly newsletters at www.jrothman.com and www.createadaptablelife.com.
I write in all genres except for horror because I need my sleep, and horror gives me nightmares. My short fiction has appeared in Pulphouse Magazine, Fiction River, and Heart’s Kiss in addition to several other anthologies.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 12 of 12 reviews
June 10, 2017
TODO full review:
i Part of my effort to learn about modern management practices in software research and development.
i Part of reading the Johanna Rothman author-series.
+ Predicting the Unpredictable focuses on a challenging task that appears in every project : estimating whent the project gets done. Typical approaches partition the work in stages or chunks, and use various kinds of measurent and continuously revised estimates to keep th remaining work predictable. Typical issues include overestimating the remaining time, not producing enough data to predict, relying on gut-feeling (some call it experience) to predict, team-changes of personnel or structure, the need to learn for new features and to experiment for innovative features, and the common approach of ignoring non-functional features (such as performance, availability, security, etc.) until too late.
--- Overall, this book was for me a waste of time. The main message, that estimates are inherently inaccurate and should thus be avoided, lacks new insight and ignores the reality of the market.
What I liked:
What I didn't like:
1. There was little to learn and much pro-agile chatter.
2. The conceptual information was poorly structure, hidden in-between argumentative text. Good advice such as "never, ever, ever provide a single date for a project or a single point for a budget without a range [of dates for which the estimate is correct] or a confidence level [for the estimate]" is never followed by methods or processes to compute date-ranges or confidence intervals.
3. There was little practical information, other than to ignore timing and just do your best with the problem at hand ("I no longer estimate my work").
4. There was much information that can get you fired: refuse help or orders from above ("Do NOT let your manager SWAG for you"), and even the suggestion to lie to your managers, when they pressure for an estimate. The latter would bring even more disrepute to the profession of software engineer.
5. Non-functional properties are treated perfunctorily, and the only meaningful advice is that estimates for this type of requirements are even less accurate than for other kinds of requirements. There is no proof for this. There is no additional info about how much more inaccurate. There is no discussion about what to do about it.
i Part of my effort to learn about modern management practices in software research and development.
i Part of reading the Johanna Rothman author-series.
+ Predicting the Unpredictable focuses on a challenging task that appears in every project : estimating whent the project gets done. Typical approaches partition the work in stages or chunks, and use various kinds of measurent and continuously revised estimates to keep th remaining work predictable. Typical issues include overestimating the remaining time, not producing enough data to predict, relying on gut-feeling (some call it experience) to predict, team-changes of personnel or structure, the need to learn for new features and to experiment for innovative features, and the common approach of ignoring non-functional features (such as performance, availability, security, etc.) until too late.
--- Overall, this book was for me a waste of time. The main message, that estimates are inherently inaccurate and should thus be avoided, lacks new insight and ignores the reality of the market.
What I liked:
What I didn't like:
1. There was little to learn and much pro-agile chatter.
2. The conceptual information was poorly structure, hidden in-between argumentative text. Good advice such as "never, ever, ever provide a single date for a project or a single point for a budget without a range [of dates for which the estimate is correct] or a confidence level [for the estimate]" is never followed by methods or processes to compute date-ranges or confidence intervals.
3. There was little practical information, other than to ignore timing and just do your best with the problem at hand ("I no longer estimate my work").
4. There was much information that can get you fired: refuse help or orders from above ("Do NOT let your manager SWAG for you"), and even the suggestion to lie to your managers, when they pressure for an estimate. The latter would bring even more disrepute to the profession of software engineer.
5. Non-functional properties are treated perfunctorily, and the only meaningful advice is that estimates for this type of requirements are even less accurate than for other kinds of requirements. There is no proof for this. There is no additional info about how much more inaccurate. There is no discussion about what to do about it.
September 3, 2015
Very pragmatic overview of estimation techniques and pitfalls in agile and traditional projects.
August 4, 2016
Estimation is in my experience a "unavoidable evil" of the Software profession. I found it interesting to get some new perspectives on this.
September 2, 2019
An incredibly helpful book for everyone working in a project. The biggest challenge we all face is the question “How long does it take?”. Johanna has many great tips on how to find an answer to that question (split the work in small and understandable parts and estimate all those parts) and makes clear that estimating is always guessing. We will never have a precise estimate, but for most questions that is not needed - a range is all it takes, or confidence levels if your stakeholders are more familiar with them. I found so many places in this book where I could say “that’s exactly how it is” that I stopped highlighting those parts. If you have to do any form of estimates, you definitely should read this book!
June 17, 2016
Good, practical book. Concerning what is difficult to predict, time. Wha I don't like are reffers to previous authors book, nevertheless I think that short book is worth refreshing from time to time.
Some quotes:
An initial project estimate is your best guess at the time you make the estimate. The accuracy of that estimate depends on the people doing the estimation and what they know about the project.
Your estimate is a guess, a prediction. It is not fact. If I have trouble estimating my driving time, which has far fewer variabilities than a project, how can you expect your project estimate to be accurate? You can’t, not with the very first estimate you create. You can iterate on the estimate and make it better over time.
Managers and sponsors ask a project team for estimates all the time. Sometimes, managers use those estimates to plan which project to do first—which is a terrible idea. More on that later. Sometimes, managers use those estimates to predict a target date. Sometimes, managers use those estimates as a commitment. None of those ways are the way we should use estimates. Here is the problem with using estimates that way: Estimates expire. Estimates change. Estimates are guesses.
Here’s one problem I have with estimation. Software is not construction. We can’t build software the same way we construct or manufacture something. Software is all about learning and innovating as a team. Some people think that software is invention. Whatever you think about software, it is not construction.
Since software is about learning, and we rarely, if ever, do the same project twice, we are always estimating the unknown.
cautions: Never, ever, ever provide a single date for a project or a single point for a budget without a range or a confidence level. Expect to iterate on the release date and on the budget, and train your managers to expect iterative, improved estimates from you. If you get a ranked feature set, you can provide working product in the order in which your managers want the work done, while you keep refining your estimates. This has to be good for everyone. If you can say this without being patronizing, practice saying, “Remember, the definition of estimate is guess.”
You report all estimates with a confidence range. If you report estimates as a single point in time, people think your estimates are accurate and precise. If you report them as a confidence range, people realize how inaccurate and imprecise your estimates are, and you have a shot of people treating them as real estimates.
Managers and senior architects tend to underestimate the amount of work. They tend to think the work is easy to do, especially if the requirements are clear.
You have options for estimation, once you have met the preconditions. If you don’t have the feature set in a ranked order, you are in trouble.
Managers think they can predict team size from the estimate. You might be able to add more teams and/or people. You cannot guarantee a larger team or more feature teams will meet an estimate, or decrease the time needed. This is the problem of splitting work in the mistaken belief that more people make it easier to do more work. More people make the communications burden heavier.
As you continue to manage the project, track your initial completion date estimate. Each month, or in a short project, each week, take 5 minutes out of your project team meeting, and ask: “When do you think we will finish the project?” Track that estimate on a chart set up with the release dates on the Y-axis, and the date that you asked the question on the X-axis.
Any 100% date I give now will be wrong, wrong, wrong.
It doesn’t matter what kind of life cycle you use, the further out the dates are, the less you know. You can use probabilistic scheduling to help you, the project team, and your sponsors see the risk in the schedule.
Exact estimates are an oxymoron. Estimates that you update? Those are useful. I can’t understand why any manager wouldn’t want those.
The best guess I have is to estimate the number of cycles you’ll need for testing, the duration of one cycle, and the time it takes for developers to fix problems between cycles. Add up the testing plus fixing/cycle and multiply by the number of cycles you think you’ll need, and you’ll have an estimate of the testing time needed.
By the way, when I do this, I never give a single number; I always give time per cycle (“It will take us six days per cycle”), my estimate of the number of cycles (“We’ll need four cycles”), and my estimate of defect-fixing and verification time (“Plus three days between test cycles for developers to fix problems”). That way I can show the costs of not performing proactive defect prevention in a nice way. And I can show my uncertainty in my estimation (“That’s a minimum of thirty-six working days, longer if the defects take longer to fix and verify”).
If you want to reduce testing time and create a low-defect product, test all the way through the project with a variety of test techniques. Use test iterations so you know at the end of one test cycle where you stand with defects. The lower the number of defects and the more sophisticated your tests, the faster your testing time.
Some quotes:
An initial project estimate is your best guess at the time you make the estimate. The accuracy of that estimate depends on the people doing the estimation and what they know about the project.
Your estimate is a guess, a prediction. It is not fact. If I have trouble estimating my driving time, which has far fewer variabilities than a project, how can you expect your project estimate to be accurate? You can’t, not with the very first estimate you create. You can iterate on the estimate and make it better over time.
Managers and sponsors ask a project team for estimates all the time. Sometimes, managers use those estimates to plan which project to do first—which is a terrible idea. More on that later. Sometimes, managers use those estimates to predict a target date. Sometimes, managers use those estimates as a commitment. None of those ways are the way we should use estimates. Here is the problem with using estimates that way: Estimates expire. Estimates change. Estimates are guesses.
Here’s one problem I have with estimation. Software is not construction. We can’t build software the same way we construct or manufacture something. Software is all about learning and innovating as a team. Some people think that software is invention. Whatever you think about software, it is not construction.
Since software is about learning, and we rarely, if ever, do the same project twice, we are always estimating the unknown.
cautions: Never, ever, ever provide a single date for a project or a single point for a budget without a range or a confidence level. Expect to iterate on the release date and on the budget, and train your managers to expect iterative, improved estimates from you. If you get a ranked feature set, you can provide working product in the order in which your managers want the work done, while you keep refining your estimates. This has to be good for everyone. If you can say this without being patronizing, practice saying, “Remember, the definition of estimate is guess.”
You report all estimates with a confidence range. If you report estimates as a single point in time, people think your estimates are accurate and precise. If you report them as a confidence range, people realize how inaccurate and imprecise your estimates are, and you have a shot of people treating them as real estimates.
Managers and senior architects tend to underestimate the amount of work. They tend to think the work is easy to do, especially if the requirements are clear.
You have options for estimation, once you have met the preconditions. If you don’t have the feature set in a ranked order, you are in trouble.
Managers think they can predict team size from the estimate. You might be able to add more teams and/or people. You cannot guarantee a larger team or more feature teams will meet an estimate, or decrease the time needed. This is the problem of splitting work in the mistaken belief that more people make it easier to do more work. More people make the communications burden heavier.
As you continue to manage the project, track your initial completion date estimate. Each month, or in a short project, each week, take 5 minutes out of your project team meeting, and ask: “When do you think we will finish the project?” Track that estimate on a chart set up with the release dates on the Y-axis, and the date that you asked the question on the X-axis.
Any 100% date I give now will be wrong, wrong, wrong.
It doesn’t matter what kind of life cycle you use, the further out the dates are, the less you know. You can use probabilistic scheduling to help you, the project team, and your sponsors see the risk in the schedule.
Exact estimates are an oxymoron. Estimates that you update? Those are useful. I can’t understand why any manager wouldn’t want those.
The best guess I have is to estimate the number of cycles you’ll need for testing, the duration of one cycle, and the time it takes for developers to fix problems between cycles. Add up the testing plus fixing/cycle and multiply by the number of cycles you think you’ll need, and you’ll have an estimate of the testing time needed.
By the way, when I do this, I never give a single number; I always give time per cycle (“It will take us six days per cycle”), my estimate of the number of cycles (“We’ll need four cycles”), and my estimate of defect-fixing and verification time (“Plus three days between test cycles for developers to fix problems”). That way I can show the costs of not performing proactive defect prevention in a nice way. And I can show my uncertainty in my estimation (“That’s a minimum of thirty-six working days, longer if the defects take longer to fix and verify”).
If you want to reduce testing time and create a low-defect product, test all the way through the project with a variety of test techniques. Use test iterations so you know at the end of one test cycle where you stand with defects. The lower the number of defects and the more sophisticated your tests, the faster your testing time.
October 22, 2017
A right-sized, experienced, wise discussion of what goes into delivering software on time.
August 30, 2016
Anyone involved with delivering a product or a project will have to face two questions: when will it finish, and how much will it cost?
The questions are straightforward and simple, they are also justified, but the answers are the source of a huge literature with a lot of books and articles, leading to heated debates and claims. And if you're dealing with a software-intensive product or a project, you already know the difficulties of making predictions about future.
In this no-nonsense and pragmatic book, the author tries to look at the various aspects of predicting the timing of software projects. Given the statistical nature of the problem at hand, and the thirst for determinism of the business, she manages to clarify the concepts and draw attention to critical pitfalls. One of the things I really appreciated is the fact that author is very well aware of what kind of pressure the upper management can put on the shoulders of a software project manager: she has clearly been through such situations, and constantly focuses on how you can convey the fragile nature of ambitious of project predictions.
I can easily the recommend because I think it'll useful for practicing software managers, as well as the developers who try to evaluate whether they are working with good management practices.
So, as the author says, make your features small, break down that epic, go on a spike, don't multitask, put an expiration that on your estimates, always use confidence numbers for your predictions, communicate your status concretely, provide value at the end of each increment, and get to work!
The questions are straightforward and simple, they are also justified, but the answers are the source of a huge literature with a lot of books and articles, leading to heated debates and claims. And if you're dealing with a software-intensive product or a project, you already know the difficulties of making predictions about future.
In this no-nonsense and pragmatic book, the author tries to look at the various aspects of predicting the timing of software projects. Given the statistical nature of the problem at hand, and the thirst for determinism of the business, she manages to clarify the concepts and draw attention to critical pitfalls. One of the things I really appreciated is the fact that author is very well aware of what kind of pressure the upper management can put on the shoulders of a software project manager: she has clearly been through such situations, and constantly focuses on how you can convey the fragile nature of ambitious of project predictions.
I can easily the recommend because I think it'll useful for practicing software managers, as well as the developers who try to evaluate whether they are working with good management practices.
So, as the author says, make your features small, break down that epic, go on a spike, don't multitask, put an expiration that on your estimates, always use confidence numbers for your predictions, communicate your status concretely, provide value at the end of each increment, and get to work!
November 3, 2016
Probably, it's not for me! It didn't attract me and felt that it's a repeated advice from the beginning to the end. An advice that could be great to read in an article or a blog post but doesn't need a while book, from my point of view. Maybe you should read a sample chapter to find if this book for you or not.
November 24, 2015
Escape the sound and fury of the #NoEstimates argument, read Johanna's calm, experienced voice instead.
Fully acknowledges the risks and weaknesses of traditional estimating, open to better ways of doing it, but recognising the stakeholder value of the old ways too.
Fully acknowledges the risks and weaknesses of traditional estimating, open to better ways of doing it, but recognising the stakeholder value of the old ways too.
October 24, 2015
Johanna gives a wonderful overview of the common problems that originate from traditional estimates and offers a lot of advice and alternative techniques.
The style of the book is clear and feels very honest. I would definitely recommend this book!
The style of the book is clear and feels very honest. I would definitely recommend this book!
February 6, 2017
This was a pretty comprehensive book on all things estimation. It's not what I was looking for, but it's a book I'll recommend to people looking to improve how they estimate and how they communicate their estimates.
November 12, 2015
Excellent stuff - this is uncertainty in the real world for grownups.
The calm, wise tone and eminently practical advice shows the whole #NoEstimates debate (both sides) as shrill and a bit silly
The calm, wise tone and eminently practical advice shows the whole #NoEstimates debate (both sides) as shrill and a bit silly
Displaying 1 - 12 of 12 reviews