Jeroen Swart

One of the things I'm missing in Team Foundation, is an easy way to prioritize and plan workitems (user stories, tasks, bugs, etc.). The easiest way right now, is to open a workitem query in excel and edit the priority of each workitem. But that's not really easy. You need to change the priority field, making sure to provide a correct value that will put the workitem in the right position priority-wise. If you managed to pick the correct values, you need to sort the workitems; which is a manual action.

I would like to be able to drag & drop workitems in the correct position in the list. I don't care about the exact value of the priority field. I only care about the order in which the workitems show when they are sorted by priority. I would also like to be able to easily plan workitems, by moving workitems into (or out of) a specific iteration path. In my case that would be the product backlog and several sprint backlogs, but the functionality should be applicable to all process templates. Finally, I would like to have some sort of status- or scrumboard. Each possible status for workitems is a column on the board and each workitem is represented by some form of card. By moving a workitem card into a specific column, the status of that workitems changes accordingly. We use physical (white)boards, with a recent print-out of the sprint burndown in some corner, but they are of course not connected to TFS.

I did some research on how to build such functionality and, especially, on how to integrate it into TFS Web Access and/or Sharepoint. I quickly found that TFS Web Access would be the easiest way, for me at least :-P. Last month I started a project on codeplex: TFS Scrumboard. Below is a short description and a screenshot.

Project Description
TFS Scrumboard is an extension to TFS 2010 Web Access, providing easy planning and managing of workitem progress.

TFS Scrumboard is build (in C#) as an extension to TFS 2010 Web Access. It is designed to be used in scrum projects, using one of the many scrum process templates available. I use my own custom scrum process template, to support the way we do scrum projects, but no dependency on any kind of process template is assumed.

When installed, TFS Scrumboard provides two extra tabs in TFS Web Access: Planning and Tasks.

The Planning tab is meant for planning and prioritizing workitems. It shows the product backlog and each sprint backlog on the left side, and the workitems in a selected (product/sprint) backlog on the right side. A workitem can be planned by moving it to (dropping it on) a specific sprint backlog or removed from planning by moving it to the product backlog. A workitem can be prioritized by dragging-and-dropping it in the desired position inside a (product/sprint) backlog.

The Tasks tab is meant for managing the progress of workitems during a sprint. It shows vertical swimminglanes which represents one or more statusses of the workitems in a specific sprint. The status of a workitem can be changed by dragging-and-dropping it in the desired swimminglane. A workitem can be prioritized by dragging-and-dropping it in the desired position (vertically).

Goals

• Planning work items, by dragging-and-dropping them into a specific (product or sprint) backlog
• Prioritizing work items, by dragging-and-dropping them into the desired order
• Manage sprint progress, by dragging-and-dropping them into the corresponding swimminglane
• Print workitem cards, to be used on a RL scrumboard (if possible with a link back to TFS, using a camera, some form of (RFID?) tags or (2D?) barcodes)

The last few months, we used a single server for our first TFS installation to host both TFS 2010 and Sharepoint 2010. We started with the single server because of lack of resources on the virtual hosts, and I couldn't wait for the new hardware to arrive :-P.

Today I moved the Sharepoint server to a new dedicated virtual machine. Only a few team projects with a team portal exist yet and since most portals don't have any content except the dashboards, I decided to simply recreate the team portals on the new machine and copy any content manually.

The installation and configuration of the new Sharepoint 2010 server was quick and without problems. We also changed the NAT of the firewall to point our external IP & domainname to the new server, again without any problems.

Then it was time to install & configure the Sharepoint extensions as well as reconfigure the integration with Sharepoint for TFS 2010. I encountered some errors during this part that we quickly fixed, but learned a few lessons that might be usefull for others.

TF250049 & TF25006

The first error happened during the configuration of the TFS Sharepoint extensions on the new Sharepoint machine. Error TF250049 (the URL for Team Foundation Server could not be verified), which in turn was caused by error TF250067 (No connection could be made). This error was solved by first changing the 'Sharepoint Web Applications' configuration on the TFS machine. By adding the new Sharepoint web application (or changing the existing one) the service accounts used by Sharepoint are granted access to TFS.

TF250067 and not associated project portals

Before (re)creating the site collection and project portal sites, you need to add the TFS service account to the farm administrators group in Sharepoint. This will prevent TF250067 errors during the creation of the project portals. The project portal will be created, but without a working association with TFS.

If this happened to you, delete the project portal site before recreating it, again.

Team Project Site collection

To recreate the site collection, navigate to the team project collection in the 'Team Project Collections' node in the TFS admin console and select the SharePoint Site tab. Select 'Edit Default Site Location' (, make any changes to the Default Site Location if you want) and click OK. Since the Sharepoint is a fresh install, you will be prompted to create a new site. This is the site(-collection) for the team project collection, that will contain all the project portals within the team project collection.

Project Portals

The easiest way to recreate the project portals, is to use the tfpt command-line tool that is part of the Team Foundation Power Tools (which can be downloaded from the Visual Studio Gallery). You can easily see what arguments must and can be provided by executing: tfpt addprojectportal /?, but here is some extra information.

The collection argument is the uri of the TFS server, as you configured them e.g. in the Team Explorer. Examples:
/collection:http://tfs.domain.local:8080/tfs
/collection:https://tfs.domain.com/tfs

The teamproject argument specifies the name of the team project. Of course, you need to put the name between quotes if it contains spaces. Examples:
/teamproject:MyProject
/teamproject:"My Other Project"

The processtemplate argument specifies the name of the process template. Again, use quotes if it contains spaces. Examples:
/processtemplate:"MSF for Agile Software Development v5.0"
/processtemplate:"Quintor Scrum 0.8"

If you want to create the portal on a different url, e.g. team project name contains spaces and you do not want those in the url of the project portal, provide both the webapplication and the relativepath arguments.

The webapplication argument specifies the url of the web application (and not the name as the usage help says). Examples:
/webapplication:http://sharepoint.domain.local
/webapplication:https://projects.domain.com

The relativepath specifies the path to the project portal. Examples:
/relativepath:/sites/DefaultCollection/MyProject
/relativepath:/sites/Quintor/MyOtherProject

Process template

The version control part of our process template is the same as both the MSF for Agile and the Microsoft Scrum templates.

Multiple check-out is enabled, because there is no reason to disabled it. Any conflicts can easily be resolved using the tools available in Visual Studio, most of the time even automatically. In some instances however, like when refactoring a lot of code, you may consider checking out the affected files with a check out lock. This is still possible with multiple checkouts enabled, but you need to check-out the file(s) manually and select the ‘Check Out’ Lock type.

Get latest on check-out is disabled, because I want control over when the latest version is downloaded. I get the latest version before I start changing any code, but I don’t want any changes on the server to interfere with my coding work while I’m coding. I’d rather resolve any issues once, during check-in, instead of every time I check out a file. Of course, if I need changes made by others, I will get the latest changes, but I’ll decide when.

I didn’t define any check-in policies. Of course everybody should provide comments, associate with work items, run code analysis and make sure the code builds before check-in. But we’ve decided not to make them policies and let them prevent from checking in. One reason is that, although a policy can check if certain information (like comments or a work item) is provided, a policy can’t check if it is meaningful. So these things will be monitored and if a team member is not providing the required information, we will explain why it is important and help to provide the right and meaningful information.

I also didn’t change the check-in notes. I’ve not used them yet and don’t expect to use them in a scrum project, but decided to leave them in.

The above mentioned settings are the default in the process template, but can of course be changed in a specific team project if there is a need to do so. And if there is a very good reason to do so, we can even change the process template :-).

Branching and merging

Branching and merging is an important part of version control, but not a part of the process template. Based on the Branching guide from the ALM Rangers (http://tfsbranchingguideiii.codeplex.com/), we have decided upon a strategy that will allow us to start simple, grow as we need and even take different approaches if required. Below are the basic choices, where the simplest workable solution is the best.

Always start with a Main folder and make it a branch. For very small projects, this could be the branch where development takes place. Only if maintenance is needed on a released version, a new release branch is created using the label that was created during the build of that particular version.

Create separate development branches for multiple teams, or small projects if working in the Main branch is making that branch unstable. Always create a container folder that holds all the development branches, even if there is (currently) only one development branch. Forward and reverse integration with the Main branch is done as much as possible, to minimize the amount and complexity of conflicts.

Release branches, as already mentioned, but also branches for hotfixes, service packs and other maintenance work are only created when necessary. Such branches can easily be created using the label of the build related to the version requiring maintenance. The complexity of the total branch structure really depends on the project and we use the branching guide as a guideline.

It has been a while since my last post, but I’ve been very busy. I’ve setup a fresh TFS 2010 environment at Quintor and customized it to our needs. I created a custom process template, a custom SharePoint site definition and custom build activities, to name a few. In this and some following posts, I would like to share what I’ve done.

Of course, to be able to edit the process template, I’ve installed the TFS Power Tools. The latest version (now March 2011) can be downloaded from the Visual Studio Gallery.

Since we use Scrum for all our projects, I decided to start with the Microsoft Scrum template (also available in the Visual Studio Gallery). Some parts I left as it is, other parts I’ve changed to fit our process and needs. And I’m sure some more things will change (or change back) once we have more projects done using this template.

I will take a look at the following subjects, and any changes and customizations I've made, in upcoming posts and provide links to them here:

• Version control
• Build automation (including continuous integration)
• Code quality
• Work items
• Reports
• Project Portal
• Security

Test and Lab management are missing because I haven’t touched them yet. As soon as I do, and I will :-), I will add those to the list.