Work items

You can use work items to manage the tasks and issues that your team must address during the development cycle. The status and number of work items are indicators of the condition of your project.

Work item types

The Scrum process is ready to use and provides multiple predefined work item types:

  • Adoption Item: Tracks when changes by one team must be adopted by another team
  • Defect: Identifies a bug
  • Retrospective: Records what went well and what did not go well in the recently completed iteration
  • Story: Describes part of a use case
  • Task: Describes a specific piece of work
  • Impediment: Tracks things that get in the way of progress
  • Epic: Used when a story is too big to complete in a single iteration (sometimes called a "sprint") or when there are too many unknowns to estimate the amount of work. An Epic can be broken down into several stories.
  • Track build item: Typically created from a build result to track the fixes that are needed for a failed build
The Formal Project Management process is also ready to use. This process provides the following work item types:
  • Defect: Identifies a bug
  • Task: Describes a specific piece of work
  • Project Change Request: Provides a formal mechanism to renegotiate key project parameters, such as scope, timeline, or resources
  • Business Need: Records commitments that the development team makes to the business organization
  • Risk: Describes project risks, and provides a matrix to calculate the risk probability and impact
  • Risk Action: Describes specific actions to counter or mitigate a risk
  • Issue: Identifies and describes a potential problem for which no concrete solution is proposed. Issues can be created from risks that do not have a proposed solution.
  • Milestone: Identifies a significant event in the project plan or a phase plan

You can define additional work item types to complement the development process that your team follows.

Work items for tracking work

As with defect-tracking systems, you can use work items for the following purposes:

  • Describing defects
  • Describing feature improvements
  • Identifying simple tasks, such as updating copyright notices
  • Recording customer requirements

You can also use work items to generate a list of new features that your team is delivering with a release. From a project management perspective, you can use work items to provide metrics about the status of your project.

Work items for managing work

With work items, you can complete several activities to manage your work:
  • Associate source code change sets with work items so that users can navigate between a work item and code. You can associate source code change sets from the Pending Changes view.
  • Attach documents and screen captures
  • Transfer ownership from one team member to another
  • Include work items in plans for specific milestones by setting the values in the Filed Against and Planned For fields to those values of the plan
  • See which work items other team members are working on
  • Add an approval to a work item. When you add an approval, you identify one or more users who must review, approve, or verify the work done to resolve the work item
  • Chat with the submitter of the work item or another team member to answer questions

Each work item type has a state transition model that defines the states a work item can be in and the actions to move the work item throughout states. A typical state transition model provides a path from a submitted or opened state to a resolved or closed state. In states between those start and end points, team members can indicate their progress in addressing the issues described in the work item.

Work item queries

The primary mechanism for finding work items is the query. To get started, you can use predefined queries, such as a query that returns all unresolved work items assigned to you. You can create queries to meet your needs, and you can share queries with all members of your team or with specific users.