How many times do you verify a task in Scrum?

Question

On our Scrum board, tasks start at 'To Do', go to 'In Progress', and when you're done with a task, they move to 'To Verify' before ending up in 'Done'. The 'To Verify' column is when you're done with a task and someone else can have a look at it, test it, and comment on it.

This has proven helpful for errors, better code, etc.

To people who have a similar practice: after the developer has addressed the comments/errors, do you verify it again, or do you assume the issues have been addressed and move the task to 'Done'?

I hope this is clear, and would like to hear your thoughts.

Answer 1

In my expirence the fixing of bugs have a 50 - 75% chance of introducing new bugs, especially if the code if not covered by test cases. I would certainly verify it again.

Answer 2

This question is not specific to Scrum, I've seen this problem outside agile processes too.

The answer turns out to be: it depends on the issues raised in verification. If there are minor issues raised, and the responsible developer is senior enough, then trust him to fix things the first time around. But if the person doing the verification considers the items too complex, or the Scrum Master lacks the confidence to trust the developer to get it right the second time around, then you move the post-it back to In Progress.

A good example of the kind of error you don't bother checking is a simple typo. A good example of something you would check again is an error in a boundary condition, when there are many interdependent boundary conditions.

Answer 3

Never assume the issue as being addressed until it is independently (i.e. not by the person who fixed it) verified.

Answer 4

We have no To Verify column. A task is in progress till it has been implemented and tested. An untested task cannot be done and why should someone else test it, report back to the programmer and then the programmer has to fix it? This only adds latency to the workflow. The programmer should test his own code, write unit tests for it if possible and integrate it into the app if possible and test it here as part of a natural workflow. That way he finds his own bugs and can immediately fix them. When he sets the task to Done, he's not only convinced to have fully implemented the task, but also that the task is bug free.

Okay, we all know, that means little. Sometimes bugs are found much later, but these are then not so obvious bugs and usually their fix will be a task of its own.

Answer 5

In the projects I have been in (both agile and non-agile), bug fixes were always verified by someone else. Quite often new bugs are introduced, so a bit exploring around the fix is needed. I have even seen some debug code forgotten in the build - everything works fine but extra files appear from nowhere.

Its also possible the developer did not find all paths to a bug, or that the bug report was so unclear that the developer made a wrong fix - e.g. if something has been misunderstood, and correct functionality is reported as a bug.

To ensure things stay done when they are done, tests for the fix should also be added to your automated tests - otherwise some embarrassing corner-case bug will re-appear months later.