Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/categories/6&page=5' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Project Management
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

How to Estimate Any Software Problem

Herding Cats - Glen Alleman - Sun, 05/08/2016 - 20:13

The conjecture of #NoEstimates starts with the first Tweet

No Estimates

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?

  • What are we looking for?¬†It says we're looking for An Alternate Way to make¬†decisions¬†- in the presence of uncertanty. Uncertainty of course is present in all software development work¬†both¬†reducible and irreducible¬†uncertainty.
  • How will we recognize it when we encounter it?¬†Any expectations for what we'll¬†find? Any expectations of how to measure if what we¬†found is what we're¬†actually looking for?
  • Once we find it, how can we test that what we found is actually of use to anyone other than us?¬†The use of anecdotes is to collect a sample of One from an Unknown population and consider it representative of as evidence of our hypothesis.

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. 

Reading Materials

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. 

Hard Fact Dangerous

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. 

How Many Licks

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.

Economics of Itertaive SW 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.

Estimarting SW Intensive Systems

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.

Agile Estimating and Planning

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.

SW Estimating

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.

Probability methods for cost uncertainty analysis

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.

 Estimating SW Costs

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

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:

  • Split big items,
  • Does a light weight analysis for basic understanding,
  • Estimates the items,
  • Identifies strongly related items to reveal shared work, common work, or coordinated work.
Agile IT Org

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.

Agile Project Management

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.

How to Measure Anyhting

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.

Forecasting and Simulating

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.

Facts and Fallacies of SW

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.

Software Cost Estimating with COCOMO II

 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. 

Forecasting Methods

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

Evm+agile estimating from Glen Alleman 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. Screen Shot 2016-05-08 at 9.20.50 AM

 Related articles

Risk Management is How Adults Manage Projects Making Choices in the Absence of Information Decision Analysis and Software Project Management Risk Management is Project Management for Adults Economics of Software Development How Not To Make Decisions Using Bad Estimates Complex, Complexity, Complicated Software Engineering is a Verb Making Conjectures Without Testable Outcomes
Categories: Project Management

A Working Definition of Agile

In a recent workshop, a¬†participant asked me, “What does agile mean? How do you know if you are agile?” He wants to use kanban to see the flow of work through his group. Someone told him he needed to use iterations to be agile. (I had a little rant about this in¬†What Does Agile Mean to You?)

I suggested this could be his working definition:

  • You can deliver what you want (some form of value).
  • You can deliver that value ¬†when you want.
  • You can then change to the next most important chunk of valuable work.
  • You learn from the previous work you did, both about the work and the process of doing the work.

That’s not all agile is, but it might be a good working definition. If you work towards being able to deliver what and when you want, move to the next thing, and learn, you have the feedback cycles. (You might also look at the agile principles behind the Manifesto.)

These are practices that increase your agile capabilities:

  • Iterations, because they limit the work a team can commit to in a given time period.
  • Kanban with work in progress limits, because they limit the work a team can do, and show the flow of work.
  • Retrospectives because you learn from previous work. (Someone important said if they only did one practice it would retrospectives. I can’t remember who said that. Sorry.)
  • Standups because they reinforce micro-commitments to finishing work.
  • Technical excellence practices from XP, because they make changing the code and tests easier.

You don’t need any of these to be agile. They help. You might find other practices to be more helpful in your context.

I have some previous posts that might be interesting if you also are wondering what agile means for you:

For me, practices are interesting, especially if I choose to experiment with them. What could I do to increase my throughput and learning, and therefore, my ability to adapt? Agile is not about specific practices. It is about a mindset of finishing small valuable chunks, feedback, and change.

Categories: Project Management

Podcast About Geographically Distributed Agile Teams

Lisette Sutherland posted a podcast we recorded about geographically distributed agile teams. See Organize Your Distributed Team over on the CollaborationSuperpowers site.

We covered how you can think about your geographically distributed agile team:

  • Why you want a distributed agile team (yes, there are some great reasons)
  • How you might organize your team.

Here are the articles I mentioned:

Managing Multicultural Projects with Complementary Practices

I wrote about the timezone bubble chart in Managing Timezones in Geographically Distributed Agile Teams

Here are three posts about Geographically Distributed Teams Have Choices for Lifecycles about options for how you might do agile with a geographically distributed agile team.

I even had a chance to rant about management. We had a blast, as you can tell. Hope you enjoy it.

Categories: Project Management

Small-World Networks Article Posted

I’m a new contributor to the TechBeacon site. I have an article up, called¬†Small-world networks: a lightweight alternative to SAFe for scaling agile.

 Scaling Collaboration Across the OrganizationYes, it’s based on Agile and Lean Program Management: Scaling Collaboration Across the Organization.

Hope you enjoy the article.

Categories: Project Management

Thu, 01/01/1970 - 01:00