Configuration Management

• Overview
• CM Tools

Issue Tracking

• Field Summary
• State
• Priority
• Severity
• Issue Type
• Symptoms
• Functional Area
• Resolution
• Target Release

Issue Reports

• Cumulative Trends
• Rolling Totals
• Historical Priority
• Historical Severity
• Project State Distribution
• Project Trends
• Transition Summary
• Staff Workload

Target Release

Many tracking systems don't have this field out of the box. This field avoids the issue of trying to specify alpha/beta/RTM releases based on numbers of defects based on other fields such as priority or severity. Face it: Target release is an independently tracked piece of data: don't try to cram it on top of another field.

Priority remains the developer's tool for what to work on first, second, etc. Target release, on the other hand, is used by the product manager to identify items that are slated for a given release. By making this a separate field, it's easy to have some developers working on issues within release X (in priority order), while other developers work on issues from release Y, also in priority order.

Note that if work is originally scheduled for a release like 3.0.1 and instead the release becomes 3.1, that most tracking systems provide for a 'Mass Transition' that would allow all of those to be updated at once.

Often, a PM does not yet know in which release an issue will (or should) be addressed. Do not use Priority or Severity for these issues with unknown target release. Instead, if you don't know the target release, then have a release value called "unknown" or "deferred."

Contact Primary Goals for a detailed review of your issue tracking system, or for consultative assistance to ensure that you have a smooth deployment of your CM system.