While I appreciate your suggestion, I think you may have missed my point. I'm not saying "I'm having a problem keeping my velocity high", which is what I think you are hearing. Instead, I'm saying "the whole concept of velocity tracking doesn't apply well during the acceptance testing phase."

Useful velocity tracking is based on two things: a constant time period (one iteration), and an estimated number of ideal days of work to do in that time. Say you accomplish 6 ideals in the iteration; your velocity is 6 (*).

So, what happens when you need to estimate the following story: "Figure out why the output file is corrupt."

It's (comparatively) easy to estimate how long it will take to construct something. But how do you estimate how long it will take to have a flash of insight?

--Whitehawke

* As an aside, I prefer to divide the ideals by calendar days in the iteration, so I would say that 6 ideals completed in a 2 week iteration is a velocity of (6 ideals accomplished/14 calendar days to do them == ) 0.43. Doing it this way automatically normalizes all iteration lengths against each other, making for easier historical comparisons.