Professional Team Foundation Server 2013 (2013)

What's in this chapter?

· Defining and managing your portfolio and product backlog

· Planning an iteration while balancing resource capacity

· Tracking your work using task boards

· Understanding options for customizing the agile planning and tracking tools

· Communicating with your team using Team Rooms

· Discovering how the development team can request feedback from stakeholders on specific features or requirements

· Learning how project stakeholders can use the Microsoft Feedback Client to provide rich feedback about your software

The Agile Manifesto defines several guiding principles that have implications on the ways in which teams manage projects. Instead of attempting to define an entire project schedule up front, as with a waterfall methodology, an agile team allows the plan to evolve over time. Work is broken down into multiple successive iterations, each of which might last between one and four weeks.

Teams practicing an agile development methodology tend to embark upon a journey of mutual discovery with their customers to determine new work dynamically, based on changing business priorities or on feedback from work done in previous iterations. The customer, or at least a proxy for the customer, is considered a virtual member of the team and participates in defining and prioritizing (and often re-prioritizing) work over time.

The pursuit to embrace agile development, with dynamic schedules and evolving requirements, has meant that many of the tools and techniques used for traditional project management are no longer sufficient. Agile practitioners have needed to look for different ways of capturing work, balancing resource capacity, tracking status, and so on.

Scrum, which is by far the most popular agile development methodology in use today, defines such tools, terminology, and methodology. Future work is captured and prioritized on a product backlog, which can then be committed into specific iterations, called sprints. Each sprint has its own sprint backlog in which work is further decomposed into smaller units of work. This work is tracked to completion on a task board, which usually takes the form of sticky notes on a whiteboard.

Team Foundation Server 2013 has embraced these concepts by providing a set of web-based tooling for managing your product backlog, decomposing your work into iterations, and tracking your work using a digital task board. Anyone familiar with or practicing Scrum should feel immediately at home with this set of tooling, although it cannot be understated that this same set of tooling can be adopted by any team who wants to use it, even if they aren't practicing Scrum per se. One of the design principles of Team Foundation Server has always been that teams can use any process they want to, and Team Foundation Server provides the right level of flexibility and customization to support such a process.

In this chapter, you learn about the web-based tooling available within Team Foundation Server 2013 to support agile project management and tracking. This book is not a true primer on how to run a project using a Scrum (or any other) development methodology, but there are several great books to choose from that cover this topic.

Later in this chapter, you will also explore the new tools available for teams that allow them to communicate with each other and be notified of useful events in real time. You will also learn how team members can request feedback from stakeholders. Stakeholders are then able to respond to that request using a new Feedback Client that they can then submit, which will then be available for the requesting team to manage and process.

Defining a Team

Team Foundation Server 2013 defines the notion of a team, which you can use to organize people who are working together. This should not be confused with the concept of a team project within Team Foundation Server, which is a large container of work, consisting of source control and work items that all share a common process template. A team project usually contains multiple teams, and each team can have its own product backlog, iterations, and task board. A single person might also participate in more than one team. For instance, a graphic designer might be a shared resource responsible for contributing artwork to different teams.

Note

For more information about making decisions about the scope and size of your team projects, see Chapter 2 about planning your Team Foundation Server deployment.

To create a team, follow these steps:

1. Open a browser and visit the Team Web Access home page for your team project. You can access this by clicking the Web Access link in Team Explorer. The address takes the format of http://<server>:<port>/tfs/<collection-name>/<team-project>.

2. Now open the administrative context by clicking the gear icon in the upper-right corner. If you do not have administrative privileges for your team project, you need to contact your team project administrator to perform these steps. On this screen you should see a list of any teams already configured for your team project.

3. Click New Team to display the Create New Team dialog box, as shown in Figure 14.1. You can provide a name and description for your team and specify what default permissions new team members should inherit. From the Settings tab, you can declare any users who should be team administrators.

Figure 14.1 Create New Team dialog box

The Create New Team dialog box also lets you create an area path for this team. You were introduced to the concept of areas in Chapter 12. Areas provide a way for you to categorize your work within a team project. You can choose to create areas for each of your teams, so that (for example) bugs that are filed against the \Fabrikam Fiber Web Site area path are automatically routed to the Fabrikam Fiber Web Team.

4. Click Create Team when you are finished to create your team and return to the list of teams on your team project. Click your team in this list to display the team administrative dialog box shown in Figure 14.2. From here you can easily add new team members or team administrators. You can also change the name of your team or the description, or choose an image to represent your team.

Figure 14.2 The team administrative dialog box

You are able to add whole Team Foundation Server groups to teams as well as individuals. If you have added groups, you can toggle between seeing individual members and their teams by clicking on the membership filter at the top right of the list.

5. Click the Iterations tab to select the iterations your team is participating in, as shown in Figure 14.3. In Chapter 12, you also learned how to manage iterations and assign start and end dates to them. On this screen, you are indicating which iterations your team is using to structure its work. You should ensure that the iteration dates do not overlap.

Figure 14.3 The Iterations dialog box

Your iterations need to be hierarchical, consisting of at least one parent and one child. This is required so that your backlog iteration (representing unscheduled work) can exist at the root or parent node, and specific iterations (representing scheduled work) are represented by child nodes. In Figure 14.3, Release 2 is the parent node representing the backlog iteration. You can select a new backlog iteration by highlighting that iteration, clicking the small drop-down arrow to the left of the iteration name, and then selecting Set as Team's Backlog Iteration. But you need to first ensure that your desired backlog iteration has at least one child iteration.

Note

It may be necessary to create different iteration structures for each team within your team project. For example, if your Web Team is using the term “Sprint 3” to define an iteration that begins on March 1, but your Database Team thinks of Sprint 3 as beginning on April 15, each team should have its own iteration structure. You can use any naming convention you want for this, such as WebTeam\Sprint3 and DataTeam\Sprint3. This way, each node can have its own start and end date independently.

If your organization's goal is to report across multiple teams, it is recommended that you not take this approach and attempt to align the team's iteration schedules appropriately. You can even have some teams on differing lengths as long as the time spans are equally divided. For example, one team may work on four-week iterations and another may work on two-week iterations. That can be accommodated by placing two child iteration nodes for each four-week iteration node. One team would select the four-week iteration node and the other would select the two children that represent the two-week iterations.

Similarly, click Areas to configure which area paths your team is using to manage its work, as shown in Figure 14.4. You can select multiple areas, or the root area path, although if you have many people using your team project you might want to use areas to more carefully segregate work—for example, based on application, project, team, and so on.

Figure 14.4 The Areas dialog box

You can use the Security tab to configure permissions for your team, and you can use the Alerts tab to configure e-mail notifications for your team. For example, you might want to automatically send an e-mail to any team member if a work item assigned to that person changes. Or you can e-mail the entire team if a daily build fails.

Finally, you can click the Version Control tab to change permissions specific to source code files and folders if you are using Team Foundation Version Control, or repositories and branches if you are using Git.

6. Close the administrative context when you are finished, and return to Team Web Access. You can now access the team home page for any team you are a member of by clicking the drop-down to the right of “Visual Studio Team Foundation Server 2013” in the header of the Team Web Access view and selecting the appropriate team. For example, Figure 14.5 shows the home page for the Fabrikam Fiber Web Team.

Figure 14.5 Home page for the Fabrikam Fiber Web Team

If you just created a brand-new team, your home page won't yet look as rich as the one shown in Figure 14.5. The top half of this view shows information relevant to your current iteration. The status bar on the left shows the amount of work remaining as compared to the capacity of your team (in this example, 49 hours of work have been completed and the team has a total capacity of achieving 108 hours of work). The burndown graph is a trend that shows how remaining work has decreased (or increased) over time during your current iteration. You learn more about iteration capacity and burndown visualizations later in this chapter.

Figure 14.6: Add to team favorites optionThe bottom half of this view shows any Team Favorites you have configured. These can represent work item queries—such as open bugs or in-progress tasks. They can also display graphs of recent builds or even recent changesets that have been checked into a particular branch. To add Team Favorites to this view, you should first open a relevant work item query, branch, or build within Team Web Access. You can then click the small drop-down arrow located to the left of the object and select Add to team favorites, as shown in Figure 14.6. This adds a new tile to your team's home page, which can make it easy for the entire team to see the metrics you believe are most important to track. You can then drag and drop each of the tiles to reorganize the final view.

Figure 14.6 Add to team favorites option

Next you will see how to define and manage your team's product backlog.

Maintaining Product Backlogs

A product backlog is essentially just a list of work that your team has identified but hasn't yet scheduled for implementation. The product backlog is a useful tool for collaborating with customers or other project stakeholders. As new work is requested by your stakeholders, you can track it in a central location on the product backlog. You can also estimate and prioritize this work, usually with input from your customer or stakeholders to help determine which items are most important to deliver first.

The 2013 release of Team Foundation Server introduces the concept of Agile Portfolio Management. While in previous versions, the product backlog was defined without a hierarchy, now you can define your work at multiple granularities. This allows you to define high-level goals or features that contain multiple product backlog items.

All of the standard process templates that come with Team Foundation Server have been updated to provide support for this new hierarchy. Each template includes a new Feature work item type for this purpose.

Managing the Backlog

From your team's home page, click View Backlog to display your product backlog, such as the one shown in Figure 14.7. In Team Foundation Server 2013, a small colored bar has been added next to work items to indicate the work item type. In Figure 14.7, you can see one red Bug in our backlog surrounded by blue Product Backlog Items. The “quick add” panel at the top of this page, shown as a light gray box, enables you to quickly enter new work as it is identified. You can select the type of work to add (such as Product Backlog Item or Bug), provide a title, and press Enter (or click Add) to quickly add this work to your backlog. When you do this, you automatically create a new work item within Team Foundation Server.

Figure 14.7 Product Backlog hub

If you highlight a row within your backlog, any new work you add from the Quick Add panel is inserted above this highlighted row. The exception to this rule is when you have highlighted the last row in your backlog; new work is added at the end of your backlog.

Note

The screenshots in this chapter reflect a team project created with the Visual Studio Scrum 2013 process template included with Team Foundation Server 2013. The terminology varies slightly if you are using either the MSF for Agile Software Development 2013 or MSF for CMMI Process Improvement 2013 process templates, but you can still take advantage of the same tooling. You can even customize this tooling for use with your own custom or third-party process templates. Customization options are discussed later in this chapter.

You can easily reprioritize work by dragging and dropping it on the backlog. Changes you make here are saved to Team Foundation Server in the background. You can also double-click an item in this view to open the work item editor to provide additional detail or make changes.

Note

If you have used previous versions of Team Foundation Server then you are used to changing priority by hand-editing a field within each work item. But notice that the Priority field is no longer visible within Team Web Access or Visual Studio when viewing work items. Backlog Priority is now a hidden field by default. The recommended way of setting this value is to use the Team Web Access view to drag items up and down the backlog. Behind the scenes, Team Web Access uses large integers and an algorithm to assign Backlog Priority values. The use of large integer values here makes it possible to insert a work item between two items on a backlog without needing to make updates to each of the surrounding items.

Team Foundation Server 2013 introduces a few new options at the top of your backlog. You can click Create query to create a work item query representing the current view. You can change the columns that are shown by clicking Column options, and you can even e-mail your backlog by clicking the envelope icon.

Teams practicing Scrum will be familiar with a concept known as velocity. Velocity is a metric used to calculate the amount of work that a team is able to deliver for a given iteration. It is usually measured in story points on Scrum teams. Other teams may prefer to do their estimations in hours, or days, or ideal days, and so on. Regardless of the estimation technique used by your team, you can use the product backlog view to get a sense for when you will be able to deliver items on your backlog. The only requirement is that you should be consistent with your estimation techniques. For example, when some people on the team are estimating in days and other people are estimating in story points, it's difficult to create consistent plans.

Toggle forecast lines on or off by clicking the On/Off link in the upper right of this page labeled “Forecast.” Forecast lines display, as shown in Figure 14.7, to indicate when work is estimated to be delivered based on your current team's velocity. This approach requires that you have estimated your backlog items by providing a value for effort. Do this by double-clicking each item in your backlog to provide this additional level of detail.

Note

Most teams practicing Scrum also transition the state of an item on the backlog from New to Approved at the time that the team provides an Effort estimate. You are not required to follow this protocol, but it can be helpful for differentiating between truly new work (which might only be in the “idea” stage) and work that your team has taken time to estimate.

The Forecasting Based on Velocity Of text box enables you to experiment with different values to see the effect that given values for velocity might have on delivering work. For example, you might be able to ask for additional funding from your customer to hire new team members and speed up the rate at which items are delivered. Or you might know that there are several upcoming holidays that will affect your team's ability to deliver. You can also click the velocity column graph in the upper-right corner of this screen to see your historical velocity for the preceding (and current) iterations.

The forecast lines are purely estimates. In order to actually schedule work for a given iteration, you can drag and drop it onto either the current or future iterations listed on the left-hand side of this view. When you drag and drop work onto an iteration, the value in the Iteration Path column is updated to reflect the assigned iteration, and the Iteration field is updated within the work item in Team Foundation Server.

Teams practicing Kanban will be familiar with the Cumulative Flow diagram visible on the upper right of the product backlog page that was introduced in the 2012 Update 1 release. This diagram shows you how your backlog items are moving through their state transitions over time. It shows up to 30 weeks of data and is an easy way to visualize how your team is working, highlighting any bottlenecks.

Note

Even though you have assigned work to a particular iteration, it continues to show up in your product backlog until you have transitioned the work item to a state that shows it is in progress. For the Scrum process template, work is considered to be in progress when it reaches the Committed state. By convention, most teams typically wait until they have broken work down into child tasks before they transition it to a Committed state. Next, you find out how to break work down.

Agile Portfolio Management

If you are familiar with Team Foundation Server 2012, you'll notice a few new additions to the backlog page in the 2013 release to support the new portfolio management functions.

Click the On/Off link next to the Mapping label below the graphs to toggle mapping of backlog items to features. A Features panel will open on the right of the screen, enabling you to drag backlog items into features to group them.

You will also notice a link next to a View label in this section. Clicking the link expands a drop-down with various views of your backlog. The text in the drop-down options and the views they trigger varies between process templates, but there is some consistency. The first option will show you a flat view of your backlog items. The subsequent views will show you hierarchical views. For example, if you are using the Visual Studio Scrum 2013 process template, you will be able to see the Backlog items to Features hierarchy, or the Backlog items to Tasks hierarchy.

Note

When you're on the Backlog items page, Team Web Access will only give the option of forecast lines if you're viewing a flat list of items. To see forecast lines, you must choose the basic view.

Team Web Access introduces an entirely new Features page accessible via the link on the left of the page. The Features page is very similar to the backlog page but it allows you to manage the work items above your backlog items in the hierarchy. You can switch between various views in a similar way to the Backlog items page. In the case of the Visual Studio Scrum 2013 template, you can see a flat list of Features, Features to Backlog items, or even Features to Tasks, which shows you two levels of hierarchy.

Note

In Team Foundation Server 2013, the backlog board has been moved. In the previous release, the board was another option under the top-level Work hub. The backlog board can be considered another view of the Backlog items page so it exists as a link at the top of the page. This is consistent with the board for an Iteration, and the board for Features.

Planning Iterations

After you have identified the work that you want to deliver for a given iteration, you can click an iteration from the list on the left-hand side of the product backlog view to open the iteration planning view shown in Figure 14.8. This figure shows an iteration that is mid-sprint, meaning that the team has already completed some work and is preparing to finish this iteration.

Figure 14.8 The Iteration Backlog view

When you first add items to an iteration (such as a Product Backlog Item or a Bug) you are only declaring your intention to deliver this functionality. The next phase of planning this work is to actually break it down into the individual tasks that people on your team need to complete in order to perform the work. When you hover over a Product Backlog Item, you can click the plus (+) sign that appears to display the dialog box shown in Figure 14.9, which enables you to add a new task work item as a child to the parent you clicked on.

Figure 14.9 New task dialog box

You should provide a title for this task and, if possible, an estimate for the amount of remaining work. By default, remaining work is assumed to be provided in hours, but you can also customize this (see the section “Customization Options” later in this chapter). You can assign this to a team member who will complete this work, but you are not required to do so. Save this work item and proceed to break down the rest of your work into child tasks. If you haven't already done so, set the state of parent work items to Committed as each item is broken down.

Note

A common question that many people have is about the relationship between effort, provided earlier when defining an item for the backlog, and remaining work, provided for tasks. Effort is typically a rough estimate used to provide a quick indication about the size of work in relation to other items on the backlog. Remaining work values in your iteration should be much more precise, and represent the additional level of planning and estimation analysis that has been given to considering how a given feature or user story will be implemented. As a team gains experience, it becomes better at providing more realistic estimates while the product backlog is being defined.

As you begin to create tasks with values for remaining work, you will notice that the capacity graphs on the right-hand side of this screen begin to render. These graphs are broken into three areas:

· Work—shows the total amount of work remaining for this iteration, calculated as the sum of the remaining work across all task work items.

· Work By: Activity—enables you to categorize the amount of remaining work into categories. When creating tasks, you can use the activity field to categorize tasks, such as Development, or Testing, and so on. If you don't provide a value for activity, work simply shows up as Unassigned.

· Work By: Assigned To—shows the amount of remaining work that is assigned to each person on your team.

Click the Capacity tab to assign the capacity for each of the members of your team, as shown in Figure 14.10. The Capacity Per Day column enables you to specify the average number of hours per day that a given resource is working on tasks. The Activity column enables you to specify the discipline of a team member, which is necessary if you want to view capacity by activity type. Finally, you can use Days Off to define days that a team member is sick or on holiday, and you can use Team Days Off to define days that the whole team will be unavailable, such as during a holiday or company retreat.

Figure 14.10 Capacity planning for iteration

The values you enter for this table are specific to this team and this iteration. So a shared resource who works on multiple teams might have different values for Capacity Per Day or Days Off depending on the team. Also a resource who works five hours per day on one iteration might work only two hours per day during a subsequent iteration. If you like the capacity settings for the team from the previous iteration or just like a quick start, you can even copy those values by clicking Copy Now to copy capacity from the previous iteration tool, as shown in Figure 14.10.

After you assign capacity values for your team, the capacity indicators on the right change to either green, if a resource is at or under capacity, or red, if there is too much work given the planned capacity. The iteration plan is designed to be viewed on a regular basis so that you can make adjustments to the plan as needed. For example, if a team member is sick, you might need to reschedule work that was originally planned for this iteration. You can drag and drop parent items from this list onto other iterations on the left-hand side of the page.

Tracking Work

When you are satisfied with the iteration plan, it's time to start writing code, authoring documentation, designing user interfaces, and doing all the other work that's required to develop great software. During the course of this activity, it can be helpful to have a single location to easily determine the status of the work that everybody is doing.

Scrum teams typically use a task board for this purpose. In its simplest form, a task board takes the form of a whiteboard with sticky notes on it that you move from the left side of the board (work that is not yet started) to the middle (work that is in progress) to the right (completed work). Similarly, Kanban teams often use these boards to help visualize the flow of backlog items through various phases.

Physical boards work very well for teams that are co-located, especially if they share a team room, because anybody can quickly look up at the whiteboard to determine the state of the team's work. Of course, this approach has its challenges for teams who work in different geographic locations, have individual offices, or even spread across multiple floors or buildings.

Team Foundation Server 2013 provides digital versions of these boards that overcome the limitations imposed by traditional physical boards. There are Kanban boards available for managing Features and Product Backlog Items, and task boards for managing individual Iterations.

Using the Kanban Board

To view a Kanban board, choose either the Features or Backlog items view, and then click Board at the top of the page. The boards are very similar; they simply show different types of work items. Figure 14.11 shows a Backlog Kanban board. The board consists of tiles that represent individual Product Backlog Items or Features, and columns that represent the progress of each item.

Figure 14.11 Kanban board

To change the state of a backlog item or feature, you can drag and drop the tiles to move them between columns, provided the process template transitions allow you to do so.

Warning

Moving a Feature or Backlog item from one column to another does not affect the children of that work item. To mark a backlog item or feature as completely “done,” you need to ensure all child work items have an appropriate completed status.

A key concept in Kanban is limiting work in progress. This means that a team should not have too many items in one column, as this represents a potential bottleneck. With the exception of the first and last columns (which represent brand new and completed work items, respectively) you will see two numbers in the column header. These represent the number of backlog items currently in the column, and the “work in progress limit” assigned to that column. You will see how to customize the work in progress limit soon. InFigure 14.11, you can see the team has committed to more items than the work in progress limit for the Committed state. Team Foundation Server will not prevent you from committing to more items, but it will alert you by coloring the header red.

By default, the columns map one-to-one with the available states for the work items. You can click the Customize columns link to add additional columns with the Customize Columns dialog box shown in Figure 14.12.

Figure 14.12 Customizing columns

The Customize Columns dialog box allows you to add and remove columns using the plus (+) signs between columns and the crosses at the top right of each column respectively. You also can change the display name of a column, change its work-in-progress limit, and change the work item state that that column maps to.

This feature allows you to manage your portfolio or backlog in more detail than your process template may allow. Teams can take advantage of this feature to temporarily introduce columns for situations such as external audits, deployment or test processes, or even code reviews.

Note

Changes you make using the Customize Columns dialog box are local to that Web Access board and do not change the available states for the process template. New columns represent pseudo-states that will not be available for selection when changing the state of a work item, and name changes will only be shown on the board.

Be careful when adding and removing pseudo-states as they will show in the Cumulative Flow graph if at least one work item has moved into that pseudo-state at any point in time. If you are frequently adding and removing pseudo-states, your Cumulative Flow graph can become very messy.

Using the Task Board

Agile task boards will be familiar to anyone coming from Team Foundation Server 2012, but there have been some useful changes in this release. To view an individual iteration's Task board, select an Iteration and then click Board at the top of the page to see a task board like the one in Figure 14.13.

Figure 14.13 Agile task board

Each row on this task board represents a parent backlog item from your current iteration. The tiles on this task board represent the individual child tasks that you created. Each task begins in the To Do column. When a team member is ready to begin a task, he or she can drag and drop it onto the In Progress column. As the team member makes progress against a given task, he or she can click the number on the task to update the remaining work. If he or she has finished a task, he or she drags it into the Done column to automatically set the amount of remaining work to zero. Clicking the name of the team member for a given task opens a drop-down menu that enables you to quickly reassign work. Similarly, clicking the number of hours remaining opens a drop-down menu allowing you to change the remaining hours.

Click a task to open it in a full editor, such as the one previously shown in Figure 14.9. This is often helpful if you want to add more detail to a task or comment on its progress.

Note

The task board understands the rules and limitations of the underlying process template your team project is based upon. For example, consider a scenario where you have prematurely moved a task from In Progress to Done—perhaps by mistake, or perhaps you realized there is additional work that needs to be finished. If you try to move work from the Done column back to the In Progress column, you receive an error message indicating that work that is In Progress cannot have a value of 0 for remaining work. To fix this, click the task to open the full editor and assign a new value for remaining work.

The entire interface is touch-friendly. If you have a touch-screen monitor, such as in a shared team room, you can configure it to display your task board and make it easy for team members to update the status of their work whenever they walk by it. And because everything is stored in Team Foundation Server, remote workers can access the same view in any modern web browser and device to see what their colleagues are working on and provide their own status updates.

If you find yourself constrained for space in this view, you can collapse finished backlog items by clicking the arrow to the left of the parent work item title. You can also use your browser's zoom functionality (usually Ctrl plus a hyphen or a ++ sign) to fit more work on a single screen.

You can change the view to focus on individual team members by clicking the Person: All link and selecting the name of any team member. This highlights the work assigned to that team member, making it easier to differentiate from the rest of the team's work.

You can also click the Group By: Backlog items link to change the view such that tasks are organized by the team member they are assigned to, instead of by their parent work item. This is a helpful view for team meetings, where team members might be expected to tell their peers what they worked on yesterday and what they are planning to work on today. This view is also helpful for seeing whether there are any team members with too much work remaining and whether other team members might have the capacity for picking up some of that work.

As work is finished, the team can transition parent backlog items to a state of Done. Open a parent backlog item by clicking the title of the item on the left-hand side of the screen. This state transition is not done automatically when all of the tasks are finished because there may be additional checkpoints or quality gates in place before work is considered to be truly finished. For example, you might want to request feedback from your project's stakeholders to ensure that everybody is satisfied with the work as it has been implemented. You will explore requesting feedback from stakeholders later in this chapter.

The burndown chart in the upper-right corner of this screen displays a trend of the remaining work over time for your iteration. This chart is updated in real time as your team completes work (or identifies new work) during the course of an iteration. You can display the burndown chart in full screen by clicking it, as shown in Figure 14.14.

Figure 14.14 Burndown chart

Customization Options

As mentioned previously, the examples in this chapter follow the default experience you get by using the Visual Studio Scrum 2013 process template for a team project. If you are practicing Scrum today, then you are likely already familiar with the types of tools available in this chapter. But even if you aren't practicing Scrum or using the Scrum process template, you can still benefit from these tools.

Depending on the process template you choose, the default terminology and views might vary. For example, a team using the MSF for CMMI process template tracks Requirements instead of Product Backlog Items as the primary backlog work item type to be planned. An MSF for CMMI Software Improvement 2013 task board contains four columns (Proposed, Active, Resolved, and Closed) instead of the three shown earlier for a Scrum project (To Do, In Progress, and Done).

If you are using a team project that was created using one of the process templates provided by Microsoft with Team Foundation Server 2013 (Scrum 2013, MSF for Agile 2013, or MSF for CMMI Process Improvement 2013) then this tooling is preconfigured automatically to work with your team projects. If you are upgrading an existing team project from an earlier release of Team Foundation Server, then you need to perform some additional steps in order to begin using the agile planning and tracking tools mentioned in this chapter. These steps are outlined at http://aka.ms/TeamProjectUpgrade2013.

Note

Upgrading from previous versions of Team Foundation Server is covered in more detail in Chapter 27.

There are also several ways you can customize these tools to change their appearance and behavior. For example:

· Add or remove fields from the “quick add” pane in the product backlog view. For example, in addition to setting a title, you might also want to specify an effort estimate with each new item.

· Change the available states for work items in the feature, backlog, and iteration boards.

· Change the list of activities that task work items and team members can be assigned to.

· Change the working days to be used when calculating capacity and rendering the burndown graph. By default, Saturday and Sunday are considered nonworking days, but you can modify these.

· Configure the types of work items to be used as parents and children throughout the tooling.

· Change the color used for different work item types in the backlogs and boards.

The types of customizations and other process template customizations are covered in more detail in Chapter 13.

Team Rooms

Team rooms are a new feature in Team Foundation Server 2013. A team room provides an online area that encourages and captures communication between team members, regardless of their physical location. Team rooms are created for each team defined in a project, but you can create additional rooms for any purpose.

On your team's home page, you will see a tile showing the number of people currently in your team room. To open a team room, click the room tile. Figure 14.15 shows an example team room interaction.

Figure 14.15 Team room

The main area of the page shows the conversation between team members as well as any Team Foundation Server events that team members have chosen to be notified about. You can change the date you are looking at using the calendar links at the top of the page. Contributing is as easy as typing in the “Post a message” text area and pressing Enter. Messages are primarily text, but can be enriched in a number of ways.

Clicking on the smiley face icon gives you access to various emoticons. These will also replace known character combinations in your message. For example, :( will be replaced by a face with a frown.

You can mention a specific team member using the @ character, and when you type @, a drop-down will appear to help you choose valid members. As a team member, you will be notified if you're mentioned in a message, and your name will appear with an orange background and border, as in Figure 14.15.

Finally, you can link directly to any work item using the # character. In Figure 14.15, you can see a link to work item #230. This is a rich link that can be clicked on to view and edit the work item details.

Note

Team rooms are only officially available in Team Web Access, but a Visual Studio extension has been created by MVPs Utkarsh Shigihalli and Tarun Arora. You can download the extension at http://aka.ms/VS2013TeamRooms.

On the left of the page, you will see all the rooms you have permission to enter. You can click on any of these to enter the room and start chatting with the other members of your team.

On the right side of the page, you can see everyone who is currently in the room. You can also click the small arrow next to Away to see people who have access to the room but are not currently present. Finally, you can manage the users who have access to the room and the Team Foundation Server events that will be surfaced in the main chat area.

To invite other Team Foundation Server members to a team room, click on the Manage users link. This dialog box allows you to add individual users or entire teams to the team room.

Team rooms can also surface Team Foundation Server events such as the check-in and build failure visible in Figure 14.15. To manage the events that are shown, click the Manage events link. You will see a dialog box with four categories of events, as in Figure 14.16.

Figure 14.16 Configuring team room events

This dialog box enables you to subscribe to multiple events for build completions, code changes, work item updates, and code reviews. You can further filter these to only members of the room, and in the case of work item updates and code reviews, restrict them to a specific area path.

Stakeholder Feedback

You have learned about the importance of engaging with your software development project's stakeholders to ensure that you have a clear understanding of what your stakeholders want you to build before you start implementing it. However, regardless of how much time you spend up front during this requirement's elicitation phase, the first iteration of software you create is rarely going to meet all of their expectations.

There are a variety of reasons for this: Technical challenges might get in the way of the originally planned implementation; business requirements may evolve from the time when you first captured them to the time that you implement the first working code; the opinions of users can be fickle, even influenced by seeing the software in action for the first time; you may not have truly understood what your stakeholders were asking for when you were capturing their requirements; or, you may not have had time to implement all the requirements in the initial release.

These possibilities will be anticipated by any agile software development team that embraces the fact that software development is something of an art form, requiring iterative cycles of requirement gathering, implementation, and feedback, which in turn informs an additional round of requirements and changes that must be implemented. However, the challenge for any team is in finding a way to effectively capture feedback from its stakeholders in a manner that can be analyzed, synthesized, and acted upon. This problem is made harder when stakeholders are time-shifted or geography-shifted away from the software development team. Even if the development team shares a common location with its stakeholders, finding a systematic way of gathering feedback from all of its stakeholders on a recurring basis can be a burdensome task.

In Visual Studio 2013, Microsoft has integrated the process of collecting stakeholder feedback directly into its application life-cycle management tooling capabilities. In this chapter, you find out how to use this tool to solicit and capture feedback from your stakeholders in a rich, actionable way.

Requesting Feedback

The first step toward getting great feedback from your stakeholders about your software is to properly frame the question of what you are asking for feedback on. The question of whether or not your software provides the right level of functionality is a very different question from whether or not your software is designed properly. Functionally, a tractor can get you from your house to your office in the morning, but it is probably not what you feel comfortable being seen in as you pull into the parking lot at work. But early on in a software development iteration, the team may be focused squarely on strictly implementing the required functionality with the understanding that it can make it look nice later on. Unless you properly scope your request to the stakeholders when you ask for feedback, you may get a lot of feedback on things that you haven't yet started to address in the software.

With Team Foundation Server 2013, you can request specific feedback from your stakeholders by visiting the Team Web Access home page for your project or team. In the list of Other Links, click Request feedback. You are presented with the dialog box shown inFigure 14.17, which allows you to specify what you are requesting feedback on and from whom.

Note

If you don't see Request Feedback under the list of activities, this indicates that your Team Foundation Server instance has not been configured to use an SMTP e-mail server. Your Team Foundation Server administrator will be able to configure this using the Team Foundation Administration Console on the application tier server.

You will also need to ensure that your user account has appropriate licensing access level to request feedback. Only users with Visual Studio Test Professional 2013, Visual Studio Premium 2013, or Visual Studio Ultimate 2013 are permitted to request feedback using this capability. This can be configured using the Administration features of Team Web Access, as described in more detail in Chapter 24.

Figure 14.17 The Request Feedback dialog box

Follow these steps in the dialog box to request feedback from your stakeholders:

1. Specify the names of the users you want to request feedback from. These users need to be recognized as users who have access to your team project.

2. Specify how users should access the functionality you are asking them to test. For a web application, users might need to access a staging server (potentially in a Lab Management environment) that contains a recently deployed build. For other applications users might need to remote into another machine or install an interim build. Use this space to give the users any specific instructions they need in order to get started with your software.

3. Specify up to five aspects of your software that you want feedback on.

When specifying what you want to collect feedback on, be as specific as possible. You can also use the area below each feedback title to provide additional instructions that might help your stakeholders access certain features or scope their feedback to what you care most about. When applicable, you might want to also specify the things that you do not want feedback on. For example, if you know that the staging server you are using is very slow and doesn't reflect the performance of your production environment, then you might want to mention this to the users so they don't waste time giving you a lot of feedback on the performance of the application. If the user interface hasn't yet received attention from a designer (affectionately known as “programmer art”), be sure to specify this as well, so users don't spend time critiquing anything other than the application's functionality. The 2013 release of Team Foundation Server added rich text capabilities to the feedback fields to allow you to highlight important points.

After you have told your users how to access your software and what you are looking for feedback on, click Preview to see the e-mail that your stakeholders will receive. Click Send to deliver an e-mail to the stakeholders you specified earlier and also create Feedback Request work items (up to five, one for each item you added in Step 3) for you to track this request in Team Foundation Server.

Providing Feedback

After you have requested feedback from your stakeholders, they will receive an e-mail like the one shown in Figure 14.18. Before stakeholders can provide feedback, they need to first install the Microsoft Feedback Client by clicking the Install the Feedback Tool link in the e-mail.

Note

The Feedback Client is freely downloadable from Microsoft and does not require a Team Foundation Server client access license. Users will, however, need to have appropriate permissions to your Team Foundation Server instance. At a minimum, users will need to be a member of the Limited access level group. See http://aka.ms/TFS2013FeedbackPermission for details.

Figure 14.18 Request feedback e-mail

After the feedback tool is installed and stakeholders are ready to give feedback, they can click the Start Your Feedback Session link in the e-mail to open the Feedback Client shown on the left side of Figure 14.19. The menu at the top enables the stakeholders to dock the Feedback Client on either side of the monitor or to float the window to another monitor. The instructions provided on this first page are from the feedback request that you created earlier. After the stakeholders have installed or otherwise launched the application for which they are providing feedback, they can click the Next button to start giving feedback.

Figure 14.19 The Feedback Client

Figure 14.20 shows a stakeholder in the middle of providing feedback on this web application. The top half of the Feedback Client scopes the specific questions the stakeholder has been asked to address. In this case, you asked if the right information is displayed in the summary table. The stakeholder responded by asking if an Employee ID column can be added to this table. The stakeholder then used the Screenshot button to capture a snippet of the table and double-clicked that snippet so that he could annotate it with a red rectangle showing where the Employee ID column should go.

Note

By default, Microsoft Paint is used to edit a screen clipping any time the user double-clicks within the Feedback Client. You can configure the Feedback Client to use your own favorite image-editing tool by clicking on the gear icon at the top of the window. For example, if you want to make annotations with a tool like SnagIt, you can configure it as your tool of choice. For more information, take a look at http://bit.ly/VSFeedbackwithSnagIt.

Figure 14.20 Providing feedback

The Feedback Client can also be used to capture video and audio recordings while the stakeholder is using the application. This can be the next best thing to actually being in the room, watching over the shoulder of the stakeholder as he or she uses the application. A video recording can be a powerful way of truly understanding the way in which a user tends to interact with your software. Audio annotations enable a stakeholder to provide commentary about his experience without having to take the time to type notes. Video and audio contextualize the feedback you get from your stakeholders so that you can better understand how to respond to it.

After a stakeholder is finished providing feedback on a particular feedback item, he or she can provide a star rating before clicking Next. If there were other feedback items specified in this request, the stakeholder would now be prompted with each one sequentially. At the end of the feedback session, the stakeholder has an opportunity to review the feedback he or she has captured before submitting it to Team Foundation Server. This creates new Feedback Response work items (one for each Feedback Request, which was created earlier), which include all of the artifacts captured by the Feedback Client (video recordings, text and audio annotations, screen clippings).

The software development team can view the feedback responses using the built-in Feedback work item query (see Figure 14.21). If a piece of feedback results in a new bug or new requirement, the team can use the New Linked Work Item button to create a new work item linked to this specific Feedback Response work item. By linking the feedback directly from the stakeholders into the new work item, you can provide additional context and traceability for the developer who is assigned to implement the fix or new requirement specified in that work item.

Figure 14.21 The Feedback Requests work item query results

As feedback is reviewed and any necessary actions have been taken (such as fixing bugs or implementing requirements), you can transition the State field of each Feedback Response to Closed.

Voluntary Feedback

Stakeholders can also provide unsolicited or voluntary feedback at any time by launching the Feedback Client directly instead of from a feedback request e-mail. They are first prompted to connect to the appropriate Team Foundation Server instance and team project where they want to provide feedback. After doing so, they can file feedback using video, audio, text, and screen clippings as they did previously. The one thing to be careful of here is that Feedback Response work items created when using a voluntary feedback method do not show up in the default Feedback Requests work item query. Instead, you should write a custom query to search for all work items of the type called Feedback Response. Feedback that is generated by the Feedback Client in an unsolicited manner will, by default, have a title that starts with Voluntary.

Summary

In this chapter, you discovered the new tools available with Team Foundation Server 2013 for planning and tracking work in an agile manner. You found out how to use the product backlog view for defining and managing items that your team may schedule and implement in the future, as well as the new feature hierarchy available in Team Foundation Server 2013. You then saw how to break down work for an iteration into tasks and examine the remaining work for these tasks against the capacity of your team.

You also learned about using the digital boards to track work during the course of a project and an iteration so that everybody on the team can easily understand what their colleagues are working on and how much work is left to deliver.

You learned about the new team rooms that facilitate communication between team members and notify them of Team Foundation Server events, regardless of where they are. You saw how to subscribe to relevant events so the team can see what is happening with your server at any time.

You learned how you can request scoped feedback from your stakeholders to get actionable data that can help you refine your application development. You learned about the new Feedback Client that can capture rich information—including video recordings, text and audio annotations, and screen clippings—from your users as they give feedback about your applications. Finally you learned how you can use this feedback to create actionable bugs or new requirements that your team can use to ensure that you are continuing to build the right software to please your stakeholders.

In Chapter 15, you will have the opportunity to learn about the rich reporting features of Team Foundation Server 2013 as well as collaboration integration with team portals hosted in Microsoft Office SharePoint Server.