Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020
To plan a software project and track defects using Scrum, teams use the Product Backlog Item (PBI) and Bug work item types (WITs). Product owners and program managers map PBIs and bugs to features to view portfolio-level progress. When teams work in sprints, they create tasks that automatically link to PBIs and bugs.
Note
If you're new to the Scrum process, review About Sprints, Scrum and project management.
Testers create and run test cases using the web portal or Microsoft Test Manager and file bugs to record code defects. Use Impediments to track blocking issues.
Define PBIs and bugs
When you define a product backlog item, focus on the customer value and avoid describing implementation details. The product owner prioritizes the backlog by business value, effort, and dependencies. As requirements evolve, the backlog evolves; teams usually provide full details only for the highest-priority items or for items assigned to the current and next sprint.
Create PBIs and bugs from the quick add panel on the product backlog page. Then open each item to add details and estimate effort. The backlog page captures item prioritization (Backlog Priority), which product owners use to indicate relative priority.
When you set Effort for PBIs and bugs, use forecast and velocity charts to estimate future sprints. Product owners set Business Value to express priority separate from backlog stack rank.
Use the following fields and fields used in common across work item types when you complete the work item form. For details on bugs, see Manage bugs.
Field/tab
Usage
Estimate the work required to complete a PBI using any numeric unit your team prefers, such as story points or time. A numeric value is required.
Agile velocity charts and forecast tools reference this field.
Enter a number that captures the relative value of a PBI compared to other PBIs. Higher numbers indicate greater business value.
Provide enough detail for your team to estimate effort. Focus on who the feature serves, what users want to accomplish, and why. Avoid implementation instructions. Include enough context so your team can create tasks and test cases.
Describe the conditions that define "Done" for the PBI or bug fix. Clarifying acceptance criteria before work starts helps the team and customers share a common understanding and supports acceptance testing.
Capture comments in the Discussion section
Use the Discussion section to add and review comments made about the work being performed.
The rich text editor toolbar appears under the text entry area when you place your cursor in any text box that supports text formatting.
Note
A Discussion work item field doesn't exist. To query work items with comments from the Discussion area, filter on the History field. The full content of the text entered in the Discussion text box is added to the History field.
Mention someone, a group, work item, or pull request
Select one of the following icons to open a menu of recent entries where you mentioned someone, linked to a work item, or linked to a pull request:
You can open the same menu by using keyboard shortcuts: at-mention @, hash tag #, and exclamation point !.
Enter a name or number to filter the menu list to match your entry. Select the entry you want to add. To bring a group into the discussion, enter the at symbol @ followed by the group name, such as a team or security group.
Edit or delete a comment
To edit or delete any of your discussion comments, select Edit 
or More actions (
) and then select Delete:
After you update the comment, select Update. To delete the comment, confirm the deletion. The History tab on the work item form maintains a full audit trail of all edited and deleted comments.
Important
For on-premises Azure DevOps Server, configure an SMTP server for team members to receive notifications.
Add a reaction to a comment
Add one or more reactions to a comment by choosing an emoji icon at the top right of any comment. Choose from the icons at the bottom of a comment next to any existing reactions. To remove your reaction, choose the reaction on the bottom of your comment. The following image shows an example of the experience of adding a reaction, and the display of reactions on a comment.
Save a comment without saving the work item
Note
This feature is available starting in Azure DevOps Server 2022.1.
If you only have permissions to add to the Discussion of a work item, then you can do so by saving comments. This permission is controlled by Area Path nodes and the Edit work item comments in this node permission. For more information, see Set work tracking permissions - Create child nodes, modify work items under an area or iteration path.
When you save the comments, you don't need to save the work item.
Note
When you save changes made to the Discussion control, only the comment is saved. No work item rules defined for the work item type are executed.
Track progress
As work progresses, update the State field to reflect current status and optionally provide a reason. The state and reason appear in the work item form header.
Scrum workflow states
When you update State, the team understands which items are new, in progress, or completed. Most WITs support forward and backward state transitions. The following diagrams show the main progression and regression states for the PBI, Bug, and Task WITs.
| Product Backlog Item | Bug | Task |
|---|---|---|
|
|
|
PBIs and bugs often follow this progression:
- The product owner or tester creates a PBI or bug in the New state with the default reason, New backlog item.
- The product owner moves the item to Approved once described enough for the team to estimate effort. Items near the top of the backlog typically appear in Approved; items further down often remain New.
- The team sets the status to Committed when they agree to include the item in the sprint.
- The team moves the item to Done when all associated tasks are complete and the product owner confirms it meets the acceptance criteria.
Update status with board or Taskboards
Use the board to update PBI status and the sprint Taskboard to update task status. Dragging an item to a new column updates both State and Reason.
Customize the board to add swim lanes or columns. For other customization options, see Customize your work tracking experience.
Map PBIs to features
When you manage multiple products or experiences, define features and map PBIs to those features to view scope and progress across the portfolio.
Use portfolio backlogs to drill down between backlog levels and to roll up work across teams. You can also view rollups after you set up a hierarchy of teams.
Define tasks
When your team delivers work in sprints, break items into tasks from the sprint backlog page.
Name the task and estimate the effort.
Teams forecast work and define tasks at the start of each sprint. Each team member completes a subset of tasks, which can include development, testing, and other activities. For example, a developer creates tasks to implement PBIs and a tester creates tasks to author and run test cases.
When teams estimate work using hours or days, use the Remaining Work and optional Activity fields.
Field/tab
Usage
Enter how many hours or days remain to complete a task and update this field as work progresses. This value feeds capacity charts, the sprint burndown chart, and related reports. If you break a task into subtasks, track Remaining Work on the subtasks only.
Select the activity type that best represents this task when you estimate sprint capacity by activity.
Track test progress
Test PBIs
From the web portal or Test Manager, create test cases that automatically link to a PBI or bug, or add a link from the 
(links tab).
The test case contains many fields that integrate with the build and test process; see Query based on build and test integration fields.
The
(links tab) lists the PBIs and bugs linked to a test case. Linking helps teams track test progress.
Track code defects
Create bugs from the web portal, Visual Studio, or Test Manager (see Manage bugs).
Definitions for common work tracking fields
The following fields and tabs appear in most work items. Each tab is used to track specific information. Commonly used tabs include 
History,
Links, and 
Attachments.
The only required field for all work item types is Title. When you save a work item, the system assigns a unique identifier, ID. The form highlights required fields in yellow. For information about other fields, see Work item field index.
Note
Other fields might be required depending on customizations made to your process and project.
Field or Tab
Usage
Enter a description of 255 characters or less. You can modify the Title later.
Assign the work item to the team member responsible for performing the work, or leave blank and complete the assignment later.
When you first create a work item, the State field automatically shows the first state in the workflow, such as New or Unassigned. As work progresses, update the State to reflect the current status of the work item.
When you first create a work item, set the default Reason value, such as Created or New work item. As the State changes for the work item, update the Reason value accordingly. Each State for the work item is associated with a default Reason value.
Choose the area path associated with the product or team, or leave blank and enter an appropriate value later. You can change the dropdown list of available areas. For more information, see Define area paths and assign to a team.
Choose the sprint or iteration in which to complete the work item, or leave blank and assign the value later. You can change the dropdown list of iterations. For more information, see Define iteration paths (sprints) and configure team iterations.
History tab
View the work item History to see all changes made to the item, as captured by the system. Each time a work item is updated, the details are appended to the history. You see the change date, the change author, and the list of updated fields. You can also add formatted text to the History field.
Links tab
Add Links to create connections with other work items. Many kinds of links are supported, such as hyperlinks, changesets, source files, and more. Specify the relationship of the linked item to the work item, such as Parent, Found in Build, or Test Result.
Attachments tab
Use Attachments to include supporting information about the work item with the item. Attach email threads, documents, images, log files, or other file types.
Customize work item types
For most work item types, you can add fields, change the workflow, add custom rules, and add custom pages to the work item form. You can also add custom work item types. For more information, see Customize an inheritance process.
For most work item types, you can add fields, change the workflow, add custom rules, and add custom pages to the work item form. You can also add custom work item types. For more information, see Customize an inheritance process or Customize the On-premises XML process model depending on the process model used by your project.
Track impediments
Use the Impediment work item type to track events that block progress. Use the Bug work item type exclusively for code defects.
You can add an impediment from the New work item widget on a team dashboard or from the New menu on the Queries page.
Work items you add from the widget automatically scope to your team's default area and iteration paths. To change team context, see Switch team context.
Backlog list order
Use the Backlog Priority field to track the relative ranking of PBIs, bugs, features, or epics. The backlog page orders items based on where you add or move them on the page (see Create your backlog). As you drag items, a background process updates the Backlog Priority field.