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 |
|---|---|
|
Process Guidance Workbooks 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:
.png "CMMI Issue work item form")
.png "CMMI Issue work item form - tabs")
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
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, click 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 Area and Iteration lists, click 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.
In the Priority list, click 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, click 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, click Yes if the issue is affecting the critical path of the project plan.
By default, this value is the current date.
On the Details tab, in the Description box, provide as much detail as you want to describe the issue.
In the History box, 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.
On the Analysis tab, click each box, and provide details about how the team can resolve the issue:
In the Impact on project promise list, click 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.
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.
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.
On the All Links tab, link the issue to one or more other work items, such as a requirement or task.
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
Click
.gif "Save")
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
On the All Links tab, click
.gif "Add Links")
Link to.The Add Link to Issue dialog box opens.
In the Link Type list, click Related or another type of link that represents the relationship that you want to track.
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.
Click Browse to specify work items from a list.
The Choose linked work items dialog box appears.
.png "Choose linked work items dialog box")
In the Saved query list, click a query that contains the work items that you want to add. For example, you can click Open User Stories or Open Tasks.
Click Find, select the check box next to each work item that you want to link to the issue, and then click OK.
(Optional) Type a description for the items to which you are linking.
Click OK.
For more information, see Find Work Items to Link or Import.
Click
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
Click 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 Titles, IDs, Description, and History (CMMI).
Click
Save Work Item.
To add an attachment to an issue
On the Attachments tab, perform one of the following actions:
Drag a file into the attachment area.
Click
.gif "Paste")
or press CTRL-V to paste a file that you have copied.Click
.gif "Add Attachment")
Add, click 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, click OK.
Click
Save Work Item.
To add a hyperlink to an issue
On the All Links tab, click
Link to..png "Specify URL for hyperlink address")
In the Link Type list, click Hyperlink.
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.
(Optional) In the Comment box, type additional information about the hyperlink.
Click OK, and then click
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 Assignments, Workflow, and Planning (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
Open the issue.
In the State list, click 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.
Click
Save Work Item.
Typical workflow progression:
Atypical transitions:
|
Issue State Diagram .png "CMMI Issue state diagram or workflow") |
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
Fields that Track Bugs, Issues, and Risks (CMMI)