—Can #NoEstimates lead to better decision making on project delivery?
People are still talking about “NoEstimates”. I first looked at this in the Mythical Man-Month (Worth Reading Again).
Recently, I caught a discussion on Twitter wherein:
For the sake of clarity, let’s agree in (sic) this. Estimation = asking the team to sit down and evaluate the cost/duration/effort of a piece of work they haven (sic) done yet. #NoEstimates = the team just focuses on delivering valuable increments of software at a regular cadence.
Two interesting responses.
To know whether an increment is valuable, you often need to know its market window. You also may need to know its cost. If so, and if your definition is right, #NoEstimates makes no sense. It must be far more finessed than this.
Not my exact useage (sic), but certainly a definition that would allow for meaningful discussion.
Interesting. The entire thread.
Woody is the originator of the concept. Vasco published a book on it. James doesn’t dismiss it. Just the proposed definition.
My take on this is there is something worth exploring but there is still much debate. It’s interesting that Woody doesn’t offer an alternative definition or expand on his usage. A simple definition would add clarity.
Woody’s definition, from 2013:
#NoEstimates is a hashtag for the topic of exploring alternatives to estimates [of time, effort, cost] for making decisions in software development. That is, ways to make decisions with “No Estimates”.
My take is that #NoEstimates is about creating awareness of and prompting investigation into alternative approaches to estimating and the decision making around estimates.
So #NoEstimates isn’t about eliminating estimates. It’s about finding alternatives to cost, time and effort. And its about addressing dysfunction around the decision making that leverages estimates.
In effect, it’s about trying to do something sensible about a problem we all have.
I wonder about the psychological implications of #NoEstimates. I’ve had experience where
I’m sure this is a common experience for many teams.
Clearly, there is a gap. There is no simple answer.