How to assign reviewers in Scrum with code review

Question

In Scrum, what strategy should the team use to efficiently assign reviewers to tasks/stories?

A reasonable Definition of Done contains a requirement of code review:

The source code must be reviewed another programmer.

I'm interested in how the process of selecting a reviewer should interact with the board.

I've seen multiple approaches:

• Scrum board isn't concerned with code review. Effectively, the author and the reviewer work together to move the task to the Done column.

  This is quite flexible, but the downside is that the author must find a reviewer "behind the scenes" and convince him to spend time on the task. Sometimes the reviewer is not available/non cooperative (*). Sometimes both parties just forget.

• There's a special column named something like "waiting for review". A reviewer takes a task and performs a review (gives OK or moves it back to "in progress").

  This makes the process transparent, but it doesn't really represent what happens during code review. Usually, there are multiple exchanges or multiple commits, so the bureocracy feels unnecessary.

• One commit per task on the board

  This looks like an attempt to solve the problem from the previous point, but fails when the project is something more than a single git repository. This also creates bureocracy barriers for the good practice of focused commits.

• The reviewer merges on OK

  The reviewer merges a commit on OK and closes the task. This speeds up some bureocracy, but fails when the task involves additional work outside the repository.

(*) Especially when the developers are evaluated on the number of tasks closed/story points gathered.

Answer 1

Let the Team Self-Manage Its Processes and Supporting Tools

Scrum doesn't mandate code-level practices. From a framework perspective, that's an implementation detail that's up to the Scrum Team to decide.

Ideally, you shouldn't be "assigning" anything to anyone. Scrum (and agile practices in general) are based on pull queues and collaboration. The central notion is that a self-managing team is motivated to get a story to "done" within a time box, and that the people collaborating on prepping a user story for the Sprint Review will validate that the Definition of Done has been met.

Code Reviews with Branching Workflows

There are certainly tools that a Scrum Team can adopt to enforce its chosen workflow, but there's no universal standard. Once the team has decided on a workflow, it can select tools that automate and support that workflow. One example would be leveraging protected branches in the Development Team's source control tools.

In Git, branches are just pointers. There are a lot of different Git workflows, but a common one is the use of feature branches to represent user stories or Sprint tasks, which are then rebased onto the master or release branch once they've been completed. If "completion" includes code review, Github supports setting a required number of code reviewers before merging onto protected branches. Bitbucket supports very similar functionality.

Why "People Over Process and Tools"

It's worth remembering that most technical controls support administrative processes like code reviews. They represent a check step, and can automate elements of a sign-off and create audit trails, but they can't actually validate the quality of the reviews or force people to do more than pay lip service to the process if they aren't actually on board. In the end, you're still relying on people to be invested in the process, and to work together to deliver the product.

It's usually better to require the team to inspect-and-adapt its own processes based on empirical outcomes rather than inflexible (and often arbitrary) standards. If the Development Team finds that enforcing code review standards improves the team's productivity or output quality, then they should select workflows and tools that support that. Alternatively, almost anything the Development Team does that allows it to meet the negotiated Definition of Done and the Sprint Goal is okay provided it's sustainable. Perhaps pair programming and continuous integration are sufficient to sustain the pace of development and quality targets; if so, larding the process becomes an impediment rather than a facilitator.

Focus on Outcomes, Not Implementation Details

Set goals, and then let the team self-direct. Coach when necessary, but don't fall into the trap of thinking that more process or heavier-weight controls are inherently better. Scrum is all about "good enough for right now" with room for continuous refinement, and it's all too easy for a good practice like code review to take on a life of its own or become a rubber stamp. Focusing on the outcomes, rather than on the implementation details, avoids that trap.

Answer 2

As per Scrum Guide, the "Definition of Done" does not include code review.

Code reviews totally depend on development team and practices they follow. Every development team must have an agreed coding standard that contain code reviews as part of normal practice and considered during task estimation or sprint planning.

This means if a story is estimated and broken down into tasks by development team then code review may be the part of it.

What development team should not do is to do code reviews as an activity not linked to any user story.