Scrum process work item types and workflow
Visual Studio Team Services | Visual Studio 2015 | Previous versions
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.
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.
Feature availability: Work item tracking forms and features available to you differ depending on whether you connect to the cloud or an on-premises Team Foundation Server (TFS), and whether you open the form from the web portal or Visual Studio Team Explorer. Forms and guidance provided in this topic reflect those available from the web portal when you connect to Visual Studio Team Services.
If you connect to an on-premises Team Foundation Server (TFS) or open the form from Visual Studio Team Explorer, see the previous version of this topic for guidance.
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.
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.
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 will be 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.
Tip: Use the Discussion section to add and review comments made about the work being performed. This feature is only available when you connect to VS Team Services.
Teams can use the Kanban board to track progress of user stories, and the sprint task board to track progress of tasks. Dragging items to a new state column updates the workflow State and Reason fields.
A typical workflow progression for PBIs and bugs follows:
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 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.
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.
By updating the workflow status, teams know which items are new, in progress, or completed. Most WITs support transition both forward and backward from each workflow state.
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.
Scrum workflow states
These diagrams show the main progression and regression states of the feature, PBI, bug, and task work item types.
Product Backlog Item
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.
From the Feature backlog page, you can quickly add features, in the same way that you added PBIs.
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.
From the backlog page with mapping turned on, you can drag PBIs to the feature that they implement.
This mapping creates parent-child links from feature to PBIs, which is captured in the (links 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.
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 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.
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.
Select the type of activity this task represents when your team estimates sprint capacity by activity.
Track test progress
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 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.
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
Definitions for common WIT 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 WITs is Title. When the work item is saved, the system assigns it a unique ID. The form highlights required field in yellow.
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. Depending on the context you are working in, the drop-down menu will list only team members or contributors to the team project.
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 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.
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.
For information about other fields, see Work item field index.
Before you start tracking work, you must have a team project. Go here to create one.
If you have a team project, start tracking work:
- Add work items to manage a project - to gain more familiarity with the work item form features
- Create a backlog
- Plan a sprint
- Track work using Kanban
Use the impediment WIT to track events that may block progress or ship a PBI. Use the Bug WIT exclusively to track code defects.
Rich text format
To convey detailed information, you can format text and insert images inline within their description and history fields, or within any HTML field type.
The formatting toolbar appears above each text box that can be formatted. It only becomes active when you click within the text box.
You can format text in HTML data fields, such as the Description, Accepted Criteria, and History. Available fields depend on the work item type and if you've customized the process.
You can format text and insert images inline using the web portal or Team Explorer. The specific set of formatting features differs between the two clients.
Rich text formatting toolbar - Web portal
Rich text formatting toolbar - Team Explorer
For example, using Team Explorer you can choose the font, font size, and text and background colors in addition to applying formats of bold, italics, underline, lists, and hyperlinks that are available with web portal.
You can copy and paste HTML text or an image from another application directly into the text box using Ctrl+C and Ctrl+V shortcuts.
You can also use the following shortcut keys to format your text:
- Bold Ctrl+B
- Italic Ctrl+I
- Underline Ctrl+U
- Hyperlink Ctrl+K (Team Explorer only)
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 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.
Customize work items
For an overview of what you can customize, see Customize work.
- To add a custom field or modify field rules or the form, see customize process (../process/customize-process.md) (VS Team Services only)
- To change the pick list for a field, see Customize a pick list. (on-premises TFS only)
- You can customize the workflow states and reasons for the user story and tasks which will change the default column headings on the Kanban and task boards. (on-premises TFS only)
Switch team context
You navigate to your team context from the top navigation bar.