These scores are then modified by the priority level:
- Mandatory: The defect is highly visible or critically impacts the customer. It must be repaired prior to general availability release.
- Exciter: The defect has significant impact upon the customer and inclusion of this functionality would greatly increase customer satisfaction with the product.
- Moderate: The defect moderately impacts the customer and should be repaired before a general availability release, but it is not necessary unless at least medium severity. This level is also used for requirements that have not been prioritized.
- Recommended: The defect has some impact upon the customer and should be repaired before a general availability release, but it is not necessary unless the defect is scored at least high severity.
- Desired: The defect has a low impact upon the customer and should be repaired before a general availability release, but it is not necessary.
As you can see, while defects are still prioritized, some requirements will have the same priority. This is not a problem; rather, it is the developer’s choice to determine which defect to fix next or the requirement will be rescored.
The team decides on the requirement’s severity, and the product owner on the requirement’s priority. Since the estimation does not handle time in “man-hours,” but rather in “team-weeks,” the estimation has more value because all those little bumps in time are smoothed out. You don’t even need to show an employee’s time off, as other members of the team will be able to pick up his tasks.
Verification points, being a defined metric, are the same no matter who calculates them. New York, Denver, or New Delhi, a verification point is a verification point and means the same thing. This is not true of storypoints. With verification points, you’ll be able to determine which of two teams should develop faster by using simple velocity. The total verification points for a project are a good metric for determining the development effort’s overall size. You can accurately determine how many verification points can be cleared during each iteration by using a form of iterative development, over time. Cleared verification points represent deliverable software. Verification points cleared by the team per day, week, iteration, or sprint is a valuable metric that can be used to show how much effort was required per verification point, determine how rapidly a project can be completed, and estimate a project’s duration and cost.