What do you think?
Rate this book
NoEstimates: How To Measure Project Progress Without Estimating
How to always be on time, and not risk missing important deadlines or go over budget
This book is the result of many years of hard work, and plenty of lessons learned. I wrote it because I believe we can do better than the accepted "status quo" in the software industry.
It took me years to learn what I needed to learn to come up with my version of the #NoEstimates approach. You can do it in weeks!
The techniques and ideas described here will help you explore the #NoEstimates universe in a very practical and hands-on manner. You will walk through Carmen's story. Carmen is a senior, very experienced project manager who is now confronted with a very difficult project. One would say, an impossible project.
Through the book, and with the help of Herman, Carmen discovers and slowly adopts #NoEstimates which helps her turn that project around. Just like I expect it will help with the project you are in right now. The book also includes many concrete approaches you can use to adopt #NoEstimates, or just adopt those practices on their own.
252 pages, Kindle Edition
Published June 13, 2016
74 people are currently reading
557 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 21 of 21 reviews
July 28, 2017
I'm a big fan of the #NoEstimates movement. I've seen multiple talks, I fight against "story points" and other forms of estimate waste whenever possible, and I trumpet the "new" movement in agile of having no estimates. I recognize that estimates are a tremendously bad way of achieving predictability in software development - in short, estimates simply do not accomplish what they are meant to accomplish, and are thus a total waste of time. But I do have a dirty little secret... I don't really have an alternative.
I go around various places of employment saying that estimates are a waste of time, and they are, but when stakeholders, product owners, and business people try to get me to explain how they're supposed to get a sense of when products will be delivered without them, I wave my hands and mutter something about how you can achieve greater predictability using real data and tracking your team's throughput, cycle time, and lead time. I know I've heard people say this, and it makes sense to me, but I don't really know the specifics, and I've had a hard time finding them. I seem to get away with this nonsense simply because, as it turns out, businesses don't really need predicability as much as they think they do. Marketing teams and salesmen tend to work better when they're selling or marketing what's already done, rather than what's going to be done "soon". And business stakeholders, for all the claims to the contrary, never actually seem to use the relative estimation/cost for various projects to actually decide what projects to do - it always seems like there's a "most important thing" that needs to be done no matter what. We have an industry where tons of people are convinced that they need to know the exact date features are going to be done, but my experience has shown me time and time again that they actually don't need that, most of the time.
Notice I keep saying "most" or "usually". There definitely ARE times when companies need to get a sense of when something's going to be done. I know estimating doesn't work for that purpose - I'm fully convinced and on board with that idea. But I've been long seeking an understanding of how to achieve it for those situations when it's needed, and I've mostly gotten away with simply not having to know. My hope going into this book, which presents itself as largely the complete guide to the #NoEstimates movement, was that it was going to answer this for me.
In the end, it still felt pretty hand-wavey, I don't think I came away with what I wanted. The book plays a lot of lipservice to the notion of predictability without estimates, but I felt like it largely does what I keep doing, which is kind of deal in vague terms and assure the audience that it's possible, without really making someone understand exactly how. The final two chapters deal most directly with this question - everything leading up to it is mostly about why estimates are worthless and how much better off you'd be without them. But the last two mostly attempt to deal with predictability and they do an admirable job, but still felt a tad vague. There's quite a bit about how one can measure progress and know if your project is going off the rails, which is helpful I guess, but not what I was looking for.
Agile books can be kind of "culty" in nature, like they come across like someone trying to convince you to join their religion. This one is no exception, a tone that I felt was exacerbated by the unfortunate decision to write much of the book as a hypothetical fictional novel. There are characters working jobs and trying to deal with problems, and of course there are super-smart characters who explain the principles of the #NoEstimates book, and of course they wind up being completely right. One particularly hilarious scene near the end has the big boss character excitedly telling the main character, Carmen, that he's never seen anyone work so well, and he demands that she and her #NoEstimates buddy (Herman, get it, "her man"?) come work directly for him. It's so dorky and ridiculous, kind of has the same vibe as an infomercial where someone can't open a soda bottle right until Billy Mays comes in and says he's got the perfect product that will solve all their problems. It reminded me a lot of how The Phoenix Project was written, but at least that book stayed consistently in "novel" mode, not switching back and forth. At one point, Herman actually gives Carmen a copy of the #NoEstimates book in which they are characters, Neverending Story style, wrap your head around that one.
But here's my fundamental problem: #NoEstimates, the movement, is something of a new agile cult, and I know it - but I'm WAY bought in. Estimates are a complete waste of time, and I'd rather simply avoid them entirely. If this is a religion, I'm a devout member, even though I don't really understand all the sacraments or whatever. So even though I didn't feel like this book really helped me come away with how to answer the "okay smart guy, how do I get predictability then?" question, I'm still way, way bought into it. Like I said, I think people need these dates/predictions far less often than they think they do, and in my opinion it's better to simply say "I don't know" than to outright lie, which is what estimating is.
I recommend everyone working in this space read this book, at the very least to absolve you of the notion that estimates are valuable and worthwhile things to produce. I loved most of the book, but I had to knock a star off because it ultimately DOES fail to provide the sort of "silver bullet" I'm looking for. I'll have to keep searching for the book/post/video/lecture/conference that actually helps me understand how to have predictability without estimating - I mean, I'm sure it's possible, using cycle times and throughputs and whatever. Right?
I go around various places of employment saying that estimates are a waste of time, and they are, but when stakeholders, product owners, and business people try to get me to explain how they're supposed to get a sense of when products will be delivered without them, I wave my hands and mutter something about how you can achieve greater predictability using real data and tracking your team's throughput, cycle time, and lead time. I know I've heard people say this, and it makes sense to me, but I don't really know the specifics, and I've had a hard time finding them. I seem to get away with this nonsense simply because, as it turns out, businesses don't really need predicability as much as they think they do. Marketing teams and salesmen tend to work better when they're selling or marketing what's already done, rather than what's going to be done "soon". And business stakeholders, for all the claims to the contrary, never actually seem to use the relative estimation/cost for various projects to actually decide what projects to do - it always seems like there's a "most important thing" that needs to be done no matter what. We have an industry where tons of people are convinced that they need to know the exact date features are going to be done, but my experience has shown me time and time again that they actually don't need that, most of the time.
Notice I keep saying "most" or "usually". There definitely ARE times when companies need to get a sense of when something's going to be done. I know estimating doesn't work for that purpose - I'm fully convinced and on board with that idea. But I've been long seeking an understanding of how to achieve it for those situations when it's needed, and I've mostly gotten away with simply not having to know. My hope going into this book, which presents itself as largely the complete guide to the #NoEstimates movement, was that it was going to answer this for me.
In the end, it still felt pretty hand-wavey, I don't think I came away with what I wanted. The book plays a lot of lipservice to the notion of predictability without estimates, but I felt like it largely does what I keep doing, which is kind of deal in vague terms and assure the audience that it's possible, without really making someone understand exactly how. The final two chapters deal most directly with this question - everything leading up to it is mostly about why estimates are worthless and how much better off you'd be without them. But the last two mostly attempt to deal with predictability and they do an admirable job, but still felt a tad vague. There's quite a bit about how one can measure progress and know if your project is going off the rails, which is helpful I guess, but not what I was looking for.
Agile books can be kind of "culty" in nature, like they come across like someone trying to convince you to join their religion. This one is no exception, a tone that I felt was exacerbated by the unfortunate decision to write much of the book as a hypothetical fictional novel. There are characters working jobs and trying to deal with problems, and of course there are super-smart characters who explain the principles of the #NoEstimates book, and of course they wind up being completely right. One particularly hilarious scene near the end has the big boss character excitedly telling the main character, Carmen, that he's never seen anyone work so well, and he demands that she and her #NoEstimates buddy (Herman, get it, "her man"?) come work directly for him. It's so dorky and ridiculous, kind of has the same vibe as an infomercial where someone can't open a soda bottle right until Billy Mays comes in and says he's got the perfect product that will solve all their problems. It reminded me a lot of how The Phoenix Project was written, but at least that book stayed consistently in "novel" mode, not switching back and forth. At one point, Herman actually gives Carmen a copy of the #NoEstimates book in which they are characters, Neverending Story style, wrap your head around that one.
But here's my fundamental problem: #NoEstimates, the movement, is something of a new agile cult, and I know it - but I'm WAY bought in. Estimates are a complete waste of time, and I'd rather simply avoid them entirely. If this is a religion, I'm a devout member, even though I don't really understand all the sacraments or whatever. So even though I didn't feel like this book really helped me come away with how to answer the "okay smart guy, how do I get predictability then?" question, I'm still way, way bought into it. Like I said, I think people need these dates/predictions far less often than they think they do, and in my opinion it's better to simply say "I don't know" than to outright lie, which is what estimating is.
I recommend everyone working in this space read this book, at the very least to absolve you of the notion that estimates are valuable and worthwhile things to produce. I loved most of the book, but I had to knock a star off because it ultimately DOES fail to provide the sort of "silver bullet" I'm looking for. I'll have to keep searching for the book/post/video/lecture/conference that actually helps me understand how to have predictability without estimating - I mean, I'm sure it's possible, using cycle times and throughputs and whatever. Right?
June 17, 2017
This book was a suggested read by a colleague. So, what can I say about it?
It's hard to dismiss that our industry has a knack for turning estimates into commitments. I assume that's partly because our brain just anchors to the first numbers it heard (see Kahnemans Thinking fast & slow). Probably that's just how we humans tick. Undesirable, but unfortunate reality.
I always tried to work my way around estimates with corridors and probabilities wherever I can, especially to communicate uncertainty and use forecasting techniques afterwards.
It has already helped me to survive unrealistic project expectations multiple times, but that should not be an excuse to look into alternatives that could do the job better. NoEstimates seems to be a good fit for that.
The core of the book is explained via a fictional business story that follows the typical "Heros Journey" template. A manager in trouble, seeks help by a mentor figure who teaches him new ways of thinking, which ultimately achieve the impossible, saving the project. If you know Goldratts "The Goal" or Kims "Phoenix Project". You get the idea. Of course everything is slightly exaggerated, in order to emphasize the message.
The central ideas behind NoEstimates are
- Getting story size variability down
- Using past data and story cycle time for forecasting
- Using corridors for forecasting (optimistic & pessimistic)
- Focussing on value and scope management for adjusting deliveries
All of those seem to fit nicely with what I've learned from Gene Kim (Devops Handbook, Phoenix Project), David J. Anderson (Kanban), Goldratt and other agile influencers. The book gave me enough additional insights, to be tempted to try out the techniques in the next milestone of my current project. Let's see how that goes.
All in all a quick, enjoyable read.
It's hard to dismiss that our industry has a knack for turning estimates into commitments. I assume that's partly because our brain just anchors to the first numbers it heard (see Kahnemans Thinking fast & slow). Probably that's just how we humans tick. Undesirable, but unfortunate reality.
I always tried to work my way around estimates with corridors and probabilities wherever I can, especially to communicate uncertainty and use forecasting techniques afterwards.
It has already helped me to survive unrealistic project expectations multiple times, but that should not be an excuse to look into alternatives that could do the job better. NoEstimates seems to be a good fit for that.
The core of the book is explained via a fictional business story that follows the typical "Heros Journey" template. A manager in trouble, seeks help by a mentor figure who teaches him new ways of thinking, which ultimately achieve the impossible, saving the project. If you know Goldratts "The Goal" or Kims "Phoenix Project". You get the idea. Of course everything is slightly exaggerated, in order to emphasize the message.
The central ideas behind NoEstimates are
- Getting story size variability down
- Using past data and story cycle time for forecasting
- Using corridors for forecasting (optimistic & pessimistic)
- Focussing on value and scope management for adjusting deliveries
All of those seem to fit nicely with what I've learned from Gene Kim (Devops Handbook, Phoenix Project), David J. Anderson (Kanban), Goldratt and other agile influencers. The book gave me enough additional insights, to be tempted to try out the techniques in the next milestone of my current project. Let's see how that goes.
All in all a quick, enjoyable read.
December 2, 2015
This is all about Agile development and #NoEstimates. The book spends about 60% just telling you that traditional software estimates are wrong and restates the same basic arguments many times. You'll see the same diagrams hauled out in the first chapters then again later, and again.
If you're interested in Agile development and dropping estimates this is an okay book. I have a feeling that there is better out there though.
If you're interested in Agile development and dropping estimates this is an okay book. I have a feeling that there is better out there though.
October 21, 2018
I was really looking forward to reading this book and well, now am I am slightly disappointed. As an agile practitioner I felt that there is not much new inside. The book also covers some agile practices in general which I would not expect of a book focussed on estimation. If you rally want to know what #NoEstimates is about chapter 5 should be enough. Also it lets you hope that there is some real advice on how to handle the bidding phase but then no advice is given. Still: It is well written and nice to read. I really enjoyed the style of mixing story telling and theory. That is pretty cool! If someone new to agile would ask me about a book dealing with estimates I would definitely recommend it but not to someone experienced.
December 23, 2020
Amazing
Really great book! Practical, realistic and mandatory read for any tech professional. Really great reading, easy to read, great theory behind it.
Really great book! Practical, realistic and mandatory read for any tech professional. Really great reading, easy to read, great theory behind it.
May 31, 2022
The fictional scenario with Carmen is a little cheesy, and there are some oversimplifications, but this is a five star book because if really boils estimation down to its most basic elements and challenges traditional project management ethos.
May 24, 2019
NoEstimates is a useful guide to the ideas of slicing work and using forecasting to determine the likely completion date of a project, based on the rate that the sliced work is completed. I found it to be approach in introducing these ideas. It gives a good break down of the various ways to slice work and how to do so and makes a compelling case for the power of slicing work combined with forecasting. I also like the simple rolling wave forecasting that is discussed. This is a simpler way to do forecasting than I've seen advocated before and therefore I think it's more approachable and easier to implement. If you're looking to get started with these ideas, this book is a good place to start.
So, if it's a good place to start, why three stars? The book has some serious flaws. First, the title is unnecessarily provocative. The book isn't really advocating for no estimates - it even points out they can be useful. It is advocating for a different way to measure project of a project, which is different.
The book also has a section that lays out why it says estimates don't work. And certainly what it says is true for the many ways estimates can fail, but it isn't a good faith argument as presented in the book. It has an underlying assumption that estimates are bad and doesn't try to grapple deeply with how they might help, so it comes off as disingenuous.
The book also sets things up using a standard business fable where we follow a fictional person as they learn about the items talked about in the book and put them to use. Like all business fables, this one is corny and contrived. Which is fine, except it also has serious flaws. The fable sets up a situation where the main character needs to have estimates to win a contract and implies instead they should use the the techniques presented in the book - but then somehow the character has magically won the contract for ways that are never explained and it's not explained how the techniques of the book could have helped.
The book could use clean up in areas such as this, but I do believe the underlying techniques are useful and if you're a skill practitioner who understand project management and systems you can likely put them into place to have better outcomes. For that I like this book, even with its flaws.
So, if it's a good place to start, why three stars? The book has some serious flaws. First, the title is unnecessarily provocative. The book isn't really advocating for no estimates - it even points out they can be useful. It is advocating for a different way to measure project of a project, which is different.
The book also has a section that lays out why it says estimates don't work. And certainly what it says is true for the many ways estimates can fail, but it isn't a good faith argument as presented in the book. It has an underlying assumption that estimates are bad and doesn't try to grapple deeply with how they might help, so it comes off as disingenuous.
The book also sets things up using a standard business fable where we follow a fictional person as they learn about the items talked about in the book and put them to use. Like all business fables, this one is corny and contrived. Which is fine, except it also has serious flaws. The fable sets up a situation where the main character needs to have estimates to win a contract and implies instead they should use the the techniques presented in the book - but then somehow the character has magically won the contract for ways that are never explained and it's not explained how the techniques of the book could have helped.
The book could use clean up in areas such as this, but I do believe the underlying techniques are useful and if you're a skill practitioner who understand project management and systems you can likely put them into place to have better outcomes. For that I like this book, even with its flaws.
June 1, 2017
Interesting but not a lot that is new for people who have read up on agile software development. The approach of telling a story of a project manager in a fictional company kept otherwise dry material interesting. But at the end of the day it felt light on guidance on how to actually implement "No estimates". It seems to boil down to continue writing stories until you get to the point where none of your stories are longer than a day. That is a drastic oversimplification but if someone who has read Kent Beck's books on XP and the planning sessions will see that as the major tweak to what Kent has been advocating for years.
The section on weening yourself off estimates by story points was the most practical but not earth shattering. The part about slicing stories was what I found the most helpful although it would be nice to see it presented more in a pattern format and perhaps with a few more examples.
The section on weening yourself off estimates by story points was the most practical but not earth shattering. The part about slicing stories was what I found the most helpful although it would be nice to see it presented more in a pattern format and perhaps with a few more examples.
March 2, 2018
This book describes the agile process but in a very painful method. It drags out concepts rather then explaining them briefly and concisely. Also the book needs an editor, it uses a lot of broken English, which further detracts from the books purpose.
March 29, 2019
This books makes you think about why we use estimates and challenges you to find alternatives. I like Vasco’s focus on Value. I do think that sometimes we work to achieve an agreed target (be it scope, cost or deadline) in the detriment of real customer value.
So, how can you minimize the amount of estimates? You should timebox features. Working within this boundary should encourage the team to come up with creative options. As for user stories, timeboxing them to 1 day is a great target, but I find it hard to achieve. There are some useful tips on how to do that, but it requires hard work to get there. It would be really interesting to see a realistic 1 month feature split into 1 day stories.
I enjoy business novels, but, somehow, the blend between business novel and regular textbook seemed a bit off in this book. I also think Carmen’s story jumped over an essential part: how did she come up with a bid for the project?
All in all, a good book, that challenges the way you think about estimates. I've posted a more detailed review on my blog.
So, how can you minimize the amount of estimates? You should timebox features. Working within this boundary should encourage the team to come up with creative options. As for user stories, timeboxing them to 1 day is a great target, but I find it hard to achieve. There are some useful tips on how to do that, but it requires hard work to get there. It would be really interesting to see a realistic 1 month feature split into 1 day stories.
I enjoy business novels, but, somehow, the blend between business novel and regular textbook seemed a bit off in this book. I also think Carmen’s story jumped over an essential part: how did she come up with a bid for the project?
All in all, a good book, that challenges the way you think about estimates. I've posted a more detailed review on my blog.
March 22, 2017
Although I liked the book and the fact that it was not too long, I could not help feel it fell a bit short of my initial expectation. Guess I was expecting a bit more of actionable recipe, and not so much insistence against a background of waterfall process, that everyone knows does not work. Maybe my expectations were not that realistic, but that being said, one has to be fair to the book and recognize that some of the advice and tactics here can deal with all that is broken about "agile" in many companies. I put "agile" in quotes because now that everyone claims to be agile and it has all the hallmarks of a faith-less religion, that is, empty liturgy and ceremony, there are a lot of anti-patterns and "un-agile" behaviors to be found in "agile" projects within companies that fancy themselves to be agile when they are lacking in varying degrees. In that common scenario is where I think it would be possible and useful to evangelize some parts of this #NoEstimates approach. All in all, I liked the general approach and it looks like it is a less wasteful way of forecasting (as opposed to estimating). I would still have to put it in practice, which is an altogether different battle.
August 1, 2023
Knowledge Level: Intermediate
Audience: Whoever wants to learn new ways to #NoEstimate the work.
Review: The author reviews the foundations and the reasons why estimation is a problem and a waste in software development. Also, how the story is told and the examples that he uses are really easy to read. So, you will learn about new concepts and also how to implement this approach in your teams.
Lessons Learned: Laws why estimations do not work: Hostader, Parkinson and Accidental Complication. Reasons why people estimate: Emotional sense to reduce stress, client security.
Audience: Whoever wants to learn new ways to #NoEstimate the work.
Review: The author reviews the foundations and the reasons why estimation is a problem and a waste in software development. Also, how the story is told and the examples that he uses are really easy to read. So, you will learn about new concepts and also how to implement this approach in your teams.
Lessons Learned: Laws why estimations do not work: Hostader, Parkinson and Accidental Complication. Reasons why people estimate: Emotional sense to reduce stress, client security.
August 20, 2021
Great idea but not the silver bullet
The idea the book promotes is good. However, it can be applied in a very limited context, e.g. when the company develops its own product. And even then it depends on the willingness of the management and key stakeholders. The idea is great, it impose you to look at estimates from a different perspective and enriches your knowledge. But it is quite difficult to apply it and might not worth the effort in the end if the context is not suitable.
The idea the book promotes is good. However, it can be applied in a very limited context, e.g. when the company develops its own product. And even then it depends on the willingness of the management and key stakeholders. The idea is great, it impose you to look at estimates from a different perspective and enriches your knowledge. But it is quite difficult to apply it and might not worth the effort in the end if the context is not suitable.
February 19, 2023
Let’s do this!
I’m sick and tired of dressing up “wild eyed guesses” as some form of scientific estimation that then morphs into a “locked in” commitment. Let’s finally let go of this unhealthy obsession with estimating large, complex, knowledge work and start working on improving our forecasting!
I’m sick and tired of dressing up “wild eyed guesses” as some form of scientific estimation that then morphs into a “locked in” commitment. Let’s finally let go of this unhealthy obsession with estimating large, complex, knowledge work and start working on improving our forecasting!
October 4, 2017
Some very good thoughts and ideas to try. I have the feeling that the one requirement for #NoEstimates is all about splitting your (INVEST) PBIs - so you might want to have a very good and full time Product Owner on your side :-)
February 18, 2019
El mensaje y las ideas son profundas y muy interesantes. Sin embargo, a la historia que ejemplifica el proceso el falta mucho más detalle y claridad en los momentos claves.
Por otra parte, podría estar bastante mejor escrito, parece más un borrador que un libro.
Por otra parte, podría estar bastante mejor escrito, parece más un borrador que un libro.
January 20, 2025
Light reading/easy to read and it helps a lot every new PM/PO in the software industry. The Book is presented as a story, which it pretty nice. I recommend it to anyone who is trying to build a product or want to use the ##noestimates idea.
October 23, 2022
Is it happening? Deliver early to be able to forecast using actuals and navigate the complexity of projects by taking informed decisions early.
Count the tickets. During each sprint.
Count the tickets. During each sprint.
December 29, 2020
The style could be improved. It's pretty chaotic and not very concise (like other reviewers already mentioned). Still, I think it is an important topic and this is the one book actually addressing it.
I rate this a five for the research and insights that went into the book.
I rate this a five for the research and insights that went into the book.
January 17, 2017
Very nice overview of the #noestimate way of doing things, easy to read, not too long, and pretty hands on. Now, will have to test implementation ...
March 12, 2019
Jo, bon. Jetzt, wo ich durch bin, mag ich das ganze tatsächlich, obwohl das ein langes, wirres Ding ist. Die letzten Kapitel sind sehr klar: Stories teilen, Fortschritt im Liefern von Stories messen, agil planen, alles klar, und alles nicht sooo neu.
Die Story, in die das ganze eingebettet ist: puh. Wäre eigentlich nicht nötig gewesen. Und das Problem (das mich am meisten interessiert hat), nämlich *zum Projektbeginn* zu schätzen, wird einfach nicht beantwortet (obwohl es als Problem aufgeworfen wird). Das fand ich suuuper frustrierend hier. (Vielleicht hätte ich den Untertitel noch mal genau lesen sollen: How to measure _project progress_... jo. ok.)
Also: nicht wirklich viel neues, aber durchaus launig und klar in den Kapiteln, in denen es drauf ankommt (in meinem Progress log sollte sich das ablesen lassen, wo). Die erste... Hälfte? Die ersten zwei Drittel? sind eigentlich Quatsch, der immer und immer wieder iteriert, warum konventionelle Planung Mist ist. Ja. Lange Lektüre für knappe Insights.
Die Story, in die das ganze eingebettet ist: puh. Wäre eigentlich nicht nötig gewesen. Und das Problem (das mich am meisten interessiert hat), nämlich *zum Projektbeginn* zu schätzen, wird einfach nicht beantwortet (obwohl es als Problem aufgeworfen wird). Das fand ich suuuper frustrierend hier. (Vielleicht hätte ich den Untertitel noch mal genau lesen sollen: How to measure _project progress_... jo. ok.)
Also: nicht wirklich viel neues, aber durchaus launig und klar in den Kapiteln, in denen es drauf ankommt (in meinem Progress log sollte sich das ablesen lassen, wo). Die erste... Hälfte? Die ersten zwei Drittel? sind eigentlich Quatsch, der immer und immer wieder iteriert, warum konventionelle Planung Mist ist. Ja. Lange Lektüre für knappe Insights.
Displaying 1 - 21 of 21 reviews