The primary driver should be the number of defects. The more defects you have, the more frequently you should meet. If you track your defect discovery rate (number of defects found per day), you will usually find there are more defects following each new build or release or test cycle. Plan accordingly. Sometimes you will not have enough time. Sometimes you will break early.
Whether you call it Defect Review or Triage, the process, formal or informal, is a necessary part of any software development project. At some point in the process you have to review and prioritize defect resolution. Project success depends on effective defect management and making tough decisions. This is the best way I have found to do it. It's not pretty, but it's necessary. Why not make it easy? By the way–I've found that pizza or doughnuts encourage attendance. Anyone have the number to Krispy Kreme?
|Software Triage||49.5 KB|