The more rigorously you try to analyse the problem, cutting it into smaller and smaller parts, the more error you introduce, reducing the value of the estimate at each step.
Thus, the best practice is to give a very rough estimate based on the scale of the project and your past experiences.
If you don't have previous experience with similar projects, then you should not even try to estimate.
Jokes aside I think accumulation of errors together the fact that time estimations are hard and Parkinson's law is the fatal flaws with Agile.
> Thus, the best practice is to give a very rough estimate based on the scale of the project and your past experiences.
This is my experience too. It is somehow easier to estimate big scopes then many small that sums up to the same scope. Also you get a better feeling of how far you have come when looking at the big scope then when digging down to the details.