Professional Team Foundation Server 2013 (2013)

What's in this chapter?

· Getting to know the additions and enhancements to project management capabilities in Team Foundation Server 2013

· Understanding work items and process templates

· Managing and querying work items

In Part II, you learned about the support that Team Foundation Server 2013 has for source control. In Part III, you will learn about how Team Foundation Server 2013 helps with project management.

Project management can involve many aspects of developing software, such as tracking remaining work and open bugs, determining how much work you can commit to with your available resources, and even helping to enforce a standard process of interaction between your team members. You will see that Team Foundation Server 2013 provides capabilities to help you achieve all of these things and more.

In this chapter, you will start by learning about the enhancements to project management available in this release. This chapter also provides an overview of work item tracking, including some ways to manage and query work items from Visual Studio, Excel, Project, and other clients. You will also learn about the importance of process templates, including an overview of the process templates provided by Microsoft for use with Team Foundation Server 2013.

Subsequent chapters in Part III of this book will also familiarize you with process template customization (Chapter 13), describe the use of the new Agile Planning tools (Chapter 14), provide an in-depth look at using reporting and SharePoint dashboards to get real-time insights into how your software development project is going (Chapter 15), and discuss the implementation of integration between Team Foundation Server and Microsoft Project Server (Chapter 16).

Project Management Enhancements in Team Foundation Server 2013

In Team Foundation Server 2012, Microsoft made significant strides to align Team Foundation Server with Agile methods. In Team Foundation Server 2013, the focus has broadened to support Agile project management at a larger scale. This section highlights some of the most significant improvements and additions you will find in this release, as well as those introduced in Team Foundation Server 2012. This will allow those readers coming from Team Foundation Server 2010 or 2008 to get up to speed on the significant differences that the 2012 and 2013 releases bring. If you are brand new to Team Foundation Server, concepts such as work items will be explained in greater detail later in this chapter.

Rich Work Item Relationships

According to Microsoft, the top-requested project management feature by users of the first two releases of Team Foundation Server (2005 and 2008) was representing rich relationships between work items. In these releases of Team Foundation Server, it was only possible to relate work items with one another via a simple linking mechanism. But these links didn't provide any explicit meaning, directionality, or cardinality.

For example, a common project management use case for many software development projects is to be able to model parent/child relationships between work items, such as for capturing a feature catalog or for detailing the tasks required to implement a particular requirement. You could link these work items together using early releases of Team Foundation Server, but the links didn't carry enough meaning to convey proper parent/child relationships. Without directionality, it's not easy to discern which work item is the parent and which work item is the child in this representation. Furthermore, without cardinality, there isn't a mechanism for restricting that each child work item could only have (at most) one parent work item.

Beginning with Team Foundation Server 2010, Microsoft introduced rich relational linking between work items. You can model rich relationships between work items using a variety of link types. These link types can also include directionality and cardinality. Team Foundation Server 2013 ships with many link types, but the following are the most common:

· Parent/child—This is a useful link type for representing hierarchies such as feature catalogs, or for detailing task work items (children) that will be used to implement a requirement or user story (parent). Any work item can have zero or more child work items, and zero or one parent work item.

· Tests/tested by—This link type is primarily intended to model the relationships between test-case work items and the requirements or user stories that they test. This makes it easier to determine the quality of a given requirement or user story by examining the recent results for its related test cases. A work item can test zero or more work items.

· Successor/predecessor—The successor/predecessor link type is used to indicate work items that have a dependency relationship with one another. For example, designing the user interface for a web page is generally a predecessor to writing the code and markup that will provide the implementation of that web page. A work item can have zero or more successor and/or predecessor links to other work items.

· Related—The related link type is the same as the legacy linking system found in Team Foundation Server 2005 and 2008. These link types are not directional and provide no additional context about the type of relationship. If you had linked work items in a project that was upgraded to Team Foundation Server 2013, those relationships will be represented by the related link type.

You will discover that rich work item relationships provide the basis for other features and enhancements across the project management capabilities of Team Foundation Server 2013, such as enhanced querying and reporting. It is also possible to define your own link types if you wish, although for most teams, the provided link types will be sufficient. More information on creating custom link types can be found at http://aka.ms/WICustomLinks2013.

Note

Team Foundation Server 2013 does not have a mechanism for ensuring that your links are semantically correct. For example, it's possible to create circular chains of successor/predecessor links or tests/tested-by relationships between two work items that don't involve a test case. If you notice that you have invalid link types in your project, you can easily delete them at any time.

Test Case Management

Test cases are represented as work items in Team Foundation Server 2013. This makes it possible to create rich relationships between the code you are implementing and the results of your quality assurance (QA) efforts.

For example, test case work items can be linked (via tests/tested-by link types) to requirement work items. As tests are run, results can be reported on by querying a given requirement work item, navigating to the related test cases, and viewing the results of recent test runs. Many of the new default reports make use of this information to expose new perspectives on software quality.

Note

You learn more about the role that testing plays in Team Foundation Server 2013 in Chapter 26.

Agile Portfolio Management

In Team Foundation Server 2013, Microsoft added an additional category of work items to assist in managing a project at a portfolio level. A management team can define high-level goals and can assign work to those goals in a hierarchical manner. Individual teams can work with their own backlogs, while managers can see the progress of multiple projects across the entire scope of work for one or more projects.

By default, the out-of-the-box templates for Team Foundation Server 2013 contain one additional layer to the hierarchy, called the Feature category. However, Team Foundation Server now gives you the ability to create up to five levels of portfolio backlog. For example, you may have an Initiative work item that contains Goals, which are further broken down into Features. This hierarchy is fully supported in the Team Web Access user interface.

Note

To add additional work item categories, you will need to modify the process template for your project. For more information on customizing process templates, see Chapter 13.

Enhanced Reporting

One of the primary reasons Microsoft designed Team Foundation Server as an integrated solution (including source control, project management, build automation, and so on) is to enable multidimensional views into software development projects. Effectively managing a software project is not unlike managing other complex projects. Making smart decisions requires you to have a rich set of information resources available, usually in real time, which can help to inform resource allocations, prioritizations, cuts, schedule changes, and other important evaluations.

The rich work item relationships that exist within Team Foundation Server 2013 enable Microsoft to significantly enhance the types of reports available. As just one example, parent/child relationships between user stories and tasks can produce a report showing the amount of work required in order to finish implementing any given user story. By further analyzing the tests/tested by links, you can get a view into software quality for those same user stories based on the results of your test cases. There are countless other examples.

Starting in the 2010 release, Microsoft made it much easier to customize existing reports, or create new ones. The ad hoc reporting capabilities allow you to create reports from just a work item query.

Basic reporting has now been included in Team Web Access with the addition of work item charts and Team Favorite tiles. These simple reporting elements can give insights into the state of your project at a glance.

Note

You learn more about reporting with Team Foundation Server 2013 in Chapter 15.

SharePoint Server Dashboards

Most software development projects involve many stakeholders. In addition to the core programming team, a team may include project managers, business analysts, testers, architects, and so on. There may also be external stakeholders—such as end users or executive management—who have a vested interest in monitoring the progress of your project. Most of these people don't use Visual Studio; so how do you effectively communicate project status to everyone?

Microsoft has integrated Team Foundation Server with SharePoint for this reason. Whenever you create a team project with Team Foundation Server 2013, you can optionally create a new SharePoint site (or use an existing one). This site can be used as a dashboard to provide everybody on your extended team with a view into your project. Your SharePoint site provides a web-based view of reports from your team project, along with a document repository where you can store artifacts such as specifications and storyboards.

Note

At the time of writing, you cannot create a SharePoint site for Team Projects created in Visual Studio Online.

Note

In Chapter 15, you will learn about how these SharePoint dashboards can be used and customized for your team.

Agile Planning Tools in Team Web Access

When planning for Team Foundation Server 2013, Microsoft noted that there was a significant shift among development organizations toward the group of Agile development methods. To help support teams moving toward these methods, this release of Team Foundation Server includes some “must-have” features to help you plan your backlog, track velocity, understand your capacity, plan each iteration (or sprint), view a burndown of hours for each iteration, and view how work is flowing through your project. These tools will be immediately familiar to teams that practice Scrum.

While creating these tools, the Microsoft team wanted to ensure that usage was not limited to the practitioners of Scrum or Agile development methods, but rather was available and usable by any development team using Team Foundation Server. To support this, every process template that ships with Team Foundation Server 2013 supports the agile planning and tracking tools. You can also modify a custom or third-party process template to support these new features. You will learn more about process template customization in Chapter 13.

Significant improvements have been made in the Team Web Access interface in the 2013 release. These include color-coding of work item types, drag-and-drop management of work items, and customization of columns on the agile boards. Many more small UI changes have been included in the various minor releases.

Note

In Chapter 14, you learn more about managing teams and using the Agile Planning tools.

Work Items

If you're new to Team Foundation Server, you may be wondering what exactly a work item is after reading the preceding section. A work item is the basic building block of the project management capabilities in Team Foundation Server. Microsoft defines a work item as “… a database record that Team Foundation uses to track the assignment and progress of work.”

Work Item Types

There are many kinds of work items, known as work item types. An instance of a work item type is a work item, in much the same way that, in object-oriented programming (OOP), an instance of a class is an object. A work item can represent explicit work that needs to be completed (or has been completed), such as with a Task work item type. Work items can capture details of the software you are building, such as with Requirement or User Story work item types. Work items can be used to capture problems, such as the Bugwork item type (which indicates a problem with your software) or the Issue work item type (which might describe a problem with tooling, processes, or people that may be slowing down your project, or even preventing work from happening). In Team Foundation Server 2013, Feature work items have been added for managing a portfolio of work. Team Foundation Server 2013 includes other default work item types as well, and you can even create your own.

Note

You learn more about work item type customization in Chapter 13.

Work items include a handful of key elements, as shown in Table 12.1.

Table 12.1 Work Item Elements

Figure 12.1 shows an example of a bug work item form that has been resolved by the developer. This screenshot is taken from a bug that was created with the MSF for Agile Software Development process template. You will learn more about process templates later in this chapter.

Figure 12.1 Bug (Agile) work item form

Figure 12.2 is a state diagram showing the transitions for the default Bug work item type included with the MSF for Agile Software Development process template. State diagrams for each work item type are included with the documentation for the process templates provided by Microsoft. They are useful for understanding how a work item behaves.

Figure 12.2 Bug (Agile) work item type state diagram

Areas and Iterations

Most of the system fields available for work items (such as Title and ID) are fairly self-explanatory. But there are two important fields—Area and Iteration—that warrant further discussion.

The Area field is a versatile one that can be used to create logical categories for your work items. In Team Foundation Server 2013, when you define a Team, a corresponding Area is created by default. This helps organize work items according to the team responsible for delivering them. There are a number of other ways you can use areas, and another common approach is to define an area for each logical part of your application.

For example, in Figure 12.1, this bug is assigned to the Tailspin Toys\Web site area to indicate that it is part of the web application being developed by the Fabrikam Fiber Web Team for the Tailspin Toys team project. The complete string that is used for this designation is referred to as an area path. Other area paths might include Tailspin Toys\Database or Tailspin Toys\Mobile Application, or can be several levels deep, such as Tailspin Toys\Web site\Shopping cart\Update controller.

The Iterations field is useful for project planning, and it can indicate a timeframe for when you plan to address a work item. In Figure 12.1, this work item is assigned to Tailspin Toys\Iteration 2, where Tailspin Toys is the name of the team project and Iteration 2 is the specific iteration this work item is assigned to.

You can name your iterations whatever you'd like; some teams choose sequential iterations (such as Iteration 1, Iteration 2, and so on), while others choose to map them to milestone releases (such as Beta 1, Beta 2, and so on). You can also create trees of iterations and employ a blend of naming strategies, such as Tailspin Toys\Version 2.0\Beta 1\Iteration 2. In addition, Iterations allow you to set start and end dates, as shown in Figure 12.3. This metadata is used in the Agile Planning tools discussed later in this chapter.

Figure 12.3 Iteration administration

You are not required to use iterations and areas to categorize your work items, but they can be very useful for querying, managing, and reporting on your work items as your team project grows. When used effectively, areas and iterations can allow you to employ a single team project for dozens or even hundreds of applications across many years of iterative releases.

A team project administrator can manage the list of valid areas and iterations from within Visual Studio by selecting Team Team Project Settings Work Item Areas and iterations by clicking Team Team Project Settings Work Item Iterations. This launches the Team Project's Control Panel in the Web Access portal. Figures 12.3 and Figure 12.4 show the screens for editing iterations and areas, respectively.

Figure 12.4 Area administration

A nice feature of area and iteration administration is that you can use the Security option in the context menu, as shown in Figure 12.4, to define granular permissions for indicating who is allowed to modify or even read work items in each part of your team project. For example, maybe you work for a government security contractor and there are bugs of a sensitive nature that should only be viewed by team members with a certain security clearance. Or maybe you are building a prototype of the next version of your application and want to restrict access to minimize the potential for leaks that your competitors could get access to. These sorts of restrictions are possible by using iteration and area security settings.

At any time, you can return to the Area and Iteration settings to add, rename, move, or delete areas and iterations. If you rename or move areas or iterations for which there are existing work items, those work items will automatically be reassigned by Team Foundation Server using the new name or location you choose. If you delete an area or iteration for which there are existing work items, you will be prompted for the value that Team Foundation Server should use to replace the iteration or area value in affected work items.

You will discover that work items are used throughout Team Foundation Server. They form the basis of many of the reports you will read about in Chapter 15. They can be linked to changesets (which you read about in Part II) to provide more information about what changes were made to a set of files and why. They can be used by project managers and team leaders for project planning, and they are used to help control which work team members should be focused on, and how they should interact with other team members.

Work items, work item types, and all of the activities involving work items (editing, querying, reporting, and so on) are usually referred to collectively as the work item tracking capability of Team Foundation Server. Now that you understand the basics of work items, you are ready to learn about process templates, which include the definitions for work item types.

Process Templates

A process template defines the default characteristics of any new team project. Process templates are a powerful concept in Team Foundation Server. A process template includes the default work item types, reports, documents, process guidance, and other associated artifacts that provide you with everything you need to get started with your software project.

Choosing the right process template is an important step in creating a new team project. You should carefully choose the best process template for your team's preferred work style and the type of project you are working on. This section will help you understand the types of process templates available. While you are reading this section, you should be thinking about the following types of questions:

· How does your team work today?

· Is there anything about how your team works today that you'd like to change?

· Do you need a formal process, or do you work better as a more agile team?

· Are there areas of your process where you prefer to be more agile, but other areas where you need to be more formal? (For example, maybe you want to manage your team's iterations in an agile manner, but decisions about requirements require formal negotiations with your customer.)

· Do you have resources to invest in and maintain your own custom process template, or would one provided by Microsoft or a reputable third party be a better solution?

· What other stakeholders should be involved in the decision-making process for answering these questions?

If answering these questions proves difficult for you or your team, you may want to start with a small pilot project first and see how your team performs when using one of the existing process templates. You can then use the findings from that pilot to determine which process template to start with, and what changes (if any) need to be made to that process template before using it for subsequent projects. Process template customization is covered in Chapter 13.

Embracing the right process template can have a transformational effect on an organization by providing everyone on the team with a predictable and repeatable process for capturing and communicating information, making decisions, and ensuring that you are delivering on customer expectations. This, in turn, can drive up software quality and development velocity, which ultimately delivers more value to your customers.

MSF for Agile Software Development

The MSF for Agile Software Development 2013 process template included with Team Foundation Server 2013 is designed for teams who are practicing agile methodologies, such as Scrum or Extreme Programming (XP). These methodologies have their roots in the now-famous Agile Manifesto (www.agilemanifesto.org/).

Note

MSF version 1 was introduced by Microsoft in 1993, and version 4 was first codified as a set of process templates with the release of Team Foundation Server 2005. MSF provides guidelines, role definitions, and other materials to help organizations deliver IT solutions, including software development projects. Many of the guiding principles of MSF align closely with those of the Agile Manifesto.

A key tenet of agile methodologies is that requirements will evolve over time, both as business needs change and as customers begin to use interim releases of your software. For this reason, the MSF for Agile Software Development process template assumes that teams will be frequently refining requirements and reprioritizing work by maintaining a common backlog of requirements (which are captured as user stories in this template). Periods of work are time-boxed into short lengths of time (iterations). Prior to each iteration, the development team works with the customer to prioritize the backlog, and the top user stories on the backlog are then addressed in that iteration.

Another important aspect of agile methodologies is, as the Agile Manifesto describes it, valuing “individuals and interactions over processes and tools.” This doesn't mean that processes and tools shouldn't be used at all, but instead that they sometimes can get in the way of empowering people to communicate and work together in order to make smart decisions.

This is also reflected in the MSF for Agile Software Development process template, which defines a relatively small number of states, fields, transitions, and work item types as compared with other process templates such as the MSF for Capability Maturity Model Integration (CMMI) Process Improvement process template. By keeping the process simple, the goal is to prevent any unnecessary burdens from getting in the way of people making the right decisions.

The following are the work item types available in the MSF for Agile Software Development process template:

· Bug

· Issue

· Task

· Test Case

· User Story

· Feature

Note

There are a few additional work item types present in all of the Microsoft-supplied process templates (and available to be added to custom and third-party process templates), which cannot be created directly, but are instead created during special situations. Code Review Request and Code Review Response work items are used to provide the code review functionality, which you read about in Chapter 6. Feedback Request and Feedback Response work item types are created during the process of requesting feedback and providing feedback from stakeholders, which are covered in Professional Application Lifecycle Management with Visual Studio 2013 (http://www.wiley.com/WileyCDA/WileyTitle/productCd-1118836588.html). Finally, the Shared Steps work item is essentially a special instance of a Test Case. You learn more about shared steps and test cases in Chapter 26. Most team members won't interact with shared steps directly, so they are excluded from the preceding list.

The MSF for Agile Software Development process template works well with the Agile Planning tools and Task Boards in Team Foundation Server 2013.

Note

You can explore the MSF for Agile Software Development 2013 process template in depth, including more detail on each of the included work item types, at http://aka.ms/MSFAgile2013.

MSF for CMMI Process Improvement

The MSF for CMMI Process Improvement 2013 process template is designed for teams who want to, or may have to, take a more formal approach toward developing software. This process template is based on the Capability Maturity Model Integration (CMMI) for Development, which was developed by the Software Engineering Institute, a part of Carnegie Mellon University. CMMI defines not only a framework for developing software, but it also prescribes ways for an organization to constantly improve its processes in an objective and repeatable way. An organization can even become certified by an outside appraiser who can verify whether or not it is performing at one of five CMMI maturity levels.

CMMI is a popular model for developing software by such organizations as systems integrators (SIs) and software factories. There is very little subjectivity in the model, so it allows an organization to represent its services using a standard that is well understood globally and can be appraised and certified by a neutral third-party organization. CMMI is also used for developing many mission-critical systems by organizations such as NASA or defense contractors. In fact, the Software Engineering Institute at Carnegie Mellon was originally funded by the United States Department of Defense to help them find better ways of managing their projects.

As you might expect, the MSF for CMMI Process Improvement process template is more complex than its Agile counterpart. The CMMI template includes the following work item types:

· Bug

· Change Request

· Issue

· Requirement

· Feature

· Review

· Risk

· Task

· Test Case

Note

The Feedback, Code review, and Shared Steps work item types are also omitted from this list for the same reason as mentioned previously in the discussion of the MSF for Agile Software Development process template.

In addition to including three additional work item types, the work item types themselves are also more complex in the CMMI process template than in the Agile process template. Compare the screenshot of a bug work item form from the Agile process template, shown earlier in Figure 12.1, with a bug work item form from the CMMI process template, shown in Figure 12.5. Take note of the additional fields, such as Root Cause, Triage, and Blocked, which were not in the bug work item from the Agile process template. There are also additional tabs across the lower half of the bug work item from the CMMI process template.

Figure 12.5 Bug (CMMI) work item form

The states and transitions of work item types from the CMMI process template are also more complex than in the Agile process template. Now compare the state diagram of the bug work item type from the Agile process template, shown in Figure 12.2, with the state diagram of the bug work item type from the CMMI process template, shown in Figure 12.6.

Figure 12.6 Bug (CMMI) work item type state diagram

The key difference you should notice between these two state diagrams is that the CMMI process template introduces an additional state—Proposed. This explicit decision stage is required in the CMMI process template before a developer is ever assigned to work on a bug. This should cause the team to ask such questions as, “Is this really a bug, or does this represent a request to change the way certain functionality was designed? Will fixing this bug have unintended side effects on other parts of the software? If you choose to work on this bug, how should it be prioritized against your other work?”

This shouldn't imply that those aren't important questions to be asking even if you are using the Agile process template, and a seasoned team practicing an agile methodology will likely already be mentally following this checklist as they triage bugs. But the CMMI process template makes this step explicit, which helps to ensure that this step takes place for every bug, regardless of the experience level of the development team.

Another way of thinking of CMMI is to realize that by following the model, NASA isn't guaranteed that it will never again develop a rocket that fails because of a software defect. But if NASA is following CMMI correctly, then it can guarantee that an agreed-upon process was used to make decisions leading up to that defect. And conversely, in the event of a defect, it can audit the process that was used, examine the assumptions that went into the decision-making process, and learn from those mistakes in the interest of refining its process and helping to ensure that the same mistake never happens again.

It is also important to point out that using the MSF for CMMI Process Improvement process template alone will not ensure that an organization can successfully pass a CMMI certification audit. This is akin to the fact that simply having a smoke alarm and a fire extinguisher on hand won't keep a family safe if they don't know how to properly use and maintain this equipment.

But Team Foundation Server 2013, along with the MSF for CMMI Process Improvement process template, can be very useful for helping an organization that wants to adopt CMMI as its model of development. Team Foundation Server features such as end-to-end traceability, multidimensional reporting, rich linking (between work items, and with other artifacts such as builds and changesets), and preservation of history are all incredibly useful capabilities that can help an organization to prepare for and pass a CMMI audit.

Note

You can explore the MSF for CMMI Process Improvement 2013 process template in depth, including more detail on each of the included work item types, at http://aka.ms/MSFCMMI2013.

CMMI Development Methodology

There is a common misconception that CMMI dictates a waterfall, or “Big Design Up Front,” development methodology. While there is certainly a strong correlation between teams practicing waterfall methodologies and those following a CMMI model, CMMI actually does not define a development methodology. You can choose to use an agile development methodology along with the MSF for CMMI Process Improvement process template if you want to, although you might have a hard time selling agile diehards from your team on the value of the additional rigor imposed by its processes.

As a compromise solution, another approach is to pick and choose the aspects of the CMMI process template that are most interesting to you, and incorporate those into the Agile process template as a custom process template. For example, maybe you like the explicit decision point created by having your bugs begin in a Proposed state before being activated, but you don't see a need for the additional work item types in the CMMI template. In this example, you could start with the Agile process template and import the Bug work item type from the CMMI process template.

Visual Studio Scrum

While there are many development methodologies that make up the agile movement, Scrum has established itself as the most popular for the time being. Scrum defines clear roles, responsibilities, and activities that team members practicing Scrum must follow.

A team practicing Scrum uses a standard vocabulary to define what they are doing. Teams hold daily scrum meetings (meetings where team members talk about what they did yesterday, what they will do today, and anything that might be blocking them—called animpediment). Instead of a project manager, a team practicing Scrum is usually led by a Scrum Master. There are other terms as well, which you can learn about in any of the dozens of books about Scrum, or from the hundreds of Scrum user groups or trainers around the world.

The Visual Studio Scrum 2013 process template was introduced specifically to help teams who want to practice Scrum and use Team Foundation Server 2013. The first version was made available a few months after Team Foundation Server 2010 first shipped. The current version now ships in the box with Team Foundation Server 2013; in fact, it was also made the default process template for team project creation.

So, you might now be wondering, if the MSF for Agile Software Development process template is designed to support any of the agile development methodologies—including Scrum—what is the purpose of the Visual Studio Scrum process template? The Visual Studio Scrum process template was created to provide teams practicing Scrum with the specific artifacts and terminology used universally by teams who have adopted Scrum.

Instead of User Stories or Requirements, Visual Studio Scrum uses Product Backlog Item work item types. Instead of Issues or Risks, Visual Studio Scrum uses Impediment work item types. Sprints are represented by the Iteration Path, and the dates you use to define your Sprints are used when rendering your burndown and velocity reports. The Agile Planning Tools discussed in Chapter 14 were created specifically with the Scrum template in mind. In short, if you practice Scrum or are considering practicing Scrum, the Visual Studio Scrum process template is designed to help you do so while making the most of Team Foundation Server 2013.

Note

You can explore the Visual Studio Scrum 2013 process template in depth, including more detail on each of the included work item types, at http://aka.ms/Scrum2013.

Compromising with Scrum

If you want to practice Scrum, the Visual Studio Scrum process template provides a great option for doing so. But you shouldn't feel locked into this process template if there are other process templates you like better, such as the MSF for Agile Software Development process template.

For example, you may prefer some of the additional reports that are included with the Agile process template. You can still use the Agile process template and practice Scrum, but you will just need to make some mental translations between the terminology you use as a Scrum team and the way the Agile process template expects you to enter information (such as referring to Product Backlog Items as User Stories).

Third-Party Process Templates

Several third parties provide process templates for use with Team Foundation Server 2012 and 2013.

There are several great third-party process templates available, but you should carefully consider the support and road map implications of adopting a third-party process template. For example, when the next version of Team Foundation Server is released, will the process template be upgraded to take advantage of new or improved features? And if so, what is the upgrade path for migrating existing projects to the new version of the process template?

If you aren't prepared to take over the maintenance of the process template in the event that the third party chooses to stop investing in it, then you might want to consider one of the aforementioned process templates that are built and supported by Microsoft.

Custom Process Templates

Finally, you might decide that none of the process templates provided by Microsoft or third parties fit the needs of your team or your development project. While you could certainly create your own process template from scratch, a far more common approach is to start with an existing process template and customize it to suit your needs. You can learn about customizing process templates in Chapter 13.

Now that you understand your options for choosing a process template, the next section will introduce you to some of the different ways you can manage your work items.

Managing Work Items

There are many ways of accessing your work items within Team Foundation Server 2013. Because work items will be used by many stakeholders across your team (including programmers, testers, project managers, and so on), and most of these roles don't use Visual Studio as their primary tool, you will discover that Microsoft provides many client options for accessing work items.

In this section you will be introduced to using Visual Studio, Excel, Project, and Team Web Access to access your work items. This chapter won't cover every aspect of accessing work items from each of these clients, but it will give you a better idea of the ways each client can be used, as well as the relative benefits of each, and provide you with pointers to detailed documentation for each client.

The list of clients in this section isn't exhaustive. There are also dozens of third-party clients, a few of which are examined in this section. Testers might use Microsoft Test Manager (discussed in Chapter 26). Eclipse users can utilize Team Explorer Everywhere. You can even write your own clients using the Team Foundation Server object model if you want to.

Using Visual Studio

In Chapter 4, you learned about using Team Explorer to work with Team Foundation Server 2013. Team Explorer not only provides access for Visual Studio users wanting to connect to Team Foundation Server, but it also installs the add-ins required to work with Excel and Project. So, even if you don't plan on using Visual Studio, if you want to use Excel or Project with Team Foundation Server, you should install Team Explorer.

Note

The examples in this chapter assume that you are using Team Explorer 2013. While it is possible to use older versions of Team Explorer to connect to Team Foundation Server 2013, you will not be able to access some of the new features in the product. In particular, because earlier editions of Team Explorer (2005 and 2008) aren't aware of the rich relational-linking capabilities of Team Foundation Server 2013, you won't be able to manage these link types or use the newer querying capabilities to navigate your work items.

You can still use older versions of Visual Studio along with Team Explorer 2013. Team Explorer 2013 will be installed “side by side” with your legacy version of Visual Studio, and you can access it by opening the Visual Studio 2013 shell. You can continue to use your legacy Visual Studio client to check in code changes, and then switch to Team Explorer 2013 to update your work items.

Creating Work Items

Work items are easy to create using Visual Studio. Open the Team Explorer window of Visual Studio 2013 and click on the Work Items entry. Now, click on the New Work Item menu. The drop-down menu will reveal the work item types that are available in your team project. Click the work item type that you want to create an instance of. An empty work item form will appear, similar to that shown in Figure 12.1.

The new work item form will vary in appearance based on the work item type you chose to create. For the most part, filling out the work item form is self-explanatory, but there are a few things to notice when creating and editing work items.

The first is that your work item won't have an ID until it has been successfully saved for the first time. Remember that the ID is a number that is globally unique across your team project collection, numbered sequentially, starting with 1. This means that the first work item you save within a new team project won't have an ID of 1 if there are existing team projects in your team project collection that also contain work items.

For now, your work item probably says something like “New Bug 1” at the top of the form. The number 1 isn't your work item's ID; it's just a temporary number used by Visual Studio to track unsaved work items in this session. In fact, until it is saved, Team Foundation Server won't know about your work item.

Before you can successfully save this work item, you will need to assign a Title to it at a minimum. There may be other required fields as well, depending on the work item type you selected. An error message at the top of the form will indicate any remaining fields that you must complete. Some required fields may appear on other tabs.

Another thing you'll notice about work items is that you can't skip states. A work item must be saved in one state prior to moving to the next state. For example, if you refer back to Figure 12.2, you will notice that a bug from the MSF for Agile Software Development process template generally moves from Active to Resolved to Closed.

You can't immediately create a new bug and save it in the Resolved state, however, even if you already fixed the bug that you found, and you're just creating the bug work item as a record of what you did. You must first save it in an Active state, change the state to Resolved, and then save it again.

This may seem cumbersome at first, but the reason you can't immediately change the state of a new work item is that the work item type may define rules that must be satisfied as a work item transition from one state to another. Additionally, the meaning of some fields changes during a work item's life cycle, so each time you save in a new state, the available choices for a field may change. For example, when you create a new bug using the Agile process template, the Reason field helps to indicate how a bug was discovered. When you are transitioning the same bug from Active to Resolved, the Reason state indicates why you are doing so (the bug was fixed, or couldn't be reproduced, or was a duplicate, and so on).

The interface for creating and editing work items with Visual Studio is very straightforward. What can be difficult to master is an understanding of all of the fields found throughout the work item types, their transitions, when to use them, and so on.

For the process templates provided by Microsoft, the documentation is very thorough and is recommended reading to help you decide how to best adopt these process templates within your team. But wholesale adoption of these templates isn't for every team. You should feel empowered as a team to decide which fields are more or less important than others. You may even decide to add to or simplify the work item types to better meet your needs. Process template customization is covered in Chapter 13.

Deleting Work Items

A common complaint by people who are new to using work items with Team Foundation Server is that work items can't (easily) be deleted. This was a design decision by Microsoft. Organizations do not want bugs, requirements, or other important work items in a project to be accidentally (or maliciously) deleted, so there isn't an option within Visual Studio or the other clients you'll read about in this chapter for deleting work items.

Team Foundation Server 2013 makes deletion possible from a command prompt. Open a Visual Studio command prompt and type witadmin destroywi /? for the command-line syntax help. This action is not reversible, so take care when using it. As a general rule, destructive operations are only available from the command line and require Administrative permissions.

Microsoft's recommended approach is to transition work items as appropriate instead of deleting them. For example, if you examine the state diagram in Figure 12.2, you will see that valid reasons for resolving a Bug work item include indicating that the bug can't be reproduced, it's obsolete (maybe it refers to a feature or functionality that has been removed or changed), or it's a duplicate of a bug that already exists.

While it might be tempting to just want to delete these work items instead of resolving them using one of these reasons, the resolution data might prove useful later for a QA lead to discover that a tester isn't doing his or her job effectively when filing these erroneous bugs. It's easy to generate a report later on showing, for example, all of the bugs created by a tester that were later discovered to be duplicates of existing bugs. But if those same work items are deleted, they won't show up in such a report.

Changing a Work Item Type

In Team Foundation Server, the fields for each work item type can be vastly different. For this reason, it is not possible to simply change the type of a work item. This is a common complaint by people familiar with alternative process management tools such as Atlassian's Jira.

Even though changing a work item type is not supported in Team Foundation Server, both the Team Web Access and Visual Studio interfaces provide convenient ways to create a copy of a work item. The copied work item can be a different type, and all data in corresponding fields will migrate across. This includes all links to work items.

For more information on copying work items, see the blog post at http://aka.ms/ChangeWIType.

Work Item Queries

Now that you know how to create work items, the next task you should learn about is how to find them. You can type the ID of the work item directly in the Search box in Team Explorer, but this assumes that you know the ID of all of your work items. Chances are you'll want to use queries most of the time.

The process template you are using probably includes some useful built-in queries already. Open the Work Items page of Team Explorer to reveal the My Queries and Shared Queries folders under the Queries node. The contents of the Shared Queries folder are visible to everybody on the team, whereas My Queries provides a personal location to save queries, which may only be useful to you. By keeping specialized queries in My Queries, you can avoid creating too much clutter for your fellow team members.

Note

You should consider using permissions to lock down queries within the Shared Queries node. This will prevent someone from accidentally overwriting a shared query with their own, which might cause unexpected results for others. You can set security on a query or query folder within Team Queries by right-clicking it and selecting Security.

If you have an existing query, you can simply double-click it to run it. Your results will vary based on the type of query you run and the number of matching work items in your team project, but it will look something like the query results shown in Figure 12.7.

Figure 12.7 Results of a tree query

The query results shown in Figure 12.7 are from a Tree of Work Items query. This query type returns a list of work items matching your query and groups them according to their parent/child relationships. In this example, there are top-level User Story work items that are linked to child task work items.

Another type of query is Work Items and Direct Links. This type of query is similar to the Tree of Work Items query, except that you are not limited to parent/child links. For example, you can specify that you want to see all user stories and their test cases as represented by a tested-by link type. You can even construct a query that shows all of your user stories that do not have linked test cases; this is useful for spotting potential holes in your test plan.

Finally, the Flat List query type does not show any link types and is the basic type of query found in all versions of Team Foundation Server.

From within the query results window, you can open a work item simply by double-clicking it. You also have several options available to you from the toolbar located at the top of the query results window. You can place your mouse over these toolbar icons to learn more about them. The available options will vary slightly between query types, but all of them allow you to create new work items (linked to any work items you have highlighted); to link the work item you have highlighted to another existing work item; to open your query results in Microsoft Project, Outlook, or Excel (more on this later); to edit the query you are working with; and to change which columns are displayed in your query results (and in which order).

The query editor shown in Figure 12.8 is the result of having opened the query from Figure 12.7 and clicking Edit Query.

Figure 12.8 Query editor

Even if you've never used queries with Team Foundation Server before, this query should be fairly straightforward to reverse-engineer to learn what it does.

The first row (Team Project = @Project) means that your query results should be scoped to the team project where the query is saved. If you delete this row, your results may return work items from the entire team project collection. @Project is a query variable. Query variables are converted into their respective values when the query is executed. So, for this project, @Project will resolve to “Tailspin Toys.” By using query variables, you can write more flexible queries. The two other query variables available to you are @Me (which is converted into the user name of the currently logged-in user) and @Today (which is converted into today's date).

The next row of the query (AND Area Path Under @Project) indicates that work items from any area path of this project can be included because the area path specified is the top-level area path (for this project, that means that @Project will resolve to the \Tailspin Toys\area path). You could change this clause to something like AND Area Path Under Tailspin Toys\Web site if you wanted to restrict results to work items related to your website. Because you are using the Under operator, if you had further sub-paths (such as Tailspin Toys\Web site\Shopping cart), these would be included as well. If you wanted to restrict the results so that the area path matched exactly what was specified in the rightmost column, you could change the operator to the equals sign (=).

The third clause (AND Iteration Path Under Tailspin Toys\Iteration 2) is similar to the second clause. This means that work items must be assigned to an iteration of Iteration 2 (or anything under this path).

Clauses four and five are grouped together (as shown by the vertical bracket on the far-left side of the query). This means that they should be interpreted together, in much the same way that math operations within parentheses or brackets are interpreted together. These clauses, when interpreted together, mean Return work items with a work item type of User Story OR a work item type of Task.

Finally, because the query type for this query is a “Tree of Work Items,” there is a second grid (labeled “Filters for linked work items”), which allows you to specify any constraints on the child work items that are returned. In this example, only task work items will be returned as children.

Note

Work item queries can be very powerful, and the options for creating queries are endless. A full guide for understanding how to use queries can be found at http://aka.ms/TFSQueries2013.

Using Microsoft Excel

Microsoft Excel is another popular client for editing work items. If you have installed Team Explorer 2013 on a machine with Microsoft Excel (2007, 2010, or 2013), you will have a Team tab available from the Office Ribbon, which allows you to interface with Team Foundation Server 2013.

There are two ways of opening work items in Excel. One option is to open query results from within Team Explorer and then, from the query results toolbar, click Open in Microsoft Office Open Query in Microsoft Excel. The other approach is to start in Excel, open the Team tab from the Office Ribbon, and then click New List. You will be prompted to select your Team Foundation Server and team project, along with the query for the work items you want to manage. Or, instead of a query, you can start with an empty list. This allows you to enter new work items, or to select individual work items to add to your list by clicking Get Work Items.

Managing work items in Excel is a fairly rich experience. You can create new work items, make edits to existing work items, and even manage Trees of Work Items. Figure 12.9 shows the results of the same query you saw earlier. Note that parent/child relationships are represented here as well. Parent work items have their titles listed in the Title 1 column, and their children have their titles listed in the Title 2 column. If you added a third level to the tree, grandchild work items would be listed in a column named Title 3, and so on.

Figure 12.9 Work items in Excel

You can make any changes you want to within your Excel grid. You can add new work items for a Tree of Work Items query by clicking an existing work item and clicking Add Child from the Team tab of the Ribbon. To create a new work item, you can simply place your cursor on a new row at the bottom of your grid, and start typing.

Note, however, that none of your work will be persisted to Team Foundation Server until you click Publish from the Team tab of the Ribbon. Even if you save the Excel workbook file, your work items won't be synchronized to Team Foundation Server until you publish them. Similarly, you won't see any changes that have occurred in Team Foundation Server until you click the Refresh button in the Team tab.

Note

In order to access the Publish button from the Team tab, your cursor will need to be within a cell that is a part of your work item grid. Otherwise, the Publish button will be disabled.

You will receive an error message if the values you entered for work items in Excel do not conform to the validation rules or state transition workflow for the work item type. At this point, you can even view the offending work items using the same form view you are familiar with from Visual Studio.

Note

Excel is a useful tool for making bulk edits of work items, for quickly importing several work items between team projects, or for people who just prefer working with Excel over Visual Studio. You can read more about using Excel as a work item client at http://aka.ms/TFSExcel2013.

Using Microsoft Project

Microsoft Project is one of the most popular project management tools in the world and supports integration with Team Foundation Server. If you have installed Team Explorer 2013 on a machine with Microsoft Project Professional (2007, 2010, or 2013) or Standard, you will have a Team menu that allows you to interface with Team Foundation Server 2013.

As with Excel, you can either start with a query in Team Explorer (and choose Open in Microsoft Office Open Query in Microsoft Project), or you can open Project and use the Team menu to access a query of work items from Team Foundation Server. Figure 12.10shows work items being managed by Microsoft Project.

Figure 12.10 Work items in Project

Project will also display work items according to their parent/child relationships. A major benefit of using Project to view your work items is that it's easy to visualize dependency relationships (successor/predecessor) using the built-in Gantt chart visualization that Project is popular for. In Figure 12.10, it's easy to see that some work items have dependencies on others, which can be helpful for teams deciding how to prioritize their work.

Like Excel, changes to work items that you make within Project are not synchronized to Team Foundation Server until you click Publish from the Team menu.

Note

You can learn more about using Project for managing work items at http://aka.ms/TFSProject2013.

Using Team Web Access

Team Web Access provides yet another way of managing your work items. You learned about how to connect to Team Web Access in Chapter 4. Team Web Access provides a rich, web-based way of accessing Team Foundation Server. An obvious benefit of Team Web Access is that users do not need to have any software other than a web browser. Figure 12.11 shows Team Web Access being used to manage work items.

Figure 12.11 Team Web Access

Team Web Access provides a surprising number of features for a web-based client. You can edit queries, manipulate work items, manage tasks with the task board, manage security, and manage team members.

Team Web Access makes an ideal work item client for users who don't have Team Explorer installed. Some organizations even encourage end users to file bugs and enhancement requests about their software using Team Web Access.

Note

You can read more about using Team Web Access as a work item client at http://aka.ms/TFSWebAccess2013.

Note

If you are interested in using Team Web Access as a way for end users to file and track bugs and enhancement requests, you should consider the Limited Access or Work Item Only View version of Team Web Access. When users connect to Team Foundation Server using the Limited Access View, they do not need to have a client access license (CAL) for Team Foundation Server. For more details on enabling Limited Access View for your end users, see http://aka .ms/TFSWIOV.

Using Third-Party Tools

In addition to the tools mentioned previously, several third-party tools are available that integrate with Team Foundation Server 2013 and make use of work items. The following sections examine just a small sampling of the many tools that integrate with Team Foundation Server 2013.

AIT Tools Suite

The folks at AIT GmbH & Co. in Germany have created a number of free add-ons to the Team Foundation Server system. They include tools to check dependencies between branches of code, generate documentation and change logs during your build, and allow you to use Microsoft Word to edit work items.

AIT WordToTFS is an add-in to Microsoft Word that allows the user the ability to create, modify, and delete work items. You can import work items directly into a Word document or refresh existing work items from the data stored in Team Foundation Server. Once you have finished making changes to the work items, you can publish those changes back to Team Foundation Server so that the rest of your team can see them.

You can download the AIT Tools Suite programs for free at http://tinyurl.com/AITToolsSuite.

TeamCompanion

TeamCompanion (by Ekobit) is an add-in to Microsoft Outlook that provides most of the same functionality as Team Explorer but from within a tool that you probably always have open. This is an excellent UI for those team members who live in Outlook, such as project managers. From TeamCompanion, you can create new work items from received e-mails, send work items as an e-mail, and send the results of a query as the body of an e-mail.

TeamCompanion can also schedule queries to run at intervals and let you know something in the query results has changed in a manner similar to Outlook's ability to show you that you have new e-mails. You can also view reports, manage alert subscriptions, or use the powerful work item search capabilities.

A free trial version of TeamCompanion can be downloaded from http://teamcompanion.com.

Project Server Integration

Earlier in this chapter, you learned about how Microsoft Project can be used to create project plans with your work items in Team Foundation Server 2013. But organizations that utilize Project Server may also be interested in the capability of Team Foundation Server 2013 to integrate with their Project Server 2007, 2010, or 2013 deployments.

This integration allows planning and status information from your development team, using Team Foundation Server, to flow through to your project management office, using Project Server. This enables the software development team to use a single tool—Team Foundation Server—for managing their work while allowing Project Server users to easily report on and participate in project management activities from those same projects. Project Server Integration is discussed in detail in Chapter 16.

Summary

In this chapter, you learned about the project management capabilities of Team Foundation Server 2013, with a focus on work item tracking. You first learned about some of the major features related to project management that have been improved or introduced in this release. You were introduced to work items, including the key components that make up work item types. You discovered the importance of process templates, which include predefined work item types, and you read overviews of several of the most popular process templates available for use with Team Foundation Server 2013. Finally, you were introduced to a variety of ways that you can manage your work items with Team Foundation Server 2013, including from within Visual Studio, Excel, Project, and through integration with Project Server.

In Chapter 13, you will learn about how work items and process templates are defined, and how you can customize them to best suit the needs of your team.