What Assumptions Do We Make When We Don’t Estimate?

inverted_flight_attitude_indicatorNext up in the 4th session, what assumptions are we making when we decide to skip estimation?  This produced some interesting results and likewise we realized that some assumptions are the same between the two, though there were some subtle differences in how they get worded. Like before we explored the first set then discussed those we felt had significant difference.

  • That we know enoughto do the right thing
  • The team gets more value from starting work sooner
  • That our work is emergent in nature
  • We can commit to a high level objective versus a detailed plan
  • We know the value of what we’re building or have a testable/measurable hypothesis of value
  • That what we are doing is actually not some form of estimating
  • Underestimating that is just another easy one, but not
  • Heroics are a given (to get the work done)
  • The estimates are wrong or don’t provide value

  • We can deliver working software frequently
  • Estimates are wrong so why bother
  • We have a collective sharing of the risk (with the business or person hiring us)
  • We can properly measure progress or ROI
  • That dependent items can identified just in time (timed w/our release)
  • We don’t need to help someone else understand why they should spend their $|£|¥|€|rubles
  • There are our limits to our knowledge (and we don’t always know those limits)
  • That we don’t need them
  • We’ve defined the system into a predictable state of behavior
  • We need to discover what we need to do
  • The team understands what the highest priority work is and can make a plan without estimation

What Assumptions Do We Make When Estimate?

In_Dive_Attitude_IndicatorThe 3rd session began our exploration of assumptions underneath making estimations. We explored the first 12 in detail, and then hit ones that significantly differed from these 12 in the list below the line. (People voted on their individual top assumption by placing it above the line.)

  • Stable (long-standing) teams that have everyone and everything they need to start/continue working
  • The estimate is more valuable than the time spent generating it
  • That the estimation in and of itself adds value
  • The customer knows what they need
  • That we know all there is to know
  • The stories are defined and the team understands the relative complexity of the work involved (including dependencies)
  • That we understand what we are estimating
  • That the Definition of Ready is correct
  • That estimated cost = value (as reflected by EVM)
  • If estimating “when”, that we know how many working hours there are (assuming fixed feature set)
  • We have a model (for estimating) that is “useful”
  • Team’s competency and past experiences for dealing with similar stories

  • We understand “it” well enough to estimate
  • Confidence in estimate
  • That we’re somewhere close to right
  • That we’re probably wrong/they are wrong
  • That further analysis will improve on our initial intuition
  • We know enough about the work to make relative estimates
  • We will actually use the estimate to make decisions
  • That we know our throughput
  • Dependencies of our gives and gets from other groups
  • Unknowns as risks
  • That past experience actually informs future returns
  • We have perfect knowledge
  • That people consider time impacts (i.e. people think too optimistically about their availability)
  • Risks
  • That is an estimate and not treated as some super-duper precise time set in stone
  • Things will not change/evolve as we begin
  • We have perfect knowledge

Objectives and Techniques

With knowledge of the successes and failures we had encountered, and the start of an inventory of items we estimate (see Background), we began to explore what objectives we were pursuing when pursue one approach or the other.



For Estimating When Not Estimating
  • Build trust
  • Build confidence/feel more comfortable about being able to deliver
  • Data for retrospectives
  • Plan and coordinate with other functions/groups
  • Transfer risk (and find a scapegoat)
  • See complexity over time (in points) that a team can sustainably deliver on in a sprint (ballpark)
  • Confidence for team and business
  • Plan accurately
  • Forecast to coordinate
  • Justify project
  • Make budgets
  • Make better prioritization decisions
  • Forecast to make commitment/investment decisions
  • Get funded
  • Calculate ROI
  • Satisfy Management
  • Improve release planning
  • Gain clarity & visibility
  • Produce more value
  • Focus on value (or even just questions to answer)
  • Eliminate waste
  • Reducing waste in the work system
  • Get started faster knowing where we are going
  • Deliver more value over time
  • Stop giving super specific (and false) estimates to minor detailed tasks to the business
  • Free our creativity (don’t box us in)
  • Depends on work if points even make any sense
  • Potentially allow for a different trade-off
  • Routine work e.g. monthly release support
  • Focus on retrospective action items for improvement


Then we turned our attention to what techniques we use when we either estimate or don’t.


Used For Estimating Used When Not Estimating
  • Only talk about estimation  during backlog refinement (t-shirt sizing)
  • Burndown chart
  • Understand the confidence interval
  • Affinity estimation
  • Discuss, ..1-2-3… Show count
  • Monte Carlo simulation
  • Planning Poker
  • Rank Ordering
  • Weighted Shortest Job First
  • Modeling
  • Use/Compare to Actuals
  • Estimation by Analogy
  • Specific criteria & acceptance
  • Affinity mapping
  • In depth grooming for debated story complexity
  • Sustainable commitments
  • Mob programming
  • Implicit estimation (ballpark)
  • Impact – Effort Matrix
  • Kanban
  • Pay only what it’s worth
  • Priority Pyramid for a backlog
  • Cycle-time analysis of work items in the retrospective
  • Team’s confidence & vote to commit
  • Flow efficacy and run rate
  • Update progress on tasking frequently
  • Measure story completion rates (flow)
  • “Just do it”
  • See investment, flow, et cetera for entire line of funding
  • Monte Carlo on live data
  • Use economic/finance metrics (run rate)
  • LeSS, no Lean
  • Establish a time or cost box to discover if value is there (think like a spike)
  • Revisit Definition of Ready stories (much as you do for Definition of Done)
  • Tabletop card sorting (can sort by relative effort without writing down size)


15.0 1st Agile Dialogs Unconference focused on Agile Predictions


The Theme for our First Agile Dialogs Unconference is —

“Agile Predictions: Exploring the tools for making sound business decisions with & without estimates”

So whether you are proestimate, noestimate, or somewhere in the middle, if you have a passionate position, please join us 13 November 2015 in the Washington, DC metro area at the Navy League Building; 2300 Wilson Blvd, Arlington, VA.

Below is a link to the survey for you take; you can revisit it and update your answers. We’re keeping this open for people to express their interest and opinions regardless of their attendance. We’ll probably put this in a packet (without names/emails) for attendees to have.

Register your Agile Dialogs Interest on Predicting Value with and without Estimation.

Be sure to check out the planned unconference agenda to see how we hope to promote dialog!

Sponsored by –


Space provided by –