Work Item Tracking in Microsoft Visual Studio 2005 Team System
Microsoft Visual Studio 2005 Team System
Summary: This article examines the work item tracking system available in Visual Studio 2005 Team System. (11 printed pages)
Note This document was developed prior to the product's release to manufacturing, and as such, you may find inconsistencies between the details included here and those found in the shipping product. The information is based on the product at the time this document was created, and should be used for planning purposes only. Information is subject to change at any time, without prior notice. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Work item tracking (WIT) is a feature included with Microsoft Visual Studio 2005 Team System that helps not only developers, but also project managers, analysts, and testers. As the name implies, work item tracking provides a means of tracking the various items that individuals involved in development projects must work on. Work items are no different than the task lists that are kept in project plans, bug lists, and feature lists. What is different is how the work item tracking system is integrated with the rest of Visual Studio Team System. This article covers how the various team members can make use of the work item tracking system to bring value to their software development projects.
The primary individuals using work item tracking include all people directly involved with the development process: project managers, analysts, developers, and testers. Other individuals, such as business sponsors, may indirectly use the work item system by viewing reports.
Visual Studio Team System includes various editions that provide the features that each of the different types of individuals require. One of these versions will be Team Explorer, a client tool that is based on the Visual Studio IDE but includes only the required features to connect to, and interact with, Team Foundation Server.
Visual Studio Team Editions (Architect, Developer, Test, and Team Explorer) include the capability to connect to a Team Foundation Server (TFS). Users can add Team Projects to TFS, using their Team Explorer window.
The Team Explorer window allows the user to view and create new work items (see Figure 1). The work item data and the various work item types are defined by your chosen methodology template. When creating a new Team Project, the option is given to select a methodology template to use for the project. For example, selecting MSF for Agile Software Development creates several standard work items as part of the process. In addition, MSF for Agile Software Development makes use of five distinct types of work items: Scenario, Task, Quality of Service Requirement, Bug, and Risk. The Team Explorer window makes up the Team Explorer application, also referred to as the Team Foundation Client.
Figure 1. Add new work items
Project Management with Work Items
Project managers are probably the most familiar with the concept behind work item tracking. A good portion of their job entails creating and managing various tasks. They are usually responsible for mapping out all the tasks that need to be completed on a development project. The work item tracking system in Visual Studio Team System will allow them to take the work they currently do, and interact more efficiently with the rest of the team.
As part of the creation of a new Team Project, the project manger will select the appropriate process template. The process template will provide the definitions for the work item types, the initial work item list for the project, and other supporting information such as document templates and process guidance documentation. The selection is based on the type of project being undertaken. For example, a small informal Intranet Web application may be based on a less formal process, such as MSF for Agile Software development, whereas a more intensive project such as an airplane flight control system will require a more formal process, such as MSF for CMMI Process Improvement. The selection of the process template is important, because it can't be modified during the project. Future versions of the software can be based on different process templates and, of course, the contents of the work item list and document libraries will be modified during the project.
Project managers who install Team Explorer (formerly called Team Foundation Client) will be able to connect to a Team Foundation Server and import, as well as export, work items from either Microsoft Excel or Microsoft Project. Prior to installing Team Explorer on his or her computer, the project manager will want either (or both) Microsoft Excel or Microsoft Project installed with the optional Microsoft .NET interoperability components. Once installed, there will be a new menu option added to either (or both) Project or Excel, called Work Items (see Figure 2 for an example of this). This menu will allow the project manager to connect to a Team Foundation Server and download work items from any project that they have access to on the server. Once they do this, they can add additional items, change resource assignments, and complete the project plan. When they are ready, they can synchronize their changes with the Team Foundation Server using the Publish Changes option. Any assignments they make to individuals who are using the work item tracking system will be seen by those individuals when they run the My Work Items query from within Visual Studio.
As team members complete tasks, they mark those tasks as complete, using Visual Studio or Team Explorer. The project managers will receive this updated status the next time they synchronize with the Team Foundation Server.
Installing Visual Studio Team System or the Team Explorer application provides extensions for Microsoft Project and Microsoft Excel. Using Microsoft Project, a project manager can retrieve data from Team Foundation Server, use Microsoft Project to manage and plan work, and then publish the updates back to the work item database for consumption by other team members. Figure 2 shows the Microsoft Project extensions that allow synchronization with work items.
The Microsoft Project file itself will generally be stored in a document library in the project team site. This will allow basic version control of the file, as well as make it available for other users to review.
Figure 2. Work item integration with Microsoft Project
Business analysts can also become more integrated in the development process by having their work managed through the same work item tracking system as the rest of the team. The various types of documents that are produced by business analysts should be stored on the team project portal. For instance, the creation of a requirements document could be a task assigned to a business analyst. Once compete, that document can be stored within WSS, and the business analyst would mark the work item as completed. A new work item can be created to actually implement that requirement, and a link can be set up from the work item to the actual requirements document on the WSS site. This allows the developer assigned the task to quickly navigate to and review the associated documentation. In order for business analysts to interact effectively with the work item system, they will need to install Team Explorer and have a client access license for the Team Foundation Server.
Developers and testers will be greatly impacted, from a workflow perspective, by the introduction of work item tracking. The system was designed to make the use of work items by developers as seamless as possible. Rather than being notified by e-mail, spending hours in planning and status meetings, or looking at the project plan, the developers will receive their work assignments from within Visual Studio. They will simply use the Team Explorer window to run the My Work Items query (Figure 3).
Figure 3. Work item list in Visual Studio 2005 Team Edition for Software Developers
Developers can begin their day by viewing their work items. As they work on tasks, they can update the status of their work items in two different ways. First, they can edit the work item information directly from within Visual Studio by simply selecting the work item they wish to edit from the list of work items. In this case, they can directly enter data such as status updates, or modify any other field exposed in the work item. Depending on process customizations, individual fields may be protected in such a way that other roles can set the work item field values but development can only read them, as may be the case when a bug work item is prioritized by a project manager or tester. Likewise, some fields may be modifiable by developers and not by other roles. Figure 4 shows a sample work item detail screen including a custom field Start Date added to the default MSF for Agile Software Development process. Additional information on customizing work items in Visual Studio Team System is provided later in this document.
Figure 4. Work item details in Visual Studio 2005 Team Edition for Software Developers
The second way to update the status of a work item is as a side-effect of the check-in process. When combined with Team Foundation Source Control, several powerful capabilities are added. Depending upon the policies defined for the Team Project, the check-in process may allow or require developers to link a work item to a changeset (a collection of files checked in as a group) during the check-in process. As developers complete their coding tasks, they simply associate code check-ins with work items.
For example, imagine that a developer has a coding task called "implement customer feedback form." When the developer completes this task and checks in his or her work, he or she has the option of associating that work item to the checked-in code. All of the different files that are checked in are called a changeset, and the work item will be associated with the changeset, not the individual files. The work items can simply be associated, or marked as resolved. Figure 5 provides a sample of how the work item is associated with the changeset during check-in.
Figure 5. Associating work items at check-in
This is a simple process and allows the work item status to be automatically updated. This updated status can then be used by the project managers when they synchronize their project plan. The associated work items will also be used in build reports that can be automatically generated and distributed as part of an automated build process using Team Build. This will allow testers to know precisely what items they should be testing in a new build.
Work Item Check-in Policy
Work item associations can be implemented and enforced in check-in policies. Check-in policies enforce certain behavior when team members attempt to check items into the source control system. One of the standard policies that can be enabled would require developers to associate a work item with all code check-ins. This ensures that all development efforts are tracked and visible. There is an option of overriding the policy, and notification can be set up to alert the project manager (or someone else) of the override.
Figure 6. Adding check-in policies
Bugs and Issues as Work Items
Using classic development practices, developers and testers perform work from several different sources. The project plan schedules work such as developing code and writing test plans. Separate lists are kept and scheduled outside of the project plan, to handle defect tracking, enhancement requests, issues, and risks. Project managers may set aside buckets of time to allow team members to work on these other lists, or they may create separate project plans. Regardless, the management of different types of work for the same development resources is cumbersome and error prone.
Since the work item tracking from Team System allows flexible and customizable tracking of all types of work in a single repository, managing these different types of tasks becomes easier. Different types of work items can be managed separately through different work item queries. However, since they are in the same Team Project, a work item list for a developer could have new development tasks, research tasks related to project risks, and bug fix tasks; all of them could be prioritized side by side and worked from a single list.
As implied in previous sections, testers also get significant integration in the overall development lifecycle as a result of work item tracking. Testers using Visual Studio Team Edition for Software Testers have full access to Team Explorer to view their own work items. For instance, many projects require the creation of manual test cases. These manual tests are created and managed in Visual Studio Team Edition for Software Testers. What test cases need to be written, and the status of those test cases, can be tracked by the work item tracking system. The project manager can then synchronize in order to track and manage the efforts of the test team as well as the developers. Testers follow the same process as developers do, and work on the tasks delegated to them through the work item tracking system. The manual test cases they develop would be checked into source control and can be associated with work items in the same fashion as developer code.
In addition, testers are able to review build reports to find out what features are ready to test. As developers complete development tasks and associate their code check-ins with work items, those relationships are stored by the Team Foundation Server. During the build process, the status of these work items can be updated to indicate that they are completed and included in the build. Those items included in the build are ready for test. By running a build report, a software tester will know exactly which work items they should focus their testing efforts on. Those work items could be requirements, bugs, or some other type of task.
This, however, is just the beginning. As testers discover problems in the system, they can report these back into the Team Foundation Server, using work items. By issuing a "Bug" or similar custom work item, the tester can record work that needs to be done. These new "Bug" tasks can be routed to a development lead, a project manger, or the appropriate developer, as specified in the process templates. In addition, the tester can set up a work item relationship so that the bug work item is connected to the original work item that he or she was testing against.
When the developer receives the work item assignment and addresses the defect, he or she continues the workflow. The developer's resolved "defect" work item would appear in build reports so that the test team can verify the fix. Since Team Foundation Server is acting as a back end for this entire process, requirements, development tasks, defect reports, and problem resolutions can all be tied together. These items can be traced and reported on with minimal effort from the team members.
Reporting and the Work Item Database
An important aspect of Visual Studio Team System and the Team Foundation Server is the storage of work items. All work item data is maintained by Team Foundation Server in a Microsoft SQL Server 2005 database. In addition to the flexibility, stability, and scalability of this approach, there is a tremendous value from a reporting perspective.
As a result of creating a Team Project based on a specific process template, the project portal exposes appropriate reports. Individuals who are interested in the status of a development project, but not directly involved, can run reports to get the status of development tasks, bug counts, and any other work item or non-work item reports. This is of great value to business users and IT management. The project portal is a WSS team site and contains a Web part that allows viewing of reports created in SQL Reporting Services. The reports available on the site can be customized through the methodology templates.
The process templates provided by Visual Studio Team System are highly customizable. Individual organizations and groups are able to modify almost all aspects of the process to be compatible with their own requirements. In fact, some organizations will want to create multiple types of custom process templates tailored to different types or sizes of development projects.
At a high level, the process template architecture provides customization of the following areas:
- Classification Structure Service (CSS)—Defines the structure for team projects, including the iterations defined for the project lifecycle and the project hierarchy.
- Group Security Service (GSS)—Defines the initial groups and permissions for the process templates.
- Reports—Defines the standard reports provided by the process.
- Source Control (SCC)—Defines the permissions and notes available for source control.
- Windows SharePoint Services (WSS)—Defines the document templates, document libraries, and the process guidance.
- Work Items (Currituck)—Defines the type and characteristics of work items, work item queries, a default list or work items for new Team Projects, and the mapping of work items to Microsoft Project.
Within your process templates, the work item tracking system can itself be heavily customized. You have the ability to define your own work item types or, as will typically be the case, refine work item types based on an existing process. For example, instead of the default five work items provided in MSF for Agile Software Development, you may define work item types for: requirements, bugs, risks, and issues. You can name the types of work items whatever you like; for example, perhaps you prefer "Defect" instead of "Bug." You can have as many, or as few, types of work items as you need for your purposes.
In addition, you can actually change the contents of the work item definitions. For example, you may decide that a specific work item type needs additional attributes to make it useful in your environment. Adding a Severity field to your "Defect" work item type is as easy as editing an XML file. In addition, you may specify valid values for your new field (for example, Very Severe and Unimportant). You can also configure how the field is visible, and the permissions required for modifying the value. Additionally, there is support for basic workflow that will allow the Team Foundation Server to automatically impact the value of the field as your work items move through their lifecycle.
As an example of the different fields that are commonly associated with work items, the following list contains the default fields for the "Bug" work item defined by MSF for Agile Software Development, beta 2: Id, Title, Assigned To, Area Path, Iteration Path, History, Reason, Changed Date, Changed By, Created Date, Created By, Summary, Issue, State Change Date, Activated Date, Activated By, Resolved Date, Resolved By, Closed Date, Closed By, Priority, Triage, Test Name, Test Id, Test Path, Found In, and Integration Build. It is nice to note that with all of the fields that may hold data for this work item, many of them are automatically captured during standard processing, without extensive data entry for team members.
Microsoft Project Integration Customization
The work item database is not a direct mapping of data stored within Project. A project manager will use Microsoft Project to manage the project timeline as he or she normally would, but will have additional fields that will be synchronized with the work item tracking system. Some fields, such as task dependencies, are not maintained in the work item database, and the individuals working on tasks may still want to consult the project plan on occasion. For beta 2 of the MSF for Agile Software Development process template, the following fields are mapped between the work item database and Microsoft Project.
Table 1. Field Mapping Between the Work Item Database and Microsoft Project
|Work Item Field||Microsoft Project Field|
Although the work item field names may seem intimidating, they simply include contextual information describing the source of the fields. These names are actually the reference names defined in XML in the work item task definitions XML file. When defining your own custom work item fields, you should also provide reference names in a similar fashion—for example, MyCompany.VSTS.StartDateField. Those same work item type definitions also provide friendly names such as Start Date.
On the Microsoft Project side of the mapping, the names are all prefixed with pjTask, to indicate that they are Microsoft Project task fields. Although Microsoft Project also supports resource fields, these types aren't applicable to work items. When naming a Microsoft Project field in the map, find the field name in Project, strip the spaces, and add the prefix. For example, the Microsoft Project task field named Resource Names would be referenced in the map as pjTaskResourceNames. Note that the default mappings use many of the generic Microsoft Project task fields to store work item-specific data. For more information, you may wish to consult the Microsoft Project SDK.
There is no direct synchronization between the work item database and Microsoft Project Server. Project managers who wish to move data back and forth between the two systems can do so by using Microsoft Project Professional to synchronize with each system independently.
Work item tracking provides a great way of tracking all of the individual items of work that must happen in order to develop a successful software application. Remember that the work item system is targeted at the development team and not just the developer, and that it is also customizable to meet the needs of a wide variety of organizations.