3

As said many times before (1, 2, 3):

"Do not estimate bugs / defects".

I know in Scrum we try to minimize the defect rate, but it happens now and then. Fixing such unestimated tasks might have big effects on the actual velocity of the team. I wonder if there is some kind of proceeding or formula to make this visible to the team and to others?

Or is it just, that an increase of defect rate (= drop of velocity) is a sign we should pay more attention to our QA?

As we do not estimate Bugs, this one is not a duplicate of that question: Tracking points spent on bugs during sprint

2

If you are measuring a long(er) running project with velocity to get an idea when features or milestones will be reached it is a good idea to not estimate defects. Defects are work that should have been completed in other points already in the past. If you have a lot of defects now, probably you will have the same amount in the future, slowing your whole project down. It would give a false sense of speed if you give non-valuable work story-points. Velocity goes down when you have defects or technical-debt.

An increase in defects or decrease in velocity should always result in a good root-cause analysis during a retrospective to find ways to prevent similar mistakes or improve the process. If the cause is really your QA process is something you have to find out, as it greatly depends on the situation.

Some metrics I like to use to signal issues:

  • Average velocity over time (should go up or stay stable)
  • Defect count vs complete features count (feature side should go up)
  • Time spend on defects (should go down or stay stable)

These should be pretty stable or going down/up, depending on the metric.

Now from experience the root-cause of most defects is most often not the lack of a QA process, but an architecture or design that has a lot of coupled dependencies, making it hard to maintain and extend the code base. Often it is hard to create test-automation for it and therefor it hard to refactor and clean it. I always suggest to watch the first episode of Clean Code to get an idea of common issues with code.

  • This is all true and reasonable - thanks for the input. But my question targets, how to make these "problems" visible to the team and others. If I only show the velocity, people outside the team only see a drop. I want to simple explain what caused the lower velocity and thought there might be an easy to understand approach. – ppasler Jun 6 '17 at 8:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.