Viewing Work Items

Viewing Work Items

In a development life cycle build using Team System, the primary method for initiating action is a work item. Depending on the structure of the development team, a developer might be assigned a task from the development manager, an application architect, a senior developer, a tester, a fellow developer, or even the developer himself.

Work items are the mechanism by which members of the team track items of interest to the development life cycle. The first type of work item that most people are exposed to is a task. This work item simply assigns work to some member of the development team. That task can then be commented on, tracked, reported on, and closed out when it is complete. The types and names given to work items generally depend on the methodology being used. Microsoft Solutions Framework (MSF) 4.0 for Agile Software Development, for instance, includes Task, Quality of Service (QoS) Requirement, Risk, Scenario, and Bug. Other methodologies may implement different work item types, which allows for a large amount of flexibility in the way a team develops code. Work items are also extensible, allowing for easy custom creation of work items specific either to a custom methodology or even tailored to a specific development project. For instance, a development team might create a “Critical Bug” type of work item for bugs that are discovered in software that has already been shipped, or a “Security Bug” work item type that tracks the discoverability, reproducibility, exploitability, affected users, and discoverability (DREAD) of the security flaw. Reports could then be generated that could aggregate and rank the security risks of the software in its current state of development.

Work items, then, are the base tracking mechanism in any Team System project, and the work items can be of many different types. As a developer, you'll be exposed to hundreds or thousands of work items throughout any given project; unfortunately, many of them will be tasks.

Besides the many different types of work items, there are also many different ways of viewing the work items that have been tasked. Inside Visual Studio, the primary way to view work items is to use the Work Items Project Queries. There are several default queries created inside the project. These queries are determined by the development methodology used. For instance, in the MSF 4.0 for Agile Software Development methodology, there are queries that return the currently active bugs, all the work items assigned to the currently logged-in developer, all tasks, and all bugs. There are also several other built-in queries. You can also create your own query to view particular work items of interest. In fact, if the development methodology has been modified to include new types of work items, you can create a custom query to ensure you stay on top of your assigned work items.

Custom queries are created by adding them to the My Queries folder. (See Figure 6-1.) When you add a query, you can choose from a variety of selection criteria, including who assigned the work items, who the items are assigned to, whether or not the items have attachments, the current status of the item, and many other criteria. In fact, you can even query work items based on the number of files that were attached to the work item!

Figure 6-1 Creating a new work item query from Team Explorer