Peer Reviews

Peer reviews are similar to the "pair programming" concept of extreme programming (XP), except that the coding itself does not occur in pairs, the meetings often involve more than two people, and the reviews apply to all types of task deliverables besides programs. Peer reviews are informal meetings that combine reviewing, testing, and a limited amount of brainstorming about a project task deliverable. The purpose of peer reviews is to allow the developer of a given piece of project work to present a task deliverable to his or her peers for validation or discussion. This is best accomplished in a core team setting, but a peer review can also involve team members from the extended team who have a vested interest in that project task.

At the completion of a project task, the developer of the work (or any other core team member) may decide to ask for a peer review to solicit input to a complex problem, get feedback to a creative solution, or ask for opinions on an item that is uncertain or poorly defined. He or she then determines which team members should participate in the peer review, schedules the informal peer review meeting, and distributes copies of documents (e.g., specifications, programs, data models, reports ) to the invited peers before the meeting.

The developer of the work leads the meeting. The project manager, who should always participate in peer reviews, ensures that the meeting does not bog down in disagreements nor stray from the issues at hand. Each attendee should have reviewed the distributed documents and should be prepared to comment and to brainstorm on the issues. Together, the participants are responsible for uncovering errors or misconceptions in the task deliverable. Discussions are initiated to help the developer understand the problems uncovered or to allow the developer to justify his or her work to the satisfaction of all in attendance.

Brainstorming is usually limited to finding the errors or misconceptions; it does not extend to solving them unless a solution is obvious and can be presented or discussed within a few minutes. At the conclusion of a peer review the uncovered errors or misconceptions should be documented, and the developer of the deliverable is tasked with correcting them or with creating a new solution to the project task.

Peer reviews sound more formal than they really are. They can be best compared to high- powered , structured brainstorming sessions. Peer review meetings should be limited to about one hour .