In a recent post I praised forecasts based on velocity and said everyone should use them. I would be remiss if I didn’t point out that using velocity to directly estimate end dates will cause you to be late. The culprit here, as in much of development, is bugs.
Some tools go to great lengths to lead you astray. In the Pivotal Tracker FAQ, you find this answer to “Why can’t I estimate bugs?”
By default, only features can be estimated. In contrast to features, bugs tend to emerge over time, and while they are a necessary part of your project, they can be thought of as an ongoing cost of doing business.
Tracker’s automatic velocity calculation frees you from having to account for this cost. By measuring velocity in terms of features only, Tracker can estimate how much real, business-valued work can be completed in future iteration, allowing you to predict when project milestones might be achieved, and allow you to experiment with how any change of scope might affect such milestones.
After all that, they admit that you can enable bug estimation if you must. That’s good. They pack an amazing amount of wrong into those few sentences: suggesting that features don’t tend to emerge over time, for example; Or that software development should be thought of in project terms (the root of much evil); Or that the business value of software can be considered independently of defects (all defects reduce value; there’s some threshold above which the software would be worthless); Or the subtle suggestion at the end that the impact of scope increases will be linear…. but I’ll stick to the impact of bugs on velocity. 
If you follow their recommendation, how bad your estimates will be wrong depends on how you manage your rework cycle. I’ve included the diagram here for reference.
You could choose to measure velocity purely on features, ignoring the bottom half of the diagram. All bugs will accumulate in that case (while you’re off adding business value), but you’d be adding a potentially large, but un-estimated pile of work to the end of your plan. Depending on the defect rate, the bug-fix effort can easily be greater than the feature work. I have to assume that’s not what the Pivotal folks have in mind.
In the best case, you fix bugs as you go. In this scenario, bugs do have an immediate impact your velocity, and your predictions will be better, but you should keep in mind that the only way that velocity can fully account for defects is if these assumptions hold:
1. You find all of your defects with no delay.
2. You fix all of your (must have) defects before moving on to the next bit of feature work
The first assumption will never hold in the real world; the second is just extremely unlikely.
In any other scenario, your velocity calculation will be optimistic and your projections wrong. Going back to the Pivotal example, if you don’t fix all your bugs before moving on, you must estimate them to keep your velocity reasonably correct.
In general, if you have a highly effective test process and keep the known bug count at a constant value, the delay will also be constant. But if you allow bugs to accumulate un-estimated in either the known or unknown state, your projections will be off by a growing amount as work proceeds. And that could turn out to be a big problem.
 I edited the Pivotal quote slightly for readability. Pivotal is one of the best tools around so the shear amount of misunderstanding suggested in those paragraphs is some indication of how much folklore and urban legends still drive engineering management.