Now this is a well balanced piece about estimates. Starting from the "why" to decide how you approach the estimates and the level of details is just very good advice.

Couple of interesting tips. I like how it challenges the usual mythical man-month quote. Indeed sometimes adding people might help, if the conditions are right.

It feels a bit like cumulating aphorisms and "laws" to prove the point. Still it's nice to know them at least for the general culture.

Old video. A bit preachy, especially in the beginning, but then covers well the arguments of why counting stories is likely better than estimating them. In my opinion there's a catch that is not covered here though: the quality and granularity of the stories matter.

This is a good piece. Killing all planning is indeed not a good thing. Setting plans in stone wasn't a good thing either, it's no reason to go to the other extreme.

Potentially interesting tricks for estimating. Some of it I did, some not... I guess I'll try some more of what's proposed here at some point.

This is a sane approach and a good list of steps for estimating at large scale.

Excellent advises on project planning and management. It explains pretty well why being optimist in those areas will just drive your project through a wall.

Last part about estimates. Plenty of very good advises again on how to deal not meeting a deadline. Communicating the bad news early is key.

Another nice piece about estimates. This time for the tough times when you're asked a quick ballpark number. The best piece of advises in there: know when you shouldn't do it at all, and, if you go for it sound vague.

I'd even add "you can never be to vague". Even if you go for "a few weeks, maybe two or three" very often people here "two weeks". Don't hesitate to hammer down the uncertainty in all this.

Looks like an interesting alternative to three point estimates. Indeed it feels a bit more complex at first but in practice it might require less discipline than three point estimates. Often three point estimates can devolve into forced distribution for tasks. I have already seen enough time cases where most likely is always say twice the optimistic case, and pessimistic four times the optimistic case for all tasks. By forcing to explicitly treat the uncertainty as a separate metric it's seems less error prone.

I got a slightly different view on the topic. To me there's value in the process of estimating, the estimation itself less so. The process often helps you refine both your understanding of the technical domain but also of the business domain.