Formal Walkthrough

Goal

Of BABOK's seven reviews, the formal walkthrough is the one whose definition comes down to two activities: it uses the individual review and the team consolidation often seen in inspection, and walkthroughs, BABOK adds in the same sentence, are used for peer reviews and for stakeholder reviews (§10.37.3.2). Each reviewer receives the work product several days before the session and examines it alone; the session gathers what each of them found on their own. The whole economy of the technique comes out of those two activities alone.

BABOK gives this review its other name inside the definition itself, "Formal Walkthrough (also known as Team Review)", and it is that second name a reader needs in mind to read Wiegers. His comparison table carries two columns, team review and walkthrough, which are BABOK's formal walkthrough and its informal walkthrough (10.37d).

BABOK lists seven possible objectives for a review (§10.37.3.1), and the formal walkthrough serves four of them, one of those by half. Remove defects: Wiegers' Table 3-3 marks that row for the six methods he compares, and he bounds it for this one, one industry study having found that this type of team review discovered only two-thirds as many defects per hour as inspections did (Van Veenendaal 1999). Check conformance to a specification or a standard: BABOK's objective bundles two, and Wiegers separates them. He grants the team review conformance to a specification and refuses it conformance to a standard, and his prose says the same thing, the review serves to identify the ways in which the product does not satisfy its specifications. The half that leaves has somewhere to go: a single standard that has to be settled belongs to the single issue review (10.37c), and a reader alone with the text of the standard to a desk check (10.37e) or a pass around (10.37f). Establish consensus on an approach or a solution: being less formal than inspection, Wiegers writes, team reviews might also devote some meeting time to discussing solution ideas and having participants reach consensus on a technical approach. The agreement also leaves a trace, since an appraisal of the product comes out of the session (Wiegers, Table 3-2). Educate reviewers about the product: Wiegers sees a good learning opportunity for the participants in it, and the informal walkthrough (10.37d) serves that objective just as well.

Three of the seven escape it. Ensure the work product is complete and correct: Table 3-3 marks completeness for two methods only, the inspection (10.37a) and the informal walkthrough (10.37d). The formal walkthrough does bear on the whole work product; what it lacks is the objective of establishing that nothing is missing from it. Answer a question, resolve an issue, explore options: BABOK's fifth objective bundles three, and the formal walkthrough takes none of them. Wiegers grants the exploration of options to the informal walkthrough and to pair programming. A bounded question is put to an available peer, which is the ground of the ad hoc review (10.37g); an issue that has to be settled is convened as a single issue review (10.37c); options are weighed against each other in front of the group the author has gathered, which is the ground of the informal walkthrough (10.37d). Measure work product quality: Table 3-3 reserves the measurement of a document's quality for the inspection (10.37a).

Two rows of Wiegers' table that BABOK's list does not carry are nonetheless this review's own. Assess the understandability and maintainability of the document: the individual reading is the reviewer's private encounter with the document, and that is where it is judged whether it reads without its author. Table 3-3 marks that row for the inspection, the team review, pair programming and the pass around (10.37f), where readers meet the document each on their own. In a formal walkthrough the author is in the room during the session, and the reviewer met the document without him during the reading. Collect data for process improvement: Table 3-3 marks that row for two methods only, the inspection and the team review. Wiegers writes that the team collects data on the review effort and on the defects found, and his Table 3-2 bounds the practice, data collected and analyzed being a "maybe" for the team review, where it is a "yes" for the inspection. The objective is the team review's; the activity remains optional.

What it leaves behind is a consolidated set of findings and an appraisal of the product. The first is what BABOK's definition names, individual review then team consolidation, and the scribe records it in session (Table 10.37.1). The second is in Wiegers: his Table 3-2 marks the row product appraisal determined for the team review, and his prose says what that means, a team review allows a group of qualified people to judge whether a product is suitable for use. The session pronounces, and it does not come back: Table 3-1 marks correction for the team review and refuses it verification. The author corrects. A finding that has to survive the session belongs to item tracking (10.26).

Usage

When to use it

• An agreement on the work product has to be evidenced: the appraisal comes out of the session (Wiegers, Table 3-2).
• The product has to be held against a specification: Wiegers grants that conformance to the team review (Table 3-3).
• Whether the document reads without its author has to be known: each reviewer meets it alone, before the session.
• Individual readings have to be consolidated as a team: that is BABOK's own definition (§10.37.3.2).
• The review has to feed data on the review process: Table 3-3 marks that objective for the inspection and the team review only.
• The product does not call for the full rigour of an inspection: Wiegers puts the technique's own case there, a group or a work product that does not require the full inspection process.

When not to use it

• The product is not critical enough to pay for a prepared session: BABOK writes that rigorous team reviews take time and effort, and that only the most critical work products might therefore be reviewed using inspection or formal walkthrough techniques (§10.37.4.2). A desk check (10.37e) puts one competent reviewer in front of the document; a pass around (10.37f) puts several, each on their own.
• What is missing matters more than what is wrong: Table 3-3 refuses completeness to the team review. An inspection (10.37a) covers the product in small chunks; an informal walkthrough (10.37d) has its author narrate it end to end.
• The question bears on one standard, and it has to be settled: Wiegers gives the team review conformance to a specification and refuses it conformance to a standard (Table 3-3). A single issue review (10.37c) exists for that matter and for it alone.

Description

Read alone, then consolidate

BABOK gives this technique no steps. Its definition names two activities for it, and Wiegers describes both.

The individual reading. The participants receive the review materials several days prior to the review meeting and are expected to study them on their own. It is the technique's main cost and it is its condition: a formal walkthrough where nobody has read starts reading, and a reading in the room is another review.

The consolidation in session. Wiegers describes the mechanism in one sentence, and he builds it by contrast with the inspection: instead of having one participant describe a small chunk of the product at a time, the moderator asks the participants if they have any issues on a specific section or page. His Table 3-2 confirms it twice, the granularity of the material presented is the page or the section, and the one who presents the material is the moderator. BABOK says the same thing from the side of the role: the facilitator ensures that each relevant section of the work product is covered (Table 10.37.1). The formal walkthrough canvasses the product section by section, and asks each reviewer what they found.

Who facilitates, who records. BABOK lists the facilitator among the roles applicable to the inspection and to the formal walkthrough, and it specifies that this facilitator should not be the author, in order not to compromise the review (Table 10.37.1). It lists the scribe for the same reviews and for the informal walkthrough (10.37d): it is the facilitator who separates the two walkthroughs, and the scribe is common to both.

Where the formal walkthrough sits

BABOK lists its seven review types in decreasing formality and calls the first three formal techniques, the next four informal techniques (§10.37.3.2). Two binary questions cut across that ordering: is the session planned, does the reviewer examine the product alone before speaking? The formal walkthrough answers yes to both, like the inspection (10.37a) and the single issue review (10.37c).

In the two standards of the field, the word walkthrough names the review the author leads himself, the least formal of their types: IEEE 1028-2008 lists it among its five review types, ISO/IEC 20246:2017 among its ten, and it is the one BABOK calls an informal walkthrough (10.37d). The formal walkthrough, for its part, is found in Wiegers, who calls it a team review, and BABOK takes that name up in its definition.

The two walkthroughs carry seven objectives each

Wiegers' table of objectives compares six review methods on fourteen objectives. His team review column carries seven of them, his walkthrough column, which is the informal walkthrough (10.37d), carries seven, and only the inspection (10.37a) carries more, eight. Four rows are common to them. The other six split three and three. That is where the difference plays out between the two reviews that share a name.

One activity separates the two columns, and Wiegers' Table 3-1 names it: the preparation, which he marks for the team review and refuses to the informal walkthrough (10.37d). BABOK says the same thing, since its reviewers may do minimal preparation. That activity trades three objectives for three others.

What it buys, only a reader alone with the document can produce: the product held against a specification, a judgement on the understandability of a document read without its author and data that somebody has counted. What it costs, only the author's live narration can produce: the completeness of the product end to end and the options one sets against each other.

Completeness is the counter-intuitive row. BABOK's facilitator ensures that each relevant section of the work product is covered (Table 10.37.1). Wiegers' moderator asks the participants if they have any issues on a specific section or page. The two texts describe the same activity, and setting the two lines side by side is ours: the formal walkthrough canvasses the product's sections, and what has a section nowhere is asked of nobody. The inspection (10.37a) covers the product in small chunks; the informal walkthrough (10.37d) has its author narrate it end to end, and the case that has a step nowhere announces itself there. The formal walkthrough finds what is wrong on the page. The informal walkthrough finds what has no page.

The traps

The session starts reading. Four reviewers walk into the room, two have read, two open the document. The session becomes a collective reading, the consolidation has nothing to consolidate, and the hour is spent discovering what the preparation was supposed to bring. Validating that the reviewers have examined the product before the session begins is what Table 10.37.1 entrusts to the facilitator, and it is the only task of the technique that happens before the room fills up.

The case where nobody has read the document is the standard case. A field practice answers it by design rather than by enforcement: the reading is held in the room, deliberately. The invitation goes out with the document, asks for it to be annotated, announces that the reading will be collective, names the stakeholders whose presence is mandatory and allows a delegate who can commit their department. In session the facilitator reads the document section by section and paraphrases it, which is the reader role Wiegers documents in the inspection, and the group converges on a single interpretation. Questions, vetoes and the negotiation between stakeholders are settled immediately, in the room, and what has to be adapted, completed, clarified or removed is written into the document during the session. What the people present cannot settle goes into an "open points" section with a mini-RACI: who handles it, who is consulted, who validates, one or two named people at most. With no open point the document is accepted; with open points it is accepted with reservations, and once every open point has been treated it changes version, passes to accepted and is distributed according to the project's RACI. If a key stakeholder neither attends nor sends a delegate, the session is cancelled.

The session drifts towards solutions. Wiegers warns that the team can get sidetracked on tangential discussions, and he grants on the same page that a team review might devote some meeting time to discussing solution ideas. The two sentences hold together, and the facilitator holds them: the matter of the session is what each reviewer found, section by section, and a design debate that opens on a finding is noted and taken up elsewhere.

Having the author run the session. BABOK specifies that the facilitator should not be the author, in order not to compromise the review (Table 10.37.1). The author who runs the session decides the order of the sections, the time spent on each and the moment when the group moves on, and that is exactly what the technique takes away from him in order to give his reviewers' findings the value they have.

Taking it for an inspection. It is formal, it is prepared, it holds a session and it pronounces an appraisal, and it is easy to conclude from that that the loop is closed. Wiegers' Table 3-1 marks correction for the team review and refuses it verification. The author corrects, and a finding that has to survive the session enters item tracking (10.26) the same day. A review that closes the loop it opened itself is an inspection (10.37a).

AI considerations

This review's own asset is the individual reading: each reviewer meets the product alone, before the room fills up. That is where a large language model serves best, and it is also the one activity of the technique that it cannot answer for.

Preparing your own reading. The reviewer has to walk into the session having read the package alone. A model can pass the package against the specification first: the requirement with no acceptance criterion, the term used in two senses, the section the specification calls for and the package does not carry. The reviewer's reading is then spent on what only a domain reader can see.

Preparing the consolidation. The session of a formal walkthrough is a consolidation, and Wiegers warns that it can get lost. A model can merge the four reviewers' findings by section in advance and surface the two places that count: where two reviewers found the same thing, and where they contradict each other. That is the work the room does by hand, and doing it beforehand gives the session back what is its own, the decision on what remains a finding.

It cannot be the individual reading. The facilitator's task is to validate that the reviewers have examined the work product before the session begins (Table 10.37.1), and a model's pass is nobody's reading. A session that consolidates a machine's findings has consolidated something nobody answers for. The appraisal is the judgement of a group of qualified people (Wiegers, Table 3-2), and a model does not sign it.

Data protection. An e-government requirements package carries personal data, the AHV/AVS social-security number included. The revised Federal Act on Data Protection (nFADP) comes before productivity, and the organisation's rule, which model, which data, hosted where, is fixed before the package goes out to the reviewers.

Examples

A formal walkthrough produces a consolidated set of findings that each reviewer made alone and an appraisal pronounced on the product.

The six findings were made alone, before the session, and the session consolidated them: where two reviewers had seen the same gap, only one line remains.

No row reports a missing section. The facilitator went through the package's sections, and what has a section nowhere is asked of nobody. What the package does not say is looked for in an inspection (10.37a) or in an informal walkthrough (10.37d), where the author narrates the product end to end.

The session pronounced an appraisal on the package. The author corrects, and what becomes of the corrections is no longer a matter for the technique (Wiegers, Table 3-1: correction, yes; verification, no); the two points that have to survive the session (§3.2 and §6) enter item tracking (10.26).

Cost

Tooling

The formal walkthrough first needs a way of putting the work product into the reviewers' hands several days before the session and a place where each of them records what they find during their reading. A comment thread in the tool where the product was built is enough, on one condition: that the findings carry the section they attach to, because it is by section that the session will call them up.

It then needs a defect checklist. Wiegers marks that row for the team review in his Table 3-2, where he refuses it to the informal walkthrough (10.37d), and the list is built from what the product has to hold up against: the specification, article by article. It is what gives the individual reading its shape, and it is what distinguishes four readings from a review.

It finally needs something to consolidate with in session and something to write with. The scribe records (Table 10.37.1). Two artefacts leave the room, the consolidated set of findings and the appraisal of the product (Wiegers, Table 3-2). What has to live beyond the session lives elsewhere: a finding that stays open belongs to item tracking (10.26), and a standard question left hanging belongs to a single issue review (10.37c).

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.37 Reviews (§10.37.3.1, the seven objectives; §10.37.3.2, the seven types and the definition of the formal walkthrough; Table 10.37.1, the roles; §10.37.4.2, the limitations).
• Karl E. Wiegers, Peer Reviews in Software: A Practical Guide, Addison-Wesley, 2002, chapter 3, "Peer Review Formality Spectrum" (Table 3-1, activities by review type; Table 3-2, characteristics compared; Table 3-3, objectives and methods; the section devoted to the team review).
• ISO/IEC, ISO/IEC 20246:2017, Software and systems engineering: Work product reviews.
• IEEE, IEEE Std 1028-2008, IEEE Standard for Software Reviews and Audits.
• Olivier Wagner, "Document review, I read it aloud in the room", SmartGecko Academy, 2024 (the collective reading in session, how it runs and what it costs).