Combine Microsoft Project and Visual Studio Team System for a One-two Punch of Productivity : Page 3

Visual Studio Team System (VSTS) provides centralized storage of work item tracking features while MS Project provides rich planning and tracking features. By using them together, you can improve team productivity, minimize data conflicts, and reduce administrative overhead.

by Sanjay Narang

Dec 22, 2005

Page 3 of 5

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.

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.

Author's Note: Hereafter I've used the term "connected project plan" to refer to a project plan that has been created by connecting to one of the team projects. The word "connected" does not represent the network connection between MS Project and TFS. It simply means that the plan is associated with a team project. In terms of network connections, MS Project works in a disconnected mode. It connects to TFS only when required, such as when publishing or refreshing.

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:

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.

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.

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.

Author's Note: I've used the term "task" above to mean the row in the project plan, because that row is never published and hence does not have any corresponding work item.

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.