Many a times developers come back with the question,
Can I consider defect fixing as part of the velocity ?
Broadly speaking I have seen following types of answers
1. No, do not track it as part of velocity
2. One should negate these points from the velocity
3. Track it in a different bucket
Let me explain the above types in detail.
1 & 2. Do not track it as part of velocity and may be one should negate it : Many thought leaders believe that, tracking defect fixing leads to double counting of velocity. People who advocate this believe in delivering quality code with ZERO defects, each time and every time. Velocity is measured as part of delivering a quality code with no defects. So, the defect found in the future is nothing but your past sin in creating the defect. They believe that, rather than asking for credits, deduct the velocity.
Many developers feel that deducting velocity is more like punishment, and punishment will not improve the code quality. There has to be a better way.
3. Track it in a different bucket : Instead of worrying too much about deducting or not tracking, go ahead and track it. Try to have “Defect Velocity” as a separate bucket. During estimation, one could look at the Defect velocity and plan the “DBT(Design, Build, Test) velocity”.
There will be some defect lurking in the code all the time. Even the complex and popular operating systems like Windows OS and iOS have defects in the shipped product.
As long as the “Defect Velocity” bucket is predictable, its in a good shape.
Summary: Type 3 feels better than Types 1 and 2
Tell me which type do you follow in your project ?