Here's a straightforward approach to estimating on agile projects. This is an example of the estimating profession found on many domains.
Principles, Practices, and Processes to Increase Probability of Success
Uncertainty is all around us. In the project world, uncertanty comes in two forms:
When we hear you can make decisions without estimates, this is physically not possible if you accept the fundamental principle that uncertanty is present on all projects. If there is no uncertanty - no aleatory or epistemic uncertainties - then there will be no probabilistic or statistical processes driving the project's outcomes. If that is the case, then decision have no probabilistic or statistical impact and whatever decision you make with the information you have is Deterministic.
So if you want to learn how and why estimating is needed to make decisions in the presence of uncertainty start here:
And then when you hear about a conjecture that decisions can be made without estimating you'll know better, and consider anyone making that conjecture as uninformed about how probabilistic and stochastic processes in the project world actually work - especially when spending other people's money.
Wise men profit more from fools than fools from wise men; for the wise men shun the mistakes of fools, but fool do not imitate the success of the wise - Cato the Elder
Any conjecture not based on testable principles, independent of personal opinion or anecdotes cannot stand up to the questioning of the wise.
We all know estimates are hard. But there are lots of hard things in the development of enterprise software. We wouldn't be whining about how hard it is to construct a good First Normal Form database schema, or bullet proof our cyber security front end from attack by the Chinese would we.
So why is estimating a topic that seems to be the whipping boy for software developers these days?
My first inclination is that estimating is not taught very well in the software arts. In engineering schools it is. Estimating is part of all engineering disciplines. One undergraduate and one graduate degree is in physics. Estimating is at the very heart of that discipline. A second graduate degree is in Systems Management - which is a combination of Systems Engineering and Managerial Finance - how to manage the technical processes of engineering programs with the principles of managerial finance, contract law, and probabilistic decision making.
This book comes with a spreadsheet for making the needed estimates to increase the probability of project success. It opens with an important quote that should be a poster on the wall of any shop spending other people's money
For which of you, intending to build a tower, sitteth not down first, and counteth the cost, whether he have sufficient to finish it? Lest haply, after he hath laid the foundation, and is not able to finish it, all the behold it begin to mock him, saying, This man began to build, and was not able to finish - Luke 14:28-30
The on-going discussions that Decisions can be made in the absence of estimates reminds me of this concept.
The conjecture that we can manage in the presence of uncertanty without estimating the impacts of our decisions, willfully ignores uncertainties in the present and future that will impact our outcomes, the external governance frameworks of managerial finance, probability and statistics of the processes under management, and regular governance processes and the decision rights of those governance frameworks.
Those decision rights by the way belong to those paying, rarely to those spending. So the decision to estimate or not estimate rarely belongs to the developers spending the business's money.
When the claim that #Noestimates critics say we're simply not being Opened Minded those advocates want us to accept that everything can be challenged, without any basis for that conjecture. If that were the case, those proforring #Noestimates fit right into those believing the pseudoscience of spending other people's money in the presence of uncertanty.
Thanks to Peter Kretzman for the link to the video.
Do not deny the classical approach, simply as a reaction, or you will have created another pattern and trapped yourself there.
— Bruce Lee
Any new innovative or revolutionary suggestion in the software development world, needs to be anchored on the established principles of how to manage the spend of other people's money. If it's your own money, spend as you please - no one cares.
But if you're spending other people's money to produce value in exchange for that money, those providing the money likely have a fiduciary obligation to know something to some level of confidence how much it will cost, when it will be done, and what they'll get for that that cost and time.
To suggest otherwise without a foundation of principles by which this new and innovative idea can be tested is selling snake oil to the uninformed. That approach has worked since the dawn of time - I have the solution to your unnamed ailment, just try this magic elixir and all will be better.
A primary learning process is research. This process is part of all science, engineering, management processes. Here's a starting point for learning how to estimate in the presence of uncertainty on agile projects.
This is the start of a literature search. Anyone making suggestions about making decisions in the presence uncertainty on agile project can start here for establishing the basis of any arguments of how and why that suggestion (conjecture possibly) is based on some set of principles. Not just anecdotal opinion.
The conjecture of #NoEstimates starts with the first Tweet
This conjectures - (there are) ... ways to make decisions with No Estimates ... is not founded on any principle of business management, microeconomics of decision making, or principles of probability and statistics. It's a fallacy.
Let's start with a simple approach to exploring for anything?
The Hypothesis might well be (if there was one) is ... can we make a decision in the presence of Uncertainty without making an estimate of the impact or outcome of that decision?
Let's put aside for the moment the missing principles of managerial finance, probabilistic decision making, microeconomics of decision making, Real Options, Bayesian decision networks, and other decision making processes used in modern business when spending other people's money. And ask a simple question...
What would be the evidence that we could make decisions in the presence of uncertanty without estimating the impacts and outcomes of those decisions?
The Myths of No Estimates and the busting of them is one purpose of this blog post. Here are some books and papers that can provide you with all the tools needed to learn to estimate in the presence of uncertainty. As well these books and papers can show you the snake oil salesman's fallacy that estimates are hard, are a waste, and aren't needed to make decisions in the presence of uncertainty.
Before listening to any conjecture that estimates aren't needed to make decisions in the presence of Uncertainty for software development, please read these books. Ask the person making those conjectures if they have read the books. Ask to see the marked up, sticky noted, tabbed copy of the book and the notes they made from the content. If not, walk away. They are not informed by the principles of spending other people's money.
Before we start, let's look with the notion of estimation. A Guess is uninformed by experience, skill, or data. An estimate is.
This is a simple book that will show how to estimate most everything. Start here. Read the entire book,. Learn how to think as an estimator.
Take that experience and start making estimates for software projects. Then and only then ask yourself why do people claim estimates are wrong, why is estimating hard. And you'll know the answer - they have no experience, they have no skill, they have no knowledge of how estimates can be made. Then you'll know. It's not that estimates that are smell of dysfunction, it's the unskilled, inexperienced, untrained, uninformed, unknowledge people making those unsubstantiated claims.
The next learning opportunity is to realize how much nonsense is floating around about not estimating. Here's the start for that understanding.
Managing a business profitably is always hard work. There are intense pressures, incomplete information about what’s happening in the marketplace and an army of consultants, advisors and others who come along with new ideas every day. Under these conditions, it isn’t surprising managers sometimes fall victim to hype about “miracle” cures for management challenges or simply adopt the “best practices” of other successful companies. The result is sometimes poor-quality decisions are made which end up wasting time and money which are badly needed elsewhere.
This book was handed out by Jeff Sutherland at the State of Agile conference as an indication of how agile has come to represent sloppy thinking on behalf of many of its advocates.
Here's a start of actually estimating in a credible manner, using tools available to anyone.
Start here to learn how simple it is to estimate things. Things you have never seen before. Things you have never done before Using Enrico Fermi’s theory of approximation.
The Fermi estimate, or order estimation is an estimation problem, teaches dimensional analysis, approximation, using a back-of-the-envelope calculation. The estimation technique, named after physicist Enrico Fermi, makes good approximate calculations with little or no actual data. Fermi problems typically involve making justified guesses about quantities and their variance or lower and upper bounds.
There is no excuse for not learning how to apply this approach to software development.
With the basic concept that estimates are straightforward, this book shows the economics of managing iterative development. Here estimates are part of planning and measuring progress.
The book speaks to assessing the technical viability of the system and the overall cost to achieve that technical viability.
These are core business processes for the success of any investment. And of course based on making decisions in the presence of uncertainty.
Now that we've established with the above sources there are conjectures without basis, nonsense statements like estimates are the smell of dysfunction without ever stating what the dysfunction is or what could possibly be causing the dysfunction, here's the place to start for serious estimating for software intensive systems.
A de minimis software project rarely benefits from estimates. Willfully bad management rarely benefits from learning how to estimate. If you customer has no real value at risk, of has no real concern about showing up on time to start accruing the business value in exchange for the cost to produce that value, then estimates are unlikely to be needed.
This is a seminal book on estimating. It provides the background and the practices needed to estimate Agile projects.
Mike shows why traditional processes fail and why agile approaches work. It's standard Feature Story breakdown but with the reasoning behind the processes.
This is the other seminal book on estimating.
Between these two books, you'll find need to know to make credible estimates for the development of software using Agile. The book claiming to show hwo to improve your project performance by 10X is so riddled full of holes, it's worthless. Don't waste your money on it. For the same price as that book, you can own both Mike's and Steve's books with field proven examples rather than fictitious anecdotes of bad management practices.
All project work is probabilistic. Some probabilities are event based, some are statistically based. Cost is always a driving consideration for how products are built, delivered, and sustained. A critical success factor for all software project work is cost and the associated schedule. Showing up on or near the needed time at or near the planned cost is simple business. Anyone saying cost is not important is not accountable for the business success of the development. Ignore them, they have no seat at the business management table.
If we come out late with the product we lose revenue needed to meet the business plan. If we spend more than planned, we erode profit and fail to meet the business plan.
Both these variables - cost and schedule - along the the needed technical performance to meet the expected acceptance of the product are probabilistic. Estimates are needed to inform the decision makers of the Probability of Success of the product.
Setting the date before the project is planned is the oldest root cause of project failure. Not having some sense of the scope of work, the effort needed to produce that scope, and the capacity for the development to produce the needed features for that scope is in the same class of failure modes.
Ignoring the need to have estimates of effort, time, and cost is not only bad project development it is bad business management.
Any suggestion that decisions can be made in the presence of project uncertanty without estimates willfully ignores these principles.
Large Scale Scrum (Less) is a framework for scaling Scrum to the enterprise. In the Less method, estimates are part of the Product Backlog Refinement. This process:
Agile at Scale is not the same as small agile teams. Governance drives processes in Agile at Scale. Governance can be ignored or even flaunted for small self contained teams. Organizing for responsiveness to external business drivers at scale means additional cost must be absorbed to govern in the presence of these externalities.
Agile at Scale also means dealing with architecture - technical architecture,process architecture, business architecture. Managing in the presence of all these uncertainties mandates we estimate the impact of these decisions. At scale without estimating the work processes turn into chaos.
This is one of the books that started it all. In Highsmith's books he calls out explicitly the need for estimating and some of the steps to do it.
Any enterprise agile development operating inside a corporate governance process requires knowing something about the outcomes of the work effort. The cost, the expected delivery date, and the expected business value produce for the cost. The time cost of money is a foundation of business decision making.
O those paying you have no need to know the time cost of money, how much it will cost, what the possible business value will be and when you might be done, then estimating is not needed.
Anyone suggesting you can't estimate must read this book to learn that conjecture is false - patently false - and learn how to actually make estimates of anything.
What I've found is when there are statements like all estimates are wrong, we can't estimate, estimates are misused is that those making those conjectures aren't actually informed how good estimates are made.
So instead of learning about estimates, they fall into the fallacy of #Noestimates.
This is another book that if the #Noestimates advocates had read on day one of their exploring they would have found the destination and stopped spouting all the nonsense about the smell of dysfunction.
Troy combines all of my favorite topics - mathematics of project management, monte carlo simulation - the actual monte carlo simulation, not the bogus sampling of past performance advocated by some No estimator's, and a logical, clear, and concise approach to making estimates in the presence of uncertanty to inform the decision makers when spending their money.
There are many fallacies in the software development world. Many of these fallacies go unchecked, unaddressed, unchallenged.
Here's where to start learning about the fallacies and their facts.
This is a similar issue with #Noestimates. This starts with the missing principle by which a decision can be made in the presence of uncertanty without estimating. Attempts to question these missing principles, results in further fallacies being put forward, along with labeling anyone probing further for the missing principle as aggressive, rude.
This is the basis of software estimating. It's been updated for agile.
Read it first, then read the agile updates. Learn how to use numbers, models, evidence, tools to estimate in the presence of uncertanty.
This is how non-trivial projects are managed. Anyone suggesting this is olde school hasn't done their homework to earn the position to be critical of the contents.
Spending other people's money involves governance of those decisions.
Governance by its definition is about decision rights
Who gets to the decide what is needed, when it is needed, how much it could cost (affordability). These decision rights are almost alwasy assigned to those paying for the outcomes.
The #NoEstimates advocates would have those decision rights transferred to those who spend, by suggesting estimates are a waste. Without stating who they are waste to. It is very unlikely they are a waste to those provided the funds that enable the #NoEstimates advocates to produce the software needed by those providing the funds.
It's illogical to invert this relationship between those paying and those spending.
Now we're into the heavy lifting of estimating. Yes estimating is forecasting. Forecasting is an integral part of the decision making activities of management. The organization establishes goals and objectives to produce outcomes from its decisions. The need to forecast (estimate future outcomes) is based on management's need to decrease its dependence on chance and become more predictive in dealing with the uncertainty it encounters.
We're now down to the core processes of making decisions in the presence of uncertainty. This is how business operates. Anyone conjecturing that decisions can be made in the presence of uncertanty without estimating - forecasting is estimating outcomes in the future - needs to stop and learn more.
Learn how business actually works. Not just assume that some who make an unsubstantiated statement about estimates are the smell of dysfunction has any credibility when spending other people's money. It's time to call BS on the notion of #NoEstmates.
Along with these books here's a collection of papers and articles showing how to estimate on agile development projects and how to avoid the Snake Oil Sales Pitch of #NoEstimates
So stop listening to the fallacy that estimates aren't needed to make decisions. And start learning to estimate and be a proper steward of your customers money.
Predictions are always difficult - especially about the future ― Niels Bohr
― Neandertal's Guide to Cost Estimating, Naval Aviation Systems
This is a quote often used by those conjecturing that estimating is a waste. The quote is true of course. Making predictions about the future is difficult. But that has nothing to do with the need for predictions and the estimates that support them. When making decisions in the presence of uncertainty about some outcome in the future - this is the basis of Microeconomics of decision making.
Guess: a conjecture based on little or no evidence
Estimate: a guess made by an expert
― Neandertal's Guide to Cost Estimating, Naval Aviation Systems
All project work is based on probabilities driven by statistical processes. All decisions made on projects for time, cost, and technical performance involve making decision in the presence of uncertanty. To attempt to make those decisions in the absence of estimating the impact of the decisions is foolhardy at best and doomed to failure at worst.
All successful projects adhere to these five immutable principles during the lifecycle of the design, development, deployment, and operation. These principles are independent of any project or program domain or context in that domain. They are also independent of any project management method or product development method, including agile.
They ask five questions that must have credible answers that establish the foundation for success. Without credible answers to these 5 questions, the project has little hope of success.
So if you hear some unsubstantiated conjecture like ... decisions can be made without estimating ask how any or all of the 5 immutable principles can be met?
The answer to this question starts with a simple principle based notion.
Can you make a non-trivial (not de minimis) decision in the presence of uncertainty?
The #Noestimates advocates didn’t start there. They started with “Estimates are a waste, stop doing them.” Those advocates also started with the notion that estimates are a waste for the developers. Not considereing those who pay their salary have a fiduciary obligation to know something about cash demands and profit resulting from the investment work in the future.
The size of the “value at risk” is also the starting point for estimates. If the project is small (de minimis) meaning if we over run significantly no one cares, then estimating is likely a waste as well. No matter the size of the project, from multi-million’s to smaller, it's actually determined by “value at risk,” and that is determine by those paying not by those consuming. So the fact we work on larger projects does not remove the principle of “value at risk.” Your client’s (internal or external) V@R may be much different than mine – but it’s not our money.
Next comes an original post from Woody – “you can make decisions with No Estimates.” If we are having a principled based conversation (which NE’er don’t) then that statement violates the principles of Microeconomics. Making decisions in the presence of uncertainty (and I’m assuming all projects of interest have uncertainty), than estimates are needed to make decisions. Those decisions are based in MicroEcon on the Opportunity Cost and the probability of making the best choice for the project involves assessing the probability outcome of those choices, estimating is required.
Real options are a similar process in IT based on estimating. Vasco stated long ago he was using RO along with Bayesian Decision Making. I suspect he was tossing around buzz words without knowing what they actually mean, since we never saw an example of how he used RO when asked to show one.
From the business side, the final principle is Managerial Finance. This is the basis of business management of its financial assets. The balance sheet is one place these are found. Since the future returns from the expenses of today and the “potential” expenses of the future are carried in that balance sheet, estimating is needed there as well for the financial well being of the firm.
These three principles - Value at Risk, MicroEconomics of Decision Making, and Managerial Finance appear to be ignored by the NE advocates when they start with the conjecture that “decisions can be made without estimates,” and continuing on with “estimates are a waste of developers time, they should be coding not estimating.”
It’s the view of the world, that as a developer “it’s all about me.” Never looking at their paycheck and asking where did the money come from. That’s a common process and one I did when I started my career 35 years ago as a FORTRAN developer for Missile Defense radar systems and our boss had us get out our paychecks (a paper check in those days) and look at the upper left hand corner. “That money doesn’t come from the Bank of America, El Segundo, Blvd, Redondo Beach, it comes from the US Air Force. You young pups need to stay on schedule and make this thing work as it says in the contract.”
In the end the NE conversation can be about the issues in estimating and there are many - Steve McConnell speaks to those. I work large federal acquisition programs – IT and embedded systems. And many times the “over target baseline” root cause is from “bad estimating.” But the Root Cause of those bad estimates is not corrected by Not Estimating as #Noestimates would have us believe.
As posted on this blog before and sourced from the Director of “Performance Assessment and Root Cause Analysis,” unanticipated growth in cost has 4 major sources:
1. Unrealistic performance expectations – that will cost more money.
2. Unrealistic cost and schedule estimates – the source of poor estimating.
3. Inadequate assessment of unmitigated risk exposure.
4. Unanticipated technical issues.
Research where I work some times (www.ida.org) has shown these are core to problems of cost overruns in nearly every domain from ERP to embedded software intensive systems. It is unlikely those 4 root causes are not universal.
So what’s #NoEstimates trying to fix? They don’t say except - “exploring” new ways.” In what governance frameworks are they exploring? They don’t say. They don’t actually say much of anything, just “estimates are waste, stop doing them and get back to coding.”
As my boss in 1978 reminded us newly minted physical Master’s degree'd coder, “it ain’t your money it’s the USAF’s money, act accordingly – we need an estimate of this thing you’re building can be used to find SS-9’s coming our way?” Since then I’ve never forgotten his words, “business (in that case TRW) needs to know how much, when, and what, if it’s going to stay in business.”
If your business is not subject to any external governance process, you’re free to spend your money as you please. But you’re not free to suggest your approach is applicable to those who are governed by external frameworks of spending and accountability for that spend, without a testable confirmation this idea doesn’t violate those governance principles.
Governance includes: Responsibility for a specific duty, task, or decision. Authority to influence behaviours. Communication of decisions. Empowerment to give individual's authority to act.
The governing of IT systems has two distinct components.
All businesses that operate inside governance frameworks, which address:
make use of estimates in their decision support processes. To suggest Not Estimating can be the basis of those decision making process is to willfully ignore these principles.
If it’s not your money, you don’t get to do as you please. If it’s your money, do as you please no one really cares. If it’s your customer’s money, confirm with them how they expect you to behave when spending that money.
For the great enemy of truth is very often not the lie ― deliberate, contrived, and dishonest ― but the myth ― persistent, persuasive, and unrealistic. Too often we hold fast to the clichés of our forebears. We subject all facts to a prefabricated set of interpretations. We enjoy the comfort of opinion without the discomfort of thought. ― John F. Kennedy
Take care when you hear any opinion not based on principles, for you are succumbing to those opinions produced by personal anecdotes - untested outside that personal experience - are the basis of myth. When those making those untested personal anecdotal conjectures vigorously criticize those asking for evidence, be more careful. For the smell comes from the propagation of the myth not the facts.
From Estimating Software Costs: Bringing Realism To Estimating, 2nd Edition.
Agile addresses 1, 2, 3, 4, 5, and 6 well.
So if these are the causes of project difficulties - and there may be others since this publication, what are the fixes?
There's a meme going around in some parts of agile that management is inhumane. This is an extreme view of course, likely informed by anecdotal experience with Bad Management, or worse lack of actual management experience.
Managing in the presence of Agile is not the same as managing in traditional domains. The platitude is Stewardship, but that has little actionable outcomes needed to move the work efforts along toward getting value delivered to customers in exchange for money and time.
One view of management in Agile can be informed by Governance of the work efforts. Here's a version of Governance, from "Agile Governance Theory: conceptual development,” Alexandre J. H. de O. Luna, Philippe Kruchten , and Hermano Moura.
The Project Breathalyzer provides question for the Program Manager to assess of the project is fit to be on the road. If the Program Manager cannot answer these questions about the current status, or answers in the negative , then the project is subject to a critical review.
This concept comes from the Software Program Managers Network, and the work of Norm Brown in 1997. The SPMN was a non profit organization, with funding canceled in 1002. but is now for Profit. The questions can from the Airlie Software Council of experts after the failure of the Airane 5 launch vehicle failure attributed to a Software Design Flaw.
There a popular notions in the agile development world that authors like Hayek and Taleb speak to how software development works. Let's look at one example. You Can’t Understand Agile Without Understanding Hayek. Let's look at Hayek's paper. "The Use of Knowledge in Society," F. A. Hayek, The American Economic Review, Vol. 35, No. 4, September 1945, pp. 519-530.
Let's look at the thesis of Hayek in light of software development and the decisions that must be made when spending other people's money in the presence of uncertainty. Below is from the paper, but download the paper and read the whole thesis. Hayek was a social scientist. He was not a program manager of engineered to order software intensive system of systems. His ideas have not held up well. Hayek and Modern Macroeconomics. So I'd suggest not spending your customers money before doing some more research.
What is the problem we wish to solve when we try to construct a rational economic order?
On certain familiar assumptions the answer is simple enough. If we possess all the relevant information, if we can start out from a given system of preferences and if we command complete knowledge of available means, the problem which remains is purely one of logic. That is, the answer to the question of what is the best use of the available means is implicit in our assumptions. The conditions which the solution of this optimum problem must satisfy have been fully worked out and can be stated best in mathematical form: put at their briefest, they are that the marginal rates of substitution between any two commodities or factors must be the same in all their different uses.
This, however, is emphatically not the economic problem which society faces. And the economic calculus which we have developed to solve this logical problem, though an important step toward the solution of the economic problem of society, does not yet provide an answer to it. The reason for this is that the "data" from which the economic calculus starts are never for the whole society "given" to a single mind which could work out the implications, and can never be so given.
The peculiar character of the problem of a rational economic order is determined precisely by the fact that the knowledge of the circumstances of which we must make use never exists in concentrated or integrated form, but solely as the dispersed bits of incomplete and frequently contradictory knowledge which all the separate individuals possess. The economic problem of society is thus not merely a problem of how to allocate "given" resources-if "given" is taken to mean given to a single mind which deliberately solves the problem set by these "data." It is rather a problem of how to secure the best use of resources known to any of the members of society, for ends whose relative importance only these individuals know. Or, to put it briefly, it is a problem of the utilization of knowledge not given to anyone in its totality.
First some questions:
Is there vague and unfolding knowledge, driven by externalities, of what the project should be accomplishing, with uncertain and variable funding? With members of the project team having differing views of the outcomes from those paying for the project?
If so, the project has already failed, the members of the project team are on a death march (Yourdan) and should start looking for work elsewhere, before it gets canceled.
So like the other misrepresentations of seminal works, the agile community adopts this attractive ideas with little or no consideration or understanding of their principles. And most of all it those principles are applicable to software development or if those principles are even applicable in today's understanding of who the world works. Macroeconomics is the dismal science - treat it as such when developing software.
So whenever there is some conjecture that someone outside the software development domain has a principle that can be applied to Agile, test that idea first before spending any time and money acting on it. Especially if that time and money is not yours.
There was a Twitter post mentioning Russell Ackoff YouTube about systems.
A system is never the sum of its parts, it's the product of their interactions.
This is a good start, but it needs to produce actionable outcomes, not just principles, but practices and processes. How do you define, design, represent, assess, analyze, and manage these interactions. The notion that systems are somehow unmanageable is fine in some domains. Finance, social, political. But in technical systems - engineered technical systems - the system has to work when commanded to do so. Much of Ackoff's principles are the basis of practices and processes that assure this happens.
I come to this systems domain from the Software Intensive System of Systems paradigm. This is where systems are designed, tested, verified, operated, maintained, enhanced, repaired, and replaced with other system. The touchy feely view of systems does not belong here. This is the domain of Systems Engineering, that many times is based on the principles of Ackoff and others like him.
When I hear about complex software systems and how difficult they are, and how undesirable they are, and all the other urban legends about complexity, complex, complicated and chaos, I get a smile. This is the world we work in. And the world where most people are users of those systems. Here's a start in learning how to manage in the presence of these systems.
Ask anyone mentioning complex, complexity, complicated, and chaos if they have a background in Systems Engineering? No, walk away, they don't know what they're talking about.