Velocity

There's an old joke that goes like this:

One day a pilgrim was walking towards Santiago and, during the way, he encountered a philosopher. He asked the supposedly wise man:
"How much does it take to arrive to Santiago?"
But the philosopher did not answer.
Then the pilgrim began to walk again, and only when he was fifty meters away, the philosopher shouted:
"Half a day!"
The pilgrim looked back and said "But... Couldn't you tell me while I was there with you?"
And the philosopher: "I did not know what was your velocity."

One of the points of Agile methodologies is in approaching estimation without random guesses. We are often asked to prepare a schedule and a deadline without knowing enough about a software problem.
Agile prescribes to estimate relative size of user stories (which can be think of features with an acceptance test) in points instead of estimating time. The time spent to complete the user stories varies, because it is dependent on the team or programmer's velocity.
Velocity in physical definitions is a different quantity than speed. Velocity is defined as the derivative of displacement in respect to time, while speed is the derivative of path length in respect to time. While the shortest path between two points in space is a straight line, following a non rectilinear path results in an average velocity lower than the equivalent average speed, which could thus be a biased progress metric. If I go to Tokyo and return home in an hour, my speed would have been amazing while my velocity is exactly zero.

Velocity focuses on the effective work which has been completed, not on the effort nor on the hours spent coding. Only the finished stories are taken into consideration to calculate velocity.
Velocity is best estimated by gathering data from some short iterations (some weeks long). After the first iteration, which accomplishes a certain number of points from several completed stories, we are able to extrapolate a range for the remaining number of iterations required.

Consider this example: during the first two-week iteration of a project, a solo developer finished two stories, which are worth 5 and 2 points respectively. The velocity of this single-person team is 7 points per iteration. It does not matter how much hour he spent on this project as long as he can commit to the same effort in the subsequent iterations.
If the remaining stories' points amount to 40, we know that, on average, the number of remaining iteration will be 40 / 7 ~ 6. We may give a range of 5 to 7 or 4 to 8 iterations as the time estimate.
After more iterations, the velocity estimate is adjusted as the sample which we measure it on increases in size. The average velocity can be used to re-estimate the number of remaining iterations, providing a stricter range and updating the project schedule with newer informations. The team and the iteration length should be consistent during the project to take advantage of these metrics.

If you want to deepen your knowledge of this subject, I reviewed a book which may be propedeutic to this goal: Agile estimating and planning.