> Contrariwise, if you can't know what tasks are required to complete a sprint, your team is in deep shit. You can get a decent picture over a time horizon of 1

> Contrariwise, if you can't know what tasks are required to complete a sprint, your team is in deep shit. You can get a decent picture over a time horizon of 1-3 months, with certainty going down as the time horizon gets farther out. This is why Agile works. Fair enough on the level of a sprint. In my experience, management and stakeholders rarely care about a sprint, they care about the project as a whole. And again, in my experience, the accuracy of estimates falls off precipitously once you get beyond 1 or 2 sprints, unless you're willing to pad estimates or lock down your plans to a degree that will hurt the success of your project (by not taking into account learnings as you build). > This is part of why you need to capture estimates and actuals. Even if those estimates are wrong, in practice, by comparing estimates to actuals by each developer, a picture will emerge of how far that developer will overshoot or undershoot their own estimates. Those estimates the become actionable data, even if they're wrong 100% of the time. This would be true if estimates had high precision, but low accuracy (i.e. developer A consistently overestimates, and developer B consistently underestimates). In my experience, the opposite is more true than not - developers have relatively well tuned accuracy, but horrible precision. If everything goes according to plan, developers can estimate that fairly well. It's the amount of times things don't go according to plan that's the problem.