Section 5.3. Walkthroughs | Applied Software Project Management

5.3. Walkthroughs

A walkthrough is an informal way of presenting a technical document in a meeting. Unlike other kinds of reviews, the author runs the walkthrough: calling the meeting, inviting the reviewers, soliciting comments, and ensuring that everyone present understands the work product. It typically does not follow a rigid procedure; rather, the author presents the work product to the audience in a manner that makes sense. Many walkthroughs present the document using a slide presentation, where each section of a work product is shown using a set of slides. Work products that are commonly reviewed using a walkthrough include design specifications (see Chapter 7) and use cases (see Chapter 6).

Walkthroughs are used when the author of a work product needs to take into account the perspective of someone who does not have the technical expertise to review the document. For example, a requirements analyst must make sure that the use cases she builds will provide the functionality that the users need, but the user representatives may not have seen use cases before and would be overwhelmed by them. If these users are simply included as part of an inspection team, it is likely that they will read the document and, failing to find many defects, sit silently through the inspection meeting without contributing much. This is not their faulttheir training is in the business of the organization, not in reading and understanding software engineering documents. This is where a walkthrough can be a useful technique to ensure that everyone understands the document.

Before the walkthrough, the author should distribute any material that will be presented to each person who will be attending. For example, if the walkthrough is done as a slide presentation, copies of the slides should be emailed to the attendees. If only a portion of that material is going to be covered, that should be indicated as well.

During the walkthrough meeting, the author should solicit feedback from the audience. This is an opportunity to brainstorm new or alternative ideas, and to check that each person understands the document that is being presented. The author should go through parts of the document to make sure that it was presented in as clear a manner as possible.

These guidelines can help an author lead a successful walkthrough meeting:

Verify that everyone is present who needs to review the work product. This could include users, stakeholders, engineering leads, managers, and other interested people.
Verify that everyone present understands the purpose of the walkthrough meeting and how the material is going to be presented.
Describe each section of the material to be covered by the walkthrough.
Present the material in each section, ensuring that everyone present understands the material being presented.
Lead a discussion to identify any missing sections or material.
Document all issues that are raised by walkthrough attendees.

After the meeting, the author should follow up with individual attendees who may have had additional information or insights. The document should then be corrected to reflect any issues that were raised.

Note: Additional information on walkthroughs can be found in Peer Reviews in Software by Karl Wiegers (Addison Wesley, 2002)