Announcing Team Foundation Server Scrum v1.0 Beta

7/19/2010 Update - this post applies to the beta release of this template. For details on the RTW please see this updated post.

- - - - - - - - - - - - - - - - - - - - - - -

Today , we’re announcing and releasing a brand new process template… Team Foundation Server Scrum v1.0 Beta.  This is a new process template built from the ground up specifically for Scrum teams.   So, why a new template?  Quite simply, because you told us you wanted one.   Scrum has become a dominant methodology in software development and you have told us that you want a process template aimed directly at Scrum teams. 

I’ve written up a quick FAQ below to help with common questions.   I’ll update this thread with additional questions and answers as they come in.  We would love your feedback, so download the template and give it a shot.  Click here to visit the Visual Studio Gallery where you can download the template.

Q: How does Team Foundation Server Scrum differ from MSF Agile v5.0?

A:  TFS Scrum v1.0 is a Scrum process template.  Nothing more, and nothing less.  In contrast, MSF Agile v5.0 is an Agile process template that can be used to apply a variety of Agile practices/methodologies including Scrum.  The biggest differences between the templates are found in the work item types, terminology, and state transitions. 

TFS Scrum v1.0 WITs MSF Agile v5.0 WITs
Product Backlog Item User Story
Bug Bug
Task Task
Impediment Issue
Test Case Test Case
Shared Steps Shared Steps

Below are screenshots of the Product Backlog Item, Bug, Task, and Impediment work items. 

Product Backlog Item BugTask image 

Q: Why did Microsoft decide to have both a Scrum and Agile template?

A:  Because you told us you wanted both of them.  We have many customers that want a generic Agile template that can be used to implement Scrum and other Agile methodologies.  MSF Agile does this very well.  At the same time, we have many customers that want a very prescriptive Scrum template that matches the terminology they read in the Scrum literature.   Enter Team TFS Scrum v1.0.

Q: How is the state model different between Team Foundation Server Scrum differ from and MSF Agile v5.0?

A:   MSF Agile 5.0 uses a fairly consistent state model across all work item types:  Active –> Resolved –> Closed.  TFS Scrum v1.0 uses a unique state model for each work item type that matches common Scrum terminology.  For example, a Task work item in TFS Scrum v1.0 has the following state model:  To Do –> In Progress –> Done.

Product Backlog Item and Bug Work Items


Task Work Item


Impediment Work Item



Q: What reports are included in TFS Scrum v1.0?

A:  The first release of the template includes 3reports:

  • Release Burndown - Indicates how quickly the team is completing work and delivering Product Backlog Items. 
  • Velocity - Indicates the amount of effort the team is completing in each sprint.
  • Sprint Burndown - Indicates the team's progress towards completing its work for a sprint


imageimage image


Q: Why are there only 3 reports in TFS Scrum v1.0?

A:  We recognize that there are many more reports that could be helpful to a Scrum team.  However, with this first release of the template we wanted to including what we felt were the necessary reports that a Scrum team needed to be successful.

Q: How is the Sprint work item intended to be used?

A:  The Sprint work item is intended to capture the sprint dates, sprint goal, and sprint retrospectives.  Because TFS does not have a method for storing dates on iterations, we chose to create a Sprint work item that allows you to capture sprint dates and other sprint data directly in a work item.  You can see in the screenshot that the Release 1\Sprint 1 work item is mapped directly to the Release 1\Sprint 1 iteration.  When you create a new project with TFS Scrum v1.0 by default the project is provisioned with 24 sprint work items and 24 matching iterations. 


Release 1:  Sprint 1-6

Release 2:  Sprint 1-6

Release 3:  Sprint 1-6

Release 4:  Sprint 1-6

With this model, you have both Sprint work items AND iterations… the trick is that you should have only one Sprint work item for each iteration that you create.   For example, if you created a new iteration named Release 4\Sprint 7 you would want to create a new Sprint work item and assign it to Release 4\Sprint 7.  The dates for this new Sprint would be entered directly on the Release 4\Sprint 7 Sprint work item.

The advantage to this approach is that when you’re working with reports in the template you don’t have to enter dates.  Instead, you just select the Sprint(s) that you’re interested in viewing.  The dates are read directly from the Sprint work item and used in the reports.

Q: Can I move my data from my existing project in TFS Scrum v1.0?

A:   Yes.  You can use the TFS Integration Platform to create a mapping between any existing team project an the new TFS Scrum v1.0 template.

Q: How does TFS Scrum v1.0 deal with Bugs?

A:   Defects found that relate to work outside the current Sprint are added to the Product Backlog as Bug work items.  Defects found that relate to work in the current Sprint are added by the team to the Sprint Backlog as Tasks work items.  These defects represent unfinished work, and should be completed by the team during the Sprint. 

Q: Where is the process guidance?

A:   We’re writing the guidance for the work items right now, but we won’t have it ready until the beta is complete.  You’ll notice that in the interim the process guidance directs you to   We worked closely with Ken Schwaber and others at in the creation of this template.  If you’re new to Scrum I highly recommend you download and read the Scrum Guide.

Q: How long will the beta be?

A:  As long as it needs to be (I know, that’s a cop-out answer, but it’s the truth).  We don’t anticipate a long beta however, so if you’re got feedback, send it our way.  :)