Scrum

Scrum is a framework for running projects that is based on agile principles and values. It defines a set of activities that can help your team deliver more value to your customers faster. These activities provide your customers with the opportunity to review, guide and influence your team's work as it progresses. This approach does not attempt to define everything at the start of a project. Instead, your team works in short iterations (also called sprints) and refines the plan as the team makes progress. For information about the agile principles and values on which Scrum is based, see Agile Principles and Values, by Jeff Sutherland.

MSF for Agile Software Development v5.0 is based on Scrum. Therefore, your team can adopt Scrum by using tools that are integrated with your core development activities.

In This Topic Prepare for the Project Plan the Project Plan a Sprint Run a Sprint Track the Project

Prepare for the Project

Before you start your project, perform the following tasks:

• establish the business case

• assemble a team

• set up your team's infrastructure

To establish a business case, identify the business need and justification, define the vision, and obtain funding. Geoffrey Moore's book "Crossing the Chasm" provides good guidance for establishing your vision. For more information, see the following Web resource: Crossing the Chasm.

After you establish the business case, you must assemble your team and identify the ScrumMaster and the product owner. For more information, see Roles.

Finally, your team must set up the infrastructure. For example, install Visual Studio Team Foundation Server and Visual Studio Application Lifecycle Management (ALM), create and possibly customize your team project, and set up engineering practices. For more information, see Getting Started with Visual Studio Application Lifecycle Management, Customizing Your Team Project, and Engineering Practices.

Plan the Project

In a Scrum project, your team will spend most of its time developing your product in a series of sprints. However, your team must first create a high-level plan for the project. This plan is a roadmap to guide more detailed decisions that your team will make during the course of the project. As your team implements the plan, it will change. When your team has finished planning the project, the team will have created a product backlog and, if it is needed, a release plan.

Build the Product Backlog

The product backlog is a list of user stories that describe what your users need and value. The user stories are prioritized by business value and risk, and the team estimates user stories in abstract units that are called story points.

	Create User Stories: In his book "User Stories Applied," Mike Cohn defines user stories this way: "A user story describes functionality that will be valuable to either a user or purchaser of a system or software." User stories are written from the end user’s point of view. For example: "As a returning customer, I want to find a meal that I have ordered before." For more information, see Creating a Great Product Backlog.
	Prioritize the User Stories: Your product owner prioritizes the user stories in the product backlog by working with your customers to understand what they value and by working with your team to understand risks and dependencies. Your product owner specifies priorities by assigning a rank to each user story to indicate the order in which the team should implement them. Your product owner can use many techniques to analyze and compare the value of user stories. If your team already has a method for prioritizing that works well for you, use that method. A few prioritization techniques are closely associated with the agile community, such as the Kano model of customer satisfaction and relative weighting by Karl Wiegers. (For more information about relative weighting, see the following page on the Web: First Things First: Prioritizing Requirements.) Other prioritization techniques, such as cost prioritization, net present value, payback period, and internal rate of return are well established outside the agile community. These techniques are also legitimate and appropriate for prioritizing your product backlog on a Scrum project. For more information, see "Part II: Estimating Size" from the book that the following Web resource identifies: Agile Estimation and Planning.
	Estimate the User Stories: Your team collaboratively estimates each user story in story points. In his book "Agile Estimation and Planning," Mike Cohn defines story points this way: "Story points are a unit of measure for expressing the overall size of a user story, feature or other piece of work." Story points are relative values that do not translate directly into a specific number of hours. Instead, story points help a team quantify the general size of the user story. These relative estimates are less precise so that they require less effort to determine, and they hold up better over time. By estimating in story points, your team will provide the general size of the user stories now and develop the more detailed estimation of hours of work later, when team members are about to implement the user stories.

Determine Your Team's Velocity

Before your team creates its release plan and plans each sprint, your team must determine its velocity. Your team's velocity is the number of story points that it can complete in a sprint.

If your team has measured its velocity by collecting data that shows how many user stories the team completes in a given period of time, use that data. It will provide the best insight into the team's velocity. If you do not have that data now but you are starting to run your project by using Visual Studio ALM and MSF for Agile Software Development v5.0, that data will be collected over the course of the project. For more information, see Status on All Iterations Report.

If historical data is not available, your team can make a rough estimation of how many story points it can complete in the first sprint. Look at the estimated user stories at the top of the priority stack and make a quick assessment of how many stories it could complete in a sprint. Add the story points for each of those user stories to get an initial estimate. After the first sprint, you can use historical data to determine your team's velocity. In the first few sprints, you should expect substantial variation as your team learns how to estimate consistently. Over the course of several sprints, your team's measured velocity should become more stable. When your team's measured velocity is stable, reassess the release plan.

The estimate of your team's velocity provides a starting point that you can use to determine how many user stories to implement in the sprint, but the estimate is not the basis for your team's commitment. Your team's commitment will be made based on more detailed estimations of the tasks that are required to complete the user stories. For more information, see Product Planning Workbook.

Establish the Release Plan

Each sprint, your team will complete an increment of the product that it could ship. Although the user stories that your team implements are ready to be shipped at the end of the sprint, they may not provide enough business value to justify actually releasing the product. Plan your releases by assigning them to iterations:

• Identify groups of user stories that, together, provide enough business value to release to your customers.

• Determine in which sprints the team expects to complete those groups of user stories.

As your team makes progress, user stories will be added to the product backlog, and user stories may be removed. In addition, the priority of some user stories will change, and some user stories may be implemented earlier or later than originally expected. Your product owner will maintain the release plan together with the product backlog over the course of the project.

For more information, see Product Planning Workbook.

Prepare for the First Sprint

A sprint is a timeboxed iteration of development that is usually one to four weeks long and that produces an increment of the product that the team could ship. Before your team starts the first sprint, your product owner prepares the product backlog. The user stories that are high enough priority to be considered in the first sprint must be ready for the team to implement. Your product owner must prepare the product backlog by performing the following tasks:

• Break the user stories down into smaller stories.

• Provide details about the user stories that the team will need to break the stories down into tasks.

Your product owner will know that a user story is too large if it represents a significant amount of the team's total velocity. For example, a user story that is 15 story points is too large to take into the sprint planning meeting if the team's velocity is 30 story points. The team will take half the sprint just to complete that user story.

Your team will also ask for details about the user stories to be able to break them down into tasks and estimate those tasks. For example, when your team examines the user story "As a customer, I want to be able to search for a type of meal," your team may ask the following kinds of questions:

• "Must that be a free-text search, or can it be a selection for a list of available types?"

• "If more than one vendor provides a meal that matches the search, how should the results be sorted?"

For more information, see Preparing for the Next Sprint.

Plan a Sprint

When your team has developed the product backlog and established a release plan, your team can start to work in sprints. Your team starts the sprint with a sprint planning meeting, in which the team commits to completing a set of user stories from the product backlog. That set of user stories, together with the supporting tasks, is the sprint backlog. For more information, see Comparing the Product and Sprint Backlogs.

After the sprint starts, the user stories in the sprint backlog are not changed. Therefore, the plan must be detailed enough that the team can make that commitment with confidence.

For more information, see Sprint Planning Meeting.

Choose User Stories

Your team chooses the user stories that are candidates to be implemented in the sprint. You team identifies the user stories that have the highest priority and whose story points do not exceed its estimated velocity. For example, the four user stories that have the highest priority might have 8, 3, 7, 6, and 2 story points. If your team had a capacity of 25 story points per sprint, your team would include the first four stories in the sprint backlog.

For more information, see Iteration Backlog Workbook.

Identify Tasks

Your team evaluates each user story to determine what it must do to implement that story. Your team breaks user stories down into tasks to help it understand the user stories well enough to make a confident commitment to complete them in the sprint.

Teams that are very experienced at Scrum may be able to make this commitment without breaking the user stories down into tasks.

Estimate Tasks

After the tasks are identified, your team estimates how long (in hours) each task will take. Teams frequently use the planning poker technique to estimate tasks. This technique helps prevent teams from trying to estimate more accurately than is necessary.

Commit to User Stories

Your team uses the Iteration Backlog workbook to make sure that the team has enough working hours to complete all of the tasks. If the sprint has more work than your team has available in the sprint, the lowest ranked user stories must be removed until the work is within the team's capacity for the sprint. Smaller stories that are lower priority can be exchanged for larger stories that do not fit the sprint.

Your team commits to completing the user stories that it has determined that it can complete. It makes this commitment with the understanding that your product owner will not attempt to introduce additional work or change the priorities of the user stories that are being implemented in the sprint.

Run a Sprint

During a sprint, your team completes the tasks that are required to implement the user stories in the sprint backlog. Your team can track its progress and make sure that it meets the customers’ acceptance criteria and your team’s criteria for finished software before you finish each sprint.

Complete User Stories

After your team plans the sprint, it has a list of user stories that it has committed to completing during the sprint. Those user stories have been broken down into tasks. Each member of your team signs up for a task when the sprint starts. After completing that task, the team member updates its status and sign up for another task. In this manner, your team works through the list of tasks, completing the user stories in the sprint backlog. A team member can indicate which tasks are completed when checking in code. For more information, see Associate Work Items with Changesets.

For more information about assigning tasks and updating their status, see Task (Agile).

Scrum relies on people talking to each other more than formal processes to make sure that dependencies are understood, that expertise is shared, and that changes in plans are made efficiently. Hold a short, daily Scrum meeting in which each member of the team shares some details about the work that they accomplished on the previous day, the work that they plan to accomplish that day, and any issues or impediments that might affect or require help from other team members. For more information, see Daily Scrum Meeting.

In his book "Extreme Programming Explained," Kent Beck talks about how it is cheaper to fix a bug sooner rather than later. Given that fact, your team must understand what is important to your customer. Perhaps the customer values quality instead of more features. Your product owner must know this kind of information because customers control the flow of the work to the team.

The software that a Scrum team produces should be error free. However, your team will likely encounter bugs in your projects. Handle bugs with the understanding that it is cheaper and quicker to fix them as they are found than it is to put them off until later. When your team finds bugs, fix them immediately. If your team cannot fix the bug on the same day that was found, create a bug work item in Visual Studio ALM and fix it before the end of the sprint.

For more information, see Bug (Agile).

Track Sprint Progress

Your team can track the progress of the sprint to make sure that work is being completed as expected and that it meets the acceptance criteria. Scrum teams most frequently use a burndown report to track their progress through a sprint. MSF for Agile Software Development v5.0 provides a set of reports that teams can use to track the progress of a sprint.

Burndown and Burn Rate Report (Agile)

Build Quality Indicators Report

Test Plan Progress Report

Stories Progress Report (Agile)

Teams often find that they need more or less time to complete a task than what they estimated during the sprint planning meeting. This kind of variation is typical. You can record this information by specifying the actual time that the team spent in the task.

As the sprint progresses, your team might identify work that it had not expected but that is necessary to complete a user story. In this case, create a task, estimate it and then determine whether your team can complete it in the hours that remain in the sprint. If your team can complete the task, continue with the sprint. If your team cannot complete the task in the sprint, meet with the product owner to discuss how to continue. The product owner and your team can resolve the issue by making the following kinds of changes:

• Reduce the acceptance criteria for the user story so that the task becomes unnecessary.

• Remove the user story from the sprint backlog.

• Cancel the sprint.

Finish the Sprint

As the end of the sprint approaches, make sure that your team is completing all user stories or requirements. For example, make sure that the acceptance tests are passing and that each user story meets the criteria that your team defined. For more information about what it means to be done, see the following Web page: Mitch Lacey & Associates, Inc.

Bug Status Report

Bug Trends Report

On the last day of the sprint, your team will demonstrate the user stories that it has completed to the product owner and possibly to your customers. Your product owner and customers will determine whether they accept each user story. For more information, see Sprint Review Meeting.

After the customer review, your team will hold a retrospective. For more information, see Retrospective Meeting.

Track the Project

As your team works in sprints to deliver increments of the project, your customers develop a better understanding of their remaining needs, and changes in the business environment must be considered. Your product owner works with your customers to understand these changes. Your product owner will maintain the product backlog and the release plan to reflect those changes and to make sure that your team has what it needs at the start of each sprint. Your team tracks the progress of the product as a whole to make sure that it is making healthy progress toward completing the project.

Prepare for the Next Sprint

The freshness of the product backlog has a direct relationship to the overall quality and completeness of the project. The backlog must be regularly updated, changed, and rethought to make sure that it is ready every time that your team is about to start a sprint.

Your product owner prepares the product backlog for the next sprint by performing the following tasks:

• Update the user stories and their priorities as customers' needs change.

• Break down user stories that are likely to be implemented in the next sprint.

When your team finishes a sprint, other user stories get closer to the top of the product backlog. Your product owner must analyze and break down those stories that are at the top so that your team can implement them in the upcoming sprint. (For more information, see Prepare for the First Sprint earlier in this topic.) Mike Cohn often talks about this process as the product backlog iceberg. As the team works on a set of functionality, the iceberg melts, new work surfaces, and the iceberg becomes smaller. In this process, additional details emerge, just enough and just in time.

Now that your team is busy running a sprint, your product owner cannot expect to have the same level of your team's involvement in maintaining the product backlog as it may have provided in preparing for the first sprint. To help your product owner prepare the product backlog with a minimum of disruption to the sprint, your team and your product owner will discuss the open issues about the product backlog over the course of the sprint.

Track Release Progress

As the project proceeds from sprint to sprint, your team will track the overall progress toward the next release. Your team will also track its progress to assess and improve its velocity. As your team tracks its progress, it should try to answer the following kinds of questions:

• Are we working on the most appropriate user stories? Your product backlog will be refined with new user stories as the project progresses. However, if the total number of stories in the backlog is not decreasing, even though you are completing stories each sprint, the team should investigate the cause. The stories being completed might not be the best choices. The team should have a vision and a goal for each release and ensure that the stories tie directly with what is being asked of the customer.

• Are we carrying technical debt? Some teams treat a user story as finished even though work such as fixing bugs remains to be completed. Those teams take on technical debt that they must pay later, usually at a higher cost.

Visual Studio ALM provides several reports to help your team track its progress over many sprints.

Status on All Iterations Report

Stories Overview Report (Agile)

Stories Progress Report (Agile)

You can create custom reports and work item queries to help track progress. For more information, see Creating, Customizing, and Managing Reports for Visual Studio ALM and Finding Bugs, Tasks, and Other Work Items.

Finish the Release

If your team is not accumulating technical debt, it can release the product when it has completed the sprints in that release, without additional work. Your team and your product owner hold customer review and retrospective meetings to examine the release as a whole.

However, technical debt is a challenging problem that teams cannot eliminate easily. If your team, like many other teams, is still accumulating technical debt, you must spend time doing the outstanding work to finish the user stories before you release your product. In the retrospective for the release, consider what your team must do in upcoming sprints to avoid taking on more debt.

See Also

Concepts

Engineering Practices

Choose a Process Template

Planning and Tracking Projects

Other Resources

MSF for Agile Software Development v5.0