Velocity Doesn't Care

Velocity could be called the Switzerland of software metrics.  It is team, unit, and of special interest in this case, estimation accuracy independent.  The great thing about velocity is that even a team of really bad estimators can benefit from velocity. 

Velocity, especially when using a higher-level or time independent unit like points or ideal days, removes the reliance on accurate estimation.  Even if a team traditionally estimated tasks at half of what they ultimately took, velocity does not care.  Instead of the reliance on accuracy, the reliance is on relative consistency. 

Regardless of how long and feature or bug actually took to deliver, if the team consistently delivers 20 of these units every iteration, then they have reliable metric.  It may take 30 hours to complete or it may take 300 hours, but if they know that they can deliver 20 of these units every iteration, then the team can do a better job of predicting the future, especially the near future with better accuracy and predictability. 

As important, if the team consistently delivered 18-23 units of velocity every iteration for the last 6 iterations, then they probably know what their next iteration looks like.  Even more valuable, they also know what their next 6 iterations could look like.  They may or may not want to plan that far out, but just to have greater confidence in the team's ability to deliver approx. 120 units of value over the next 6 iterations is of tremendous value, and something that the team and the company can use for making real business decisions.