Hacker News Reader

Comment by spion | Hacker News Reader

This is fascinating, but I'm not sure this is the reason (or a good excuse for?) why software estimation is a mess right now. If you look at standard industry practice, the concept of "probability" rarely enters the discussion at all when estimating.

I've personally had great success with three-point estimation. [1] As far as statistical methods go, its pretty simple - yet it tends to work surprisingly well. To my knowledge however, none of the popular software on the market has any of the tools needed to do even something as basic as this, at least out of the box.

There is a whole set of tools out there for probabilistic modeling, and if we're serious about estimation, we should start talking about them.

[1]: https://en.wikipedia.org/wiki/Three-point_estimation

View on HN

From the trenches, the observable reason that approaches like this aren't taken up is often because of the power dynamics at play. Stakeholders want to treat delivery teams as feature factories, and typically have the organisational power to reject estimates that aren't in the form of "this will be done tomorrow/next week/in three months". They choose to reinforce the viewpoint that an inability to provide and keep to hard delivery deadlines is a marker of incompetence, rather than a realistic assessment of the basic physics of the situation. This is - to put it mildly - not helped by situations where hard deadlines are agreed to without speaking to delivery teams at all.

There is a lack of maturity in how software delivery is commissioned in the industry, but the fundamental issue is that the political drivers that result where Taylorist management interfaces with unpredictability in delivery reward behaving in a way that doesn't improve that maturity.

"this will be done tomorrow/next week/in three months"

This type of answer is also possible if you can agree on the desired confidence. I've found that 95% confidence is sufficient for most cases, but that number will depend on context. Understanding the stakes of the deadline for stakeholders can help adjust this further.

I agree that building trust with stakeholders can be tricky, and discussions about risks can be sometimes be interpreted as unwillingness to take responsibility. In that situation, the team can at least get a measure on their level of confidence and give an initial number they're somewhat comfortable with, as well as an estimate of how likely to succeed the agreed upon number is.

What is your technique for estimating in the case that the tech stack is (at least in part) unfamiliar? Can this technique be applied by junior developers with only a few years experience?

For cases where the tech stack is in some ways unfamiliar, we create research stories where the goal is to do the quickest thing possible to answer questions about the tech. This is typically timeboxed by the max time we'd be willing to spend on it, rather than the estimated maximum time. Its still useful to try and put a maximum estimate if possible, because then you can also estimate probability of success for the timebox which makes you better prepared for discussion with business to help them decide if they want to take the risk to invest time in it.

Few years of experience should be quite sufficient, although I think overall team culture is probably more important. I've usually done this type of estimation together with teams where there's already good communication, but when that's not the case something like pointing poker to open up safe discussion and uncover uncertainties may make sense as well.

Reply on news.ycombinator.com