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.
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.