> you're conflating the ability to estimate accurately with the ability to implement.

> Just because I can't estimate a task accurately doesn't mean I can't do it.

Most programmers could ultimately do anything... if given enough time.

But if they're going to do it professionally, you expect them to have some prior experience so they can do it somewhat efficiently. And if they have that experience, they should be able to estimate.

So yes, being able to estimate and being able to do (with reasonable professional efficiency), do tend to correlate, of course.

Because you often estimate something like three or four times as many tasks as actually get included in the sprint. You can't possibly know in advance which features will actually wind up in the sprint until you've considered all the possible candidates. You estimate, then the PM confers with stakeholders to prioritize what's actually most important and figure out the "puzzle" of which pieces add up to a coherent sprint, and then work starts.

To the developer, it seems like short-term sprint planning. But to the PM and stakeholders, it's very much medium-term planning because they're picking tasks for this sprint in light of what they also estimate the following couple sprints will look like (given current information, which is always going to change).

It's not as bad as it sounds, because when you're re-estimating something you already estimated in the past 2 planning pokers, it's usually pretty quick. You're just seeing if the previous estimate needs to be revised based on what the team has learned since. Most time is usually spent on newly proposed features, or features that have significantly changed or been split up.