Don't throw estimates out of the window. Keep in mind that the more precise they are the more expensive they become.

This is indeed two sides of the same coin. A good reminder that you need to pick the right approach depending on the context.

Interesting point of view. I'm not sure I fully agree with the classification but it gives something to mull over. For sure the less reliable your estimates the more padding is needed to have some predictability.

Or why estimates need to happen in one way or another.

They're so misused that it's better to let them go. Indeed, we can go as far as wondering if estimating stories instead of slicing them is a good idea at all. Doesn't mean all estimates disappear of course, but at the single story resolution? You likely better invest time in slicing them better.

If you're asked a broad project estimate, building a very fine grained user story list is likely not the best approach.

Or why analogies with physical work don't work...

Nice and tiny estimation approach. I can see projects where this could work.

I don't exactly use this approach to factor in the uncertainty... but I guess there's something to be made out of this proposal. I'll keep it in mind for my next project.

A very precious document. Shows great organization in the work of Knuth of course but the self-reflection has profound lessons pertaining to estimates, type of errors we make, etc.

A bit long and a couple of mistakes when pointing out the flaws of story points. Still, it's definitely a worthwhile read. Quite a lot of the criticism of story points is warranted and the proposed approach based on queue theory is welcome. This is stuff you can find in Kanban like approaches and mature XP.

This is indeed an important aspect of estimating work. The smaller you manage to break down tasks the easier it will be to estimate. Breaking down work is a skill in itself though.

Interesting approach when managing at a distance. It tries hard to stay lightweight which is definitely welcome.

Indeed, going for scrutiny on made up numbers probably won't get us nowhere. Tweaking them won't help either. It's the shared goals which matter most.

We got a problem with research around software estimates. This won't help us get better at it as an industry...

It's a bit a "yet another article" about estimates. Still there are a few good points in there, they're harder to apply than it sounds though.

For all we like to point out the software industry for blowing up estimates and budgets... it's not a unique phenomenon, civil engineering is also struggling with it. This is a good reminder.

Interesting approach regarding estimates. Might especially make sense combined with kanban like project management.

Good explanations on why trading quality for speed is always a bad idea. It also goes on about how to avoid sacrificing quality through the definition of done and proper estimates.

Very interesting musing about the technical terms we often use wrongly and how it difficult it is to be understood.