Manage Scrum process work item types & workflow
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
To plan a software project and track software defects using Scrum, teams use the product backlog item (PBI) and bug work item types (WITs). To gain insight into a portfolio of features, scenarios, or user experiences, product owners, and program managers can map PBIs and bugs to features. When teams work in sprints, they define 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 can create and run test cases and create bugs to track code defects using the web portal or Microsoft Test Manager. Impediments track blocking issues.
Define PBIs and bugs
When you define a product backlog item, focus on the value that your customers gain and avoid descriptions of how your team develops the feature. The product owner can prioritize your product backlog based on each item's business value, effort, and relative dependency on other backlog items. As your business requirements evolve, so does your product backlog. Typically, teams specify details only for the highest priority items, or those items assigned to the current and next sprint.
You can create PBIs and bugs from the quick add panel on the product backlog page.
Afterward, you can open each PBI or bug to provide more details and estimate the effort. Also, by prioritizing the PBIs and bugs on the backlog page (which is captured in the Backlog Priority field), product owners can indicate which items should be given higher priority.
When you define the Effort for PBIs and bugs, you can use the forecast feature and velocity charts to estimate future sprints or work efforts. When you define the Business Value, product owners can specify priorities separate from the changeable backlog stack ranking.
Use the following fields and fields used in common across work item types when you complete the work item form. For more information, see Manage bugs.
Field/tab
Usage
Estimate the amount of work required to complete a PBI using any unit of measurement your team prefers, such as story points or time. A numeric value is required.
Agile velocity charts and forecast tools reference the values in this field. For more information, see the Estimating white paper.
Specify a number that captures the relative value of a PBI compared to other PBIs. The higher the number, the greater the business value.
Provide enough detail for estimating how much work is required to implement the item. Focus on who the feature is for, what users want to accomplish, and why. Don't describe how the feature should be developed. Do provide sufficient details so that your team can write tasks and test cases to implement the item.
Define what "Done" means by describing the criteria that the team should use to verify whether the PBI or the bug fix has been fully implemented.
Before work begins on a PBI or bug, describe the criteria for customer acceptance as clearly as possible. Conversations between the team and customers to determine the acceptance criteria helps ensure a common understanding within the team to meet customers' expectations. The acceptance criteria can be used as the basis for acceptance tests so that the team can more effectively evaluate whether an item has been satisfactorily completed.
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. Alternatively, you can open the same menu by entering @, #, or !.
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 @ 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, choose 
Edit or choose the 
actions icon and then choose Delete.
Note
Editing and deleting comments requires Azure DevOps Server 2019 Update 1 or later version.
After you update the comment, select Update. To delete the comment, confirm that you want to delete it. 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 a smiley icon at the upper-right corner 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 gets saved. No work item rules defined for the work item type are executed.
Track progress
As work progresses, you change the State field to update the status. Optionally, you can specify a reason. The state and reason fields appear on the work item form in the header area.
Scrum workflow states
When you update the State, teams know which items are new, in progress, or completed. Most WITs support transition both forward and backward from each workflow state. These diagrams show the main progression and regression states of the PBI, bug, and task WITs.
| Product Backlog Item | Bug | Task |
|---|---|---|
|
|
|
PBIs and bugs follow this typical workflow progression:
- The product owner creates a PBI or a tester creates a bug in the New state with the default reason, New backlog item
- The product owner moves the item to Approved after it's sufficiently described and ready for the team to estimate the level of effort. Most of the time, items near the top of the Product Backlog are in the Approved state, while items toward the middle and bottom are in a New state
- The team updates the status to Committed when they decide to commit to working on it during the sprint
- The item gets moved to the Done state when the team has completed all its associated tasks and the product owner agrees that it has been implemented according to the Acceptance Criteria.
Update status with board or Taskboards
Teams can use the board to update the status of PBIs, and the sprint Taskboard to update the status of tasks. Dragging items to a new state column updates both the State and Reason fields.
You can customize the board to support more swim lanes or columns. For other customization options, see Customize your work tracking experience.
Map PBIs to features
When you manage a suite of products or user experiences, you might want to view the scope and progress of work across the product portfolio. To do so, define features and map PBIs to features.
Using portfolio backlogs, you can drill down from one backlog to another to view the level of detail you want. Also, you can use portfolio backlogs to view a rollup of work in progress across several teams when you setup a hierarchy of teams.
Define tasks
When your team manages their work in sprints, they can use the sprint backlog page to break down the work to be accomplished into distinct tasks.
Name the task and estimate the work it takes.
Teams can forecast work and define tasks at the start of each sprint, and each team member completes a subset of those tasks. Tasks can include development, testing, and other kinds of work. For example, a developer can define tasks to implement PBIs, and a tester can define tasks to write and run test cases.
When teams estimate work using hours or days, they define tasks and the Remaining Work and Activity (optional) fields.
Field/tab
Usage
Indicate how many hours or days of work remain to complete a task. As work progresses, update this field. It's used to calculate capacity charts, the sprint burndown chart, and the Sprint Burndown (Scrum) report.
If you divide a task into subtasks, specify Remaining Work for the subtasks only. You can specify work in any unit of measurement your team chooses.
Select the type of activity this task represents when your team estimates sprint capacity by activity.
Track test progress
Test PBIs
From the web portal or Test Manager, you can create test cases that automatically link to a PBI or bug. Or, you can link a PBI or bug to a test case from the 
(links tab).
The test case contains many fields, many of which are automated and integrated with Test Manager and the build process. For a description of each field, see Query based on build and test integration fields.
The
(links tab) captures the links to all the PBIs and bugs in a test case. By linking PBIs and bugs to test cases, the team can track the progress made in testing each item.
Track code defects
You can create bugs from the web portal web portal, Visual Studio, or when testing with Test Manager.
Definitions for common work tracking fields
The following fields and tabs appear in most work items. Each tab gets used to track specific information, such as 
History,
Links, or 
Attachments. These three tabs provide a history of changes, view of linked work items, and ability to view and attach files.
The only required field for all work item types is Title. When you save a work item, the system assigns it a unique ID. The form highlights required field in yellow. For information about other fields, see Work item field index.
Note
Additional fields may be required depending on customizations made to your process and project.
Field/tab
Usage
Enter a description of 255 characters or less. You can always modify the title later.
Assign the work item to the team member responsible for performing the work.
When the work item is created, the State defaults to the first state in the workflow. As work progresses, update it to reflect the current state.
Use the default first. Update it when you change state. Each State is associated with a default reason.
Choose the area path associated with the product or team, or leave blank until assigned during a planning meeting. To change the dropdown list of areas, see Define area paths and assign to a team.
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 Define iteration paths (sprints) and configure team iterations.
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.
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.
Share more detailed information by adding files to the work item, such as 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 may block progress or ship a PBI. Use the Bug work item type exclusively to track code defects.
You can add an impediment from the New work item widget added to a team dashboard, or from the New menu on the Queries page.
Work items you add from the widget are automatically scoped to your team's default area and iteration paths. To change the team context, see Switch team context.
Backlog list order
The Backlog Priority field is used to track the relative ranking of PBIs, bugs, features, or epics. However, by default it doesn't appear on the work item form. The sequence of items on the backlog page is determined according to where you've added the items or moved the items on the page. As you drag items, a background process updates this field.