Bug (Scrum)

By defining and managing bug work items, your team can track defects in the product and prioritize efforts to resolve them. When you define a bug, you should perform the following tasks:

• Report the problem accurately and precisely enough that other team members can understand the full impact of the problem.

• Describe the actions that you took before you found the bug so that other members can more easily reproduce the behavior that you are reporting.

• Specify expected behavior to help others understand whether they have fixed the bug.

In this topic

• Defining a Bug

• Adding and Linking Tasks to a Bug

• Adding and Linking Test Cases to a Bug

• Adding Other Work Items to a Bug

• Changing the State of a Bug

Required Permissions

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

Defining a Bug

The work item form for a bug contains the fields and tabs in the following illustration:

When you define a bug, you must define the Title. You can leave all other fields blank or accept their default values and update them later.

To define a bug

1. In the upper section of the work item form for a bug, specify one or more of the following fields:

   • In Title (required), type a phrase that describes the code defect.

   • In Iteration, specify the iteration path of the bug.

     For more information, see Create and Modify Areas and Iterations.

   • In the Assigned To list, click the name of the team member who owns the bug.

     Note

     Only members of the Contributors group can own a work item.

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

     For more information about the State field and how you use it to track workflow, see Changing the State of a Bug later in this topic.

   • In the Reason list, leave the default value, New defect reported.

   • In Backlog Priority, type a number that indicates the relative priority of the bug.

     A larger number indicates a lower priority. The default value of this field is 1000, which places the new bug at the bottom of the backlog.

   • In Effort, type a number that specifies the relative amount of workload that is required to fix the bug.

     A larger number indicates more work.

   • In the Severity list, click the value that indicates the effect of the bug on your project.

     By default, the value of this field is 3 - Medium.

   • In the Area list, click the appropriate area path.

2. In the lower section of the work item form, provide the following information:

   • On the Steps to Reproduce tab, provide as much detail as another team member might need to understand the problem that must be fixed.

     You can format the content that you provide in this field.

   • On the Acceptance Criteria tab, describe the criteria that you will use to verify whether your team has fixed the bug.

   • On the History tab, add comments that you want to capture as part of the historical record.

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

   • On the Attachments tab, you can attach files that provide more details about the bug.

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

   • On the System tab, describe the software environment in which you found the bug.

     In the Found in Build list, click or type the name of the build in which you found the defect.

     In Integrated in Build, do not specify a build when you define the bug. When you resolve the bug, type the name of the build that incorporates the code or fixes the bug.

     Note

     A unique build name is associated with each build. For information about how to define build names, see Customize Build Numbers.

3. Link the bug to other work items by performing one or more of the following tasks:

   • On the Tasks tab, create one or more links from the bug to tasks.

     For more information, see Adding and Linking Tasks to a Bug later in this topic.

   • On the Test Cases tab, create one or more links from the bug to test cases.

     For more information, see Adding and Linking Test Cases to a Bug later in this topic.

   • On the Links tab, create one or more links from the bug to other bugs or to other types of work items. You can also add one or more hyperlinks to Web sites or to files that are stored on servers or on Web sites.

     For more information, see Adding Other Work Items to a Bug later in this topic.

4. On the work item toolbar, click Save Work Item.

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

Adding and Linking Tasks to a Bug

You can add task work items to a bug to track the progress of work that has occurred to resolve and close the bug.

To create a task that is linked to a bug

1. On the Tasks tab, click New.

   The Add new Linked Work Item dialog box opens.

   

2. In the Link Type list, leave the default option, Child.

3. In the Work Item Type list, click Task.

4. In Title, type a name that describes as specifically as possible the area of work that will be performed.

5. (Optional) In Comment, type additional information.

6. Click OK.

   A work item form for a task opens and shows the information that you have provided.

7. Specify the remaining fields, and then click Save Work Item.

   For more information about the fields in the task work item, see Task (Scrum).

To link existing tasks to a bug

1. On the Tasks tab, click Link to.

   The Add Link to Bug dialog box opens.

2. In the Link Type list, leave the default option, Child.

3. Click Browse.

   The Choose linked work items dialog box appears.

   

4. To specify the tasks to which you want to link the bug, perform one of the following tasks:

   • Run a query to locate the tasks to which you want to link.

   • Type the IDs of the tasks to which you want to link.

   • Type the text that is contained in the titles of the target items, and then click Task as the work item type.

   Select the check box next to each task that you want to link to the bug, and then click OK.

   The Choose linked work items dialog box disappears. For more information, see Find Work Items to Link or Import.

5. (Optional) In the Add new Linked Work Item dialog box, type a description for the tasks to which you are linking the bug.

6. Click OK, and then click Save Work Item.

   Both the bug and the tasks to which you linked it are updated. For each task that you added, a parent link to the bug is created.

Adding and Linking Test Cases to a Bug

You can create a test case and link it to a bug. The recommended client for creating test suites and test cases is Microsoft Test Manager. From this client, you can also link to a bug, as described in How to: View Requirements or User Stories Using Microsoft Test Manager.

To add a test case to a bug

1. On the Test Cases tab, click New.

   The Add new Linked Work Item dialog box appears.

2. In the Link Type list, leave the default option, Tested By.

3. In the Work Item Type list, leave the default option, Test Case.

4. In Title, type a description of the area to be tested.

5. (Optional) In Comment, type additional information.

6. Click OK.

   A work item form for a test case opens and shows the information that you have provided.

7. Specify the remaining fields, and then click Save Work Item.

   For more information about the fields in the work item form for a test case, see Test Case (Scrum).

To add existing test cases to a bug

1. On the Test Cases tab, click Link to.

   The Add Link to bug dialog box opens.

2. In the Link Type list, leave the default option, Tested By.

3. In Work item IDs, type the IDs of the test cases to which you want to link, or browse for them.

   You can run a saved query to locate the test cases that you want to add and then select the check box next to each test case to which you want to link.

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

4. (Optional) Type a description for the test cases to which you are linking the bug.

5. Click OK, and then click Save Work Item.

   Both the bug and the test cases to which you linked it are updated. For each test case that you added, a Tests link to the bug is created.

Adding Other Work Items to a Bug

You can add another bug or any other type of work item to a bug by using the Links tab.

To create a work item and link it to a bug

1. On the Links tab, click New.

   The Add new Linked Work Item dialog box opens.

2. In the Link Type list, click Related.

3. In the Work Item Type list, click the type of work item that you want to create.

4. In Title, describe the work item.

5. (Optional) In Comment, type additional information.

6. Click OK.

   A work item form opens and shows the information that you have provided.

7. Click Save Work Item.

Changing the State of a Bug

A team can track the progress of a bug by setting its State field to one of the following values: New, Approved, Removed, Committed, or Done. The following diagram shows both a typical and an atypical workflow progression of a bug.

Bug State Diagram

Typical workflow progression: Create a bug work item in the default state, New. Change the state from New to Approved. Change the state from Approved to Committed when the team is committed to fixing the bug. Change the state from Committed to Done. Atypical transitions: Change the state from New to Removed. Change the state from Removed to New. Change the state from Approved to Removed. Change the state from Committed to Approved.

State Changes	When to use
From New to Approved	When the product owner approves fixing the bug.
From New to Removed	When the product owner disapproves fixing the bug.
From Approved to Committed	When the team commits to fixing the bug in the current sprint.
From Approved to Removed	When the team decides not to fix the bug.
From Removed to New	When the team reconsiders fixing the bug.
From Committed to Done	When the team fixes the bug and fulfills its acceptance criteria.
From Done to Committed	When the team has found additional work that the bug requires to be fixed.
From Committed to Approved	When the team stops working on the bug because of staff changes or priority adjustment.

See Also

Other Resources

Visual Studio Scrum 1.0