The notion of #NoEstimates ignores a critical concept (one of many)...
Promises, schedules, and estimates are important instruments in a well-run business. You must make promises - don't lean on the often-used phrase: "I can't estimate it because it depends on many uncertain factors.
This quote is from William Swanson's Unwritten Rules of Management (Swanson is the former CEO of Raytheon). His book is a near copy of The Unwritten Laws of Engineering. W. J. King, 1944. Borrwoing those ideas without attribution got him in BIG trouble!
But in the SW Dev world, developers don't get to decide when spending other peoples money. The customer does. If they're spending your own money, no one really cares what they do with it.
If there is a suggestion from the #NE advocates on how to do estimates better, it should have a measurable business value. By measureable it doesn't mean we're exploring using the customers money or I'm always looking for dysfuntion - never saying what dysfuntions have been found.
There is always room for improvement in any work process. That is a tautology. But those improvement suggestions need to have a disciplined approach. They need to have an ROI. They need to have some Measure of Effectiveness - "customer satisfaction" is a Measure of Effectiveness.
Before proceeding with any discussion around estimating anything, I'd suggest a read of How To Think About Statiistics, 6th Edition, John L. Phillips, Freeman, 2013. Here the reader will learn that many of the statements made on #NoEstimates are not only wrong and uninformed, they are not even logical.
Things like you can't predict on software projects, is of course complete nonsense. It's done everyday. Things like we don't need to know the cost, just as much nonsense, since ROI has cost in the denominator, so you get a divide by zero error when doing the ROI calculation. Etc. Etc. Etc.
Time to call BS on the way #NoEstimates is being portrayed by some. Others have good ideas. Time box scheduling, backlog management, small - same sized - chunks of work with steady productivity, fed by the same small chunks from the backlog. This is logical. Doesn't address at all the need to know how much to budget for that work though by the people giving you money to produce the value, but that's another conversation.
