Team Foundation Server (TFS) contains a feature called work items (WIs for short). These allow the members of the development team to record application requirements, communicate with each other and work in unison with the defined process model for the organization. Work Items are part of every Team Foundation Server team project, and can be created by all team members provided that they have the appropriate user rights.
When adding new work items, the process looks like typing in text to fields in an electronic form. These forms can be filled in directly using Microsoft Visual Studio, or the web-based Team Foundation Server Web Access feature. Work items can also be queried, and the information in them is the basis for many different reports in Team Foundation Server. For instance, if the work items would contain information about bugs, you could run a report estimating the amount of work remaining.
In this article, you will learn about the work item support in Microsoft Visual Studio 2010 and Team Foundation Server 2010. This article assumes you have basic knowledge of TFS and know how to get around within the product. If you are new to TFS, take a look at the previous two parts of this Microsoft ALM article series available here.
Now, let's start from the basics of work items.
What are Work Items?
Work items store information about planned work for individual members or the team as a whole (Figure 1). Different work item types available in a project are defined by the process template of the team project, and are set when the team project is created. Although certain modifications can be made into an existing team project, it is best to think that the work item definitions become fixed when the team project is created. Technically, work items are stored as records in the Team Foundation Server SQL database.
Figure 1. Work items can be viewed and edited directly in Microsoft Visual Studio.
Table 1 lists the work item types (which are a form of TFS artifacts) available in the two default process models that Microsoft provides. The MSF for CMMI process template defines slightly more work items than the agile template, MSF for Agile.
Table 1. Out-of-the-box work item types supported by Team Foundation Server 2010.
Assuming team members have the rights to do so, each member can file their own bugs and fill in as many as possible of the fields in the work item (the "form"). By default, Microsoft Visual Studio doesn't enforce that many fields to contain a value; instead filling in the fields is left to the team member's discretion.
Although not making most of the fields in the work items mandatory means easier filling in, the problem is that the reports that the system can deliver are only as good as the data the reports are based on. If team members leave out field values just out of convenience or hurry, the reports can only contain partial information at best. As it often is with TFS, it is the organization culture that defines how much benefit can be gained from the system.
Learning to use work items can also mean learning new words, especially for developers that are not native English language speakers. Words like triage, iteration, epic and stack rank might not be immediately obvious in the context of software development.
Furthermore, the debate about priority and triage values is long-lasting: what is "high" priority? By definition, setting a triage is "the process that is used to review newly reported or reopened bugs and assign a priority" and setting a priority is deciding which features should be implemented first.
In addition to being just forms with fields that can be filled in, work items participate in the defined workflow of the team project. This means that certain rules apply to filling in the fields of a work item. For instance, the organization's process model might mandate that a bug fix is verified by a tester before it can be marked as resolved. This workflow is defined as transitions in the process template for the team project.
To facilitate information sharing, Team Foundation Server allows work items to be linked with each other. This allows you to build a "tree" of work items, allowing you to walk from a higher level work item to a more detailed implementation level work item. For instance, in agile methodology, you could link tasks to a user story, or a task to an issue. Work items can be linked together by using Microsoft Visual Studio's Link to command.