Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

Scrum process template work item types and workflow

Visual Studio 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 which automatically link to PBIs and bugs.

Scrum 3.0 work item types

Using Microsoft Test Manager and Team Web Access (TWA), testers create and run test cases and create bugs to track code defects. Impediments track blocking issues.

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. The product backlog will evolve quickly if the business requirements of your project and other conditions of your team change constantly. To minimize redundant work, your team can specify details only for the highest priority items.

You can create PBIs and bugs from the quick add panel on the product backlog page.

Add an item to your product backlog

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.

Screenshot showing a new product backlog item

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 for these essential fields. For details about creating bugs, see Track code defects later in this topic.




Estimate the amount of work required to complete a PBI using any unit of measurement your team prefers, such as t-shirt size, story points, or time.

Agile velocity charts and forecast tools reference the values in this field. This is a required field to generate the Release Burndown (Scrum) and Velocity (Scrum) reports.

For additional guidance, see the white paper about Estimating.

Business Value

Specify a number that captures the relative value of a PBI compared to other PBIs. The lower the number, the greater the business value.

Description (PBIs)

Provide enough detail for estimating how much work will be required to implement the item or resolve the software defect. 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.

Acceptance Criteria

Define what “Done” means by describing the criteria that the team should use to verify whether the PBI or 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.

Teams can use the Kanban board to track progress of PBIs and bugs, and the sprint task board to track progress of tasks. Dragging items to a new state column updates the workflow State and Reason fields.

Move an item to a different column

You can customize the Kanban board to support additional swim lanes or columns. Or, you can customize the workflow for the PBI and task WITs, which will change the default column headings.

A typical workflow progression for a PBI follows:

  • The product owner creates a PBI in the New state with the default reason, New backlog item.

  • The product owner moves a PBI to Approved after it is 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 complete the work during the sprint.

  • A PBI is moved to the Done state when the team has completed all its associated tasks and the product owner agrees that the PBI has been implemented according to the Acceptance Criteria.

By updating the workflow, teams know which items are new, in progress, or completed. Most WITs support transition both forward and backward from each work flow state.

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.

From the Feature backlog page, you can quickly add features, in the same way that you added PBIs.

Quick add features from the Features backlog

The feature work item contains similar fields provided for PBIs. In addition to Priority and Business Value, you can specify the Target Date by which the feature should be implemented.

Feature work item form

From the backlog page with mapping turned on, you can drag PBIs to the feature that they implement.

Map a PBI to a feature

This mapping creates parent-child links from feature to PBIs, which is captured in the Implementation tab.

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.

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.

Add a task to an item in the sprint backlog

Name the task and estimate the work it will take.

Add a title and an estimate of hours

Using Scrum, teams forecast work and define tasks at the start of each sprint, and each team member performs 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.



Remaining Work

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. To change the menu selection, see Customize a pick list (drop down menu).

From Test Manager or TWA, you can create test cases that automatically link to a requirement or PBI.

Select the test suite and add a test case

The test case contains a number of fields, many of which are automated and integrated with Test Manager and the build process. For a description of each field, see Build and test integration field reference.

Test case work item form

The Tested Backlog Items tab lists 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.

You can create bugs from TWA, Visual Studio, or when testing with Test Manager.

Bug work item for Scrum process template



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.


A subjective rating of the impact of a bug on the project. Allowed values are:

  • 1 - Critical

  • 2 - High

  • 3 - Medium

  • 4 - Low


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. When you resolve the bug, use Integrated in Build to indicate the name of the build that incorporates the code that fixes the bug.

For information about how to define build names, see Use build numbers to give meaningful names to completed builds.

The following fields and tabs appear in most work item forms. 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, respectively.

The only required field is Title. When the work item is saved, the system assigns it a unique ID.



Title (Required)

Enter a description of 255 characters or less. You can always modify the title later.

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.


Use the default value first. As work progresses, update it to reflect current state.

To change the drop-down list of states, see Customize the workflow for a work item type.


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 Customize the workflow for a work item type.


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 Add and modify area and iteration paths.


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 Add and modify area and iteration paths.

Stack Rank

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 ProcessConfiguration file.

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.


Share more detailed information by adding files to the work item, such as email threads, documents, images, log files, or other file types.


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.

A: The quickest way is to start by creating your backlog. If you have a number of PBIs and tasks that you want to bulk add, you can use Excel or Project.

If you are planning a product suite and managing progress across several teams, you’ll want to read Work with portfolio backlogs and how to setup a hierarchy of teams.

A: By creating a query, you can filter a list of work items based on your search criteria. Also, common ways that are used to filter work items are by area path, iteration path, and by adding tags. You can only add tags and filter lists using TWA.

A: The Storyboards tab in the PBI form allows you to link to storyboards that you've uploaded to a shared network location. You can link to any URL that your team can access. Also, you can link to storyboards that you created using PowerPoint Storyboarding.

Did you find this helpful?
(1500 characters remaining)
© 2013 Microsoft. All rights reserved.