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 ?
3 comments:
If I am reading this right, it feels like you are talking about Defects discovered after release. If that is so I am inclined to say Option 3 would make perfect sense. In fact, that is the Defect Detection Percentage (DDP) that we often use.
I don't think that this should have any direct correlation to Velocity. Rather I would think a team would track their DDP to ensure they are still delivering a quality product. If their DDP were to be too low they may need to evaluate their testing practices to see why it is that so many defects are getting by them. That is the way we use DDP.
Dean, this applies to the defect fixing within an iteration too. Defects coming from N-1 or N-2 Iterations might get prioritized to be fixed at a later iteration. So, should the effort spent in fixing these defects be counted towards the velocity is a common discussion among new Scrum teams.
Excellent points ... I am assuming that you are discussing defects discovered before a new sprint starts ...
I do not count those as part of the velocity calculation
Post a Comment