Issue (CMMI)

In this topic, you can learn how to fill in the details of an issue work item. A team can use the issue work item to track an event or situation that might block work or is blocking work on the product. Issues differ from risks in that teams identify issues spontaneously, generally during daily team meetings. For more information, see Managing Issues (CMMI).

For information about how to create this type of work item, see Work Items and Workflow (CMMI).

In this topic

Related topics

Defining an Issue Linking an Issue to Other Work Items Adding Details, Attachments, or Hyperlinks to an Issue Changing the State of an Issue

Process Guidance Managing Issues (CMMI) Workbooks Issues Workbook (CMMI) Triage Workbook (CMMI) Field Reference Titles, IDs, Descriptions, and History Field Reference Assignments and Workflow Field Reference Planning, Ranking, and Priorities Field Reference Bugs, Issues, and Risks Field Reference (CMMI) Areas and Iterations Field Reference Link Controls, Restrictions, and Field Reference Attachment Controls and Field Reference

Required Permissions

To view an issue, you must be a member of the Readers group or your View work items in this node must be set to Allow. To modify an issue, you must be a member of the Contributors group or your Edit work items in this node permissions must be set to Allow. For more information, see Managing Permissions.

Defining an Issue

The work item form for an issue stores data in the fields and tabs that appear in the following illustrations:

   

When you define an issue, you must define the Title. You can leave all other fields blank or accept their default values.

To define a single issue

1. In the top section of the work item form, specify one or more of the following types of information:

   • In Title, verify and, if necessary, update the text to more accurately define the problem and the areas of work that are affected.

   • In the Assigned To list, choose the name of the team member who is responsible for addressing the issue.

     Note

     You can assign work items only to members of the Contributors group.

   • In the State list, leave the default value, Proposed.

     By default, the value of the Reason field is New. For more information about this field and how you can use it to track workflow, see Changing the State of an Issue later in this topic.

   • In the Priority list, choose the level of importance of the issue on a scale of 1 (most important) to 4 (least important).

     By default, this value is 2.

   • In the Triage list, choose the triage substate.

     This field identifies the level of triage that has been decided for any issue that is in the Proposed state. Valid values are Pending (default), More Info, Info Received, and Triaged.

   • In Escalate, choose Yes if the issue is affecting the critical path of the project plan.

     By default, this value is the current date.

   • In the Area and Iteration lists, choose the appropriate area and iteration.

     Note

     Your project administrator defined the Area and Iteration tree hierarchies so that team members can track progress by those designations. For more information, see Create and Modify Areas and Iterations.

2. On the DESCRIPTION tab, provide as much detail as you want to describe the issue.

3. On the HISTORY tab, provide as much detail as you want, and format the text.

   Every time that a team member updates the work item, its history shows the date of the change, the name of the team member who made the change, and the fields that changed.

4. On the ANALYSIS tab, choose each box, and provide details about how the team can resolve the issue:

   • In the Impact on project promise list, choose the impact level.

     Valid values are 1 - Critical, 2 - High, 3 - Medium, and 4 - Low. By default, this value is 3 - Medium.

   • In the Analysis box, describe the root cause of the issue and one or more solutions that might resolve it.

     You can format the text that you type in this box.

5. On the CORRECTIVE ACTION tab, perform the following steps:

   • In the Plan box, describe the proposed corrective action on which the team has agreed.

     You can format the text that you type in this box.

   • In the Actual resolution box, describe the corrective action that the team took to resolve the issue.

     You can format the text that you type in this box.

6. On the OTHER tab, specify the following types of information:

   • In the Target resolve date box, type the date by which the team must resolve the issue.

   • In the Original Estimate box, type a number that represents the hours of work that the issue will take to address.

7. On the ALL LINKS tab, link the issue to one or more other work items, such as a requirement or task.

8. On the ATTACHMENTS tab, attach specifications, images, or other files that provide more details about the issue.

   For more information, see the following sections later in this topic:

   • Linking an Issue to Other Work Items

   • Adding Details, Attachments, or Hyperlinks to an Issue

9. Choose Save Work Item.

   Note

   After you save the issue, the identifier appears in the title under the work item toolbar.

Linking an Issue to a Requirement, Task, or Other Work Item

On the Links tab, you can link an issue to another work item.

To link an issue to a requirement, a task, or another work item

1. On the All Links tab, choose Link to.

   The Add Link to Issue dialog box opens.

2. In the Link Type list, choose Related or another type of link that represents the relationship that you want to track.

3. Perform one of the following actions:

   • In Work item IDs, type the IDs of the work items that you want to find. Separate IDs by commas or spaces.

   • Choose Browse to specify work items from a list.

     The Choose linked work items dialog box appears.

     

     In the Saved query list, choose a query that contains the work items that you want to add. For example, you can choose Open User Stories or Open Tasks.

     Choose Find, select the check box next to each work item that you want to link to the issue, and then choose OK.

   • (Optional) Type a description for the items to which you are linking.

4. Choose OK.

   For more information, see Find Work Items to Link or Import.

5. Choose Save Work Item.

   Note

   Both the issue and the items to which you linked are updated. A Related link to the issue is defined for each work item that you added.

Adding Details, Attachments, or Hyperlinks to an Issue

As more information becomes available, you can add it to an issue in the following ways:

• Type information in the boxes on the Details, Analysis, or Corrective Action tab.

• Attach a file.

  For example, you can attach an e-mail thread, a document, an image, a log file, or another type of file.

• Add a hyperlink to a Web site or to a file that is stored on a server or Web site.

To add details to an issue

1. Chose the Details, Analysis, or Corrective Action tab, and type information in the boxes.

   You can format information to provide emphasis or capture a bulleted list. For more information, see Requirement Field Reference (CMMI).

2. Choose Save Work Item.

To add an attachment to an issue

1. On the Attachments tab, perform one of the following actions:

   • Drag a file into the attachment area.

   • Choose or press CTRL-V to paste a file that you have copied.

   • Choose Add, choose Browse, and, in the Attachment dialog box, type or browse to the name of the file that you want to attach.

     (Optional) In the Comment box, type additional information about the attachment. To close the Attachment dialog box, choose OK.

2. Choose Save Work Item.

To add a hyperlink to an issue

1. On the All Links tab, choose Link to.

   

2. In the Link Type list, choose Hyperlink.

3. In the Address box, perform one of the following actions:

   • If the target is a Web site, type the URL, or copy it from your Internet browser and paste it into the Address box.

   • If the target is a server location, type its UNC address.

4. (Optional) In the Comment box, type additional information about the hyperlink.

5. Choose OK, and then choose Save Work Item.

Changing the State of an Issue

Teams should review each issue work item and analyze it to create one or more tasks to resolve it. After the team takes corrective action by completing the tasks, the team resolves the issue. Finally, if the team decides that the corrective action is acceptable, the team closes the Issue.

For more information about the data fields that you can use to track work item states, see Tracking Status and Assignments [CMMI].

You can use the following states to track the progress of an issue:

• Proposed

• Active

• Resolved

• Closed

Any team member can change the state of a issue.

To close an issue

1. Open the issue.

2. In the State list, choose Active, Resolved, or Closed.

   • If you change the state from Proposed to Active, the Reason field automatically changes to Accepted.

   • If you change the state from Active to Resolved, the Reason field automatically changes to Resolved.

   • If you change the state from Resolved to Closed, the Reason field changes to Resolution Verified and Accepted.

3. Choose Save Work Item.

Typical workflow progression: A team member creates an issue in the Proposed state with the default reason, New. A team member changes the state of the issue from Proposed to Active with the default reason, Accepted. A team member changes the state of the issue from Active to Resolved when the team has completed tasks to take corrective action. A team member changes the state of the issue from Resolved to Closed when the team has determined that the corrective action has addressed the problem. Atypical transitions: A team member changes the state of the issue from Proposed to Closed with the default reason, Rejected. A team member changes the state of the issue from Active to Proposed with the default reason, Investigation Complete. A team member changes the state of the issue from Active to Closed after the team determines that the issue has been overtaken by other events and is not relevant. A team member changes the state of the issue from Resolved to Active when the team determines that the corrective action is insufficient or incorrect for addressing the issue. A team member changes the state of the issue from closed to active after the team determines that the issue was closed in error or is reoccurring.

Issue State Diagram

Proposed (New)

A team member creates an issue work item for a blocking problem that the team discovers, generally as part of a daily team meeting.

The following data fields are automatically captured when a team member creates an issue:

• Created By: Name of the team member who created the issue.

• Created Date: Date and time when the issue was created, as recorded by the server clock.

From Proposed to Active

Each proposed issue waits for triage, where it is either accepted or closed. If the issue is accepted, the team changes its state to Active. Otherwise, the team changes the state of the issue to closed.

A team member can move an issue from the Proposed state to the Active state for the reasons in the following table:

Reason	When to use	Additional actions to take
Accepted	When the triage committee determines that the issue should be addressed.	Assign the issue to the team member who will implement it.
Investigate	When the triage committee determines that the impact of the issue must be investigated before the committee will accept it.	Return the issue to the Proposed state after the team investigates the situation.

The following data fields are captured when a team member changes the state of an issue to Active:

• Activated By: Name of the team member who activated the issue.

• Activated Date: Date and time when the issue was activated, as recorded by the server clock.

• State Change Date: Date and time when the state of the issue was changed.

From Proposed to Closed

A team member can close an issue that is in the Proposed state because of the reason in the following table:

Reason	When to use	Additional actions to take
Rejected	When the triage committee determines that the issue does not really exist or is not important. Either the cause is incorrect, or the problem is described incorrectly.	None.

The following data fields are captured when a team member closes an issue:

• Closed By: Name of the team member who closed the issue.

• Closed Date: Date and time when the issue was closed, as recorded by the server clock.

• State Change Date: Date and time when the state of the issue was changed.

Active

When the team reviews and analyzes an active issue, the team might decide that it was created unnecessarily and reject it. If the team decides that the issue is worth addressing, the team analyzes it and creates one or more tasks to take corrective action. When the team completes the corrective action, the team resolves the issue.

From Active to Resolved

A team member can resolve an active issue with the default reason of Resolved when the team has completed tasks to take corrective action.

The following data fields are captured when a team member resolves an active issue:

• Assigned to: Name of the team member who created the issue.

• Resolved By: Name of the team member who resolved the issue.

• Resolved Date: Date and time when the issue was resolved, as recorded by the server clock.

• State Change Date: Date and time when the state of the issue was changed.

From Active to Closed

A team member can resolve an active issue with the default reason of Overtaken by Events when other decisions or events have removed the block that the issue posed.

The following data fields are captured when a team member closes an active issue:

• Closed By: Name of the team member who closed the issue.

• Closed Date: Date and time when the issue was closed, as recorded by the server clock.

• State Change Date: Date and time when the state of the issue was changed.

Resolved

A resolved issue indicates that the team has taken corrective action and the issue is no longer blocking progress. The team evaluates the corrective action, and if acceptable, a team member closes the issue. If the corrective action is not acceptable, the team member should reactivate the issue for additional work.

From Resolved to Active

A team member can reactivate a resolved issue with the default reason of Rework when the team determines that the corrective action is insufficient or incorrect for addressing the problem.

The following data is automatically captured when a team member reactivates a resolved issue:

• Activated By: Name of the team member who reactivated the issue.

• Activated Date: Date and time when the issue was reactivated, as recorded by the server clock.

• State Change Date: Date and time when the state of the issue was changed.

From Resolved to Closed

A team member can close a resolved Issue with the default reason of Resolution Verified and Accepted when the team determines that the corrective action has addressed the problem.

The following data fields are captured when a team member closes an active issue:

• Closed By: Name of the team member who closed the issue.

• Closed Date: Date and time when the issue was closed, as recorded by the server clock.

• State Change Date: Date and time when the state of the issue was changed.

Closed

Any team member can reactivate a closed issue if it was closed in error.

The team should no longer work on any closed issue. The team closes an issue when the team has taken corrective action and accepts the resolution or the triage committee has rejected the problem as a non-blocking event.

From Closed to Active

A team member can reactivate a closed Issue for the reasons in the following table:

Reason	When to use
Closed in error	When a team member accidentally closed the issue.
Re-opened	When some part of the issue needs additional work.
Re-occurred	When the event or situation that caused the issue repeats itself.

The following data is automatically captured when a team member reactivates a closed issue:

• Activated By: Name of the team member who reactivated the issue.

• Activated Date: Date and time when the issue was reactivated, as recorded by the server clock.

• State Change Date: Date and time when the state of the issue was changed.

See Also

Concepts

Artifacts (CMMI)

Bugs, Issues, and Risks Field Reference (CMMI)

Work Item Field Reference for Visual Studio ALM

Other Resources

Work Items and Workflow (CMMI)