Trying to minimize "pending for code review" time

February 25, 2018

In this article I will try to explain shortly why every agile team should try to minimize the delay of starting the code review. 

As you probably know, delivering a user story in a sprint requires several steps. Usually in scrum, these stories are visualised using a board. Physical, electronic or both. The basic columns, and therefore the steps, most teams are using are:

 

1) To Do

2) In Progress

3) Code Review

4) Validation - QA

5) Done

 

Why code review step is an important step?

The code review step, gives the signal to the team that a part of code is ready to be reviewed. This implicitly means that there is a hope this subtask of a user story or the user story itself will be done soon.

 

The team member invites other team members to review the code and give feedback. The feedback is if it's OK to be merged or not. At least that's the flow most of the times when we don't use pair programming. 

 

 

 

In case the code part cannot be accepted for merge, and there is feedback indicating changes to the team member who wrote it, these changes should be applied. After implementing them, the code should be submitted again for Code Review.

 

Another reason this step is important is because if that code is OK and approved, a part of the user story may be ready for QA. QA usually is the final step of the flow and if successful we mark the story as done. 

 

Risks of many pending code reviews

Having mentioned the importance of the code review, we realize that this step can cause delays in the flow of the sprint. Why is that? Because if we delay to give feedback to the team member who wrote the code we risk two things.

 

a) If the feedback contains suggestions for many changes in the code, the developer will need time to do them.

b) If the developer has already spent much time into the next task the context switching back to the previous task could be harder and therefore extend the delay.

Delay means potential bottleneck at this step and the risk of having multiple things for the QA phase is visible. If this accumulates then you may have to close multiple stories at the end of the sprint producing a mini waterfall model. Also it will produce a weird looking burn-down chart and of course the team increases the possibility not to deliver all stories on time.

 

Awareness for pending code reviews

Having mentioned the importance of the code review, we notice that depending how the team manage that step, can be decisive for how efficient the work is done.

 

 

Firstly you have to visualize the flow (borrowing the rule from Kanban). Secondly you have to keep focus on the code review column. Particularly for tasks that they are accumulating there. Also you can use color in this column in your physical board to indicate the importance.

 

Keep things flowing

If the team members are updating the tasks in the board daily then some important improvements could be made.

 

 

 

Rules like:

a) Agree with the team that the reviews should take priority when they occur

b) Set idle maximum time and try to pick the task for review earlier than this

c)  Immediately inform the team if a task moves to this column

d) Try to find people that can do the review immediately

e) Keep in mind to check the column at least in the daily standup

 

Keeping the flow in a sprint either by small improvements like this or managing dependencies and impediments, is necessary for achieving the sprint goal.

 

 

 

 

 

Please reload

Featured Posts
Please reload

Nikos Raptis -
Agile Coach, Speaker & Developer

I'm a scrum master, speaker and software developer. I love Agile values and principles and...

Contact me

© 2015 Created by Nikos Raptis

  • Google+ - Black Circle
  • Twitter Black Round