This posts relates to the Scrum for Team System version 3 process template and Team Foundation Server 2010 RC.
The Scrum for Team System version 3 Release Candidate (SfTS v3 RC) is available for download. This release fixes several bugs, improves performance and adds some new features which I will discuss below. It also affects users of Scrum for Team System v3 Beta 2 wishing to upgrade to the RC.
Note: Due to some breaking TFS API changes you can only install SfTSv3RC into a TFS 2010 RC environment.
Scrum Masters Workbench:
- Added the ability to filter by feature scope (area path).
- Added state colour options for swim lane items.
- Fixed several bugs.
- Improved performance.
- Fixed the issue with the synchronisation process changing the SBT planning scope to match the parent PBI.
- Fixed the planned work rollup aggregation in Team Sprints.
- Added some new SBT status descoping rules in order to help implement the behaviour described in Simon Bennett’s blog post.
- Changed the work item field name specifications. See “A Choice Of Compatibility” below.
A Choice Of Compatibility.
We’ve had to make some compatibility decisions in the SfTS v3 RC release. During the SfTS v3 Beta 2 trail it became apparent that we had a compatibility issue with the TFS 2008 scrum template. SfTS v3 Beta 2 and SfTS v2.x (TFS 2008) cannot coexist in a single TFS 2010 instance.
“SfTS v3 Beta 2 and SfTS v2.x (TFS 2008) cannot coexist in a single TFS 2010 instance.”
Some of the display field names in the beta release match the names used in the TFS 2008 scrum template. Due to the way in which TFS stores the work item field definitions (in the data warehouse), both reference and display names must be unique each field definition. Changing just one and not the other of the names causes a problem.
The clash of field names means that migrating a TFS 2008 data instance (that included SfTS v2) into a TFS 2010 environment and installing the SfTS v3 beta 2 would break the warehouse process. Once the warehouse becomes invalid, no TFS data can be processed and all TFS reporting will stop working. Not good.
Obviously, breaking the TFS warehouse process isn’t an option. Also, telling 30,000 SfTS v2 users that they couldn’t upgrade to TFS 2010 didn’t seem right either. So we took the decision to sacrifice a possible beta 2 upgrade path and rename the scrum fields in SfTS v3 RC.
Field Naming in the SFTS templates.
The below section details the history of the Scrum template field names.
SfTS v1 (TFS 2005 RTM):
- Name: "Work Remaining"
- Ref Name: "Conchango.VSTS.Scrum.WorkRemaining"
SfTS v2 (TFS 2008 RTM):
- Name: "Work Remaining (Scrum)"
- Ref Name: "Conchango.TeamSystem.Scrum.WorkRemaining"
SfTS v3 Beta 2 (TFS 2010 Beta 2):
- Name: "Work Remaining (Scrum)"
- Ref Name: "Scrum.WorkRemaining"
SfTS v3 RC (TFS 2010 RC):
- Name: "Work Remaining (Scrum v3)"
- Ref Name: "Scrum.v3.WorkRemaining"
But What About My Beta 2 project?
By changing the field names in the RC version we have stopped the ability for Beta 2 projects to get upgraded. This will not stop Beta 2 projects working. You can upgrade your servers to run TFS 2010 RC and continue to use your existing beta 2 project, but you cannot upgrade an existing SfTS v3 beta 2 project to SfTS v3 RC.
The other downside is that the SfTS v3 RC event service (installed as part of the SfTS v3 RC) will not update beta 2 projects. This is because the event service uses the field names in order to process changes and, as stated, we’ve change them all.
The needs of the many have out weighed the needs of the few in this situation. The possibility to upgrade a beta 2 project to a RC project has been sacrificed in order to allow all the existing v2 users the ability to update their infrastructure to TFS 2010 come RTM time. Maybe tough on early beta adopters but clearly the right choice for the majority.
Senior Practice Consultant,