#NoEstimates

[@islomar]

I highly recommend Ron Jeffries' answer to this video: ronjeffries.com/articles/015-jul/mcconnell/

[@stevencmcconnell]

Isidro López And here's my answer to Ron Jeffries: www.construx.com/10x_Software_Development/17_Theses_on_Software_Estimation_(Expanded)/

[@islomar]

Steve McConnell Thank you very much for the link. I read it, as well as the answer to the answer, etc :-) ronjeffries.com/articles/015-aug/est-mcc-again/ Regardless of agreeing more or less with the arguments or experiences, I would like to thank you for sharing and trying to improve how things work, as well as for involving yourself in the debate.

[@MarcPoulin]

Ask Google to [define estimate]: "roughly calculate or judge the value, number, quantity, or extent of" Ask Google to [define promise]: "a declaration or assurance that one will do a particular thing or that a particular thing will happen" Make sure your customer knows the difference between an "estimate" and a "promise".

[@MarcPoulin]

***** Thanks for the link. After watching projects crash and burn for 25 years, I have my own opinions on this subject. Most developers, when you challenge their estimates, act like spineless jellyfish. It all boils down to the inability to answer one simple question: "How do you know?" For instance, if you say "requirements will take 4 weeks" then I can ask "How do you know?" "Because a key person we need to talk to is on vacation" is a sensible answer. "Well, maybe we can do it in 3" is a bullshit answer based on nothing but wishful thinking. Having an estimating worksheet or checklist would help a lot. Even a high level waterfall overview like Requirements = 4 weeks Design = 10 weeks Coding = 12 weeks Testing = 4 weeks Documentation = 2 weeks gives you some numbers that you can defend, or scale back if necessary. Have you ever seen Marcus Lemonis on television? He always talks about the 3 P's: People, Product, and Process. If you want better estimates you need a better estimating process.

[@stevencmcconnell]

Marc Poulin No question that improved estimation skills help on a variety of fronts. You can see my blog entry on the topic here: www.construx.com/10x_Software_Development/17_Theses_on_Software_Estimation_(Expanded)/

[@RiteshManTamrakar]

Thanks estimation guru to clarify the importance of estimation with such a wonderful example. Your estimation book is one of favorite book of mine. Agile community seems to be against estimation at first sight. But in my view they are not. They need to do estimation for their iteration planning. That is to know which stories to include and which to exclude they need estimates. But yes their way of getting estimate may be totally playful like playing planning poker :) I do feel people following or try to follow agile way of software project management gets lost at the beginning of a project cycle. Because agile manifesto does not clearly say anything about it. So the logic is we don't know how to do it so lets not do it. Which is totally wrong. In future videos, I will be grateful if you could shed some light on agile ways to get estimates in the beginning of a project cycle. Thank you. #NoEstimates

[@stevencmcconnell]

Ritesh Man Tamrakar In the beginning of the project cycle (before any iterations) whether the project will be agile or non-agile doesn't really affect estimation. I go into detail on that in my estimation book. I'll see what I can do about doing a video on that topic -- but no promises about how soon I'll get that out.

[@leyton2649]

Steve, this is awesome! Especially love the kitchen remodeling example to highlight the difference between the explicit manifesto statement and its intent. :-) LOL

[@WilliamDye-willdye]

Some tasks are like kitchen remodeling, but others are like the Lewis and Clark expedition. It was a very expensive endeavour, so President Jefferson wanted estimates of cost, how long it would take, and included the goal of finding a freshwater route to the Pacific. Detailed plans were made based on known factors such as how far a canoe could be paddled per day. Today we look back and call it a great success, but in terms of meeting original estimates they failed miserably. Subjected to management techniques that I've seen first-hand, they would have been "coached" (disciplined) for their failure to meet estimates, not lauded for their success. I agree with Mr. McConnell that a good solution to our problems is to simply get better at estimating. At least in my own limited experience, however, the core problem is less about estimation per se, and more about how projects are managed. I fear that some managers will hear "don't give up on estimates, just get better at estimating", and translate it as "put more pressure on programmers to get better at estimates by punishing them more when they fail". Improvements to the estimation process should include better knowledge by managers of when to ask for a higher-precision estimate (small variations to well-known tasks), and when to settle for lower-precision estimates (exploration) and prepare in advance for the consequences. Mind you, I'm not in favor of zero management. Don't give up on management, just get better at it. :-)

[@stevencmcconnell]

William Dye Great point! I totally agree that some projects are like kitchen remodeling and some are like L&C expedition. Software professionals should develop skills to be successful at both kinds of projects. There's no reason to treat that as an either/or choice.

[@islomar]

Always from a highly deep respect for Steve McConnell, some comments about this video: * About the claim to the first point: IMHO, doing something JUST because your customer asks you to do it, is far away from my concept of professionalism (which is, obviously, very personal). Sometimes you need to say NO, explaining why and giving alternatives. For those who think that this is not a "realistic" approach, I can assure you that some companies work like that and it's possible. It just depends on how you want to work (which is always respectable). In that sense, I agree much more with the fourth item of the Software Craftsmanship Manifesto ("Not only customer collaboration, but also productive partnership"): manifesto.softwarecraftsmanship.org/ * The claim to the second point reminds me a lot what I was told at the beginning of my career as a software developer, when I worked in a waterfall project: if the analysis and design didn't prove to be right after several months, it just meant that we had not done it correctly and we needed to improve our skills. I'm sorry, but NO. That's not the right conclusion. That "if it doesn't work, it's just because you did it wrong" is a manipulation of the "reality". Some things don't work because they are plain wrong from the very basis. * The claims to the third and fourth point are basically: "just do it better and they will be fixed". Too simplistic, from my point of view. * The comparison with the kitchen remodel is funny but... well, not comparable for too many reasons (or maybe it is comparable, and so contractors shouldn't work like that either ;-) ). * The enumeration of all the reasons why business need estimates: well, some of the points make me think that it's the basis business model what I don't agree with :-) The danger with giving the business "the estimates they want", is that most of business aren't mature enough to understand the difference between an estimation and a prediction/commitment (which is partially our responsibility, probably we haven't done enough effort to explain it) Having said that, I'm not totally against giving estimates, but only with some conditions: 1. I feel comfortable doing it. 2. I am self-conscious that I will probably fail on it. 3. Explaining the person who asked me for it, that it is neither a prediction nor a commitment, and things might be very different in the end. I guess that TRUST and TRANSPARENCY are key concepts here, as well as using a framework like Scrum for having fast feedback and a clear vision about how things are going.

[@SergioPelin]

Isidro, you're 150% right!!!

[@therealdecross]

Isidro López I don't think saying "I don't believe in estimates. This is a very personal POV backed up by the belief that no one knows how to estimate properly, so I am not giving you what you are asking for, because it is stupid." is professional at all. Doctors give estimates, lawyers give estimates, writers give estimates, engineers give estimates. Are we so special, really?

[@GlenAlleman]

Luiz Esmiralha we are not special. Making decision about the future in the presence of uncertainty requires making an estimate. NE has yet to show how to make that decision w/o an estimate.

[@therealdecross]

Glen Alleman right on the nail.

[@islomar]

Luiz Esmiralha First of all, I never, ever use the word "stupid", not even with people with whom I disagree. And not even in a figurative way ;-) On the other hand, I didn't say that I don't believe in estimates. Indeed, I said that, when some conditions are met, I DO estimate and it's ok. Comparing is never good. I don't like it, it's too simplistic. But, ok, let's do it :-) * Here, it is said: "we need to give estimates to the customers, because they need it and they are asking us for it". Do you think that a doctor would do something just because "I really need it, I ask him for it and I'm paying for it"? They have something called "hippocratic oath", related with "ethics". Something that we, software development "workers", don't have as a community. * Another example: if you ask a doctor if you will be finally healed from a cancer, do you think he would give you a closed answer with a closed date? As a patient, I understand very well that he would give me PROBABILITIES based in other people cases. No promises at all (though a probability can be 90%). We are not special, I absolutely agree with that. But each profession has to be conscious about their characteristics, the context of their work, and how different or similar it is to other tasks. Once again: one of the basis problems here, is that estimates are usually considered promises. That's my experience (which doesn't mean that it has to be the Truth), and also the experience of everybody I have ever known. That's why, unless there is a high maturity and highly clear communication and trust, "estimations" are so dangerous. Anyway, someone much more experienced and intelligent than me, Ron Jeffries, wrote a post answering Steve McConnell, explaining and clarifying really well (from my point of view) what #NoEstimates really aims to be. I highly recommend reading it: ronjeffries.com/articles/015-jul/mcconnell/

"He'd like new Cabinets, Counter Tops, Flooring, Sink & Faucet, and Appliances, and our customer's budget is $300. Can we do that?... Okay. Just do it."

[@imsergiohere]

6:50, how does the customer collaborated? Collaboration is from both sides. They are only giving a requirement, not affording that there are a lot of factors that may the project be estimaded wrongly. There are a lot of comparisions of why we shouldn't compare SW DEV with other jobs like building or this, because workers or painters complexity is most-time the same. But in SW we have libraries, languages, OS, (those will break, change API...) new bussiness challenges, Computer Science problem-solution vision, deployments, rollbacks, databases, performance, security, roles ... Even if every house could have their hiden complexity, they are always houses with 2-3 rooms. Now, tell them to build the new architecture-modern unique style of house and then ask for estimates. They will sweat. This is what usually hapens to agile practicioners, usually business are different. One day we are talking about flights and air control, other we are talking about food-delivery. And we want it now and cheap. I understand that even my explanation, the customer would feel uncomfortable but, we have to spot where's the problem actually.

[@AttilaButurla]

This is a great video. It should be noted #NoEstimates says that if a customer is asking for estimates that you should provide them with estimates.

[@GlenAlleman]

Attila Buturla read smartorg.com/wp-content/uploads/2011/08/Decision-Analysis-for-the-Professional.pdf is see how business makes decision. Now suggest how those decisions can be made without estimating.

[@GlenAlleman]

How business makes decisions smartorg.com/wp-content/uploads/2011/08/Decision-Analysis-for-the-Professional.pdf Instead of assumes business needs to ask for estimates, assume that business can't run without estimates, and it's their choice to NOT estimate, not those spending the money.

[@tiborbeck4736]

I disagree. Read tiborbeck.wordpress.com/2014/09/23/estimates/ why.