Reviews are about examining some output or artifact for quality and agreement. I primarily think of this process in terms of my framework, as shown in the figure below, but many contexts are valid. In my framework, review means building up the relevant work products in each phase and having them reviewed by the customer and reworked by the solution team until they are accepted and approved by all participants. I often talk about how the framework involves continuous iteration within and between phases, and this is always based on different kinds of reviews.

Here’s how review tends to work within each phase. For clarity the activities are described from the point of view of an external solution team developing something for a customer, but it should be understood that the line between the solution team and the customer can vary from sharply defined (I spent most of my career functioning as an external vendor or consultant) to nonexistent (internal groups can analyze and develop solutions for their own problems).

  • Intended Use (Problem Definition): The team helps the customer ensure they’ve identified the problem and purpose correctly.
  • Conceptual Model: The team documents the results of its discovery and data collection processes, and then the customer verifies that the team has achieved accurate and complete understanding of the customer’s processes and vocabulary.
  • Requirements: The team elicits requirements from the customer and collaborates to ensure that the most complete and accurate possible list of both functional and non-functional requirements is generated.
  • Design: The team proposes a design and the customer decides whether to approve it or not.
  • Implementation: The team implements the designed solution with input and continuous review by the customer.
  • Test (and Deployment and Acceptance): The team and customer complete different kinds of verifications and validations.

The customer ultimately provides the final approval or non-approval for each phase. Part of the iteration between phases involves updating the Requirements Traceability Matrix to ensure consistency horizontally between phases and logical consistency vertically within the Design/Implementation phases. Multiple individual iterative create-and-review processes may take place, serially and in parallel, within each engagement phase (that is, the figure above is a stylized, simplified representation of the overall process). Imagine everything that must be going on in an engagement involving multiple teams in a SAFe environment, as shown below.

The Scrum framework incorporates two explicit review activities. In the Sprint Review, the team describes and demonstrates the latest work increment for the customer. In the Sprint Retrospective, the team (without the customer) reviews its own working methods during the just-ended sprint. It should be understood, however, that all of the other kinds of review are still taking place.

Conducting a review involves defining the objective of the review, choosing the techniques to be used during the review, and selecting the participants in the review.

The following review techniques (named and described in the BABOK) can be used (among others).

  • Inspection: This is a formal process of reviewing some or all work products to determine whether they meet defined criteria.
  • Formal Walkthrough (Team Review): These are typically performed to review the methods and behavior of internal teams.
  • Single Issue Review (Technical Review): This is a formal review, often involving a specific technical aspect, of one outstanding area of concern.
  • Informal Walkthrough: This is a fairly informal process of reviewing an item and soliciting feedback from a small number of participants.
  • Desk Check: This informal process drafts an outside participant to perform the review.
  • Pass Around: In this process, many people review the item or items and offer feedback, usually one after the other.
  • Ad hoc: This can be any type of informal review by any type of participant.

Can you think of any additional review techniques?

Finally, the BABOK identifies the following roles. An author creates a work product or artifact. A reviewer is anyone who looks at the work product or artifact and offers feedback or approval (or non-approval). A facilitator is a neutral participant who guides a review process for others. A scribe documents the actions and results of the review.

This entry was posted in Tools and methods and tagged , , . Bookmark the permalink.

Leave a Reply