Agile/Scrum Development with Team Foundation Server 2010

The agile software development methodology supports quickly adapting a project to changing business realities. This alternative approach to the traditional waterfall software development paradigm emphasizes communication and collaboration in building functioning software in an unpredictable environment. Scrum is a subset of agile in which the software development team decides how the project will proceed. In Scrum, no details are given on how to manage a project; instead, the team decides this as the project evolves. For this reason, Scrum is not a methodology or a process; rather it is a framework.

Visual Studio Team Foundation Server (TFS) 2010 is an enterprise-level solution for managing software projects in both agile and Scrum. TFS provides the tools to project-manage, track work through work items and have full traceability from requirements down to code. Entering work items in TFS stores metrics that enable a development team to monitor the health of the project through reports. Part of a team's usage of TFS involves deciding which project type to use. This decision depends on a number of factors, including the challenges that software projects are experiencing, the resources available, and the organization's culture.

The goal of this article is to provide a high-level overview of Scrum and agile and to detail what TFS offers in the areas of project management, work-item tracking, metrics capture, and reporting. This information can help you choose which development methodology/framework to use in your organization.

Agile Overview

Agile addresses the reality that during software projects, the customer's needs are ever changing and dynamic. In the traditional waterfall approach, after requirements gathering is finished, development begins. By the end of development, the entire product is done and ready for testing. Since businesses are continually changing, it is very difficult to alter a project's course when using the agile approach. Agile recognizes this reality by gathering only enough requirements to build a small part of the system at a time. The entire system evolves from a series of small iterations or tiny waterfalls. The benefit of this approach is that changes in direction are much easier when developing in smaller increments.

There are five core roles and responsibilities in agile:

The customer's needs are user stories in the product backlog. A user story communicates functionality that is valuable to the product's end user(s). The product backlog contains the requirements that are available for upcoming iterations. An iteration is a time-boxed period (normally 30 days) containing user stories from the product backlog. The iteration-planning process selects which user stories to include and how to prioritize them. Through a series of iterations, the product is built in small increments, making it much easier to redefine how the product works and make changes along the way. An iteration is a mini-waterfall that goes through requirements, design, development, and testing and ends with the product's release. The result of an iteration should be a functioning piece of the system that the customer can see.

For more information about agile development, see the Manifesto for Agile Software Development and the Agile Alliance.

Scrum Overview

Scrum follows many of the same principles of agile. Product development happens in small iterations with each iteration's tasks chosen from the product backlog. As with agile, this approach helps control risk and improves predictability. For the iterative approach to work, every iteration must have transparency, inspection, and adaptation.

There are four formal opportunities for inspection and adaptation in Scrum:

These opportunities happen in the context of the Scrum team. The Scrum team consists of the product owner, the development team, and a Scrum master.

The product owner is the voice of the customer and manages the vision of the product. This person is responsible for managing the product backlog and priority of items in the backlog. A key point with Scrum is that no one can tell the product owner what the priorities of the items are and what the team should be working on. If someone wants a change in priority, the product owner will decide whether to make the change. This means that the product owner is solely responsible for the project's success.

The development team consists of personnel responsible for delivering a potentially releasable increment of work at the end of a sprint or iteration. This team is self-organizing with no titles. It consists of programmers, testers, designers, and database administrators. This team should have five to nine members; a larger group would make coordination too difficult.

The Scrum master is responsible for ensuring that the team adheres to Scrum theory, practices, and rules. The Scrum master guides the team to be more productive and produce a higher quality product. This role recognizes problems early and determines their impact. By working with the product owner and the development team, the Scrum master facilitates identifying and solving problems. You can find more information about Scrum at the scrum site.

Scrum in TFS 2010

Microsoft Visual Studio Scrum 1.0 is a process template that has been available since shortly after the release of Visual Studio 2010. The artifacts in this template map directly to concepts in Scrum, such as a sprint, product backlog item (PBI), and impediment. There are six major work item types in the Scrum template:

The PBIs are the product's requirements. The product owner is responsible for identifying, prioritizing, and maintaining these items. The team assists in determining the level of effort in implementing a PBI and its priority for adding value to the product. Figure 1 shows a PBI in TFS.

Product backlog item in Visual Studio TFS 2010

Figure 1: Product backlog item in Visual Studio TFS 2010

The top section of the PBI contains the title and iteration. The Title field must have a value. The Status section shows who needs to work on the PBI and the current state and a reason (i.e., explanation of the PBI's status). The Details section contains the priority, level of effort, business value, and area.

The Effort field contains a number representing the relative amount of work needed to complete the item. This number is not hours but a relative scale in comparison to other PBIs. The higher the value, the more work required to complete the PBI. This relative scale can only be known through experience in estimating backlog items over a number of sprints.

PBIs are chosen for an upcoming sprint in a sprint-planning meeting. There are two phases to this meeting: determining the top-priority PBIs to include in the next sprint and determining how to accomplish them. The "how" part translates into the tasks the team will work on during the course of the sprint. The outcome of this meeting is a sprint work item.

Figure 2 shows a sprint work item that captures the sprint goal, the beginning and end date, and a Retrospective tab for reviewing the sprint after it is completed. A sprint is the same as an iteration. During the sprint-planning meeting, the Scrum team determines the sprint goal and the number of PBIs to include. The Scrum master is responsible for making sure the sprint goal does not change during a sprint. At the end of the sprint, the team discusses the result and enters the findings in the Retrospective tab. This helps improve upcoming sprints.

Sprint work item

Figure 2: Sprint work item

The sprint-planning meeting also defines the tasks for the sprint. This is known as the sprint backlog. Tasks are what the team defines as the work to accomplish to realize a PBI. The team estimates the tasks and updates the time remaining daily. The team adds additional tasks during the course of a sprint, if necessary.

Figure 3 shows a task work item that the team uses to track and report the work it must accomplish for a PBI. The work items for a sprint connect through the Iteration field; however, a task work item can link to other work items through the Links tab. Tasks can be more than coding tasks; they can represent any work that needs to be done, such as a design task or a task to run test cases.

Task work item

Figure 3: Task work item

A test-case work item defines both manual and automated tests that testers manage and run using Microsoft Test Manager. The team uses test cases to define the acceptance criteria of a PBI. The tester can create a test case prior to a sprint, during the sprint-planning meeting, and throughout the sprint. Normally tests are manual, but can later they can become automated acceptance tests. Automated tests continuously verify that the software meets the requirements. If a test finds a problem, a bug work item captures this.

A bug captures a potential problem with the code that the team is developing or that is in production. By managing and defining bug work items, the team can track defects in the product and prioritize them. The bug work item in Figure 4 includes a tab for the steps to reproduce a bug. A bug links to a test case and tasks and defines the acceptance criteria as far as what the tester expects the system to do. Microsoft Test Manager allows bug creation from a test-case run and can populate the steps to reproduce the bug and update the system information automatically. This helps eliminate the common "unable to reproduce" response of a developer addressing a bug.

Bug work Item

Figure 4: Bug work Item

During the course of a sprint, if an issue or problem is found that prevents the team from completing the tasks, an impediment work item records this, capturing the problem and its resolution. The daily Scrum meetings find problems, and the Scrum master is responsible for facilitating the resolution.

The process of capturing all the information in work items stores metrics and makes them viewable in reports. Several reports are available for Scrum in TFS:

The Release Burndown report tracks how quickly the team is delivering PBIs and tracks how much more needs to be done to complete the product release. It shows how much effort remains at the beginning of each sprint. Each sprint should show less effort remaining. The source of this information is the PBI.

The Sprint Burndown report tracks how much work remains in a sprint backlog. With this information, the team can better understand how quickly they are competing tasks and what work remains. The source of this information is the sprint backlog. Figure 5 shows how the remaining work decreases over time. The Ideal Trend line is the ideal burndown rate for completing the sprint by the end date. The In Progress series shows how many hours remain on tasks with the status of In Progress in a sprint. The To Do series shows how many hours remain on tasks that have a To Do status.

Sprint Burndown report

Figure 5: Sprint Burndown report

The Velocity report shows the completion rate across sprints. This is useful in forecasting the amount of effort to assign to a sprint if the duration remains constant. The Velocity report shows effort completion for each sprint with an average across all sprints. The source of this data is the PBI.

Agile in Team Foundation Server 2010

To use an agile development approach with TFS, you can use the MSF for Agile Software Development v5.0 process template. This process template guides you through the practice of Scrum while applying agile engineering practices. The process template includes tools for project management. Although the concepts in MSF for Agile are very similar to Scrum, there are differences in a few of the work items.

There are five major work item types in the agile template:

A user story captures functionality that is of value to the customer. A user story should focus on who the feature is for, what should it accomplish, and why. The main goal of the user story is to describe the feature from the user's perspective. The product owner is responsible for gathering and maintaining user stories.

Figure 6 shows the fields of a user story. As with a PBI, there is a Title, an Iteration, and an Area field. The Planning section contains a Stack Rank field, which prioritizes the user story relative to other user stories. The Story Points field is the relative level of effort to complete the user story. This serves the same purpose of the Effort field in a PBI. The Implementation tab links the tasks for completing the user story in a parent/child relationship. The Test Cases tab links the test cases for testing the user story.

User story

Figure 6: User story

The product owner adds user stories to the product backlog. Figure 7 is an example of the Product Backlog worksheet that comes with the MSF for Agile template. Product backlog items that are in the backlog should be given a Backlog iteration path. Someone must create this iteration path manually, as it doesn't exist out of the box. Having items in the Backlog iteration path makes it easy during the iteration-planning meeting to choose from the list of user stories still needing assignment.

Product backlog

Figure 7: Product backlog

The iteration-planning meeting is the equivalent of the sprint-planning meeting. The product owner works with the project manager and the rest of the team to decide which user stories should be part of an iteration/sprint. The story point value of each user story helps indicate how many user stories will fit inside an iteration. If the team needs more detail, creating tasks for the user story further aids in determining the level of effort needed.

The agile template provides an Iteration Backlog workbook to help a project manager assign user stories, manage capacity, and view the burndown rate. Figure 8 shows the iteration backlog worksheet. This worksheet provides a bulk way to add tasks and manage the iteration. The settings worksheet contains the beginning and end date of the iteration. The interruptions worksheet contains interruptions known ahead of time that affect the iteration. Together the three worksheets provide information for capacity planning.

Iteration backlog worksheet

Figure 8: Iteration backlog worksheet

Figure 9 shows the capacity worksheet, which is used to plan the task assignments for the team. Task assignment in agile differs from Scrum where the team volunteers to work on tasks. In agile, the project manager works with the team to decide who works on each task. As the iteration proceeds, the burndown worksheet indicates whether the team is on track.

Capacity worksheet

Figure 9: Capacity worksheet

The task work item serves the same purpose as in Scrum. The task work item shown in Figure 10 has a Stack Rank field for ordering the tasks for a user story. As with Scrum, a task captures work not only for code, but for any work on a project, such as a design task or a task to run test cases. Tasks link to a user story in a parent/child relationship, in the task's Implementation tab. The test-case work item type is the same as in Scrum except for the placement of some fields.

Task work item

Figure 10: Task work item

As in Scrum, in agile a bug captures a problem found during testing or in production. This allows the team to track defects in the product and prioritize them. The bug work item includes a tab for the steps to reproduce a bug. A bug links to a test case and tasks. As with Scrum, in the agile process template you can use Microsoft Test Manager to create a bug directly from a test run.

An issue work item has the same purpose as an impediment in Scrum. If something is preventing the iteration from progressing, an issue stores this information. An issue contains a due date and can link to other work items.

As with Scrum, in agile work items capture metrics that feed reports. Agile contains a comprehensive list of reports that also include pivot-table reporting at the aggregate level. Microsoft Excel reports display information from the data warehouse. Agile provides numerous Excel reports, which fall under the following categories:

You can also obtain reports using SQL Server Reporting Services—these reports contain aggregate metrics from work items, version control, test results, and builds. The Reporting Services reports comprise these categories:

The reporting capabilities in the agile template provide high levels of visibility into the health of a project.

Scrum or Agile: Which Is for You?

The choice of a Scrum or an agile development methodology comes down to culture. The Scrum template is for development teams who have fully bought into the Scrum programming lifestyle. Scrum teams are self-organizing and commit themselves to delivering business value with each sprint. They are typically experienced and motivated and may also feel that the project data that higher-level managers want to collect gets in the way of the development process. The Scrum template lacks this overhead. There are no product backlog or iteration backlog workbooks where resource allocation, planning, and tracking are done. The team uses the burndown report to track velocity. The Scrum template provides only a few reports.

The agile template is more comfortable to organizations that want to adopt Scrum-like practices but still desire high-level oversight, tracking, and reporting. The agile template allows project managers to keep control of the project plan using the product backlog and iteration backlog workbooks. Project managers can even bring their iteration backlog into Microsoft Project. The agile template also provides considerably more extensive reporting and capture of metrics, all of which allow managers to see tasks, tests, and bugs rolling up to a user story. Project managers can check unplanned work (adding work to the sprint after the sprint begins), bug trends, reactivation rates, and more. The management aspects of the agile template target a culture that wants to keep a close eye on their development team and measure their production process and not just their results.