My team uses Agile as a development approach. Currently, each task has four states which are todo, in progress, testing, and done.
We've just started doing code reviews, and I wonder if I need to create a code-review task or I should add time for code-review to the estimation?
Reviews are part of the work that needs to be done to bring a task to completion, just like implementation and testing. For that reason, the review effort should be included in the estimation for the task.
As you already have different states for implementation and testing, it makes sense to add an additional state to indicate that the code for a task is being reviewed.
On a side note, if you find that implemented tasks often can't be picked up immediately for review or testing (because the other team members are busy on other tasks), you might want to add kanban-like "waiting states" to your tasks, like "ready for review" and "ready for testing". This can make it clear if there might be a bottleneck in the review and/or test phases, by having a pile up of tasks in the "ready for" states. It also means that the one who wrote the code doesn't have to assign a reviewer/tester (or ask around for one), but anyone with a spare moment can pick up a pending review/test task.
We have used both. When you have a seperate review task you can assign time to that task and it is visible for everybody. But you get a lot of tasks on the board. We use a whiteboard with post-its so real estate is limited, being somewhat of a disadvantage.
At the moment we use a seperate state for review. This is less of a hassle when updating for a new sprint. An we use it also to have the code functional reviewed. In our team another developer does the technical code review and the domain specialist does a functional review.
For now a seperate state is our favoured method.
It depends.
Personally, I like having tasks for code review work since it allows those things to be estimated properly. It also creates a tracking item that clearly shows if/when it gets done. And it lets you explicitly assign someone to do the code review, and keep that work balanced.
But I am also of the opinion that not all work needs code reviews, and certainly not always formal ones.
If your organization requires code reviews for everything, then it becomes a bit of boilerplate work to create all the tasks, and it represents a unit of work that is separate. If you're requiring it for everything, you don't want it separate - you want it ingrained as "something as natural as planning/coding/testing". So while I think that this approach to software development is overkill at most places, it is appropriate in others. In those cases, I would work to make code reviews a step in the process, not separate tasks.
Before adding new states of any kind, I recommend considering what you'll use that state for. If there is some metric you're trying to track like cycle time in that state, then it might be beneficial. Otherwise, what's wrong with including code reviews in your definition of done?
I don't see the need to add additional complexity to your process just for the sake of having it. Is there value in having that state? What are you going to do with the information that knowing a thing is in that state gives you?
