58.2. Work Item Tracking

Team Foundation allows you to manage activities using work items. As you will see in the following sections, you can search for work items using work item queries and you manage them using Visual Studio, Excel, Project, or Team System Web Access. There are different types of work items like bugs, tasks, and risks, and later in the chapter you will see how to create custom types.

58.2.1. Initial Work Items

The template defined some pending tasks. These are represented as work items and by default will be assigned to the person who created the team project. You will be completing this list throughout the chapter, but for now you can close the Set Permissions, Migration of Source Code, and Migration of Work Items, and assign the ones in the Requirements, Test, and Project Management disciplines to the appropriate persons.

You can select each work item and edit its details. You will usually change the state (active, resolved, closed), rank, remaining work, or the "assign to" fields. In Figure 58-3 you can see a list of the work items edited in Visual Studio.

The initial work item list may vary depending on the process template.

Figure 58.3. Figure 58-3

58.2.2. Work Item Queries

The work items shown in Figure 58-3 are all tasks in the selected team project. You could look for different work items using the work item queries from Team Explorer. The template process includes eleven team queries (Figure 58-2) like Active Bugs, All Work Items, or My Work Items. Most of the time those queries will be enough, but you have the option to create new ones. If you're a project administrator you can add new team queries to make them available to everyone with access to this project. And if you can modify the process template, you can add new team queries, so projects created with the edited templates will include them. Changes in the templates don't apply to team projects already created. If you don't have these permissions or you want to create a personal query, you can do that, too.

When you notice you are creating the same queries over and over from one project to another, you should add those to your process templates. Over time, there will be less need to create custom queries.

To create a new query right-click the My Queries node and select Add Query (Figure 58-4).

Now you can visually design your query. In this case you only care about the work items of the selected project, assigned to the current user and under Iteration 1. You specify this using the @me and @Project variables. You can also specify which columns you want visible in the grid and sorting options (Figure 58-5). You can then run the new query to see a sub-list of the work items.

Figure 58.4. Figure 58-4

Figure 58.5. Figure 58-5

58.2.3. Work Item Types

In MSF for Agile Development you have five types of work items: bugs, risks, scenarios, quality-of-service requirements, and tasks. Each work item has different fields depending on its type. For example, a bug will have a triage state and test information field, whereas a risk is a simpler work item. Contrasting it with the MSF for CMMI template, you have a change-request work item, which doesn't exist in the Agile version. CMMI also has a risk work item, but this case is not so simple; it now requires a mitigation and contingency plan and has other fields such as severity, priority, probability, and estimate. All these fields are customizable either at a template or team-project level.

58.2.4. Adding Work Items

The basic way of adding work items is via the Team Add to Work Item menu option (Figure 58-6) and selecting the work item type you want to add. Another convenient way to add work items is through the Test Results window, which was explained in Chapter 56.

Figure 58.6. Figure 58-6

When you do it this way you will usually create a bug and also create a link between it and the selected test. You can navigate from the bug to the test or see the test and its related work items (Figure 58-7). If the test fails again, you can see the work items associated with it and track it back to their related change sets, as you will see later in the "Version Control" section. Team System also associates the test result with the work item and optionally uploads the assemblies being tested; that way the developer assigned to correct the bug can easily reproduce it.

Figure 58.7. Figure 58-7