Stop Estimating in Hours. Start Estimating in Complexity. There's a quiet truth every developer knows but nobody says out loud at sprint planning: When we estimate in hours, we always estimate low. Always. The senior estimates low because they want to look efficient. The junior estimates low because they don't want to seem slow. The team estimates low because the PM is in the room. And then the sprint ends, half the tickets roll over, and everyone pretends to be surprised. After years of watching this play out across teams, languages, and stacks, I've come to believe that the problem isn't that we're bad at estimating hours. The problem is that hours are the wrong unit . Let me explain why I now estimate in complexity, and why I think it leads to better software, better teams, and — surprisingly — better deadlines. The misunderstanding at the core Here's the trap most teams fall into: they treat complexity and time as the same thing measured with different rulers. They're not. They're two independent axes.…