There are times when you are absolutely certain that what you’ve written or coded is ready for a formal review or release. When you are certain about the artifacts contents, or its impact on the overall process is very low it’s a safe bet to publish and worry about the minutia later. Then, there are those critical artifacts that you might want to consider having informally reviewed by your peers because it does impact others or a critical process. Starting with an informal review will build your confidence in writing great requirements while it also builds additional team core strength.
An easy way to determine whether or not you need to have an informal review is to answer the following multipart question:
Is the unit of work under my span of control complete, such that I know I can
A)Hand it off to other teams to begin working on it without injecting defects into their work flow?
B)Pass a formal review in its current state with some minor tweaks?
If you strive to answer yes to all parts of this question then you are not only demonstrating your understanding of the assigned task, you are also fully committed to taking responsibility of the quality of the work. When you are proficient at this make it a practice to coach and mentor your peers accordingly. Note: being proficient does not mean answering yes to all of the question all of the time.
In my experience I have met many people who can answer yes to only one of the two completely, a few who can answer both the rare genius or a fools optimist . If you are wondering how to tell the difference the fool is the person who can say yes no matter what the facts are.
qualitasrebus 