The Value of Peer Reviews
You’re near the end of a long requirements phase, you’ve been working 60+ hours a week, and the project manager is pressuring you to deliver a final deliverable. So you do a quick spell check and proof read, and then toss it over for final review to business, development, test, etc. Hang on a second, though - there’s a problem with this picture. You missed giving the deliverable to a peer and asking for feedback. Peer reviews are an excellent technique for increasing the quality of your deliverables. In this post I’ll explain why peer reviews are so important and give you some ideas on how to do them successfully.
Why do peer reviews? After all, the PM and development are anxiously waiting for your document, so why hold things up? Well, for starters - requirement errors are very costly to fix - from 40 to 100 times more expensive to correct once implemented than if they were detected and fixed during the requirements process. So the return on investment (ROI) in doing peer reviews can be quite high. In fact, a study showed that as much as 10 hours of labor can be avoided for every hour spent inspecting requirements and other software deliverables(1). In addition:
• Turning over inferior work to business stakeholders, development, test, and other groups can reflect poorly on you and may cause a loss of credibility.
• Reviews are critical for encouraging continuous improvement, and can assist both the person conducting the review, as well as the person whose work is being reviewed. Reviews supply a mechanism for sharing approaches and provide critical feedback.
So how should you go about doing peer reviews? Karl Wieger’s Software Requirements, 2nd Edition book has an excellent chapter on doing peer reviews and inspections. Here are some ideas to consider:
• Provide as much advance notice to the person doing the review as possible - don’t drop a 100 page document into someone’s inbox and ask for feedback by the end of the day.
• Likewise, make sure you give the reviewer plenty of time. We’ve had debate in the past on the message board about how long to allocate, so you can go there to get different opinions. I won’t give a hard and fast rule - it depends on many things such as the complexity/density of the requirements, the familiarity of the reviewer with the domain space, etc.
• Do a basic check of the document before sending it out for a peer review. Make sure you do a spell check, clean up formatting, and make sure there are no gaps (such as "TBD") present, unless the document is a work in progress.
• The reviewer should utilize a standard checklist to use when conducting the review (e.g. is the requirement testable? is the requirement understandable?)
• The reviewer should focus on major defects/problems. While identifying minor problems such as spelling/grammar is helpful, it is not as important as identifying major issues such as unclear requirements, structural problems with the document, incomplete requirements, etc.
• Metrics should be collected from the review process - how many pages reviewed, how long was spent, how many problems were identified, etc.
1) Grady, Robert B., and Tom Van Slack. 1994. "Key Lessons in Achieving Widespread Inspection Use." IEEE Software 19(5):15-17.
Why do peer reviews? After all, the PM and development are anxiously waiting for your document, so why hold things up? Well, for starters - requirement errors are very costly to fix - from 40 to 100 times more expensive to correct once implemented than if they were detected and fixed during the requirements process. So the return on investment (ROI) in doing peer reviews can be quite high. In fact, a study showed that as much as 10 hours of labor can be avoided for every hour spent inspecting requirements and other software deliverables(1). In addition:
• Turning over inferior work to business stakeholders, development, test, and other groups can reflect poorly on you and may cause a loss of credibility.
• Reviews are critical for encouraging continuous improvement, and can assist both the person conducting the review, as well as the person whose work is being reviewed. Reviews supply a mechanism for sharing approaches and provide critical feedback.
So how should you go about doing peer reviews? Karl Wieger’s Software Requirements, 2nd Edition book has an excellent chapter on doing peer reviews and inspections. Here are some ideas to consider:
• Provide as much advance notice to the person doing the review as possible - don’t drop a 100 page document into someone’s inbox and ask for feedback by the end of the day.
• Likewise, make sure you give the reviewer plenty of time. We’ve had debate in the past on the message board about how long to allocate, so you can go there to get different opinions. I won’t give a hard and fast rule - it depends on many things such as the complexity/density of the requirements, the familiarity of the reviewer with the domain space, etc.
• Do a basic check of the document before sending it out for a peer review. Make sure you do a spell check, clean up formatting, and make sure there are no gaps (such as "TBD") present, unless the document is a work in progress.
• The reviewer should utilize a standard checklist to use when conducting the review (e.g. is the requirement testable? is the requirement understandable?)
• The reviewer should focus on major defects/problems. While identifying minor problems such as spelling/grammar is helpful, it is not as important as identifying major issues such as unclear requirements, structural problems with the document, incomplete requirements, etc.
• Metrics should be collected from the review process - how many pages reviewed, how long was spent, how many problems were identified, etc.
1) Grady, Robert B., and Tom Van Slack. 1994. "Key Lessons in Achieving Widespread Inspection Use." IEEE Software 19(5):15-17.
posted by Brad at 7/20/2007 08:16:00 AM
2 Comments:
Reqts development is hard. Technical reviews of unstructured reqts (i.e., text blocks) are even harder. Individuals miss 80% of the reqts defects, teams miss 65% of the defects (Tom Gilb).
Reviews are more effective when there is more structure and more understanding of the terminology (e.g. code). This suggests that reqts info expressed in tables, equations, and diagrams is more reviewable. It also suggests that detailed definitions of central terms can help.
This post is being discussed on the messageboard thread
http://www.seilevel.com/messageboard/showthread.php?t=622
Post a Comment
<< Home