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
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
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?
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.
Our daughter is an elementary school teacher in Austin - and a Graduate student at UT Austin in the Board Certified Behavioral Analyst program. When I hear about some corrective action to an unnamed cause - not the symptom but the cause - like estimates are the smell of dysfunction, I think of a chart she has hanging in her room for her students, where they are learning critical thinking skills they will need in life.
So in the end if 2nd graders in Austin Texas can figure this out, why can't adults tasked with spending other people's money do this as well?
Perhaps Mr. Elliott could provide answers to these questions to our clients, when he suggests that estimates are worthless.
Instead of just delivering demos, how about delivering capabilities in an order needed to earn the value in exchange for the cost to produce that value? And do this according the plan described in the Product Roadmap, using the Cadence or Capability Release Plan? That way those paying for the production of value can have confidence they'll be getting their investment returned as needed to fulfill the business plan or accomplish the mission?
A recent twitter post started out with I predict my train will depart from platform 12 in 10 minutes: degree of predictability correlates with length of time I then asked and what is the evidence on which you base this estimated time of departure? I got back I didn't estimate departure, there is a timetable there, but Trains someone's run late & platform sometimes changes.
But in fact - mathematical fact - there was an estimate made. The trains are sometimes late informs the probability of leaving as planned
With the time table there is a target departure time, but unless you're riding the S-Ban from our Eching office to downtown Munich office, as I did for a year - the train departure is approximate. The S-Ban departure was "exactly" 8:04, first because it was Germany 1986, and second because the train was parked at the end of the line.
But no matter if the train is departing Eching station or a London station, or the Station in Lower Downtown Denver, "margin" is needed for both you the traveler and the train. This "margin" protects the Aleatory uncertainties that exist in ALL systems, even trivial systems. The airlines bake this into their schedules. I fly a lot. Many times we arrive early to no gate and have to wait. Rarely in good weather do we arrive late.
When we do arive late on Southwest Airlines, it's most always due to some Event based uncertainty. These are Epistemic uncertainties.
Both Aleatory and Epistemic uncertainties exist on projects and in real life. They are part of life all life.
Aleatory uncertainty is handled by margin. Epistemic uncertainty is handled with by down processes. Here's the details on managing in the presence of uncertainty. Uncertainties that are ALWAYS present. Uncertainties that ALWAYS require making an estimate of the probability of occurrence (Epistemic), range of variance (Aleatory), and probability of outcomes, and probability of the impact from those outcomes, and the probability of the residual uncertainty and associated risk when the initiating uncertainty is not 100% removed.
In other word, you can't make a decision in the presence of uncertainty without estimating all those variables - occurrence, outcome, impact, residual uncertainty. That's the way life - and projects work. Saying decisions can be made without estimating - #Noestimates - doesn't change the way nature and projects work, no matter how many times it is said. Especially how many times it is said without evidence of how to actually make those decisions without estimates.
Had a Twitter conversation today about deadlines and how to remove the stigma of a deadline and replace it with a more Politically Correct term. Like most Twitter conversations there is a kernel of truth in there somewhere that sparks a thought that turns into a Blog post. This was one of those.
In our Software Intensive System of Systems world, we are not 5 people sitting around the table with the customer building a warehouse management application for our privately help gadget making company. We work on large scale, mission critical systems - critical to the Enterprise or critical to the sovereign funding an Enterprise application, building a weapon, or accomplishing something that'll you'll read about in the paper. This is not to say those 5 developers sitting around the table with the Product Owner and the Scrum Master are not working on vitally important code. But Agile at Scale has a different paradigm than Agile at the Table.
One critical paradigm is the Product Roadmap and the resulting Release Plan. Release Plans come in two flavors.
Capability Releases have variable delivery dates for the capabilities - Cadence Releases have fixed delivery dates for the Capabilities
What's the Schedule For Getting the Products in the Product Release Plan?
Customers have a fiduciary obligation to have some sense of when the work they are paying for will be completed, how much it will cost and some assurance that what they are paying for will deliver the needed capabilities in exchange for that investment.
This is the basis of managerial finance and decision making in the presence of uncertainty - Microeconomics of Decision Making.
In both the Cadence and Capabilities Release Plan, the Product Roadmap speaks to what is planned to be released. The Release Plan is built during the Release Management process which plans, manages, and governs release of products resulting from the development effort. The owners of this governance process has the decision rights to determine what gets released.
The Capabilities are laid out Cadence Releases in the chart below. The Sprints containing the Stories that implement the Features that produce the Capabilities that occur on regular periods of performance.
With the Product Backlog, the Product Roadmap, and the Cadence or Capabilities release plan, we've got all we need to define what Done looks like.
By Done it means what Capabilities are needed to fulfill the business case or accomplish the mission delivered by the project. It doesn't mean requirements, it doesn't mean tasks, it doesn't mean the details of the work. But if you don't know what Done looks like in units of measure meaningful to the decision makers the only other measure is we ran out of time and money. This has been shown through extensive research to be in the Top 5 of Root Causes of Project failure. The other 4 include Bad Estimates for the cost and schedule to reach Done.
And by the way, the term Done is NOT the Definition of Done in Scrum. That's a term used to state what processes have been applied to the work - a list of criteria which must be met before a product increment . It's a developers definition of Done. A critical activity for sure, but still far removed from the Mission Accomplished Definition of Done. Both are needed, both are Critical Success Factors, but at the business management level, developers DOD, is just the start of recognizing that the project has fulfilled the business case or accomplished the mission.
Done Done and Contrastive Reduplication
While the VP of Program Management at a nuclear weapons cleanup program, one of the Project Managers working for me introduced an idea. When we talked about being Done he chimed in and said, no Glen that's not the question. We need to know when we are Done Done. The use of the term Done Done Contrastive focus reduplication and is very useful in the Agile world, where there the notion of Definition of Done that is NOT based on a formal technical specification, but on customer approval that the results will deliver the needed Capabilities.
Jurgen Appelo used the double pendulum on page 42 of his Management 3.0 book to explain the differences between simple, complicated, ordered, complex, and chaotic. He defines the term Chaotic as “very unpredictable.” Like many of Jurgen’s definitions, they are localized to suit the needs of the story line.
There is no universally excepted definition of chaos. But almost everyone would agree on the following ingredients:
Chaos is an aperiodic long-term behavior in a deterministic system that exhibits sensitive dependence on initial conditions.
In this context, the phrase aperiodic long-term behavior means that the motion does not settle down to a fixed point or a periodic orbit. Since the double pendulum loses energy to the environment, after some time the motion does become periodic and it eventually stops at a stationary fixed point. In this sense it is only the theoretical double pendulum without energy losses that would really be a chaotic system.
Please read that last sentence again. It is critical. As well the “sensitivity” to initial conditions is a parametric measure in itself. The starting angle of the pendulum is one parameter. Low starting angles result in different “sensitivities” than larger starting angles. This is an exercise for students in the introductory classical mechanics class as an undergraduate in Physics.
A deterministic system means that the system has no random or noisy inputs. The irregular behavior is intrinsic and arises from the system’s non-linearity rather than from any noisy driving forces.
Please read this last sentence again. It is critical to understanding the definitions needed to describe the behavior of the double pendulum.
Sensitive dependence to initial conditions means that nearby trajectories separate exponentially fast, i.e. two identical systems set up together in the same way such that the initial conditions are arbitrarily close together will have their trajectories rapidly diverge. To make this more concrete, consider two trajectories, where at some time t the trajectories are at position x(t) and x(t) + d(t), then the statement of chaos would be that d(t) ~ d(0) exp [ L t] , where the average value of L is called the Lyapunov exponent, and if this is positive it means that the two trajectories are quickly separating from each other.
Why is this an issue in the management of agile software projects? Good question?
Management 3.0 - and now #NoEstimates advocates - proffers a solution to a complex problem of managing the development of software. The book, while providing advice to managers on how to manage, mixes pseudo-scientific references and concepts – like the double pendulum – in support of essentially sound staffing and personnel management. I came to the book, through Jurgen’s himself. But on first reading I ran straight into what seemed like a collection of ideas that have no actual basis in fact. The double pendulum is just an example of this approach.
So here's the fix for these conjectures. There's a paper "Distilling Free-Form Natural Laws from Experimental Data," Michael Schmidt and Hod Lipson, Science, Vol. 324 3 April 2009, showing not only the equations of motion for the double pendulum, but a machine that can deduce these equations by observing the double pendulum in motion.
Here’s the core problem. When we can't get the analogies right, what else isn’t right in the foundational principles proposed by those suggesting we can't operate in the presence of uncertainty? If those analogies miss the mark on the underlying principles of these analogies, are the other suggested approached equally flawed? Maybe, maybe not, but for someone like me, trained and experienced in the application of approaches to solving complex problems, many of the fundamental approaches used in the book are simply muddled thinking. It’s too bad. A good editor, with experience in the analogies Jurgen uses could have established that they are just notional, analogies, or possible just anecdotal experiences. Instead Jurgen states them as the foundations of the principles of Management 3.0. In the same way the original posters of #NoEstimates state their case that decisions CAN be made without estimating, when in fact that violates microeconomics, managerial finance, and several other principles.
And of course, this plays directly into the #NoEstimates conjectures, based on even less credibility than Jurgen's management processes - minus the illformed analogies.
There is no principle stated to date by the advocates of #NoEstimates that supports the conjecture that decisions can be made in the presence of uncertainty with estimating the impact on the business of those decisions.
Plans are nothing, Planning is Everything- General Dwight D. Eisenhower
While Eisenhower didn't say this quote as an original. That was "No Battle Plan Survives Contact With the Enemy" - General Helmuth von Moltke.
The quote is used - and misused - by most agilest and in the Agile Manifesto. Of course those authors probably didn't have access to the original context. Eisenhower was speaking to the National Defense Executive Reserve Conference in Washington D.C. on November 14, 1957. The quote in full context reads:
I tell this story to illustrate the truth of the statement I heard long ago in the Army: Plans are worthless, but planning is everything. There is a very great distinction because when you are planning for an emergency you must start with this one thing: the very definition of “emergency” is that it is unexpected, therefore it is not going to happen the way you are planning.
We know this for sure - any forecast about the future is wrong. All forecasts are predictions about the future, so the forecast has to be wrong. Is the forecast worthless? Of Course not. But all Plans and Forecasts must have the ability to adapt to the emerging situation
The plan establishes a goal and provides an outline and a starting point for allocating resources, delivering outcomes in the needed order, determining conflicts and dependencies. Anyone making plans and forecasting the outcome from those Plans must understand the limitations of making decisions in the presence of uncertainty.
When the conditions change - as they must in the presence of uncertainty - who best can respond quickly and make adjustment the plan or forecast? Of course the people who built the plan!
Planning is Strategy Making. All strategies are hypotheses. Hypotheses must be tested with experiments. Experiments provide actual data to adjust the Hypothesis, which in turn adjusts the Strategies, represented in the plan.
So when we hear from the Agilest who quote the Agile Manifesto - Responding to Change over Following the Plan to mean we don't need a plan, because we're not going it anyway. They have made a fatal error in understanding.
To respond to change - as the manifesto says - means we have to have a Plan to know what we are responding it and how our responses will impact to goal of the project - which the user has stated (or should have stated as the Needed Capabilities). Otherwise everything is a change and the Product Backlog is just a pile of ideas - not a map of anticipated value to be delivered to the customer.
And of course - since the future is always uncertain, when we encounter the naturally occurring changes and the event based changes, we'll need to estimate to impact of those change on our Plan to meet the Goals for the project. And we'll need to estimate the impacts of the alternative choices to get back on the path toward our Goal.
Without making those estimates we're in an Open Loop Control System being whipped around by externalities , creating extra work, building technical debt, and increasing Work In Progress, and generally mismanaging the project.
Risk Management is How Adults Manage Projects - Tim Lister (IBM)
It can't be stated too often - either manage risk, or risk will manage you. Projects without risk management are late and over budget before they start. All project work is uncertain. Uncertainties are either reducible or irreducible. Reducible uncertainties can have specific actions to reduce to risks that result from the uncertainties. Irreducible uncertainties can have no specific actions, but must have margin to protect from the resulting risk.
Here's a paper describing how to manage an IT project with Risk Management.
... and as always - you can't manage risk, without making estimates of the probability of occurrence, probability of the impact from the risk, and for the irreducible uncertainties, the statistical processes driving the naturally occurring variance and the needed cost, schedule, and technical margin to protect to project's success from the uncertainties.
So if you're not using Risk Management and associated estimates, you're not managing the project as a adult.
The conjecture that we can make decisions in the presence of uncertainty without estimating the impacts of those decisions is without any principles that can be tested beyond personal anecdotes of I know people who spend other peoples money without providing estimates
Here's some reading to help understand why its bunk and how to learn to estimate in the presence of uncertainty in order to make better decisions.
This list starts with the earliest posts, beginning in 2009.
So when you hear about all the posts about #NoEstimates, take a look here to see if those posts provide any actionable outcomes that can be put to the test on actual projects - other than Slicing.
There is a common misinformed conjecture that large programs are managed just like a military operation. Both these concepts are wrong - dead wrong.
Here's a great briefing on this topic. You'll find there are topics about managing in the presence of uncertainty and the need to make estimates to assess the outcomes of your decisions.
Scrum is an Empirical software development management system
Although the Scrum Guide does not contain that term. Emperical processes by definition contain these elements:
These attributes did not start with Scrum, they are control system terms
Let's look at a non-software development empirical process control system
We want to design a process control for a hot water system for an industrial process. We have chosen two simple attributes - the level of the hot water feed tank - so we need a pumping system to keep the water level at the desired level. This in turn keeps the head pressure at the desired level for the users of the hot water. The temperature of the water when it arrives at the point of need. This type of closed loop control system is seen on many towns across the US, where Water Towers are used to produce the water pressure at the desired - usually 65 PSI - for the residents, by pumping the ground water to a height of the tank then releasing it on demand for the residents. Let's ignore the temperature aspects for the moment and just focus on keeping the tank full
We would like to model this system before we build it to avoid spending our customers money more than once. There are two simple ways of modeling the system.
The empirical model looks like this.
The water tank level is held constant by equalizing the water flow out and the water flow in. The flow out is changed nm a step wise manner and the level response is observed. A series of step wise changes are made and the response is observed. As the level changes - and acts like an integrating or ramp process - the average time delay and gain (in percent of level change per percent of water added) can be calculated to produce.
The analytical model looks like this.
What Does All This Mean for Sofware Estimating?
Managing software development is a Control System. We have a steering target - the tank level - in the form of needed capabilities, a planned delivery date, and a planned budget for the delivery of the needed capabilities at the needed time. If you have no planned budget, planned delivery date, or needed capabilities, you have an open loop control system - just keep spending till the money runs out or the customer tells you to stop. No need for a control system, no need to estimate, just code, someone else will look after the business side of your spending.
But let's also pretend for a moment that those providing the money have a fiduciary obligation to know something about how much it will cost to produce the needed capabilities (Value) and some need to know when those Capabilities will be ready for use, so they can start earning back their investment. This is standard Business 101 time phased Return on Investment. And let's pretend that the development of the software is not a deterministic system. That there are uncertainties in the system. Uncertainties from lots of sources, some you can control and some you can't.
Then what does a model of the control system look like? It can be empirical or analytical, or a combination of both.
It needs to be both for some simple reasons:
This of course is NEVER true in software development. If it were true developing software would be a mechanical process, done by machines. And it's not.
So while empirical data is useful, it's not the only thing needed to manage the project so you can show up at or near the time needed, when at or near the planned cost, and at or near the needed capabilities, so the business can fulfill its business model.
An analytical model is also needed, fed by empirical data.
Both are needed, full understanding that the future is never like the past - and analytical modeling must include the probabilistic aspects of the future - possibly derived from the past.
So when we hear - Scrum is an empirical process, (it is true) but think a bit more on what that means. When we hear #NoEstimates is an empirical process - which it's not because it's open loop, with no steering target (a set point in the control systems paradigm), and no consideration for the probabilistic aspects of writing code for money - someone else's money.
Ask a simple question - if you use the word empirical - do you have a notion of the control system model in which that empirical data is used? Or is the term empirical data just a word used without any meaning to the problem at had.
That problem at hand is how to forecast (estimate in the future) in the presence of uncertainty about things meaningful to the business paying for the software. This means cost, schedule, and technical outcomes.
How can that be done using empirical data and NOT call that estimating?
For some software focused background of control systems see this simple starting point
There is a popular notion is some circles of Scrum, that Sprints need to produce shippable software at the end of every Sprint. This of course depends as always on the domain.
How about ...
So yes, Sprints MUST produce tangible measurable outcomes that can be verified to be compliant with the needs of the customer and other stockholders,m including external stockholders, but
...but your governance framework should not stop you from building a potentially shippable product increment each sprint
needs a VERY broad definition of Potentially Shippable Product, a specific domain and the governance framework for that domain. Only then can that notion have any chance of being a useful process goal.
And of course all this planning, executing, testing, V&V, performance assessment, etc. etc. etc. needs to have estimates for the probability of arriving on planned completion date, at the planned cost, and the needed capabilities fully functioning as required in exchange for the money being paid for the resulting value.
Let's start with the simple idea that Requirements are required items from the project. Capabilities that the project must produce in order for it to earn back its cost to produce. User Stories are a narrative of what the User would like the resulting software to do in some way. It's a story of how a problem or a need could be solved. It's not a requirement that it solve it in some specific manner. Requirements state the specific outcome.
In the software development world...
Capabilities describe how the produced system will enable the value to be delivered as planned. Requirements describe how the Capabilities will be delivered. Stories are narrative as to how those Capabilities will be used and provide the raw data as to how the Requirements will emerge.
Now For The Punch Line
Using User Stories to predict project performance is also NOT a role of User Stories. User Stories are vague narratives of a customer's desire. They can change, and likely will change as the project moves forward. They are ersatz models of what the software will do when it is done. The naive notion that ...
You can easily predict the release date of a project by just counting the number of Stories
... can only be the case, If and Only If the User Stories never change in their implementation detail, are near exact representation sof what the user wants in terms of Capabilities and the Requirements needed to provide those Capabilities, and most importantly the future is nearly exactly like the past - so the performance that happened in the past will also happen in the future.
As well there can be no emergent risk, no change in effectiveness of labor, nothing will change. This is not only naive, it ignores - some would say willfully ignores - the fact that all project work is uncertain. In the presence of this uncertainty measuring the probability of meeting the planned need date for the planned cost (remember ROI is a core business assessment of the project's performance), and the probability that the needed Capabilities will in fact be delivered as needed cannot be assessed using a measure that is itself vague, emerging, variable in undefined ways, and not actually representative of Physical Percent Complete for the work being performed.