Your crystal ball is cloudy, but you can sort of predict the future. As long as the future isn’t too far away.
In other words, if you take it in small chunks you usually know enough about the work before you to guess reasonably accurately how long it is going to take.
Back in the old waterfall days, we’d plan months and months of work at a time. The printed project schedules could be 100 feet long. The trouble was, work more than a small number of days away often depended on work that had not yet happened. We needed to know how that work turned out before we could be sure of the work that would follow, and have a good idea how long it would take.
From a straight-up project-management perspective, this is why agile is brilliant. It lets us break big projects down into small chunks of usually two weeks in duration, where ideally we have to give our best estimates only for this short period. This respects that we don’t know what we don’t know about the work that follows.
You might still need to estimate how long an entire feature will take to build. Some companies need some idea when the feature will deliver. But it has to be a projection, not a promise, because your crystal ball is too cloudy.
The current sprint’s estimate matters most. When you plan a sprint, fill it with just the work you are confident you can finish. You want to deliver all of the work in the sprint, barring unforeseen technical complexities, critical customer-reported bugs, team-member illness, or late reviews.
Then check your gut: do you think your team can really deliver all of those stories? If not, please say so, and discuss why. When you leave sprint planning, everyone on the team needs to agree, based on what you know then, that this body of work seems doable in two weeks.