icrosoft Visual Studio Team System (VSTS) provides tools for every role in a typical software development team: Architects, Project Managers, Developers, and Testers. It enables project managers to use the tools they know well?Microsoft Project and Microsoft Excel?to store project management data in Team Foundation Server, the collaboration server that is part of Visual Studio Team System. This article explains how to use Microsoft Project to work with VSTS data and describes the benefits of doing so.

In software development projects, project managers and project leads usually face the following problems:

• They spend a lot of time in tracking project management data such as project plans, tasks, issues, risks etc. They need to do frequent status meetings with other team members to get up-to-date data. Time spent in these meetings affects team productivity.
• This data is generally captured in Microsoft Project or Microsoft Excel and shared with other team members. This creates multiple copies of the data, which makes it difficult to get a consistent and synchronized view of the project status.
• Because the project data exists in multiple documents, creating project reports becomes a manual and time-intensive process.

The project management tools in VSTS help solve the preceding problems. Project Managers create tasks and other project management items, such as issues and risks, using MS Project, and save them to the Team Foundation Server (TFS). Other team members can view and update these items in their development environment itself i.e. Visual Studio.

Because all these tools work on data stored in a central server, changes made through one tool get reflected in the other tool. Centralizing project data makes capturing, sharing and reporting much easier and less time consuming. Tight integration between MS Project and VSTS allows seamless transfer and synchronization of data between the two; however, this built-in integration is available only with the MS Project client in this release of VSTS. If you require such integration with MS Project’s server counterpart, Microsoft Project Server, you can achieve it manually through the APIs of both Project Server and VSTS Microsoft plans to provide better integration between VSTS and Project Server in a future release.

The process of creating a project plan and sharing it with a team in VSTS is different from the more familiar process of working with a standalone instance of MS Project. This article describes the steps involved in this process, such as creating a plan, updating and sharing the plan, and fixing data conflicts. It also covers areas and features that one doesn’t normally come across when working day to day with MS Project and VSTS, and provides a comparison of VSTS and Microsoft Project Server, because both allow the MS Project client to manipulate their data.

The default integration of VSTS and MS Project has some limitations that restrict project managers from using MS Project the way they do normally. But because both VSTS and MS Project provide extensibility features, you can extend and customize them to provide behavior almost identical to that project managers are accustomed to. However, such customization topic is beyond the bounds of this article.

VSTS Basic Concepts
To understand the MS Project integration with VSTS, it is necessary to be familiar with a few core concepts of VSTS.

• Team Foundation Server (TFS). To enable collaboration within an organization, VSTS has a component called Team Foundation Server. This server-side aspect of VSTS integrates several key concepts.
• Work Items. VSTS stores data such as tasks, issues, risks, etc. as work items in the TFS. Work items are units of work that can be assigned to team members and store complete information about that unit of work. VSTS provides a few predefined types of work items such as task, bug, and scenario. Each work item type (WIT) has a set of fields and valid state transitions. Users can customize these WITs or can define new WITs. MS Project can manipulate any type of work items and is not limited to only tasks.
• Team Project. Because most of the activities in a software development are performed in the context of a project, VSTS also stores all the data such as roles, members, work items, and documents in project contexts, called Team Projects. A team project needs to be created in VSTS to store information about any software development project.
• Process Template. Team projects are created based on process templates. A process template is a set of xml files that specify WIT definitions, project roles, project lifecycle structure, project portal structure, source control structure, and predefined reports. VSTS ships with two such templates: MSF for Agile Software Development and MSF for CMMI Process Improvement. Process templates are also referred to as Methodology Templates.

Using MS Project With and Without VSTS
When working with MS Project alone, Project Managers typically follow these steps:

1. Create a new project plan and populate it with work break down structure.
2. Share the project plan with the team members through e-mail or other means.
3. Save the project plan.

With VSTS, however, there are additional ways to work with project management data. The next few sections explain the MS Project and VSTS integration features by taking a scenario that consists of the same steps as described above. Although the steps are essentially the same, they are executed slightly differently.

1. Project managers create a new project plan in MS Project.
2. Before populating it, they connect to a team project in VSTS and import existing work items in the team project to the project plan. Then they add new work items or modify the imported work items.
3. Finally, they publish all the work items to the TFS so that team members can view them in Visual Studio in their respective work item lists.

Enabling VSTS integration: MS Project Add-In
To enable MS Project to integrate with VSTS, you need an add-in for VSTS. The add-in gets installed automatically when any of the VSTS team clients (Team Architect, Team Developer, Team Test or Team Foundation Client) is installed on a machine where MS Project is installed or vice-versa. The add-in adds one menu group, “Team,” and one toolbar to MS Project as shown in Figure 1.

	?
Figure 1. MS Project Add-in: The figure shows the Team menu group and the toolbar installed by the add-in to MS Project.

In addition, the add-in also adds many dialog boxes that simplify working with VSTS data.

Creating a Project Plan
With VSTS, you create a project plan using the work items. This provides the following benefits:

• Work items are stored in the TFS, which helps to avoid inconsistencies created by having multiple copies of the project plan.
• Team members can update their work items in Visual Studio. Such changes are automatically reflected in the project plan, which helps to reduce the need for status meetings.
• You can specify complex rules for the allowed values of the work item fields. These rules are not just static constraints; they change according to the state of a work item at any point of time, making the creation and the maintenance of the project plan much more consistent and less error prone.
• Work Items support complex queries. Project Managers can use these queries and MS Project views to get highly customized views of the project plan.

	?
Figure 2. Connecting to a Team Foundation Server: This dialog lets you choose a team project and a Team Foundation server.

The above benefits are achieved just for using work items based project plans. When this is combined with the other features of VSTS, the project management process becomes much more efficient and simpler. Detailed description of the other project management features in VSTS is available in the MSDN article, “Visual Studio 2005 Team System: Software Project Management.”

Connecting to VSTS
To create and update work items in MS Project, you first need to connect to a team project. To do that, open a new project plan in MS Project, which enables the Choose Team Project button on the add-in toolbar (see Figure 1). When you click that button you’ll see the dialog box shown in Figure 2.

The dropdown box at the top of the dialog lists the available Team Foundation Servers. If it doesn’t list any, you can add servers by clicking the Servers button to display a dialog box listing the available servers. The dialog box contains Add and Remove buttons; clicking the Add button displays a dialog box as shown in Figure 3.

? Figure 3. Add Team Foundation Server: This dialog lets you add a new TFS to the server list.

? Figure 4. Blank Project Plan Connected to a Team Project: The figure shows a new MS Project plan with a set of columns appropriate for a Team Project.

? Figure 5. Get Work Items: Using this dialog, you can review, select, and import work items from a selected team project.

Servers added in this manner are subsequently listed in the drop down box in Figure 2. When you select a TFS, the dialog displays the available team projects for that server in the Team Projects text box. You can select only one team project at a time. After you select a project and click OK, you’ll see a normal MS Project interface, but it will have a different set of columns as shown in Figure 4.

	?
Figure 6. Populated Project Plan: The figure shows an MS Project plan populated with selected work items.

You can import work items from the connected team project by clicking the Get Work Items button, which displays the dialog shown in Figure 5.

The Get Work Items dialog box allows users to view work items available in the chosen team project and to select work items to import to the new project plan. The add-in does this by running a query based on WIT or by running one of the stored queries in Team Project. The dialog shows query results in the data grid. Users can choose the work items that they want to import by selecting the corresponding check boxes.

After you select some work items, clicking OK returns you to the project plan, now populated with the selected work items as shown in Figure 6.

Working with Projects
When you connect an opened project plan to the chosen team project, two interface changes occur: The Choose Team Project button gets disabled and other buttons get enabled, and the columns of the project plan change to show the work item fields. I’ll describe these columns and their mappings to MS Project columns later in this article.

You aren’t limited to the columns that appear automatically. You can include additional MS Project columns in the project plan by using MS Project’s Insert Column option.

It’s worth noting that you can also open MS Project from within Visual Studio; when you open it this way, you don’t have to connect the project plan to a team project manually and import work items. Here’s the process. Visual Studio provides a grid-like interface that shows the results of a work item query as shown in Figure 7.

	?
Figure 7. Work Item Query Results in Visual Studio: Visual Studio shows query results in a grid-like interface.

In Figure 7, you can see a button with the MS Project icon on the button bar on the query results page. Clicking this button automatically connects to the team project containing those work items and opens MS Project with a project plan that contains the work items selected in the query results page. Visual Studio also lets you open a connected project plan from Team Explorer. Team Explorer provides a tree-like structure to access different team projects artifacts such as work items, documents, etc. It has a Work Items node whose context menu provides the option “Add Work Items with Microsoft Project;” clicking that option opens a blank project plan connected to the team project.

After creating the project plan and connecting it to a team project, you can use the plan to edit existing work items or to create new work items as described below.

Adding and Editing Work Items
You add and edit work items in a connected plan in the same way as you add or edit tasks in an unconnected project plan. You can add new work items by entering the values of work item fields in the appropriate columns on a blank row of the project plan. You edit existing work items by editing the values in one or more columns of that work item. You can edit the values of all columns except the Work Item ID column (the first column in the project plan). The work item ID is a number that uniquely identifies the work item across the all the projects in a TFS.

Many columns have drop down boxes that show a predefined set of values that can be entered in that column. For example, the Work Item Type column shows all WITs: tasks, bugs, and so forth available in the team project to which the project plan is connected.

Sharing the Project Plan
With VSTS, you can share the project plan with team members and update it to the current status with just a button click. But this simplicity does not reduce project manager’s control over the sharing process nor does it compromise data consistency. Project Managers can specifically choose the work items they want to share. They can also choose either one way or two-way work item synchronization. If conflicts occur between data in the project plan (which is local) and that in the TFS (centralized), the project presents both local and server versions of the data to users, who can then select the version they want to keep.

Publishing and Refreshing
MS Project works with a local copy of work items in disconnected mode; therefore, to synchronize changes with the TFS, you must publish the plan by clicking the Publish button.

When you publish a project plan containing newly entered rows, the TFS creates a new work item for the corresponding team project for each new row. Each new work item gets a work item ID. The MS Project add-in uses the value in this column to identify the corresponding work item for each row in the TFS. That’s one way to tell if you’ve published the items?if the ID column is blank for some rows it means those rows have not yet been published and do not have any corresponding work items in the TFS. Similarly, when existing work items in a project plan are changed and published, the changes are applied to those work items in the TFS.

Just as you publish changes made in a project plan, you can synchronize changes made in the TFS back to the project plan by refreshing the current view. This is done by clicking the Refresh button in the connected project plan. There are multiple scenarios by which work items may be changed outside the local MS Project copy. For example, when work items are published, team members get work items assigned to them in their work item list. As they complete some work, they update the corresponding work items through Visual Studio. Team leads also may update some work items from MS Excel or some other instance of MS Project. All this is in sync with the vision of multiple team members working on a single shared copy of data that introduced at the start of this document.

Synchronization options
Project managers can control the level of synchronization between a project plan and TFS by setting appropriate values for the Publish and Refresh column. Publish and Refresh is a special column that does not have a corresponding field in any of the work items, it’s used only for setting the synchronization level, which can be one of the following three values:

1. Yes: Changes made in the project plan are published to the TFS as well as the changes made in the TFS are synchronized back to the project plan. This is the two-way default synchronization value for all the work items in a project plan.
2. Refresh Only: Changes made in the project plan are not published to the TFS but the changes made in the TFS are synchronized back to the project plan. This option is used for a work item when the project plan needs to have a read only copy of the work item. This is the one-way (TFS to local) option.
3. No: Changes made in the project plan are not published to the TFS nor are changes made in the TFS synchronized with the project plan. You can use this option for tasks that should exist only in the project plan.

Generally, project mangers use summary tasks to organize big lists of tasks in a project plan into smaller groups. But summary tasks are not tracked independently because they show only calculated values for the tasks they contain, and do not have any work associated with them. You can give these summary tasks a value of No to make sure that the TFS doesn’t create work items for these when the project plan is published.

	?
Figure 8. Work Item Publishing Errors: This dialog box displays all work items that are not published due to errors.

Remember that because project plans work in disconnected mode, the values in the Publish and Refresh column are used only when publishing or refreshing.

Deleting Work Items from a Project Plan
Once created, you cannot delete a work item from the TFS. So when a user deletes a work item row in a project plan, the work item gets deleted only from that copy of the project plan. It still exists in the TFS and can be imported back to the project plan by clicking the Get Work Items button.

Publishing Errors
Work items have data types and rules for their fields that are defined in WITs, e.g. the field Rank is of type integer and hence can have only numerical values, or the field Assigned To can take only the name of one of the valid project members. The MS Project add-in enforces most such rules by providing a dropdown box that contains only valid values only. For example, the drop down box for the Assigned To column would show only valid users, while the drop down box for the Discipline column would show only values defined in the WIT definition for that field.

But there are some rules that cannot be enforced by the MS Project Add-In. For example, a user can enter a string value in the Rank column even though that’s defined as an integer type in WIT. When a user publishes a project plan containing invalid work item values for some columns, the work items with invalid values are not published; instead, the add-in reports them in the Work Item Publishing Errors dialog box shown in Figure 8.

From the dialog shown in Figure 8, users can select a work item and click the Edit Work Item button to view and fix the error. Clicking the button displays the dialog box shown in Figure 9.

	?
Figure 9. Work Item Editor: This dialog box lets you edit and fix work items that fail to publish because of errors.

This dialog box displays all the information about the work item. It even shows fields that aren’t part of the project plan. Fields that caused publishing errors appear with a yellow background (see the Assigned To field in Figure 9 for an example). Clicking the Close button closes this dialog box and redisplays the Publishing Errors dialog box shown in Figure 8. This time the Publish button is enabled for the corrected work item. Clicking this button publishes the work item to the TFS.

Data Conflicts while Publishing
Sometimes, data in work items being published does not match the data in the TFS for those work items. This happens when multiple people update work items from different clients. When such a conflict occurs, MS Project displays a dialog box that shows both local and server versions of data (see Figure 10).

Clicking the View Database Version button displays the server side work item in read-only mode in a dialog box similar to the one shown in Figure 9. You can choose the version to keep for each of the conflict and publish the work items.

	?
Figure 10. Conflict Resolution: When data published from a local copy causes a conflict with data in the TFS, you can decide which version to preserve using this dialog.

Saving a Project Plan
Because most data in a connected project plan gets stored in the TFS, you don’t have to save a local copy. But there are instances when the connected project plan might contain data that exists only locally, and is not published to the TFS, such as:

• Summary tasks or tasks marked as No for the Publish and Refresh column, as explained earlier
• Additional MS Project columns.

In such cases, you should save a local copy of the project plan. When you open a locally saved project, the plan automatically connects to the associated team project and synchronizes itself with the TFS.

Project Plan Column Mappings
The project plan in Figure 4 shows the default set of columns that a project plan gets when connected to a team project created with the MSF for Agile Software Development Process template. Not all of the columns shown have corresponding fields in any of the work items. Some columns exist solely as MS Project columns and are not published to TFS, such as Duration and Row No. Similarly, a few columns in the connected project plan are not shown in the default view but do have corresponding fields in work items. For example, fields such as Priority and Discipline are not shown in the default view, but they are synchronized with work items when publishing or refreshing. Table 1 lists all the columns used for synchronization between MS Project and Work Items. The columns can be one of following three types:

• Columns that apply to all the WITs available in the MSF Agile process template. Examples are Task, QoS, Risk, Scenario, Bug,Work Item ID, Area Path, etc. These columns’ Work Item Type value is All in Table 1.
• Columns that apply only to specific work items types. For example, the column Completed Work applies to the Task WIT only. These columns’ Work Item Type value in Table 1 is the name of the work item to which each column applies.
• Columns that do not apply to any WIT. These columns store information that is relevant within MS Project only, for example, Publish and Refresh, and have a Work Item Type value of None in Table 1.

There are columns that apply to more than one WIT and can have values from a predefined list as specified in the WIT definition. If the lists have different values in the applicable WIT definitions, the dropdown boxes for those columns show the combined list of values from all the WITs. For example, the State field can be Active or Closed for a Task WIT, but can be Active, Closed or Resolved for three other WITs. The drop down box for the State column in project plan shows all three values.

Table 1. The table lists all the columns used to synchronize a local MS Project copy with the set of work items stored in the TFS.

	?
Figure 11. Column Mappings

Each column in Table 1 has a one-to-one mapping with its equivalent work item field in VSTS. You can view these mappings by clicking the View Column Mappings menu item, which displays the dialog box shown in Figure 11.

Figure 11 shows the default column mappings, but you can change those or add new mappings by customizing the process template.

Organizing: Areas and Iterations
You can organize work items in a team project by classifying them in hierarchies. VSTS supports two hierarchies:

	?
Figure 12. Hierarchy Association: The figure shows the process of selecting the Iteration Path for a work item.

• Iterations?Represents the lifecycle iterations into which a project is divided such as Planning, Envisioning, Development etc.
• Areas?Represents a logical division of project into feature areas and components. For example, you can divide your project tasks as per logical architecture: User Interface layer, Business layer and Data Access Layer.

You associate work items with these two hierarchies through the Iteration Path and the Area Path columns respectively. These columns have a drop down box that displays the hierarchy in a tree structure as shown in Figure 12.

You can also use these hierarchies to create MS Project views that group work items as per the containing hierarchy. Both hierarchy structures can be modified in MS Project via the “Areas and Iterations” dialog box, which you can display by clicking the Edit Areas and Iterations menu item (see Figure 13).

Comparing MS Project Server and VSTS
MS Project Server 2003 is an enterprise project management product with features such as project scheduling and management, resource utilization and billing, timesheets etc. It also allows multiple members to work on shared data by

	?
Figure 13. Edit Common Structure Classifications: The dialog box shows the Area and Iteration hierarchies as a tree structure, letting you add, delete, move, or alter node indentation.

providing a Web based interface for viewing and updating project plan assignments. MS Project Server is fully integrated with MS Project (client) as one can publish assignments from MS Project to MS Project Server and view the updated assignments back in MS Project.

As VSTS has similar features in terms of shared data and MS Project integration, it is often compared with MS Project Server 2003. But these two products are entirely different products targeting different domains. Whereas Project Server targets enterprise project management domain, VSTS targets software development lifecycle domain. VSTS does not only provide assignments (or tasks), but also provides extensible work item infrastructure that can create customized work items as per project requirements. Because of its tight integration with Visual Studio IDE, VSTS allows team members to update their tasks and other work items from the IDE itself.

So both the products provide complementary features and have small set of features that are common; this commonality gives scope for integration between the two products. Although there is no built-in integration between the two products in version 1 of VSTS, Microsoft plans to provide tight integration in version 2 of VSTS. Also, there is initiative in the community to develop a connector between Project Server and VSTS. The details about the initiative are available at the GotDotNet site.