Project Management

The Art of Guesstimation: Why Should We Estimate?

From the Disciplined Agile Applied Blog
This blog explores pragmatic agile and lean strategies for enterprise-class contexts.

About this Blog


Recent Posts

#NoFrameworks at Agile Middle East 2020

The Art of Guesstimation: Why Shouldn’t We Estimate?

The Art of Guesstimation: Why Should We Estimate?

The Art of Guesstimation: Estimation on Software Projects

Planning: The Efficiency Zone

In the previous blog in this series, The Art of Guesstimation: Estimation on Software Projects, we explored the differences between guesstimates and estimates, and in this blog I will use the term estimate to refer to both.  Because estimation isn’t limited to projects I will use the term endeavor to refer to efforts that are organized either as a project or as a non-project. As Simon Sinek suggests in Start With Why: How Great Leaders Inspire Everyone to Take Action we should start by explaining why something is important.  From that point of view, it makes sense to ask why should invest the effort to estimate the time or cost of an endeavor? 

Estimates are often required for several reasons:

  1. We want to allocate funding for an endeavor.  We are often asked to estimate the cost of the next stage of an endeavor, be that the work required to build the next release of a system or the work for the next stage of a project. Cost estimates are often required as input into the decision process around fund allocation within your organization’s portfolio management efforts.
  2. We want to financially govern our endeavors.  Allocating funds to endeavors is an important initial step but we should also monitor how those funds are spent over time.  Organizations that are new to financial governance will often choose to track actual expenses against estimated costs, perhaps calculating the cost performance index (CPI) from Earned Value Management (EVM).  EVM is a common strategy for teams taking a traditional/serial approach, sometimes called a “predictive” approach, and some organizations will apply EVM to agile teams as well. As organizations mature and adopt more effective ways of working, such as those captured in the Disciplined Agile (DA) toolkit, they learn it is better to focus on tracking value delivery rather than cost.  Instead of asking “Will we be on budget?” they instead ask “Are we investing our money wisely?”  These are two very different questions, the latter producing better outcomes through greater discipline.  
  3. We need to coordinate our efforts with others. Other teams will have dependencies on what our team delivers, and as a result we will need to estimate the time required to produce what they require and when we expect to make it available to them.  This is particularly common when our customers need to do their own planning around our delivery dates.  For example, if we’re a construction company building a new home for someone our customers will want to know when it will be ready to be moved into.  Or perhaps our team is building a system where some of the software components will be reused by other teams.  In this case these teams may want to know when the interface for the component will be defined, when the test harness for that component is in place, and when the team intends to deploy the working component into production.  
  4. We want to govern our timelines. Just like we want to govern our financials we also need to govern our timelines. EVM’s Schedule Performance Index (SPI) calculation can be applied to determine a team’s variance from their estimated timeline.  This can be particularly important when our team has a hard date to hit, perhaps due to regulatory compliance or a contractually promised delivery date.  Unfortunately SPI can give a false sense of security to teams following a traditional/serial strategy, particularly traditional software teams because they tend to push a lot of their risks to the end of the lifecycle.  On traditional software projects CPI and SPI indicators can be tracking well until you get to system integration testing (SIT) or user acceptance testing (UAT) where (surprise!) your project runs aground because when you finally detect serious quality problems that prevent you from shipping. Disciplined organizations have instead shifted from the question “Are we on schedule?” to instead focus on answering “Are we deliver value to our customers when they actually need it?”  The latter question motivates better behavior by the team because it reflects that fact that the needs of our customers will evolve as their situation changes over time.  In other words, delivering something on schedule that people no longer want should hardly be considered a success.

To summarize, there are several reasons why we should consider investing the time and money required to produce estimates.  In the next blog in this series I will explore reasons for why you don’t want to invest effort in estimating.

Posted on: January 15, 2020 08:45 AM | Permalink

Comments (8)

Please login or join to subscribe to this item
Dear Scott
Interesting perspective on the theme: "he Art of Guesstimation: Why Should We Estimate?"
Thanks for sharing

Interesting how you ask cost and time questions

I will be aware of your new blog article about: "why you don't want to invest effort in estimating"

By the way ..
Is your estimate of the publications on schedule? Or ... didn't you plan? :-)

Definitely planned, but stuff happened so the estimate was off.

Estimation in Agile lately is being phased out. Release planning and SWAG of effort can give you similar results. I plan MVP's for Releases to be 6-10 weeks in length as a guard rail. If I do that every team can give us 2 features per quarter, 2 features by 5 teams is 10 features on the roadmap per quarter. It also keeps the delivery on everyones mind and it keeps negotiation of functionality as a core principle.

In large enterprises, the “NO Estimations movement” will only get as far as the first word in their movement, “NO.” At least in these environments, I believe there are no pure adaptive or predictive projects, in other words, projects by their nature are situational and when tailored become hybrid in form (but we can call them whatever we want).

Unless it’s their first rodeo, sponsors, stakeholders, and executive management understand the nature of estimates. With this understanding, their desire is to have “approach consistency,” so that the estimates can be used to evaluate projects in the portfolio queue. This consistency should include a review done by an architectural committee who can challenge all aspects of the proposed project from the Business, Enterprise, Solution, Application and Infrastructure levels. Agility is always the way forward, but agility needs accountability to have value.

@Jim, it depends on what's important to you. By setting the date (a release of 6-10 weeks) and the cost (your team has X people on it) then you vary the scope to fit the capacity constraints that you've set. Classic iron triangle strategy.

@George, a lot of people don't understand what #NoEstimates is about, which is a shame. There's a webinar coming up in March on this topic. I suspect that they will work through what #NoEstimates is actually about given the description. You're right about projects/endeavors being situational in nature, that's one of the 7 principles of DA (Context Counts) in fact.
You've got a shot at reasonable estimates if you keep your team together over time, which sounds like @Jim is implying. The team knows their capacity, they get consistent at sizing things, so they get fairly good at consistent delivery. Such teams will have a consistent, although I hope improving, approach to their way of working (WoW). So these factors enable them to predict with reasonable accuracy.
But a consistent WoW across teams isn't going to get the job done on its own. People vary in ability, experience, and style. Platforms/technologies vary as does technical debt. If your staff varies a lot, for example in organizations that employ a lot of short-term contractors ("gig workers"), then it's hard to predict accurately.


I understand that the “No Estimates” wording is a challenge-based statement to put the focus on value-added activities within agile-based practices. Of course, meaning that cold-turkey or the creative abstract approaches to estimating have “little if any value” – which I fully agree.

I’ve been dealing with pushback on estimates (predictive to adaptive and everywhere in-between) for almost forty years and know the agony from both sides of the equation, and have found it interesting having developer go out of their way to talk to me about #NoEstimates, and listening to their hallway conversations on the same. Truthfully, they look at those two words (No Estimates) and feel that the day of reckoning is coming, that their freedom from the bonds of accountability is nearly at hand. Although I’m exaggerating, there is some truth to this which I addressed in a satirical blog post/graphic a while back.

I do not want developers spending countless hours generating estimates that have no value, and I also do not want developers who are coding in a box, which your “Enterprise Awareness” principle seems to agree with. The phrase and philosophy I teach my teams is “Architectural Awareness” which requires project team members (both business and IT) to have the ability to Understand, Interpret, and Communicate with architectural knowledge, that is, non-engineering big-picture knowledge which focuses on the strategy and structure of domains (specifically the domains the project is engaging). When team members have this level of awareness, estimates (when needed) have increased value and when challenged by a true “architectural review,” provides information that increases the project's opportunity for success.

I’m glad there’s a new DA in town with the tools needed to clean up what has become the wild-west of agility. I’m looking forward to your continued posts!

Good conversation. Thanks, Scott.

Very interesting., thanks for sharing

Please Login/Register to leave a comment.


"Less is only more where more is no good"

- Frank Lloyd Wright