#NoEstimates (Allen Holub) on HackerTube: recommended by 2 Hacker News commenters across 2 separate months, 2019–2025.
talk · intermediate · evergreen
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.
Recommended in estimation and sprint debates as a well-reasoned account of where waste is and isn't in agile.
“If you want a well-reasoned discussion of where the waste is and isn't, I highly recommend Allen Holub's talk #NoEstimates”
7 Hacker News comments link this video. Each one links back to its thread.
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
in “I don’t believe in sprints” · View on HN
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
in “Deadlines Are Killing Us, and Almost Everything Else I Know About Leadership” · View on HN
▶ this video #NoEstimates Yes, be agile. Yes, measure all the things. But estimation sets everyone up for disappointment.
in “Estimates are difficult for developers and product owners” · View on HN
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
in “Hard-to-swallow truths they won't tell you about software engineer job” · View on HN
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.
in “Microsoft researched what made employees happy” · View on HN
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
in “How I started believing in Cycle Time over Estimation” · View on HN
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
in “How I started believing in Cycle Time over Estimation” · View on HN