The question asked by #NoEstimates is in the form of a statement.
On the surface this statement sounds interesting until the second sentence. The MicroEconomics of writing software for money is based on estimating future outcomes thaty result from current day decisions. But let's pretend for a moment that Micro Econ is beyond consideration, this is never true, but let's pretend.
The next approach is to construct a small decision tree that can invert the question. Forget the exploring, since all business effort is a zero sum game, in that someone has to pay for everything we do. Exploring, coding, testing, installing training, even operating.
So let's start down the flow chart.
Is It Your Money?
In the crass world of capitalism, money talks, BS walks. While this may be abhorrent to some, it's the way the world works, and unless you've got your own bank, you're going to likely have to use other peoples money to produce software - either for yourself or for someone else. Self-funded start up? No problem, but even the best known names in software today went on to raise more money to move the firm forward. Then self-funded became venture funded, private equity funded, and then publicly funded.
If you're writing software for money, and it's not your money, those providing the money have - or should have if they're savvy investors - a vested interest in knowing how much will this cost. As well when will it be done and most importantly, what will be delivered during the work effort and at the end.
This requires estimating
Is There A Governance Policy Where You Work?
Governance of software development, either internal projects, external projects, or product development is a subset of corporate governance.
If you work at a place that has no corporate governance, then estimating is probably a waste.
If however, you work somewhere that does have a corporate governance process - no matter how simple - and this is likely the case when there is a non-trival amount of money at risk, then someone, somewhere in the building has an interest in knowing how much things will cost before you spend the money to do them or buy them.
This requres estimating
What's the Value at Risk for Your Project?
If the value at risk for a project is low - that is if you spend all the money and consume all the time and produce nothing and the management of your firm writes that off as a loss without much concern, then estimating probably doesn't add much value.
But if those providing you the money have an expectation that something of value will be returned and that something is needed for the business, then writing off the time and cost is not likely to be seen as favorable to you the provider.
We trusted you because you said "trust me" and you didn't show up on or before the planned time, at or below the planned budget, with the needed capabilities - and you didn't want to estimate those up front and keep us informed about your new and updated Estimate To Complete and Estimate At Complete so we could take corrective actions to help you out - then we're going to suggest you look for work somewhere else.
On low value projects estimating the probability of success, the probability of the cost of that success, the probability of completion date of that success is not likely of much value.
But using the Value At Risk paradigm - risk of loss of a specific asset (in this case the value produced by the project) is defined as a threshold loss value, such that the probability that the loss on the value from the project over the given time horizon exceeds some value.
As an aside the notion of slicing does not reduce the Value at Risk. Slicing is a estimating normalization process where the exposure to risk is reduced to same sized chucks. But the natural and event based variability of the work is still present in the chunks, and the probability of impacting the outcome of the project due to changes in demand, productivity, defects, rework, unfavorable and even un anticipated interactions between the produced chuncks needs to be accounted for in some estimating process. aAs well the sunk cost of breaking down the work into same sized chunks needs to be accounted.
In our space and defense world, there is the 44 Day Rule, where chunks of work are broken down into 44 days (2 financial months) with tangible deliverables. The agile community would consider this to long, but they don't work on National Asset billion dollar software intensive programs, so ignore that for the moment.
So yes, slicing is a good project management process. But using the definition of No Estimates in the opening, slicing is Estimating and done in every credible project management process, usually through the Work Breakdown Structure guide.
The Five Immutable Principles of Project Success
To increase the probability of project success, five immutable principles must be in place and have credible answers to their question. Each requires some form of an estimate, since the outcomes from these principles is in the future. No amount of slicing and dicing is going to produce a non-statistical or non-probabilistic outcome. All slicing does - as mentioned before - is reduce the variance of the work demand, not the work productivity, the variance in that work productivity process, the rework due to defects, or any unidentified dependencies between those work products that will create uncertainty and therefore create risk to showing up on time, on budget, and on specification.
The Devil Made Me Do It
Those of us seeking an evidence based discussion about the issues around estimating - and there are an endless supply of real issues with real solutions - have pushed back on using Dilbert cartons. But I just couldn't resist today carton.
When we need to make a decision between options - Microeconomics and opportunity costs - about some outcome in the future, we need an estimate of the cost and benefit of that choice. To suggest that decisions can be made without estimates has little merit in the real world of spending other peoples money.
