Manage your Scrum process work item types and workflow

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018 - TFS 2013

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.

Using the web portal or Microsoft Test Manager, testers can create and run test cases and create bugs to track code defects. Impediments track blocking issues.

Define PBIs and bugs

When you define a product backlog item, you want to focus on the value that your customers will receive and avoid descriptions of how your team will develop 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.

Later, 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.

By defining the Effort for PBIs and bugs, teams can use the forecast feature and velocity charts to estimate future sprints or work efforts. By defining the Business Value, product owners can specify priorities separate from the changeable backlog stack ranking.

Use the following guidance and that provided for fields used in common across work item types when filling out the form. For details about creating bugs, see Manage bugs.

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

By updating 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 is 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 Kanban or taskboards

Teams can use the Kanban 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 Kanban 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. You can do this by defining features and mapping 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 will take.

Using Scrum, teams 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.

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 is 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 the work item is saved, the system assigns it a unique ID. The form highlights required field in yellow. For information about other fields, see Work item field index.

Customize work item types

You can add fields, change the workflow, add custom rules, and add custom pages to the work item form of most work item types. You can also add custom work item types. For details, see Customize the On-premises XML process model.

Related articles

Before you start tracking work, you must have a project. To create one, see Create a project.

If you have a project, start tracking work:

• Add work items to manage a project - to gain more familiarity with the work item form features
• Create a backlog - to develop your product backlog
• Kanban - to start working in Kanban
• Plan a sprint - to start working in Scrum
• Excel.

For more information on Agile tools:

• Team assets
• Best tool to add, update, and link work items

Track impediments

Use the impediment WIT to track events that may block progress or ship a PBI. Use the Bug WIT 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.

Links control, client work item form

Work item forms displayed in a client and the web portal for TFS 2015 and earlier versions display link tabs and link control restrictions as described in the following table.