May be also help in onboarding and off-boarding new team members.
Note that, as they say, “Velocity is a planning tool, not a goal or a competition. Quality is a much healthier and more useful goal.“ However much effort you spend caring about velocity, spend many times as much caring about quality - code/implementation choices, UX, resulting impact to the product/business, etc.
So, yes, the root cause is often that the scope is undefined or unclear. The process of having the team estimate how long something will take to implement (in fairly small work units - think hours, not days[1]) tries to solve both of those.
With my developer hat on, if I'm handed a user story like "Sandy wants to export her transaction history to CSV" to be implemented in this release, I'm going to immediately ask a couple questions: can the user choose the length of data to export? What app(s) does the CSV need to be importable and tested with, if any? Does it contain different fields than the Web view? Can everyone do it, even less-privileged users?
We don't necessarily need to spend hours debating this stuff, we just need to decide it before implementation rather than during or after/not at all. It's probably a 2-4 hour meeting with the team, looking just at the things planned for the next ~2 weeks. In my example, if the scope answers are that the user doesn't need any control of what to export, the CSV doesn't need to be compatible with any specific app, and the CSV should contain the same fields as the Web view for everyone, then I really may have 1 work item that probably won't take a lot of time/points. OTOH, for each answer that isn't no, there's at least 1 more work item :-) You'll also get better because after the release, you'll come back and say "Well, this took 3x as long because none of us spotted <some complexity>."
The important elements are: doing this as a team, not individually (so everyone can spot scope ambiguity and implementation challenges); understanding that the goal isn't to be perfect in release 1, it's to get better over time; that even if you're wildly far off, the return on the time will be positive merely for the scoping questions.
IOW, as a byproduct of estimating points for velocity, your team gets a shot at clearing up the scope.
[1]: https://www.pivotaltracker.com/help/articles/estimating_stor...
https://www.amazon.com/Software-Estimation-Demystifying-Deve...
and
https://www.amazon.com/Rapid-Development-Taming-Software-Sch...
Also think: if the business does project A, how much money does that make for us or save for us? From a developer standpoint I have gotten the business people to tell me a value that is a fraction of the cost of the product. You fold that one and free up resources for project B which is the other way around.