This is the technique I've adopted. Interestingly when I was first introduced to scrum years ago, this is how my team was taught to estimate stories. Find simi

This is the technique I've adopted. Interestingly when I was first introduced to scrum years ago, this is how my team was taught to estimate stories. Find similar stories (or, if you're just getting started, requests of comparable scope) you worked on in the past and use those as a reference. What happened instead: team quickly ended up equating story points to some unit of time (e.g. 1 pt = 1 day to complete). Then, for a new story, play planning poker where each developer makes estimates based on rose-tinted projections of how long they imagined it would take them to finish the job if they were working on it alone without major distractions or unanticipated complications. After everyone reveals their estimate, argue pointlessly with each other for a random amount of time. Then, once the scrum master has caught up on all the latest notifications on his or her phone, either cave to the opinion of the most belligerent member of the team or average the results. After we got burned a few times, we added a "shit happens" cushion while still following the same basic procedure. I'd be surprised if that team didn't continue to use the same protocol to this day while gradually ballooning their cushion to the point their estimates coincided with the "double the number, shift to the next time unit" rule. Daniel Kahneman provides a good lesson on the difference between these kind of expert-driven (for various definitions of the word "expert") estimates and the sort of historical data-based approach you suggest in Thinking Fast and Slow. It's excerpted here: https://www.mckinsey.com/business-functions/strategy-and-corporate-finance/our-insights/daniel-kahneman-beware-the-inside-view https://www.mckinsey.com/business-functions/strategy-and-cor...