Reviewing in SCRUM

reviewinscrum“In our SCRUM team, we do not need to perform reviews.” is one of the first remarks when talking about reviewing. I think more reviews are done than you might be aware of. A first thought below. Can you think of more situations in which you review in a SCRUM situation?

It starts with the items on the backlog. Are these clear to everyone concerned? What does ‘clear’ mean? Can you build, test and accept the items, or is any extra information needed to do this? Asking yourself this question is already static testing the backlog items. Why not do this in a structured way?

  • Pay attention in the retrospective to see if there are any learning points mentioned that can be prevented at the start of a sprint by clarifying the backlog items.
  • Evaluate for yourself: did you ask for clarification on the same subject for more than one backlog item? It might be good to add this subject to your review-checklist at the beginning of each sprint.
  • Are clarifications, if necessary, always directly updated into the backlog item descriptions? If not, consider the option to perform the review (using a checklist) during the planning poker. Update the items directly when a clarification was needed.

Then static testing during the sprint. Are static tests done on code, (website)content or regression test cases? These are reviews, too! Depending on the situation you can discuss your findings directly with the author, or you can group you findings and deliver it in a batch. In all situations, a strategy can help you in structuring your review and making it as effective as possible. Use checklists (which you maintain during the sprint retrospective) to be sure not to forget specific subjects during your reviews.

  • Static code review: sometimes peers or testers are asked to review a piece of code a developer just created. Using a checklist based on previous experiences,  it becomes easy to maintain grip on the review. It also makes the review more predictable when other team members are asked to perform the review. Most of the time, findings can be fixed directly.
  • Review content: in some situations textual content is part of a deliverable. For example in websites, news letters, communication to customers, billing etc. it might be needed to review the contents before the item it Done. In some situations, findings can be fixed directly. In other situations it might be needed that more people, even from outside the SCRUM team, need to take a look. A more structured approach of the review might come in handy. The process as described on this website is a good starting point. Use whatever suits your situation.
  • Review (regression) test cases: test cases in SCRUM sometimes are considers ‘throw away test cases’. A peer review at the coffee machine might be useful enough. On regression test cases, which probably will exist for a longer time and which are quite important during the whole project to prove stability of the business value, might require a more intense review. If more than one or two reviewers are involved, especially if these people are not all part of the SCRUM team: a more strict process will be useful to keep the review within it’s time boundaries and to make sure all participants focus on their personal area of interest.

At the end of the sprint, during the sprint review, a demo is given of the items that are ready to be delivered. This demo also is kind of a review; in a live setting a product is shown to one or more reviewers who can comment on what they see. It can be organised as any review or inspection meeting. Time-boxed, some form of comment administration and a moderator (i.e. the scrum master) who leads the session.

In SCRUM, reviews are part of the daily activities. Without having a review process, the review activity itself can be structured in a way that suits the situation. The structure, be it in the form of checklists or in the form of agreements (mentioned in the DoD!) provides the team a guide to catch as much as possible during the reviews.

— update 12-01-2017 —
A slightly adjusted version of this blog is published (in Dutch):
– Tijdschrift voor IT Management 01-2017 (