Conversation

“In two back to back sentences you have a) defended the practice of agile point estimations, and then b) said that you no longer believe the future can be predicted, and that we should run organisations for fast adaptation instead.”

Cedric Chin

@ejames_c

Sep 28, 2021

Of course this begs the question: “what is an agile product development process that is ACTUALLY built for fast adaptation under uncertainty?” This latest episode of “things people have said to me that I’m shaken by”, brought to you courtesy of

@DRMacIver

Daniel Compton (in SF 7-9th Nov)

Replying to

and

Do you have a link to this?

Replying to

and

Oh, it was during a call. David was telling me his opinion about agile point estimations, I was pushing back gently on it, he successfully pointed out scenarios in which my defence of point estimations would fail, and then he brought up Superforecasting.

Replying to

and

At which point I told him about my opinion of superforecasting (commoncog.com/blog/the-limit) and he pointed out that it was incompatible with any defence of agile point estimations. He was, of course, correct.

commoncog.com

The Limits of Applied Superforecasting

Is it really worth it to generate well-calibrated probabilistic predictions? Or would you do better if you assume that all prediction is too difficult, and act as if this were the case?

2:56 AM · Sep 28, 2021Twitter Web App

Replying to

and

so what do you recommend instead?

Replying to

and

I haven't fully decided TBH - I've yet to really encounter a system working very well. I'm not actually against estimates though, my complaint was more that typical point estimates are very poorly calibrated and have no feedback on accuracy, which is how superforecasting came up.

Show replies

Replying to

and

Bigger organizations will still require estimates, but what we usually conflate is efficiency & speed which are two different topics and combined are supposed to represent "velocity". Which I agree, shouldn't be the case with points. Reminds me of a case for short-feedback loops.

Replying to

and

Feels like a theory/practice dichotomy resolving via the central limit theorem. Any given estimate is crap, but do enough and you get a distribution you can live with and plan around.

Replying to

Problem seems to be teams spending too much time being too granular. Who cares if it's a 1 day or a 2 day task -- easily within the bounds of estimation error. But "days" vs "a week" vs "weeks" is probably a useful distinction for prioritizing vs similarly estimated benefits.

Show replies