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?

  • 8
    Why aren't you considering 'review' a state (be it code or whatnot)?
    – user40980
    Commented Sep 5, 2014 at 3:58
  • 2
    I am concerned that you said "time" for your estimate. You will have trouble improving your process if you don't move to points.
    – Boggin
    Commented Sep 5, 2014 at 11:25
  • @Boggin which raises the question of estimating code reviews, perhaps half the points of the feature being written or something similar...
    – Liath
    Commented Sep 5, 2014 at 14:41
  • @Boggin what's the downside of estimating by time?
    – Anonymous
    Commented Sep 8, 2014 at 8:05
  • 1
    @Anonymous Use Story Points (SPs) as relative estimation is more correct than absolute estimation. There is no linear correlation between a SP and the number of hours. A SP is a universal measurement across the team. It’s difficult and time-consuming to to get developers to estimate time to completion. A Product Owner wants to know how many features the team will deliver not how many hours each of them take (working software instead of very accurate estimates). Measure the team's velocity. [escapologist.wordpress.com/2009/11/06/…
    – Boggin
    Commented Sep 8, 2014 at 8:33

4 Answers 4


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.

  • 1
    Concur. The reason for tracking state is to increase visibility of what's where, and to get it out of your head. If you have to remember which "in progress" tasks are really "done, waiting for review" and which are "really being worked on," you're not getting the full value from task tracking. Genuine "pending" or "wait" states deserve genuine acknowledgement. Commented Sep 5, 2014 at 18:01

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?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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