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.

Requirements

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.

Define a bug

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

1. In the form, specify one or more of the following fields. The only required field is Title. You can leave all other fields blank or accept their default values and update them later. When the work item is saved, the system assigns it a unique ID.

   Field/tab	Usage
   Title (Required)	Enter a description of 255 characters or less. You can always modify the title later.
   Iteration	Choose the sprint or iteration in which the work is to be completed, or leave it blank and assign it later, during a planning meeting. To change the drop-down list of iterations, see Create and Modify Areas and Iterations.
   Assigned To	Assign the work item to the team member responsible for performing the work. Depending on the context you are working in, the drop-down menu will list only team members or contributors to the team project.
   State	Use the default value first. As work progresses, update it to reflect current state. To change the drop-down list of states, see Design or Customize the Workflow.
   Reason	Use the default first. Update it when you change state. Each State is associated with a default reason. To change the drop-down list of reasons, see Design or Customize the Workflow.
   Area	Choose the area path associated with the product or team, or leave blank until assigned during a planning meeting. To change the drop-down list of areas, see Create and Modify Areas and Iterations.
   Iteration	Choose the sprint or iteration in which the work is to be completed, or leave it blank and assign it later, during a planning meeting. To change the drop-down list of iterations, see Create and Modify Areas and Iterations.
   Backlog Priority	Used to track the relative ranking of PBIs and bugs. The sequence of items on the product backlog page is determined according to where you have added the items or moved the items on the page. As you drag items, a background process updates this field, which is assigned to type="Order" in the CommonConfiguration file.
   Steps to Reproduce	Capture enough information so that other team members can understand the full impact of the problem as well as whether they have fixed the bug. This includes actions taken to find or reproduce the bug and expected behavior. Describe the criteria that the team should use to verify whether the code defect is fixed.
   Severity	A subjective rating of the impact of a bug on the project. Allowed values are: 1 - Critical 2 - High 3 - Medium 4 - Low To change the menu selection, see Define User Lists, Pick Lists, and Global Lists.
   System Info Found In Build Integrated in Build	When Test Manager creates bugs, it automatically populates System Info and Found in Build with information about the software environment and build where the bug occurred. To learn more about defining the software environments, see Setting Up Test Machines to Run Tests or Collect Data.When you resolve the bug, use Integrated in Build to indicate the name of the build that incorporates the code that fixes the bug. To access a drop-down menu of all builds that have been run, you can update the FIELD definitions for Found in Build and Integrated in Build to reference a global list. The global list is automatically updated with each build that is run. To learn more, see Add Fields to Support Integration with Test, Build, and Version Control. For information about how to define build names, see Work with Build Numbers.
   All Links	Add all types of links, such as hyperlinks, changesets, source files, and so on. This tab also lists all links defined for the work item, even those defined in other links control tabs.
   Attachments	Share more detailed information by adding files to the work item, such as email threads, documents, images, log files, or other file types.
   History	Review the audit trail that the system captures and capture additional information. Every time that the work item is updated, information is appended to the history. History includes the date of the change, who made the change, and which fields were changed. You can also add formatted text to the history field.

   To look up information about other fields, see Index of Work Item Fields.

2. 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.

3. On the work item toolbar, choose Save Work Item.

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

Add and link 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, choose 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, choose 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 choose 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, choose Link to.

   The Add Link to Bug dialog box opens.

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

3. Choose 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 choose Task as the work item type.

   Select the check box next to each task that you want to link to the bug, and then choose 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. Choose 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.

Add and link 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 Quick Start Guide for Manual Testing using Microsoft Test Manager.

To add a test case to a bug

1. On the Test Cases tab, choose 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 choose 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, choose 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 choose 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.

Add 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.

1. On the Links tab, choose New.

   The Add new Linked Work Item dialog box opens.

2. In the Link Type list, choose Related.

3. In the Work Item Type list, choose 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.

You can modify the workflow to add states, reasons, and transitions.

Q & A

Q: How do I resolve a bug as a duplicate?

A: Set the State to Removed and specify the Reason as Duplicate.

Q: How do I link to an existing bug from Test Runner?

A: See Update an Existing Bug while using Test Runner.

Q: How do I customize the bug work item type?

A: You can customize work item types by adding fields, changing the workflow, or changing the form.

Q: Can I manage bugs on the task board rather than with the product backlog?

A: Yes. You’ll need to make several customizations. See Add bugs to the task board or backlog.

See Also

Other Resources

Scrum Process Template for Visual Studio ALM