2 HN users recommended this talk2 months2019–2025score 3
Years with an HN recommendation, 2007–2026
Recommended in estimation and sprint debates as a well-reasoned account of where waste is and isn't in agile.
Allen Holub's keynote arguing that estimation is harmful, particularly in Agile, and presenting planning approaches based on data and flow instead. It covers the distinction between estimation and data-driven prediction.
“If you want a well-reasoned discussion of where the waste is and isn't, I highly recommend Allen Holub's talk #NoEstimates” (HN, 2022)
There's an interesting video by Allen Holub that I've seen on the somewhat related topic of ridding software development of estimates (#NoEstimates)[1]. He argues that they're responsible for deadlines that are impossible to meet due to them being based completely on a guess. He then goes on to talk about how we can still get predictive power without giving estimates. I found it extremely interesting and highly recommend it. [1] [this video]
Argues estimates cause impossible deadlines and shows predictive alternatives.
One could write a solid critique of sprints and how they help or don't, and where time is wasted, but this article is overzealous and comes off as motivated more by anger than reasoning. If you want a well-reasoned discussion of where the waste is and isn't, I highly recommend Allen Holub's talk #NoEstimates [0]. [0] [this video]
Well-reasoned discussion of where waste is and isn't in agile.
he also links to a conference talk about this. "you can make a claim that estimates are based on past behavior, but the fact is that what you're implementing is something that hasn't been implemented before. So any kind of measurement that you've made of something that has happened in the past is not going to impact what you're doing now" [this video]
Conference talk on why past data does not predict new work.
Thank you for your comment! > But I don't get how they went from that to "estimations are bad". It seems to me that they're just doing better estimations now by looking at historical data? For me personally, I went from estimations are just really poor even for the most simple things and not worth the effort. It is correct that is can still be seen as migrating to a better form of estimation. If you look at the conference talk by Allen Holub[1]. He tries to make the distinction between estimation and prediction is that the latter is only data driven. > Maybe the team leader is confused because they thought this was a man-hour estimation? And they're now afraid that one developer will work full-time five days on it? That could be the case. I never looked at it that way. > Doesn't this imply that their 10 minute estimation was done completely without asking the team? Yes, it was done with just the team lead and me. We migrated away from Scrum at that point and we did not do full team refinement with estimations sessions pre-sprint. We would collaborate on the technical solution for any story when we would pick it. This could be full team to two engineers. The engineer that brought up the bug would probably bring up the bug. > Really? You couldn't consider the complexity of a release process you designed yourself? You honestly thought this was a 10 minute task even though you knew you were dealing with a legacy system? Yes, I honestly did! It was just a simple code change in our
Distinguishes data-driven prediction from estimation.
Apparently if you do zero estimating (or just count the amount of stories), it makes ZERO difference when calculating your cumulative-flow diagram. [this video] Money segment is at the 26m15s mark. The wasted effort of trying to estimate stories provides zero business value in this context.
Shows estimating makes no difference to cumulative-flow diagrams, at 26m15s.
Planning doesn't mean estimation though; we all know it's just guesswork, and basing business decisions on guesswork is madness. On top of that it's a lot of wasted time and effort. Milestones and projections is a much more constructive approach, simply tracking the number of tasks in your backlog over time will give you an increasingly correct projection of when the project will be finished. [this video]
Supports tracking backlog tasks for projections instead of estimates.
Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.
Plays via YouTube's privacy-enhanced embed
7 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Citations, criticism and jokes
Read more