Entering Data into the Project Workbook

After you have created the project workbook, you will be able to use it to enter and view work item data from Visual Studio Team System. When you are entering data, instead of being presented with a work item form, you will type directly in the columns and fields themselves. Fields that provide you with an option of values will display those options in drop-down lists inside the cell. In fact, all of the work item rules, such as mandatory field values or workflow state options, are fully enforced within Office Excel. To enter new rows into a list linked with Office Excel, simply find the last row in the list and start typing data. Optionally, you can insert a new row by selecting a cell you want to insert a row about and choosing Row from the Insert menu.

Work items that you enter into Office Excel do not automatically get saved to Visual Studio Team System. To save any new or modified work items in Visual Studio Team System, you must publish the work items by selecting Publish from the Team menu. By controlling when Office Excel publishes changes to work items in Visual Studio Team System, you have the opportunity to enter a large number of work items without ever needing to communicate with the computer running Team Foundation Server on which the data resides. This makes it possible to use your project workbook in an offline mode, that is, when you are not connected to the network, such as on an airplane or on the bus ride home. When you instruct Office Excel to publish your work items to Visual Studio Team System, all your new and modified work items will be checked for errors. If errors are found, you will be notified with a dialog box and given the opportunity to resolve the problems before publishing the work items once more. Note that you will not be able to publish work items to Team Foundation Server if they contain errors.

When publishing updated work items, you may also experience a conflict while you have Office Excel open if some other member of your team modifies a work item in Team Foundation Server between the time you last refreshed the work item details in Office Excel and the time you are attempting to publish the new information. If such a conflict does occur, you will be prompted to resolve the conflict through the Work Item Publishing Errors dialog box. When you encounter a conflict of this nature, you will be prompted to choose a version of the work item you want to keep-either the version you just modified in Office Excel or the version of the work item that is stored in Team Foundation Server, as shown in Figure 4-3. You will also have the ability to view the version of the work item as it is saved in Team Foundation Server by clicking the View Database Version button.

Figure 4-3: A conflict error

Usually, one of the first actions you should perform when working with your project workbook is to refresh work item data from the Team Foundation Server. The more often you refresh your copy of the data within Office Excel, the more up to date your work item information will be and the lesser the chance that you can cause a conflict when updating work items. To refresh the work item data stored in a list in Office Excel, choose Refresh from the Team menu. Note that every time you publish your changes to Team Foundation Server, Office Excel will also perform a refresh.

There are a few additional actions you can perform with Office Excel as it integrates with Visual Studio Team System. Both Office Excel and Office Project provide you with the ability to edit areas and iterations on the Team Foundation Server without requiring you to switch to Team Explorer. To do this, you must be connected to a computer running Team Foundation Server (that is, working online). Choose Team | Edit Areas And Iterations in Office Excel or Office Project. Editing areas and iterations from within Office Excel or Office Project is identical to editing this information from within Team Explorer. You can also add links and attachments to work items by clicking the Links and Attachments button on the Team toolbar or by choosing Links and Attachments from the Team menu in Office Excel or Office Project.

Work Item Pivot Tables and Graphs

After you have linked data from your Team Project into Office Excel, you will be free to use other Office Excel features such as pivot tables to help you understand and organize work item information. To create a read-only pivot table of work item data, perform the following steps:

1. From your Office Excel project workbook, click in any cell within a list on a worksheet that contains information on which you want to base a pivot table. A common source of pivot information is the All Work Items list with all required columns added.

2. From the Data menu, choose PivotTable and PivotChart Report to launch the PivotTable and PivotChart Wizard.

3. On the opening page of the wizard, ensure that Microsoft Office Excel List or Database is selected as the data you want to analyze and the kind of report you want to create is a pivot table. Click Next.

4. On the next page of the wizard, you will confirm the range of values you will use in the pivot table. By default, Office Excel will select the list you chose on the previous page. Click Next.

5. Specify the location of the new pivot table report to be a new worksheet and then click Finish to close the wizard.

6. Drag fields from the PivotTable Field List pane to the predefined pivot areas on your new worksheet: Page Fields, Row Fields, Column Fields, and Data Items. For example, if you choose to create a pivot table from the All Work Items list, you might want to drag the

7. Iteration Path column into the Page Field area; the Work Item Type, Assigned To, State, Area Path, and Title columns to the Row Fields pivot area; Reason to the Column Field; and ID to the Data Item area. By default, the PivotTable report will add a Sum calculation to the field that you dropped in the Data Item area.

8. If you want to change the calculation used for Data Items, right-click the Sum Of ID cell above the Work Item Type pivot table, click the Field Settings button on the PivotTable toolbar, choose the Count function from the functions listed in the Summarize By list, and then click OK.

With a pivot table, you will quickly be provided with the perspective you need to help manage your team, especially if your team is large or you are managing a large number of work items. A common use of a work item pivot table is for task assignments and estimates. This is very handy if you want to look at the amount of estimated work allocated to your team members per iteration. To set up your pivot chart for this, ensure that the Estimate column is one of the columns listed in your Office Excel workbook, and when creating the pivot table, drag the Estimate value to the Data Item area, ensuring that Sum is the operation that will be used for calculations. The result will look very similar to Figure 4-4.

Figure 4-4: Using Office Excel pivot tables to review project estimates

Entering Requirements into Visual Studio Team System

It’s virtually impossible to provide estimates on a system without any level of detail of the system unless you are working on a strictly fixed-cost variable-functionality release schedule in which you simply deliver features until you run out of money. Software requirements can take many forms, from screen designs to business and workflow models to usage scenarios and operational needs. Arguably, there is yet to be a single unified method for storing all forms of system requirements. However, Visual Studio Team System allows you to store many of these requirement types as work items. If you are using MSF Agile, you will have two different work items to store your requirements: the Scenario work item and the Quality of Service work item. If you are familiar with more traditional use-cases methods specified by the Unified Process, you should have no problem working with scenarios. A scenario is a set of steps that a user (specified by a persona as discussed in Chapter 3) must perform to achieve a goal. Some scenarios will describe a “happy path,” wherein the steps in the scenario lead the users to their goal, and others might describe a “less-than-happy path,” wherein the steps will not lead the user to a desired outcome. Examples of an undesired outcome are when users enter invalid parameters or certain conditions in the system are not met, causing an error to be reported. These scenarios describe the behavior of the system you are implementing. Quality of service requirements, on the other hand, document what are traditionally called non-functional requirements of the software you are going to build, such as load characteristics, availability, accessibility, maintainability, and performance.

Requirements in MSF for CMMI

MSF for CMMI extends the concept of a requirement by providing you with the Requirement work item type. Unlike MSF Agile, you can use the Requirement work item type to store both scenarios and quality of service information by specifying a requirement type attribute on the work item. In fact, by default, MSF for CMMI requirements can be of the following types: functional, interface, operational, quality of service, safety, scenario, and security. Requirement work items in MSF for CMMI also provide you with more areas to capture additional information about the requirement, such as listing related subject matter experts, capturing analysis details, and status of user acceptance testing regarding the particular feature.

Of course, it may not make sense for you to store all of the details of a requirement within a work item. In this case, you should store your document-based requirements, such as user interface flow diagrams or business analysis models created in Microsoft Office Visio, in the project portal. You can then create a Requirement work item in Visual Studio Team System that links to these documents. In fact, this becomes an important practice because this will allow you to track and monitor the state of a requirement stored in document artifacts by using the default work flow specified by the work item type. For example, you can create a user interface flow diagram in Office Visio and store it in your project portal. In Team Explorer, you can create a work item called User Interface Flow of type Scenario. In the links tab of the work item, you can create a hyperlink to the document stored on your Team Project.

Tip 

A quick way to get a URL to a document stored on your project portal is by navigating to the document within Team Explorer to view the document properties (right-click the document and choose Properties from the shortcut menu). In the resulting Properties window, select the text in the Url field and copy and paste it into an HTML link to your work item.

This book is focused on the project management perspective of Visual Studio Team System; however, it might be beneficial to talk a bit more about writing scenarios and tracking the quality of service requirements. Scenarios tell a story, and they are meant to come alive in the mind of both the author of the story (business analyst and customer) and the person reading them (developers and testers). Scenarios can be highly descriptive or documented in an abbreviated form, or they can be a combination of both styles. Whatever approach they take, their purpose is to specifically convey the sequencing of events the system must be able to support and to provide context as to how those events fit into the larger picture.

For example, the following represents a highly descriptive story-like example of a scenario:

Cindy has two different corporate Wi-Fi networks available to her mobile device. She wants to connect only to the connection supporting WEP, and if that network becomes unavailable, she doesn’t want the device to switch automatically to the second one because she does not want to connect to an unsecured network. Cindy opens the Custom Connection Manager on her mobile device and selects the Manual Mode option. She makes sure that her desired network (the WEP enabled connection) is selected. The Custom Connection Manager detects that the device is now in manual mode and will attempt to connect to the manually selected network as specified in Cindy’s settings.

At the time of attempting to connect, the Custom Connection Manager determines that Microsoft Office Outlook was retrieving e-mail messages from the server. The Custom Connection Manager waits until the application has completed the transfer before continuing with switching to the preferred network.

During Cindy’s workday, she enters an area of the building where she has access to a Wi-Fi connection that Terry has configured to be of a higher preference then her currently selected network connection. Since Cindy has set her device to manual mode, her mobile device will not attempt to connect to that more preferred network connection and will instead continue to use her manually selected connection.

Later in the day, Cindy moves to an area in the office where she is unable to access the network connection that she has manually set her device to use. Her device will warn her that she has lost connectivity and will not attempt to connect to any other available network.

This scenario takes a bit of reading, but it provides excellent context for the developers of the system. In addition, scenarios such as these are very easy to validate by users of the system. Also note the extensive integration of the persona named Cindy in the scenario. Capturing requirements in this way increases the overall understanding of the system and immediately makes the application come alive in the minds of the entire team.

Alternatively, or even in conjunction, we could provide a breakdown of that scenario into something that is a more formal, as shown in Table 4-1.

Table 4-1: More Traditional Scenario Representations
Open table as spreadsheet

Description	Custom Connection Manager (CCM) Manual Mode Operation
ID	CCM-1
Author	Joel
Date	12/20/2006
Personas	Cindy
Pre-conditions	CCM installed and operational Wi-Fi enabled and functioning on the device
Actions	1. Cindy sets CCM to manual mode. 2. Cindy selects desired Wi-Fi access point. 3. Device connects to desired Wi-Fi access point. Alternative Flow: If ActiveSync is running, device waits until complete. 4. Cindy enters area with more preferred Wi-Fi access point. 5. Device does not switch to Wi-Fi access point. 6. Currently connected Wi-Fi access point disappears. 7. Device displays a message to Cindy and does not attempt connections to any other Wi-Fi access points.
Post-conditions	None
Includes	Display alert
Extends	Custom Connection Manager Automatic Mode
Generalizes	None

As you can see, both representations of the requirement are valid-the table-based version provides an easy to read, step-by-step description of the scenario, so it can easily be turned into a test cases for the testers. We suggest that you start writing highly descriptive scenarios with the help of your customer, and then during the requirements realization activities, decompose the requirements into a more organized representation such as the one presented in table format.

The use of area classifications is also extremely important to requirements management in Visual Studio Team System. Areas represent groupings of related functionality in your application that you can use to classify requirements in addition to any other work item in your project. Areas are represented in a hierarchical tree that you can build by using the Areas And Iterations settings of your project. Initially, the Area classification section is empty, and it will be up to your team to decide how you want to group features in your application. For example, some organizations choose to decompose their application into architecturally significant areas such as user experience, business processes, data management, software interfaces, and data migration. Some other organizations choose to decompose their solution into clusters of related scenarios such as breaking a Customer Relationship Management (CRM) solution into areas such as customer management, sales campaign management, reporting, and opportunity management. If you are working on a suite of related products such as Microsoft Office, you might want to break areas into an Area tree that could resemble Figure 4-5.

Figure 4-5: A more complex area hierarchy used to classify work items

By properly categorizing your requirements, you will also make your requirements easy to find and provide more filtering capability for your reports. If you manage a large number of requirements, it makes sense to ensure that each of your requirements is in the appropriate area classification. Virtually every report shipped with Visual Studio Team System allows you to provide filter criteria for the report results that include being able to specify one or many area categorizations for your work items. Take the time with your team to structure areas, allowing the structure to change in the early iterations of the project as you gain more understanding of the underlying system requirements. During construction phases of the project, however, try to ensure that the area categorizations do not change. One limitation of areas in Visual Studio Team System is that a work item can belong to only one area, so you must consider this in the structure of area tree. Also note that overly complex area trees may make working with areas cumbersome if you are working in Office Excel or Office Project because the area hierarchy is flattened and appears much like a folder path on your hard drive. These can get very long and quite difficult to work with. Areas also provide another important feature, requirement hierarchy. Many other requirement management tools in the industry, such as Borland CaliberRM, provide the ability to create hierarchies of requirements. In Visual Studio Team System, requirements are entered in a table and assigned to a hierarchy, the area tree.

Law of Consumption of Artifacts

Requirements need to be consumable by all members of the team but more importantly, by your users. The methods you choose to represent your requirements should be dependent upon your audience, so you should seriously consider many forms of requirements representation. There are many forms of requirements including UML diagrams, user interface prototypes, whiteboards, and sticky notes. In addition, there are many different types of requirements, including business requirements (usually captured in a vision document), user requirements (usually captured in scenarios), business rules, quality attributes, functional requirements, system requirements, external interfaces, and constraints (Wiegers, 2003). Our experience is to use them all, choosing the best method to capture and communicate the true message of the requirements.