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
Advertisements

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