Introducing Work Items Concepts | Professional Team Foundation Server

A work item type (WIT) defines the structure for a particular piece of work that needs to get executed. Work item tracking can differentiate between types of work that need to get done, for example, between fixing bugs, implementing a nonfunctional requirement, or completing a task. Each type of work item has its own definition of the information required to keep track of the work. For example, in a bug work item, the WIT defines the fields associated with that bug, and the layout of the form used by the bug work item. A work item itself is just a specific instance of a work item type. When you create a new work item for a project, you use a work item type to do it. Another way to look at it is that the work item type is the template used to create a specific work item in your project.

Now let's look at some of the different concepts associated with work items and Team Foundation Server.

Work Item Types

You've already learned how, when creating a new team project, you must select a process model. The two process models that ship with Team Foundation Server are MSF Agile and MSF CMMI. These process models define a template for your project. Part of this template definition includes defining all the default work items that are associated with the process model. These are the work items that users will have access to out of the box with Team Foundation Server. When a new team project is created, all the different work item types defined for that project are also created.

For the MSF Agile process model, the following work item types are defined:

Bug - A bug is a work item that provides information about a potential problem in the application. You open a bug to track this problem, and include information on how to re-create the actual issue. The more detailed information you provide on the bug, the easier it will be to fix the problem.
Quality of service requirement - The quality of service requirement is used to track information on how the system is supposed to operate. Certain items such as performance, availability, and maintainability are tracked in this manner, usually in defining how the system should operate in relation to these characteristics. These types of requirements are often referred to as nonfunctional requirements.
Risk - All projects have different levels of risk to them. The risk work item tracks all the different possible risks inherent in a project, which could cause the project schedule to slip. If a risk requires some action to prevent it, you can then open the appropriate risk work items. Identifying risks can lead to a more successful project.
Task - A task work item is your basic unit of work in Team Foundation Server. Tasks are very generic, and can be used in pretty much any way you would like. The process guidance for MSF Agile gives some detailed examples of how each role would use the task work item.
Scenario - A scenario is an example of how the end user will interact with the system. It is meant to record a single path that the user takes when trying to accomplish something with the application. A scenario can indicate a successful or unsuccessful outcome.

Detailed information on the entire MSF Agile process model, including the process guidance, can be found at the MSF Agile Web site at http://msdn.microsoft.com/vstudio/teamsystem/msf/msfagile.

The CMMI process model has a more extensive collection of work item types. Besides some of the above types it includes the following:

Change request - A change request identifies a change to be made to the application.
Issue - An issue is similar to a risk, in that it identifies something that could cause the project schedule to slip.
Requirement - A requirement lists what an application is supposed to do.
Review - A review identifies the results of an in-depth look into the code or the design of the application.

You learn more concerning the MSF Agile default work item tasks in a later section. And you can always refer to the process guidance that ships with these process models for more detailed information on the work item types and tips on how to use the process models. Finally, as you see later in this chapter, you are not restricted to using these types in the manner prescribed by the process guidance. You can customize these types, or even build your own.

Stored On Data Tier

It's been mentioned before in this book, but it is worth repeating here again: all information related to Team System and Team Foundation Server is stored on the Team Foundation Server data tier. The work item tracking system is no exception. There are two databases devoted directly to the work item tracking system: TfsWorkItemTracking, which contains all the information related to the different work item types, as well as specific instances of work items, and TfsWorkItemTrackingAttachments, which holds any attachments that you might add to a particular work item instance.

Having all this work item information stored in one location on the data tier becomes very useful. It is easy to back up and restore work item information in the event of a catastrophe. In addition, you can use Microsoft Excel to connect to the Team Foundation Server Data Warehouse, allowing you to create useful charts and pivot tables that can give you very detailed information

Work Item Form

Every work item type defines a work item form that is used to fill out a particular instance of the work item type. The form definition and layout is tied directly into the definition of the work item type. When you make changes to an existing work item type, or create a new one, you have to make the appropriate changes to the form definition. For example, if you add a new field to the work item type, you will also need to modify the form definition to allow the user to enter information for that new field.

All the information for the work item type, including what fields are included in the work item type, what fields are available on the work item type form, and the layout of the form, are defined in one XML file. This allows existing work item types to be easily customized, and enables you to extend the platform using new work item types. You learn more about this shortly.

Using the work item form, you can relate work items to changesets in the version control system. You can link to other work items, enabling you to cross-reference information. You can add attachments, such as Word or Excel documents that are related to the work item. Moreover, you can view the work item history to see all the changes that have occurred, when they occurred, and who made them. Talk about a lot of information at your fingertips! You can get all this without ever leaving the Team Explorer tool.

Work item forms can implement rules. For example, you can make fields required, or read-only. You can automatically populate fields with dates or users. You can tie fields back into certain lists. This allows you to make a form that is easier and more intuitive to use, enabling you to capture good clean data in the proper format. These lists can be specific to a work item field, or can be global lists usable by any work item type. We will cover some of these rules later in this chapter. For a more comprehensive look at the rules, we recommend you download the Visual Studio Software Development Kit (VS SDK). This kit contains specific information related to work items, including detailed information on work item forms.

Work Item Work Flow

Tying into the concept of the work item form is the ability to implement a work item workflow. This allows you to automatically change things on a work item form, for example filling out certain fields, based on a series of rules.

For example, when you change a work item from one state to another, say from Open to Closed, the workflow would automatically timestamp the appropriate fields for you. Then let's say, later in the day, someone reopens that work item. You could have a workflow set up so that, when a work item is reopened, it is automatically reassigned to the person who closed it. The person reopening the work item doesn't have to hunt to find out whom to assign the work item to, because the system does this automatically. And all of this workflow information is defined in the work item type definition.

The goal of Team Foundation Server is to support better predictability and quality of projects. And Team Foundation Server, along with the work item tracking system, will allow teams to do a more efficient job with fewer flaws. These little details, such as reassigning the work item to the appropriate person, free up valuable time which, in the long run, ultimately gives team members more time to work on the actual project.

Customizing and Extending

The work item tracking system allows you to export existing work item types, make some modifications to them, and then reimport them back into your existing projects, making the changes easily available.

For example, if you wanted to make a certain field required that was not required before, you could export the work item type, open the XML definition, make the change, then reimport the type back into the particular project. From that point on, that field would be required for all work items of that particular type.

You can also create brand new work item types. Instead of making your process conform to the types presented with the default process models, build types that allow you to work the way you want to. Don't like the built-in bug work item type of MSF Agile? Export it and change it. Better yet, just build your own that works exactly the way you want it to. The point is, Team Foundation Server in general, and the work item tracking system in particular, is designed to give you the power to use the tool the way you want to. Worry about solving your problems, not about how to use the tool.

The work item tracking system also has a built-in object model for doing custom development. We touch on this briefly in Chapter 9, and come back to it later in this chapter. This object model allows you to interact with the work item tracking system, enabling you to build tools that can help you work with the system more effectively. Later in this chapter, we show you how to build a simple ASP.NET page to view a work item.

Work Item Queries

Finally, work items have their own query language, called, not surprisingly, the Work Item Query Language, or WIQL. This language is a SQL-like construct that is used in conjunction with the work item tracking object model to query information from the work item tracking system. You learn more about the WIQL later in this chapter.

The Visual Studio Software Development Kit has detailed information on the WIQL and any of the topics you have heard about so far. This kit is packed with information related to the work item tracking system, including documentation and examples. Some of the examples may be a little out of date, but Microsoft is working on updating the information, so check back regularly.