Priority of a Code Review in Scrum?



  • Let's say we're talking about a Scrum development team.

    A task can be implemented wrong or the implementation may contain unaccetable flaws. If this is discovered near the end of a Sprint the Sprint Goal may not be achieved. So a code review is an important procedure and should be performed as soon as possible from the possible risks' point of view.

    On the other hand, if a developer performs a code reviews (of ther developers' tasks) two or more times during a day, then this inflicts a considerable context switching.

    In a Scrum team, when should a developer perform a code review of another developer's task?

    • after completing their own task (another developer's task becomes blocked, increased risks)

    • as soon as possible (may inflict a lot of context switching)

    • a policy is required (e.g. a developer performs all code reviews at the end of the day)

    I'm inclined to the last option. What is your approach?



  • Scrum intentionally does not layout exactly how the team will build the product. There are a number of reasons, but most pertinent to this question is that what works for one team may not work for another. Similarly, what works with the tools of the early 2000's may not apply as well today.

    One of the reasons we work in iterations is because it gives us the opportunity to refine our process. I would encourage the team to identify what they think may work best, try it, then review. You could even pick 2 or 3 different approaches, try each for a sprint, then reflect on the results.

    There is the logical notion that after all of these years, some best practice must have come out. While it is sensible to think this, the truth is that a development team is a complex environment. People have different preferences about how they work, code may be worked on at varying levels of granularity, and many other factors will come into play. Even today, weekly code reviews will work perfectly for one team and pair or mob programming is the solution for another.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2