Very good point, planning is a broader activity than estimation. I find people bring a lot of baggage to the idea of estimation, like in this case you say "it'

Very good point, planning is a broader activity than estimation. I find people bring a lot of baggage to the idea of estimation, like in this case you say "it's a lot of wasted time". There's an assumption in there somewhere about what constitutes an estimate. If you're talking about an eng-week granularity estimate for a project that is going to take 6+ months then absolutely I agree with you. But for me an "estimate" is just a sense of the level of effort required sufficient for the needs of planning at the time. It goes hand in hand with risks, dependencies, and other assumptions that need to be kept in mind. The exact form of an appropriate plan depends a lot on the business constraints like how delivery timeline interacts with customers, external events, and the broader ecosystem that the company operates in. As for your suggested backlog approach, this makes sense if the requirements are rigid and accuracy on the delivery timeline is the most important thing. This is situational, but in many projects I've led, the scope is negotiable, and therefore important to keep the big picture in mind to find opportunities to refining or consolidating scope. A common anti-pattern I've seen when relying on ticket/task-level tracking is the team missing the forest for the trees. It's possible to leverage these systems to support high-level planning, but I tend to prefer documents or a simple spreadsheet gantt for that purpose, and use ticket/task tracking for last-mile work, intakes, bugs and other inputs that we don't want to lose track of, but may vary widely in their importance and relevance.