Agile process work item types and workflow

Visual Studio Team Services | Visual Studio 2015 | Previous versions

Teams use the work item types (WITs) provided with the Agile process template to plan and track progress of software projects. Teams define user stories to manage the backlog of work and then, using the Kanban board, track progress by updating the status of those stories.

Agile process work item types

To gain insight into a portfolio of features, scenarios, or user experiences, product owners and program managers can map user stories to features. When teams work in sprints, they define tasks which automatically link to user stories.

Using the web portal or Microsoft Test Manager, testers can create and run test cases. Bugs and issues are used to track code defects and 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 user stories

User stories define the applications, requirements, and elements that teams need to create. Product owners typically define and stack rank user stories. The team then estimates the effort and work to deliver the highest priority items.

Create user stories from the quick add panel on the product backlog page.

Quick add panel

Later, you can open each user story to provide more details and estimate the story points.

User story work item form

By defining the Story Points, teams can use the forecast feature and velocity charts to estimate future sprints or work efforts. By prioritizing the user stories on the backlog page (which is captured in the Stack Rank field), product owners can indicate which items should be given higher priority.

Use the following guidance and that provided for fields used in common across work item types when filling out the form.

Field/tab

Usage

Description

For user stories, provide enough detail for estimating how much work will be required to implement the story. 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

Provide the criteria to be met before the bug or user story can be closed. Before work begins, describe the customer acceptance criteria as clearly as possible. Conversations between the team and customers to define the acceptance criteria will help ensure that your team understands your customers’ expectations. The acceptance criteria can be used as the basis for acceptance tests so that you can more effectively evaluate whether an item has been satisfactorily completed.

Value area

The area of customer value addressed by the epic, feature, requirement, or backlog item. Values include:

  • Architectural : Technical services to implement business features that deliver solution

  • Business: Services that fulfill customers or stakeholder needs that directly deliver customer value to support the business (Default)

Story Points

Estimate the amount of work required to complete a user story 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. For additional guidance, see the Estimating white paper.

Priority

A subjective rating of the user story, feature, or requirement as it relates to the business. Allowed values are:

  • 1: Product cannot ship without the feature.

  • 2: Product cannot ship without the feature, but it doesn’t have to be addressed immediately.

  • 3: Implementation of the feature is optional based on resources, time, and risk.

Risk

A subjective rating of the relative uncertainty around the successful completion of a user story. Allowed values are:

  • 1 - High

  • 2 - Medium

  • 3 - Low

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.

Track progress

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.

Track progress on the Kanban board

You can customize the Kanban board to support additional swim lanes or columns.

A typical workflow progression for a user story follows:

  • The product owner creates a user story in the New state with the default reason, New user story.

  • The team updates the status to Active when they decide to complete the work during the sprint.

  • A user story is moved to Resolved when the team has completed all its associated tasks and unit tests for the story pass.

  • A user story is moved to the Closed state when the product owner agrees that the story has been implemented according to the Acceptance Criteria and acceptance tests pass.

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

Agile workflow states

These diagrams show the main progression and regression states of the feature, user story, bug, and task work item types.

Feature

Feature workflow states, Agile process template

User Story

User Story workflow states, Agile process template

Bug

Bug workflow states, Agile process template

Task

Task workflow states, Agile process template

Map user stories 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 user stories to features.

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

Features backlog quick add panel

The feature work item contains similar fields provided for user stories, and includes additional fields, as the following table describes.

Feature work item form

The following fields provide support for tracking the effort and time critical nature of features and epics. To learn more about epics, see Organize your backlog.

Field

Usage

Effort

A subjective unit of measure that captures the size of an epic or feature. If you assign more effort to an item, you indicate that more work is required to implement it.

Business Value

Specify a number that captures the relative value of a feature compared to other features. The higher the number, the greater the business value.

Time Criticality

A subjective unit of measure that captures how the business value decreases over time. Higher values indicate that the epic or feature is inherently more time critical than those items with lower values.

Target Date

Specify the date by which the feature should be implemented.

From the backlog page with Mapping turned on, you can drag user stories to the feature that they implement. The Links tab icon (links tab) captures the links to mapped user stories.

Map user stories to features

This mapping creates parent-child links from feature to user stories, which is captured in the Links tab icon (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.

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.

Sprint backlog, add task

Name the task and estimate the work it will take.

Agile task work item form

Using Agile processes, 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 user stories, 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

Original Estimate

The amount of estimated work required to complete a task. Typically, this field doesn’t change after it is assigned.

You can specify work in hours or in days. There are no inherent time units associated with this field.

Remaining Work

The amount of work remaining to complete a task. As work progresses, update this field. It’s used to calculate capacity charts, the sprint burndown chart, and the following reports: Burndown and Burn Rate, Remaining Work, and Status on All Iterations.

If you divide a task into subtasks, specify hours for the subtasks only. You can specify work in any unit of measurement your team chooses.

Completed Work

The amount of work spent implementing a task.

Activity

Select the type of activity this task represents when your team estimates sprint capacity by activity.

Integrated in Build

Product build number that incorporates the code or fixes a bug.

If you use Microsoft Project to assign resources and track a schedule, you can update these fields using Project.

Track test progress

Test user stories

From the web portal or Test Manager, you can create test cases that automatically link to a user story or bug. Or, you can link a user story to a test case from the Links tab icon (links tab).

Test plan web portal

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 form

The Links tab icon (links tab) captures the links to user stories and bugs in a test case. By linking user stories and bugs to test cases, the team can track the progress made in testing each item. By defining these links, you support information that appears in the Stories Overview Report report.

Track code defects

You can create bugs from the web portal web portal, Visual Studio, or when testing with Test Manager.

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 tab icon history, Links tab icon links, or Attachment tab icon 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.

Field/tab

Usage

Title

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.

State

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.

Reason

Use the default first. Update it when you change state. Each State is associated with a default reason.

Area

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.

Iteration

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.

History tab icon(History)

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.

Links tab icon(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.

Attachment tab icon(Attachments)

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.

Related notes

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:

Track issues

Issues are used to track events that may block progress or shipping a user story. Bugs, on the other hand, are used to track code defects. You can add an issue from the New work item widget added to a team dashboard, or from the New menu on the Queries page.

Add work item from a New work item widget

Work items you add from the widget are automatically scoped to your team's area and iteration paths. Go here to change the team context.

Track business value

You can use the Priority field to differentiate the value of various stories. Or, you can add a custom field to the User Story WIT that tracks the relative value of stories. To learn how, see Customize process.

Rich text format

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 tool bar - web portal

Rich text formatting toolbar - Team Explorer

Rich text tool bar - 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)

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)

Backlog list order

The Stack Rank field is used to track the relative ranking of user stories, 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.

Switch team context

You navigate to your team context from the top navigation bar.

Choose another team from the team project menu