June 2011

Volume 26 Number 06

Agile Development - Make Agile Work for You in TFS 2010

By Chris Adams | June 2011

This is the story of one team’s road to Agile using Team Foundation Server (TFS) 2010.

In the Agile Manifesto, there are several keywords that highlight how Agile teams should work together. They include valuing individuals (and their interactions) over processes and tools. Teams use these values as one of the reasons for moving to Agile development, among others. In the past 10 or so years since the manifesto, various flavors of Agile were developed. I’ll talk more about a couple of options within TFS 2010 that offer the opportunity to adopt one of two flavors of Agile process templates, and how our team at Microsoft uses them.

The key focus of our software development team here at Microsoft when it was reorganized a few years back was to ensure we used tools that you, our customers, can use. This prevented us from utilizing internal tools that have existed for years at Microsoft. Our development team, which is in the Management & Security Division (MSD), is focused on building software that enables Microsoft to provide services to a breadth of users: IT users, IT administrators and engineers, and online service operators. In short, our team is potentially just like yours—building software that enhances or improves the businesses on which customers rely.

Prior to our adoption of Agile, we didn’t value customer feedback, had artificial boundaries between team members due to titles and were unable to deliver accurate status to our management team. If we didn’t change, our overall effectiveness would dwindle until we failed completely.

In our shift to Agile, we wanted to focus on interactions with one another, our customers and, finally, our process. Prior to this change, we spent time focused on the reverse—process, customers and then interactions. The result over the past two years is that our focus today is on empowering our team, restoring our focus on customers and executing on the right solutions at the right time. Let me share how.

What Worked for Us Might Work for You

We aren’t a unique software team. We’re a young team striving to develop the highest-quality software that leads directly to business value. None of us have been on this team for more than three years. And as I mentioned, we were struggling.

In March 2010, we decided that things had to change. We needed a system that worked with us, rather than against us, and allowed us to focus on delivering customer value. Beyond this, the system had to provide the ability to monitor and track progress at various levels throughout our team and our larger organization.

We wanted to develop in an Agile way, but we didn’t know how.

Our Introduction to MSF Agile Version 5.0

We were introduced to TFS 2010 early in the beta stage and decided to create one of our projects using Microsoft Solutions Framework Agile version 5.0 (hereafter MSF Agile for brevity). We were looking for a process template that would help us execute on our core objectives: enable effective product and sprint planning; focus on getting a rhythm to our development; and, most importantly, increase our interaction between developers, testers and program managers (PMs). The lifecycle (see Figure 1) provided to us in MSF Agile seemed to fit exactly what we were looking for.

Figure 1 The MSF Agile Process

MSF Agile provides several work item types (WITs) to help guide us into Agile. We first examined each WIT (as defined in Figure 2) to understand how to use them effectively.

Figure 2 Work Item Type Definitions in MSF Agile

A key point I’d like to make is, although we studied each WIT, we didn’t use all of them at first. Instead, we focused most of our attention on user stories, tasks and bugs. It wasn’t until several months later—or even a year later—that we started introducing some of the other WITs such as test cases. To date, our team still doesn’t use the issue WIT, but that doesn’t mean it wouldn’t work for you. Like many teams learning Agile, we used what we liked and discarded what we didn’t. The key point I want to make is that not everyone fully adopts Agile software development, and TFS 2010 provides this flexibility with the MSF Agile template.

Utilizing User Story WITs to Drive Business Value

We learned that an Agile team should spend significant effort on user stories, but we didn’t learn this overnight. At first, our user stories were quite large and spanned multiple iterations. They were more themes that drove tasks than user stories that drove incremental value.

After some time, we learned that a good user story has three key elements. First, there’s the title, which is a short reminder of what the story is about. Using a short title makes it easier for us to stack rank user stories because it’s easier to scan short titles. Second, there’s the description, written in the form “As a <type of user> I want <some goal> so that <some reason>,” which provides the context for the story. That is, why does it add value, and for whom does it add value? This is the customer value! Third, there’s acceptance criteria, the value of which we only learned later, when we switched over to the Microsoft Visual Studio Scrum 1.0 (Scrum 1.0 hereafter for brevity) process template. Acceptance criteria provides clarity to the team about what we planned to deliver.

As we matured in our adoption of Agile, we learned more about user stories and how to have key conversations with our stakeholders and customers. We couldn’t just focus on writing strong user stories. We also had to discuss whether our team had correctly stack ranked the user stories. This led to further growth as a team as we started having good, productive conversations with our customers about the order of our work.

Software teams such as ours often decide themselves what’s important. This is contrary to the Agile Manifesto, which emphasizes that everything is about the customer. To bridge that gap, we use the stack-rank field in the user story WIT to define the order in which we work on building value. This field drives the conversations with our customers and partners to ensure that our rankings are aligned with theirs. Using a simple TFS query, our stakeholders and customers can see an ordered list of work needing to be delivered to meet customer needs (this is also published on our dashboard, which I’ll discuss later).

Planning Iterations in MSF Agile

As a team, we wanted to overcome our past history of having features grow in scope or size with little or no warning. And we wanted to focus on value instead of features. We needed to accurately plan the work, allocate the right amount of resources and effectively take interruptions into account.

Work on Agile teams is divided into iterations of a fixed length. But how long should an iteration be? After some discussion, we chose four-week iterations because we didn’t think we could deliver “ship-ready” software in fewer than four weeks. A few iterations later, we discovered that it was hard to get all the work done in an iteration, so we tried switching to six weeks. However, this made the feedback loop with customers too long, so we switched back to four-week iterations. About 10 months ago, we switched to two-week sprints, which allow us to get feedback sooner.

After selecting the user stories that delivered the most value to our customers, we assigned them to iterations. Our team had to learn to focus on building small, incremental components rather than large, often monolithic, features. Smaller components gave our team the ability to estimate work at a more granular level, such as within five- to 10-hour increments. It also improved the effectiveness of our testers, as they often didn’t have long testing cycles because components were smaller.

For resourcing purposes, our team used to spend a significant amount of time focusing on the “design” of our features and the subsequent costs of building them. We replaced this in MSF Agile using story points for each story and then using the Original Estimate field to put a value on the work. We did this estimating using planning poker in our sprint planning (for more on planning poker, see planningpoker.com). Each day, we’d track our progress against our iteration goals by requiring team members to update their Completed Work and the Remaining Work fields (see Figure 3).

Figure 3 Managing Planning Estimates in MSF Agile

This is the basis for accurately tracking day-to-day work, and we found that we became better and more efficient as we progressed as an Agile team.

As our team matured, updating our work estimates daily became habit and part of our normal process.

Product Planning and Iteration Backlog Tracking Tools in MSF Agile

Using the Product Planning and Iteration Backlog workbooks in MSF Agile (see Figure 4), we were able to improve our ability to estimate the work we could take on and successfully complete.

Figure 4 Workbook Templates for Planning in MSF Agile

We weren’t discouraged by our failures during the early iterations—we just focused on improving. During iteration planning as a team, we assigned user stories to iterations using the Product Planning workbooks. We tried to have iterations set up prior to starting sprint planning to save time. (For more information on creating iterations, see bit.ly/lakyZA.) As we learned more about our team’s average velocity—how many story points we completed in previous iterations—we became better at balancing stories between iterations with some level of confidence we could finish by a specific date.

One of the most valuable parts of our transition to Agile is directly related to our use of the Iteration Backlog workbook. This workbook provides several Microsoft Excel tabs that help during iteration planning. I’ll discuss the purpose of each tab.

The workbook starts on the Iteration Backlog tab that shows your user stories and any subsequent tasks related to those user stories. This tab is bound to a TFS tree query, which allows you to easily see the user story and all the tasks as children in a familiar tree view (for more information on tree query types, see bit.ly/l0tv1K). You’ll need to update the query for each sprint so the first tab shows all items currently assigned to an iteration. You can manipulate data on this tab and republish it to the TFS server without leaving Excel, which is how we created the tasks under a user story during sprint planning (for more details, see bit.ly/lmPN4k).

The second tab, Area & Iteration, allows us to set Start Dates, End Dates and the Iteration path for our iteration, as shown in Figure 5.

Figure 5 Start and End Dates in the Iteration Backlog Workbook in MSF Agile

For complex projects, you can utilize the Area path to scope the workbook. As a smaller team, we rarely scope to this level. In a larger team with multiple areas, you’ll likely have different copies of the workbook for each Area path.

The third tab is Interruptions, which allows you to account for days off, such as vacations or holidays, when team members can’t contribute to your project. This tab, though, will only allow you to set interruptions for team members who are currently assigned a work item in the iteration. Thus, before moving to this tab, ensure that you’ve accurately tasked out the work and assigned team members to it (on Tab 1, the Iteration Backlog), otherwise you’ll have a blank list in the dropdown for team members.

Our team finds the fourth tab to be invaluable. Called Capacity, this tab provides information on over and under capacity for each team member based on the remaining work and days in the iteration. The Interruptions tab information, mentioned earlier, is taken into account on this tab.

The Capacity tab makes it much easier to load balance, by moving tasks between team members. This was what we lacked, as a team, prior to adopting Agile—the ability to do this reassignment early on instead of resorting to last-minute scrambling when it was often too late.

To calculate capacity, the workbook takes each team member’s overall daily capacity (hours per day) and multiplies this by the number of days remaining in the iteration. The net result, as shown in Figure 6, allows us to start from day one of the iteration (for example, iteration planning) knowing where we stand.

Figure 6 MSF Agile Team Capacity Planning

It’s a dynamic view that we examine in our daily stand-up. In the case of Figure 6, each team member is over capacity, leading the team to understand that it wouldn’t be possible to complete all the work planned in that iteration.

I put together a walkthrough of how to use the workbook, and I’ve shared more details on my blog at bit.ly/fZpzWx.

Making Team-Specific Customizations

The building of software isn’t always confined to a single team. In reality, multiple teams usually work together. The challenge of cross-team software development is the existence of different “team” processes. Some teams follow waterfall software development practices, while others use Scrum. The uniqueness of each team often leads to challenges, and our team certainly wasn’t isolated and able to avoid this. Instead, one of our first projects using MSF Agile required interactions between two teams using different iteration lengths and different styles, though both were Agile-based. This is where the flexibility of TFS 2010 aided our team, as it offers a rich and powerful ability to customize any WIT (or even make a brand-new one). We didn’t need a new WIT, but instead just needed to tweak one.

We were developing a new feature called User-Driven Installation (bit.ly/kjySZk) in tandem with the Microsoft Deployment Toolkit (MDT) team. It empowered end users to change their Windows 7 desktops or laptops. The MDT team utilized Scrum—using proprietary tools only available within Microsoft—while our team utilized TFS 2010. Beyond this, a great deal of interaction between the teams focused on bugs as our team delivered new features and bug fixes while their team owned all testing.

The teams worked together over multiple iterations only to see the first few iterations struggle to meet the stated output (for example, shippable software). Our velocity was low. We, as a team, were using Agile several months prior to working with our partner and had a rhythm of finishing our iterations with all work completed. Why, all of a sudden, did we stop producing everything we planned for in the sprint?

The change, ironically, was our failure to include bug estimates during sprint planning. Thus, we often would take on new features along with all the bugs our partner team asked us to fix. Because the Bug WIT didn’t have time-based fields such as Remaining Work and Completed Work, our burndown never alerted us that we had work that wouldn’t get completed.

The customization features of TFS 2010 made tweaking this WIT to meet our needs rather simple. We updated our bug WIT to include the time fields, added them to the Bug form and were then able to track both bugs and tasks via the iteration burndown. For more information on how to add a custom field, such as planning fields to a WIT, see my blog at bit.ly/gb1BOb.

TFS Integration with Windows SharePoint Services

As you recall, we needed to improve our team’s ability to track progress and report it accordingly to the team, our partners and our management.

TFS 2010 provides out-of-the-box integration to leverage a new Windows SharePoint Service (WSS) or an existing one. The creation of an MSF Agile project includes (if so desired) the creation of a SharePoint site that contains a nice, customizable dashboard. As part of our effort to improve our communication within the team and with customers, we leveraged the built-in dashboards that came with TFS. The compelling aspect of the dashboard and SharePoint integration was flexibility. The dashboard that came with the standard TFS project, for example, didn’t provide everything desired within that dashboard view. We wanted more.

The dashboards allowed us to evolve away from daily e-mail sharing of progress reports such as Burndown, Velocity or Bug Counts, and instead provide our management and partners access to our SharePoint site where they could see our progress in near-real time.

As with any organization, we have different people with different desires when it comes to what they’re interested in seeing. We customized our dashboard to include additional reports that, by default, weren’t enabled on the dashboard. For example, our management team meets with our team monthly to review the work we’ve done and to provide feedback to us as we’re moving along the lifecycle of our Agile projects. During one of these meetings, one of our key leaders asked if he could see the user stories we were working on, our progress and also user stories in our backlog that weren’t currently within the sprint. To learn more about how we were able utilize the dashboard to meet this leader’s need, see my blog post at bit.ly/jJ6XUp.

Unleash the Power of SharePoint and TFS 2010 Projects

If you or your company already have an enterprise version of Microsoft Office SharePoint Server (MOSS), you can unleash a new level of functionality by using MSF Agile projects linked with MOSS. As mentioned earlier, TFS 2010 ships with WSS, but WSS lacks some nice enterprise-ready features.

We wanted to utilize some of the great Excel reports that shipped with MSF Agile. The reports, as shown in Figure 7, offer a lot of capabilities, such as utilizing Excel Web Services (EWS) to host the reports and their data in Web Parts on our project dashboards.

Figure 7 Excel Reports in MSF Agile

This functionality isn’t available unless your team has a SharePoint 2007 or 2010 Enterprise server (or servers) available for the team project.

When TFS 2010 detects a SharePoint Enterprise server during creation of an MSF Agile project, it will create a dashboard that includes both EWS reports and SQL Server Reporting Services (SSRS) reports. This flexibility gave us a lot of capabilities because we gained the ability to use reports such as Code Churn and Bugs by Assignment, along with the reports provided in MSF Agile, such as Burndown and Burn Rate.

A key issue our team had while maintaining the SharePoint dashboard was management—specifically, who would own the task of keeping the reports up-to-date on the dashboard. For example, when our team was iterating at two-week intervals, the Burndown start date and end date needed updating every two weeks, otherwise the dashboard data wasn’t up-to-date. We maintained the dashboard for several months, but over time we were looking for ways to either automate the creation of these reports or a simpler way to track our iterations. It wasn’t long into our transition (nearly one year) that Scrum 1.0, downloadable from bit.ly/fdojaD, was released.

Agile: Retrospectives Are Invaluable

As we’ve evolved over time as an Agile team, we’ve spent countless hours together focused on improving our team, process and execution. This usually occurred when we had completed our iterations, and it ended with our sprint review (checked against our sprint goals) as well as the retrospectives. As an Agile team, it’s often easy to overlook retrospectives, and we did at times, making us refocus energy on them.

In MSF Agile, TFS provides you the ability to track your retrospectives through an iteration backlog template provided on the SharePoint site of your project. This workbook allows you to track your velocity, what you did well and what you could improve upon going forward (see Figure 8).

Figure 8 An MSF Agile Iteration Retrospective Template

We, as a team, have taken great pride in not only focusing on improving in retrospectives but also continually re-evaluating everything we do. Although much of our learning occurs in retrospective look-backs, we also tweak our Agile processes as technology evolves. In our case, TFS evolved when Microsoft released a new process template called Scrum 1.0 and we couldn’t ignore it—in fact, we embraced it.

Our Transition to Scrum 1.0

Our team, although not looking to work in a strictly Scrum-based fashion, resembles a Scrum team in many ways. Prior to adopting MSF Agile, we utilized terms such as Product Backlog Items (PBIs) and then went through the transition to user stories.

As we did before, we decided to select one of our shorter projects to evaluate the new Scrum 1.0 process template. Much like we did when adopting MSF Agile, we spent time familiarizing ourselves with the WITs available in the Scrum 1.0 template. As shown in Figure 9, the terminology is slightly different, yet many of the concepts are similar.

Figure 9 Work Item Type Definitions in Scrum 1.0

A big change we quickly noticed in Scrum 1.0 was a WIT called Sprint. It allows Scrum 1.0 teams to define specific starting and ending dates for their sprints, track their goals for that sprint and store their notes from their retrospective within TFS 2010. As I mentioned earlier, MSF Agile offered similar functionality in the Iteration Backlog workbook and a Microsoft Word template for retrospectives. The ability to have sprints, their goals and the retrospectives as a work item that then has work assigned to it was a compelling change for us. This was the primary reason we moved from MSF Agile to Scrum 1.0.

The PMs on our team who manage the features dashboards, reports and other iteration artifacts found themselves often spending significant time updating reports to reflect current point-in-time views for our team and partners. On the other hand, Scrum 1.0 has a Sprint WIT where we assign dates for our sprint. The Burndown report then uses the information in the Sprint work items to show the correct date range (see Figure 10).

Figure 10 Sample Sprint Burndown in Scrum 1.0

It was simple, seamless and fit right in with work we could do during sprint planning. We no longer had to customize reports to set the start date or the end date—now it was done for us when we created the Sprint work item before sprint planning.

To recap, MSF Agile and Scrum 1.0 offer different options to Agile teams. The decision about which to use is up to you, of course, just like it was up to our team. Figure 11 is a table that outlines WITs from each process template and how they align with each other. Again, the first thing I’d recommend to any new team adopting Agile software development using TFS 2010 is to learn in-depth how to use each WIT.

Figure 11 Work Item Type Comparisons in MSF Agile vs. Scrum 1.0

To learn more about the differences between the process templates, see my blog at bit.ly/i5tF2G.

Utilizing Iteration Workbook in Scrum 1.0 Projects

As our team evolved and more projects were created in TFS 2010, we found ourselves missing the iteration workbook. It helped us tremendously in understanding interruptions, and, more importantly, the team’s capacity at a sprint level. Because of this, as a team we customized the workbook to be compatible with Scrum 1.0.

The key focal point of this change isn’t to say that Scrum 1.0 didn’t work for us. Rather, it’s just to note that we missed a lot of the functionality provided within the workbook. My teammate John Socha-Leialoha (blogs.msdn.com/b/jsocha) outlined how to modify the Iteration Backlog workbook to work with the Scrum 1.0 template. The workbook doesn’t work natively, partly because it uses data stored in fields not available in Scrum. In his post, he focused on helping others learn how our team got the workbook to work with our Scrum 1.0 projects. The net result was that our team was able to utilize the workbook during planning and stand-ups to track capacity. The one downside we found is that Scrum 1.0, by default, doesn’t assign work to individuals during planning. Instead, the work is stack ranked and pulled directly off the backlog in an ordered approach. Thus, to be compatible with the workbook, we had to assign all work to individuals so that we could see capacity.

Discipline-Based Tracking vs. Assigned-To in Scrum 1.0

As I mentioned, assigning work to team members is problematic. Assigning work to individuals worked well for our projects that had one developer, one tester and one PM. Where we struggled, though, was in projects where we had capacity that varied based on our team dynamics. For example, one feature could have three developers, two testers and one PM. How do you “split up” work to individuals when it depends on who’s available at that time?

Our team made a big change when we switched to the Scrum 1.0 template in that we moved from assigning work to individuals to a focus on discipline-based assignment. In the first projects we ran on Scrum 1.0, we found that we failed because we assigned work to individuals instead of to disciplines. We talked about this as a team and decided to use a discipline field, called Activity, but we renamed it to Discipline in the work item (see Figure 12).

Figure 12 Discipline-Based Assignments in Scrum 1.0

This gave us the ability to see, at a glance, the capacity for developers, testers and PMs, so as we had resources added or taken from feature teams, we could adjust.

Putting It All Together

Our journey to Agile isn’t complete; there are many additional opportunities for us to streamline our processes. The misnomer about Agile is that Agile teams lack discipline. We as a team feel this is completely inaccurate. Instead, we’ve learned that Agile teams have a high level of discipline. Prior to moving to Agile, our team lacked an effective process and, unfortunately, discipline. The move to TFS 2010 and the MSF Agile process template started our maturation and created a spirit that focuses on learning and adapting.

Our adaptation has helped us evolve from using the MSF Agile process template to where we are today: we now utilize the Scrum 1.0 process template and we feel, as a team, that we’re almost “there.” I hope that our journey has enlightened you, and motivated you to move your team to TFS 2010 and one of these process templates.

Without TFS 2010, though, we wouldn’t have moved our team to where it is today. In the end, this is a story about one team’s successful move to Agile using TFS 2010.

Chris Adams is a group program manager at Microsoft, leading a software development team that builds software based on Microsoft enterprise-management tools. Prior to his current role, he spent seven years focusing on IIS (blogs.iis.net/chrisad) as a program manager in capacities such as deployment, supportability, UI and core architecture. He’s an avid blogger at blogs.technet.com/chrad and focuses on Windows, System Center and Visual Studio. You can reach him at chrad@microsoft.com.

Thanks to the following technical experts for reviewing this article: Aaron Bjork and John Socha-Leialoha