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).
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.
- Launch the SMW application.
- Connect to your new empty TFS Project.
Click menu: File –> Load Project
Use the “Show Project Selector” button to select the required project.
- Select the SMW “Project Setup” mode.
- Click the “Quick Setup” button.
- Next we need to enter some initial project setup parameters. For this test project I entered:
- Project Start Date: 17/05/2010
- Project End Date: 30/05/2010
- Team Name: Team Alpha
- Capacity: 120 Hours
- Sprint Length: 7 Days.
- 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.
- 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.
- 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:
- Click menu: Team –> New Work Item –> Product Backlog Item
- Fill in the fields:
- Title – A brief description of the feature.
- Business Value – A value indicating the comparative value of this feature.
- Story Points – The comparative size of the feature.
- 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>”.
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:
- Select the “Tested By” tab and click the “New” option.
- In the “Add New Linked Work Item” dialog, enter a title for your new test and click “OK”
- Save the work item.
- 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.
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.
- In Team Explorer, select a PBI window.
- Select the “Implemented By” tab and click the “New” link.
- Enter the a brief description of the task in the Title field and click the OK button.
- In the new Sprint Backlog Task form, enter:
- Estimated Effort – The estimated hours the task will take to complete.
- Planning Scope – Set this to [Project] \ Release 01 \ Work Stream \ Sprint 01 \ Team Name
- Work Remaining – Set the initial value of this field to match the estimated effort.
- Description – Add a full description of the task here.
- And Save.
- Repeat this for each task that needs to be completed in order to create the required PBI feature.
- 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:
- Select the impeded PBI in Team Explorer.
- Select the “Impeded By” tab and click the “New” link.
- In the new work item dialog, enter a brief description of the impediment and click OK.
- 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:
Senior Practice Consultant,