January 2009

Volume 24 Number 01

VSTS 2010 - Agile Planning Tools in Visual Studio Team System 2010

By Ajoy Krishnamoorthy | January 2009

This article is based on a prerelease version of Visual Studio Team System (VSTS) 2010. All information is subject to change.

Contents

Long-Range Planning
Release and Iteration Planning
VSTS 2010 Excel Workbooks
Product Backlog Workbook
Capacity Planning
Iteration Backlog Workbook
Reports

Is "agile planning" an oxymoron? I hope you don't think so, but in a recent focus group that took place in Los Angeles, one of the attendees indicated that her organization had moved from being agile to adopting more formal practices. When quizzed further, she said her team can no longer make a code fix based on a verbal request from her manager and then immediately deploy it to production. Now she has to follow a formal procedure. To her, this meant moving away from being agile.

However, her understanding of agile development is incorrect, and I am glad her organization instituted a formal process for change. Agile is not about flying blind or being nimble for the sake of speed. Rather, it is a disciplined approach to planning and one that factors in empirical data.

Visual Studio Team System (VSTS) 2010 introduces new features and capabilities to help agile teams with planning. In this article I will introduce you to the new product backlog and iteration backlog workbooks and a set of new reports that will help agile teams plan and manage releases and iterations.

Long-Range Planning

The concern of not having a long-range plan with precision is a common one and the one that is raised as a key barrier to adoption. In the 2008 State of Agile Development Survey, lack of advanced planning was the number-one concern in regard to adopting agile practices in respondents' organizations. For many, I suspect lack of long-range, precision planning is equated to lack of planning altogether. Agile teams opt for multiple levels of planning with course corrections over a waterfall-style plan, and rightly so.

Steve McConnell, discussing his Software Estimation Cone of Uncertainty, suggests that estimates done early in the project could be inaccurate by as much as 400% with the error leaning toward the high side: "Early in a project, specific details of the nature of the software to be built, details of specific requirements, details of the solution, project plan, staffing, and other project variables are unclear. The variability in these factors contributes variability to project estimates."

Of course, none of this means the executive management will go with a strategy of "we don't know when the project will be done and what will it look like when it is done." What it means instead is a change in the approach to how teams go about planning releases and the scope of the work completed in the releases.

Figure 1 Product and Iteration Backlog

Release and Iteration Planning

For agile teams, planning is done at two distinct levels: release planning and iteration planning. Release planning is a high-level planning activity that helps agile teams review the broad set of features or user stories. The items in the backlog are then stack ranked, estimated, and assigned to a set of iterations. Note that at this stage, the estimation is done using a unit such as a T-shirt sizing (small, medium, large). The intent at this point is to get a rough order magnitude of cost for the various items on the backlog and not a precise quote. This also helps the customer stack rank the requirements with the approximate sizing in mind.

In Scrum, this set of user stories is kept in a list called product backlog (see Figure 1). The scope of work to be tackled in each iteration depends largely on team velocity. What defines a release largely depends on when you have a credible set of requirements done according to the customers. For instance, if it takes four iterations to get the first set of features, then the first release will be scheduled after the fourth iteration.

Iteration planning is a much more detailed planning activity and the one takes place prior to the start of every iteration. High-level user stories from the product backlog are reviewed and are broken down in to smaller user stories as appropriate. At this point, the team is ready to break down user stories into smaller stories and define the tasks that are required to complete a user story. These user stories and associated tasks are then estimated in hours. At this point the team can understand the scope of an iteration.

Microsoft Office Excel is a tool you will often find in an agile team's toolbox along with index cards and sticky notes. VSTS 2010 introduces two new Excel workbooks to help agile teams manage the product backlog and iteration backlog. But let's take a quick look at the new Agile process template with VSTS 2010 before jumping right into the workbooks.

A process template in VSTS includes work item types, queries, reports, and textual guidance. Work items are the key entities here. Work items could be a user story, a task, a bug, and so on. To get started, you set up a team project in Team Foundation Server (TFS) and choose the VSTS Process for Agile Software Development v1.0 template in the New Team Project Wizard. This template includes the following Work Item Types:

• Task
• User Story
• Bug
• Issues
• Test Case

You can create your own work item type or customize the particular work item itself. Learn more about work item customization in Brian Randell's December 2008 article on using and customizing TFS process templates, "Team System: Streamline Team Projects with Process Templates."

Now let's delve into the Excel workbooks and look at how these work items flow through the development process and aid in planning and managing flow of value.

VSTS 2010 Excel Workbooks

In the paper titled "Tools for Agility," Kent Beck talks about transitions galore in agile teams and the need for tools to take transitions into account. The integration of Excel-based planning workbooks with TFS work item tracking aids in minimizing the transition overhead. From keeping the product backlog and iteration backlog synchronized to automatically capturing the update to the status of a user story or a task work item into the iteration backlog to generating the wealth of reports, many of the mundane activities are either eliminated or optimized.

Here is a suggested flow that an agile team might use to manage the product backlog and iteration backlog with VSTS 2010:

• Create a new team project using the VSTS 2010 Agile template.
• Build the product backlog by adding user story to the product backlog worksheet or by adding work items from within Visual Studio.
• Start assigning the items based on their stack rank in the product backlog to an iteration. By default, Iterations 0, 1, and 2 are created. You can create additional iterations using the team project settings.
• Set up queries to pull the user stories, tasks, and other items from particular iterations and map them to corresponding iteration backlog worksheets.

The integration between these worksheets and TFS is accomplished using the queries. Figure 2 shows the configuration for the product backlog worksheet. In the Excel ribbon, on the Team tab, in the Work Items group, click on Configure List. This opens the Configure List Properties dialog. In this dialog, you can choose a TFS query and the result of this query is what you see in the spreadsheet.

Figure 2 Query in Excel Worksheet

The queries are created in the team project. By default, when you set up a team project, a folder called Work Items\Team Queries\Workbook Queries is created. Under this folder, you will find the default queries for product backlog and iteration backlog workbooks.

To get a better idea of how the workbooks operate, let's take a look at the DinnerNow sample application included in the October 2008 VSTS 2010 and .NET Framework 4.0 CTP. (You can find the latest CTP download on the Team Suite Developer Center.) Both the product backlog and iteration backlog workbooks can be found in the \DinnerNow\Documents\Shared Documents folder in Team Explorer.

Product Backlog Workbook

Product backlog primarily serves as a list of requirements desired by customers in an application. I have heard terms such as epics or themes used by teams when referring to the set of high level requirements. Collecting this set of requirements in a list, prioritizing them, and estimating them at a high level helps answer two important questions at this stage of the planning:

1. 1.What are the requirements of the application?
2. 2.How much it is going to cost? Obviously the answer to this is based on estimates. I have seen teams use story points, T-shirt sizes, or hours to estimate at this stage.

In answering these questions, the teams can get a good handle on what the release or next few releases might look like and when those releases can be scheduled. There is usually a budget or schedule constraint, such as an upcoming ad campaign, a legal requirement, or seasonal activity. This helps to plan the scope of the release as you can manage the scope of the release based on the constraint.

If there is a target date set for a release, the scope of work is managed by deciding which requirements to include in the iterations within the release time frame. For instance, if planning begins in December and the release date is set in June, you are essentially looking at running four to five iterations (assuming one-month iterations) to complete the work.

If there is flexibility with the target date, the release schedule will depend on when a minimum set of requirements could be completed. For instance, if a minimum set of required features could be completed in three iterations, then Release 1 could be set after three iterations. If the next set of features could be completed in five or six iterations, then Release 2 would be set to go after those five or six iterations.

Figure 3 shows the product backlog worksheet for the DinnerNow project. What you are looking at is a backlog of user stories. Several of these user stories are already assigned to a particular iteration and some of them are already completed in Iteration 0 and Iteration 1. Obviously, when you are beginning a new project, you will start with a blank workbook and start building these high-level user stories.

Figure 3 Product Backlog Worksheet

The columns on these spreadsheets are the fields in the work item which, in turn, get stored in the TFS data store. The integration between Excel and TFS adds a Team ribbon in Excel (see Figure 4) that has menu items to publish the items in the backlog into TFS, refresh the backlog with updated work items in TFS, and more.

Figure 4 Team Tab in Excel Ribbon

Each row in the backlog is stored as a work item within TFS as shown in Figure 5. With this type of integration, team members who are using Visual Studio can now update the user story and other work items from within Visual Studio itself. Updating the status of a user story, the estimate, or the remaining work, can now be done without having to switch between different tools.

Figure 5 Work Item in TFS

Capacity Planning

As part of the release planning, agile teams will spend a good deal of time in the spreadsheet adding new user stories, estimating these user stories, and, more importantly, prioritizing them. But it's equally important to keep an eye on the status of the release. The product backlog workbook includes a worksheet for capacity planning. This worksheet helps you get a quick handle on the iterations themselves, based on the estimates of user stories and the iteration in which their work is assigned.

The capacity planning is an important activity in planning releases. This helps in understanding the features that can be completed in the various iterations. The key data point in this calculation is velocity. Velocity is the amount of work being completed by the team in an iteration. If you happen to have data from prior iterations, that is the best place to start.

Figure 6 Using Previous Iterations to Calculate Velocity

This is generally referred to as "prediction based on yesterday's weather." In fact, the capacity planning spreadsheet can pull the historical data from the TFS data warehouse if it is available. As seen in Figure 6, I can select Iteration 1 as the iteration to get historical data from and key in the data for start date, end date, and number of team members. In this case, I get a velocity of 816 hours, which means the team was able to complete 816 hours of work in Iteration 1. Shy of that data, teams can start with an estimate and use the velocity of the first iteration in planning the future iterations.

In the capacity planning spreadsheet, you can specify the date range for iterations, the number of team members, and any interruptions during the iteration, such as holidays. This data, combined with the user story estimates and velocity, creates a chart that gives a sense of what the iteration work load looks like. If you see estimated work exceed the expected capacity bar, then you'll want to move around user stories between iterations to get to a favorable allocation.

In my case, I do not have any work planned in Iteration 2. I can add a few of the remaining user stories in the backlog to Iteration 2. Now the capacity chart looks like Figure 7. This is a good situation to be in—the estimate work has not exceeded the capacity.

Figure 7 Capacity Chart with Work Assigned for Iteration 2

The product backlog worksheet can also be used to get a picture of the overall status of the various user stories once the project is in flight. But you can get a lot more information from reports such as Burndown and Velocity, Remaining Work, and Stories Progress. These reports are included in the Agile template and will be found in the Report folder under the team project. I will cover the reports later in this article.

Iteration Backlog Workbook

Iteration is a key activity for an agile teams. Agile teams practicing Scrum are familiar with this by the term "sprint." The duration of the iteration typically varies. Teams using eXtreme Programming follow a one- or two-week iteration, whereas teams using Scrum typically follow a four-week sprint.

Iteration planning helps define the scope of a particular iteration. During an iteration planning meeting, teams typically analyze the user stories assigned for the particular iteration, gather detailed requirements, add associated tasks, and estimate how long it would take to finish each task. During this meeting, product owners along with the rest of the team prioritize user stories based on several factors: dependencies, cost estimates, detailed requirements, and possible evidence that a particular story is not as important as it was deemed during the release planning.

Let's start by looking at the iteration backlog in the DinnerNow team project. There are folders named Iteration 0, 1, and 2 under the Shared Documents folder in the team project. Within each of these iteration folders you will find the iteration backlog. Each of the iteration backlog worksheets are connected to a specific query that only brings that particular iterations user stories and tasks.

If you have added other work item types such as features, themes, or epics, then you will add them to this query so you get those additional work items pulled in the list. The DinnerNow team project already has several tasks that are added as child items to the user stories in Iteration 2. But typically, as part of the iteration planning meeting, teams will be adding tasks and estimating them to get a good iteration plan for Iteration 2. Figure 8 shows the iteration backlog.

Figure 8 Iteration Backlog with Child Tasks

TFS now supports hierarchical work items and that allows you to create parent/child trees. In this case, the following new tasks are added as child tasks to the user story "Users should be able to use DinnerNow from their cell phones":

• Identify which parts of the UI to use for the phone
• Use a card stack architecture for the UI
• Identify most popular phones
• Reduce number of keystrokes needed to place an order

At this point, the team is ready to go with the task assignment. How much work each team member picks up depends on factors including team member capacity for that iteration, domain expertise, and how long the team member has been part of the team.

Iteration backlog workbook has additional sheets to help with other aspects of planning and execution. The capacity planning worksheet is similar to the one in the product backlog workbook. You can use this worksheet to get a sense of team's capacity.

The load balancing worksheet comes in handy during planning and during the iteration itself. Agile teams continue their planning throughout the iteration to do course correction as new information comes available about a particular user story, when a technical dependency is discovered on a task, or when a team member becomes unavailable. These occurrences call for updating the task assignments and that's where load balancing worksheet comes to play.

Another interesting worksheet is the one provided for velocity tracking. Those of you familiar with sport of cricket will recognize the terms current run rate and required run rate. These are two statistics used to get a good indication of how a team is doing in a match. In general, if the required run rate is higher than the current run rate, the team that is batting has to pick up the pace in order to avoid a defeat. On the other hand, if your current run rate is higher than required run rate, then the batting team is in good shape.

Before a cricket-savvy reader starts calling me on this, let me say that additional stats such as wickets down and remaining overs are important to get a complete handle on the status. And this is true in an agile project as well. The velocity tracking sheet gives you a quick sense of the current team velocity and the required velocity to complete the user stories in an iteration. Just as with cricket, other stats such as remaining days are important to get a complete status on where you are in the iteration. For instance, the team may have to cut scope if their current velocity is not in pace with required velocity. Again, the key is to be transparent about this to the customers and make the necessary adjustments as a team.

Reports

Of course, you don't have to become an avid fan of cricket to start managing projects with VSTS 2010. You can rely on reports to monitor a project's progress such as burn down and work remaining.

Figure 9 shows the burn down report for Iteration 1. A burn down report shows the hours of work completed, hours of work remaining, and the rate of progress. As you can see from the hours remaining in the chart, the team did not complete all the tasks allocated to this iteration.

Figure 9 Burn Down Chart

The trend lines show you this status as well. As you can see in the chart, the actual trend line indicates that the work won't be completed on time at this team's rate during Iteration 1. During the iteration, the team can watch the burn down and can make necessary course corrections and also let the customers know that the release plan might be affected.

The remaining work report is also quite useful. As you see in Figure 10, the team has been making steady progress in completing work. There is no additional work added to the backlog during this iteration which is a good sign. The team's progress tapered off towards the end of the iteration causing the tasks left unfinished.

Figure 10 Remaining Work

As you've seen, the agile planning tools and worksheets for VSTS 2010 provide the teams with an Excel front end and the integrated data store that captures and mines data from release planning to iteration planning and from test execution to build quality. This provides a great tool for both managers planning and managing agile projects as well as the developers and testers on the team—they can work together, assess progress, make changes as necessary, and manage the entire project. This integration eliminates many of the manual and monotonous activities that agile teams undertake to collect data and generate reports.

For a rather different, more mathematically based approach to advance planning, take a look at Dr. James McCaffrey's Test Run column in this issue.

Ajoy Krishnamoorthy is a Lead Product Planner with the Microsoft patterns and practices team. Prior to this, Ajoy was as a Senior Product Manager for Microsoft Visual Studio Team System. In this role, Ajoy was responsible for product management, strategy, and marketing. He has more than 10 years of consulting experience in a variety of roles including developer, architect, and technical project manager. You can check out his blog at blogs.msdn.com/ajoyk.