Welcome to EMC Consulting Blogs Sign in | Join | Help

Crispin Parker's Blog

About Scrum for Team System and .Net development

Getting Started With Scrum for Team System Version 3 (TFS 2010)

So, you’ve setup your brand new TFS 2010 environment, installed SfTS v3, deployed the template and created an empty scrum project. Now what? Hopefully the information in this posting will help you get a simple project up and running.

Before we dive straight into populating a new project, I’ll give you a brief overview of the new Scrum project infrastructure.

Project duration life cycle

The first thing to understand about the new Scrum components is the project life-cycle items. The project life time is described by Planning Scope and Life-cycle work items (Release, Sprint and Team Sprint).

Planning Scope

The planning scope (AKA iteration path) has a special strict structure within SfTS v3. This structure is important because the other template auxiliaries (reports and the event service) have been written to expect certain types of objects at certain positions. Planning scope is also used to model the team aspects of the project. There is no-longer any v2 style Global Team lists.

Here’s what the planning scope path looks like:

  • Project Name \ Release \ Work Stream \ Sprint \ Team Sprint

  • Project Name – The name of the project. Important in Project Collections because TFS 2010 allows you to write cross project queries.

  • Release - Describes a unit of project work that encapsulates a releasable collection of features. A release is generally the result of multiple sprints and marks a mile stone in the project life time.

  • Work Stream - This planning scope node is used to group teams working at the same cadence and on the same project topic. It can also be used to control complex projects that have multiple streams working in a single release. Work stream represents a reporting branch split. This means that teams working in the same work stream can appear in a single report, but teams working in separate streams cannot. 

  • Sprint - This node represents a collection of all teams working on a single sprint.

  • Team Sprint - This scope level is used to identify an individual team. 

The planning scope has been designed to allow you to model practically any setup of sprint duration, number of teams and sprint length. If you are running a simple single team project, then just ignore the extra levels of the scope. Don’t get all tidy minded and start deleting them, because that is just going to break other cool stuff.

Life-Cycle Work Items

In addition to the planning scope path, there are also 3 types of work item used to describe the project life-cycle, aggregation of sub elements and project planning.

The life-cycle work items are:

  • Release – This work item describes the purpose of the project release and aggregates the amount of planned / burned under the release node.

  • Sprint – Aggregates all the linked Team Sprint values and sums the amount of planned estimated work.

  • Team Sprint – Describes an individual team and their capacity of working hours.

Each of these work items needs to be linked to it’s parent using the scrum implemented by linkage type. So, a Release is “Implemented-By” one or more sprints and a Sprint is “Implemented-By” one or more Team Sprints.


The life-cycle work items also have a relationship to a level of planning scope. For example, you must select a release level planning scope node in the release work item. The planning scope node / work item relationship is very important because it used by the project reports and aggregation services.

  • Release work item = Project Name \ Release
  • Sprint work item = Project Name \ Release \ Work Stream \ Sprint
  • Team Sprint work item = Project Name \ Release \ Work Stream \ Sprint \ Team Sprint

Wow that sounds complicated, how am I going to set all that up?

Never fear, we are your friends. Honest! We have produced a utility that can help you set up your initial project life-cycle in about 30 seconds flat. It’s called the Scrum Masters Workbench and you download for free. It also includes a task board and list item view. I suggest you check it out.

The Project Backlog

In the version 3 Scrum template the backlog is described by the Product Backlog Item (PBI) work item. The PBI describes the product feature requirement, the size or cost (proportional to all the other backlog items) of the feature and the planned scope position.

The PBI forms the hub of the effort modelling work items. Each of the child work items must be linked using the correct linkage type.



Sprint Backlog Tasks (SBT) describe a unit of effort that is required in order to implement the PBI. SBTs are linked to PBIs using the “Implemented-By” link type. A PBI is Implemented-By a SBT.

Acceptance Test (AT) describes the conditions of acceptance, or contract that must be meet before the PBI is considered done. ATs also integrate with the Microsoft Test Manager application. ATs are linked using the “Test-By” linkage. A PBI is Tested-By an AT.

Impediment describes a blocking issue that is stopping work from being completed. Impediments are linked using “Impeded-By”. A PBI is Impeded-By an Impediment.

Bugs describe a failure condition and are linked to ATs. Bugs are linked to ATs by the “Failed-By” link type. The work required to rectify the failure condition is not tracked on the bug work item itself. If the correction requires a whole new feature, then a new PBI should be created on the backlog or if additional tasks are needed, they should be added against the failed PBI. We have chosen this approach to bring clarity to the bug model. Bugs do one thing and that is describe a failure condition. PBIs and SBTs describe requirements and working effort. An AT is Failed-By a Bug.

That’s the main template model concepts covered. Next we’ll walk through setting up a project to see how it all hangs together.

Creating a sample project


Before we start you’ll need a couple of things.

  • A new empty Scrum for Team System version 3 project.
  • Visual Studio Team Explorer 2010.
  • A copy of the Scrum Masters Workbench (which you can get from here).



In order to create work items in the new Scrum project, you’ll need to add users to the project contributors group. To do this:

  • Open the Group Membership dialog from the Team Explorer panel.


  • In the Project Groups dialog, double click on the Contributors group or select and click the Properties button.


  • In the Contributors properties dialog, use the controls to add the required users or groups. You can add TFS groups and windows users or windows groups.



Create the project life-cycle items

Our sample project is going to have a simple life. One release, two sprints and a single team. Now, you can create this structure manually using Team Explorer but that is quite slow to do as it requires you to generate all the require planning scope paths, work items and links. So instead let us fire up the Scrum Masters Workbench and use it’s project setup mode.

  1. Launch the SMW application.
  2. Connect to your new empty TFS Project.

    Click menu: File –> Load Project
    Use the “Show Project Selector” button to select the required project.

  3. Select the SMW “Project Setup” mode.

  4. Click the “Quick Setup” button.

  5. Next we need to enter some initial project setup parameters. For this test project I entered:
    1. Project Start Date: 17/05/2010
    2. Project End Date:   30/05/2010
    3. Team Name:            Team Alpha
    4. Capacity:                 120 Hours
    5. Sprint Length:         7 Days.

  6. Click the “tick” and agree to the “Delete any existing conflicts” message box.

    Note: The setup processes (both Quick and Advanced) are intended for your initial first time setup. They will destroy all conflicts on each run. Changes to the project life cycle after the initial setup should be made without running the entire setup process.

  7. Once the process has completed, you will be able to see the entire project Planning Scope displayed as a node tree.

    Note: You can edit the planning scope nodes by right clicking and selecting “Edit associated item” from the context menu or clicking on the pencil icon within the node.

  8. Finally save all the life-cycle work items back to TFS.

    Click menu: File –> Save Project

That’s it. The project life-cycle is now defined. The SMW has generated the entire planning scope path, 1 Release, 2 Sprints and 2 Team Sprints all linked together with the correct link types in the correct direction.











Create a Project Backlog

The new project infrastructure is now setup and it’s life time mapped out. Next we have to add the product backlog. The product backlog is the main focus point of the project. It details all the required end product features and (importantly) the comparative business value of each feature.

I’ll describe how to populate the backlog using Visual Studio Team Explorer. The SMW offers an alternative interface for controlling your backlog, but I’ll cover that in a separate future blog post. So, fire up Visual Studio Team Explorer and connect to your new project.

To create your backlog; select your project name in the Team Explorer window and:

  1. Click menu: Team –> New Work Item –> Product Backlog Item

  2. Fill in the fields:
    1. Title – A brief description of the feature.
    2. Business Value – A value indicating the comparative value of this feature.
    3. Story Points – The comparative size of the feature.
    4. Description – A detailed description of the feature. Note: You can use the user story pattern of “As a <role> I want <ability> so that <benefit>”.

  3. Save.

Repeat steps 1 – 3 several times to simulate a collection of backlog items. I made five dummy PBIs for this test project.

Viewing the backlog in Team Explorer

To see a list of your entire backlog, run the below Team Query.

  • Team Queries \ Backlog Maintenance \ All Product Backlog Items (PBIs)




Conditions of Acceptance

The backlog is in place, but how can we tell when a feature is complete? We need someway to describe (and test) the “Done” state so that everyone involved knows when it has been developed sufficiently to met it’s expectations. Enter the Acceptance Test (AT). ATs need to linked to PBIs using the Tested-By link type. So let’s create some linked ATs.

Using Team Explorer, open a PBI edit window and:

  1. Select the “Tested By” tab and click the “New” option.

  2. In the “Add New Linked Work Item” dialog, enter a title for your new test and click “OK”

  3. Save the work item.
  4. Repeat these steps for each of your PBIs.

Note: Creating work items from the linkage tabs ensures that the correct link types are setup.

Another Note: Acceptance Tests are optional. You don’t have to add them to your project if you don’t want to. However, they provide such a benefit to understanding the PBI, not having them is really missing a trick to improve you delivery quality. In fact, just tell everyone that ATs are not optional and PBIs must have them. I won’t tell if you don’t.


Setting the backlog release schedule.

When the backlog is entered (and prioritised) it’s time to decide which PBIs are needed in which release. This is pretty easy for us because we only have one release! So using Team Explorer, update each PBI so that it resides under the Planning Scope Release node.

  • Update each PBI planning scope to be: [Project Name]\Release 01 and save.

Doing this creates an inferred relationship between the PBIs and the Release object. It also triggers the event service to update the Release with the sum of the related PBIs Story Points.

Note: Microsoft have decided to insert a 2 minute delay into the work item change notification system. This means that it will take 2 minutes before your Release is updated. If you feel that is a bit slow (I know I do!) then you can change the delay time. See Team Foundation Server 2010 RC Job Service Delay for more information.


Sprint Planning

Now the backlog is in place, it’s time for the team to do some sprint planning. I’m not going to delve into the details of sprint planning here, but basically, the team decide on their estimated velocity for the forthcoming sprint (measured in Story Points) and commit to a corresponding number of PBIs from the backlog (using the PBI story point value against the estimated velocity).

Note: The backlog priority order is decided by the product owner and indicated by the business value.

My virtual team are pretty confident, so they commit to a velocity of 8 story points for their first sprint. This in turn means that they can take on the two PBIs with highest business Priority.

To move the chosen PBIs into the sprint, change the PBI planning scope to the target sprint and save:

  • [Project] \ Release 01 \ Work Stream \ Sprint 01

Now the team need to describe the actual tasks of work required to deliver the selected backlog items. To do this they create Sprint Backlog Tasks associated with the chosen PBIs.

  1. In Team Explorer, select a PBI window.
  2. Select the “Implemented By” tab and click the “New” link.


  3. Enter the a brief description of the task in the Title field and click the OK button.


  4. In the new Sprint Backlog Task form, enter:
    1. Estimated Effort – The estimated hours the task will take to complete.
    2. Planning Scope – Set this to [Project] \ Release 01 \ Work Stream \ Sprint 01 \ Team Name
    3. Work Remaining – Set the initial value of this field to match the estimated effort.
    4. Description – Add a full description of the task here.

  5. And Save.
  6. Repeat this for each task that needs to be completed in order to create the required PBI feature.
  7. Then repeat steps 1 to 7 for each PBI.







Finally, everything is ready for my virtual team to start doing some development work. Day one of the sprint arrives, so:

  • Set the status of the Sprint work item to “In Progress” and save.


Then the team look at all the not done tasks associated with the first PBI. Team members take ownership of tasks by setting the “Owned By” field in the SBT.


The task owner is responsible for updating the “Work Remaining” and “Status” values of all the tasks they own.

Don’t be surprised if the work remaining number goes up to start with! It is often the case that tasks take a bit longer than originally thought, especially in early sprints before the value of good estimation has really hit home. The work remaining value contributes to the Burn Down chart, so it’s important that it’s updated regularly, at least once every day.

It is also important for the task owners to keep the work item “Status” field updated.

The team continue to burn through the work until the PBI is ready to be tested against it’s Acceptance Tests. When all tasks are set to “Done” and all ATs are “Passed” the PBI will automatically be set to done. When the PBI is done, it’s time to move onto the next one. Repeat until all the sprint work is done. Simple.

At the end of the sprint, set the Sprint work item status to done. This task can be done during the sprint retrospective meeting. I won’t go into detail here because it’s pretty obvious, but the “Sprint Retrospective” work item is very useful for tracking the outcome of your retrospectives.


Bugs are unavoidable. There I said it, don’t complain it’s the truth. Software development is very complicated, no matter how many unit tests you write or how diligent your developers are, you are going to get software bugs.

In the version 3 template, the Bug work item has a single responsibility, it describes a condition of failure. No physical work is tracked on the Bug work item itself (that’s the job PBIs and SBTs). A bug stands there for all to see as nothing more than it is, a description of failure. How depressing.

But the good news is; Bugs can get fixed. As they say, “the first step on the road to recovery is to admit you have a problem…”

When an error condition is found in the project, the tester (or whoever found it) should create a Bug work item to describe it.


The bug offers a wealth of tracking options to help you keep tabs on where it occurs and what it affects; including “bug detailed description”, “system info”, “reproduction steps” and “file and screen shot attachments”.

In order to test that a bug has been rectified it needs to be associated with an Acceptance Test. This can be an existing test or a new one depending on the nature of the bug. If additional work is required to rectify the bug, then tasks should be added to the affected PBI or if there is no relevant PBI on the backlog, then one should be created for the product owner to see.

The whole concept of working with tests and bugs is a biggie (including the integration with Microsoft Test Manager), so I’ll leave an in-depth explanation for another time.


The final component we will look at is the Impediment. Impediments are linked to PBIs and describe a blocking issue that is interfering with work on the PBI. In my test project, the virtual team cannot complete work on PBI 6 because I have neglected to give them hands. So they raise an impediment against the PBI.

To create a work item that describes the impediment:

  1. Select the impeded PBI in Team Explorer.
  2. Select the “Impeded By” tab and click the “New” link.

  3. In the new work item dialog, enter a brief description of the impediment and click OK.


  4. Fill in the impediment details and save.


PBIs will not automatically be set to done all the time they have open impediments associated.

Well that’s it. I hope you find this information useful in getting you started with Scrum for Team System version 3.

More Information at:


Crispin Parker,
Senior Practice Consultant,
EMC Consulting.

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Allen Feinberg said:

Are there any sample VMs or TPCs that have a Fully populated TFS 2010 Team Project using the Scrum for Team System V3 template with working reports?

August 18, 2010 1:19 AM

Atul Minocha said:

Excellent Article for a person who is looking himself to become a scrum master.The Article gives a complete understanding on doing the set of a project using the scrum methodlogy.I will refer everyone intersted to go through this article

August 26, 2010 10:09 PM

Kris Venk said:

Thank you for the fantastic article. I had few questions about some of the work item linkage types.

1) What is the difference between a Parent-child work item linkage relationship & Implemented -by\Implements relationship?

2) What are the advantages by linking different work item types (PBI & SBT or PBI & Acceptance Test or Acceptance Test & Bugs etc) through 'tested-by\tests', 'impeded-by\impedes', 'failed-by\fails' relationships instead of generic 'related' work item linkage relationships?

I understand that the relationship linkages becomes more indicative by above linkage usages. In addition to that, is there any other specific advantage?

September 16, 2010 4:35 PM

crispin.parker said:

@Kris Venk

Thanks for the positive feedback and taking the time to ask your questions.

1) What is the difference between a Parent-child work item linkage relationship & Implemented -by\Implements relationship?

The "Parent-Child" and "Implemented-By" linkage types use the same topology and only differ in text. The intention is to include additional Meta data to the linkage, describing what the linked work items represent rather than how they are linked.

2) What are the advantages by linking different work item types (PBI & SBT or PBI & Acceptance Test or Acceptance Test & Bugs etc) through 'tested-by\tests', 'impeded-by\impedes', 'failed-by\fails' relationships instead of generic 'related' work item linkage relationships?

TFS 2010 offers several linkage topologies. These linkage types allow you to create a rich model of the work item data and how it relates to one and another. SfTS v3 uses several linkage topologies described by the linkage type name. Another reason we have used named links is to provide the ability to describe the linkage purpose and allow targeted queries on your data. It's the same reason we have work items with different names and not just a single uber Work Item that describes everything. Clarity of purpose is important.


September 20, 2010 10:21 AM

Kris Venk said:

If the state of the bug or impediment or Acceptance tests rolls up the hierarchy, how far up would that be? For Example, if I create a BUG and set as Fails to the Acceptance Test… the state of the Bug will set the Acceptance Test to Failed.  Does it also go up the tree and change the state of the Product Backlog Item (PBI) and other higher levels like Release or our custom levels too?

September 20, 2010 4:49 PM

Kris Venk said:

Crispin's response:

"In SfTS v3; the hierarchy of work items is split into two main paradigms: Lifecycle and Feature Tracking. Lifecycle work items (Release, Sprint, Team Sprint and Sprint Retrospective) are not directly linked to feature tracking items (Product Backlog Item, Sprint Backlog Task, Impediment, Acceptance Test, Bug). Status changes in one paradigm type do not affect the status in the other type. So changing the status of a PBI will not affect the status of Sprint.

However, some other work item field values do have an effect across the types. The SfTS event service includes two updating components: Transition and Aggregation. Transition rules only affect work items of the same paradigm where as Aggregation rules can cross the boundaries. For example: The release work item includes an aggregated sum of PBI story points. The entire suite of work item update rules is defined in the event service configuration files".

September 20, 2010 4:50 PM

Kris Venk said:

Is it possible to track the changeset increments associated with the work item?

In other words, is it possible to identify if a new (incremental) changeset is associated\linked (usually done through check-in process) with the work item?  

If it was possible, I was wanting the users to increase a custom field (Actual hours spent) value.

September 30, 2010 9:34 PM

JohnDB said:

Great introduction, thanks Crispin.

I just want to point out a small error in "Create the project life-cycle items" section, step 5: The year of the start date reads 2020, it should be 2010. Validation on the quick setup screen catches this but you may want to change it.

November 16, 2010 10:04 AM

crispin.parker said:

@JohnDB: All fixed, thanks for the heads up. Crispin.

November 16, 2010 10:10 AM

Crispin Parker's Blog said:

A recent question in the Scrum for Team System Q &amp; A site has highlighted that there is a lack of

December 10, 2010 6:10 PM

Diego said:

Hi i have a question.

In work item SBT you put the estimated effort in hours and have a work remaining, but i don't know where i put the completed time if the develooper complete the task in less time that it was planing.

Help me please...

March 18, 2011 5:38 PM

crispin.parker said:


If you want to track actual time spent, you will need to edit the SBT template to include a new field. I suggest you research customising TFS work items and check out the TFS 2010 Power Tools Visual Studio add-in.


March 18, 2011 5:46 PM

Diego said:

Thanks for you help.

March 18, 2011 10:07 PM

Adam said:

Hi. I've just installed TFS workbench 2.2 to trial and it looks great! However, I am seeing some unexpected behaviour when using filters. If I create a filter that is "Include" "Task" by "Assigned To" for a given developer, the filter tells me that it has some results, but the task board is now empty. Is this a bug? Can you help please?

Many thanks in advance,


March 24, 2011 6:13 PM

crispin.parker said:


When filtering in the workbench, an include will only include items that match the specified filters (everything else is filtered out). So if you only include "Sprint backlog tasks", no "Product backlog items" will be included in the results and you won't see any task board rows.

The solution is to exclude all tasks that don't equal the required user name. This then leaves that PBIs inplace so you can see the rows in the task board.

By the way, a better place to ask questions like this is the Scrum for Team System Q & A web site.

* http://www.scrumforteamsystem.com/qa


March 25, 2011 9:10 AM

Adam said:

Thanks for the reply Crispin. Q&A link duly noted and will use that in the future.

March 25, 2011 11:03 AM

nicolas said:


Thanks for the great intro above.  I also really like the TFS Workbench.

I wondered about why I can only set the sprint start and end date on the Team Sprint Level, and the start and end dates are locked on Sprint Level.  Is the idea not that, as you write, “This planning scope node is used to group teams working at the same cadence”.  I have 3 teams, so having to set up the days, whenever a change in the planed sprint dates occur, is a bit of a waste of time.

Not that I can’t handle it, I just don’t understand why it is that way.



August 11, 2011 3:26 PM

Jodi said:


We are using the Sprint Burndown chart and our current issue with it is that the first day is the starting data point and the first point is hours remaining at the end of the day.  We really want the first data point to show the total capacity, then the burndown for each day.  Also instead of a trend line we would like to show what the daily targets are.

Are these items possible?



September 13, 2011 4:36 PM

irenevan said:

I am really interested in getting this working but I am having little success locating any installation and set-up documentation. I have only found documentation of how the use the application... many of the features in TFS Workbench are grayed out (quick set-up, advance set-up, etc.) which leads me to believe that I might not be configured correctly.

First and foremost: I would love to share a view created by me to be accessible to all my team members. I have had success in creating a new view and setting it up as I want it but my team member is not able to see it.

NOTE: I am using existing project and templates used by the team; project permission are set correctly.

November 4, 2011 7:42 PM

Dipti said:

I have created the following : Release1->Sprint1->TeamSprint1. Then i created a pbi and scoped it to release1 and then implemented it by a sbt. The sbt is scoped to teamsprint1.  The sbt estimated to 8, and work remaining to 4. But, the team sprint did not show any planned hours. The release also does not show any planned or burnt hours..what could be the cause ? Its been more than 2 hours since i updated the hours.

November 7, 2012 12:21 PM

Leave a Comment


This Blog



Powered by Community Server (Personal Edition), by Telligent Systems