Crispin Parker's Blog

Team Foundation Server 2010 RC Job Service Delay

crispin.parker — Fri, 05 Mar 2010 10:57:08 GMT

This post relates to Team Foundation Server 2010 RC, the Scrum for Team System version 3 process template and TFS event notifications.

In TFS you can setup notifications to be sent on events like Build complete and work item changes.

Introduced in the TFS 2010 release candidate is the ability to set a process delay time for notifications. By default the delay time is set to 2 minutes. This is intended to reduce the load on the TFS job agent process during periods of heavy load.

“2 Minute Notification Delay”

In the SfTS solution we use this change notification to trigger our event service updates. Unfortunately the new 2 minute delay means that we no longer get an instant notification of work item updates. This delay makes the event service slower to respond and can cause you to see the dreaded “TF237079” error message more often.

Luckily, there is a way to reduce / remove the notification delay.

Removing Job Service Notification Delay

In order to change the notification delay duration, you will need to add a data row to a table in the “Tfs_Configuation” database.

Launch SSMS and connect to the TFS Database Engine.

Run the following script:

USE Tfs_Configuration
GO

IF NOT EXISTS 
(
    SELECT * 
    FROM tbl_RegistryItems
    WHERE ParentPath = '#\Service\Integration\Settings\' 
    AND ChildItem = NotificationJobDelay\'
)
BEGIN
    INSERT INTO tbl_RegistryItems (ParentPath, ChildItem, RegValue)
    VALUES ('#\Service\Integration\Settings\', 'NotificationJobDelay\', 0);
END
ELSE
BEGIN
    UPDATE tbl_RegistryItems 
    SET RegValue = 0
    WHERE ParentPath = '#\Service\Integration\Settings\' 
    AND ChildItem = 'NotificationJobDelay\'
END

-- Queue up an application update. 
INSERT INTO tbl_NotificationQueue (EventClass, EventData) 
VALUES 
(
    '0e9c44d7-52eb-4dca-b467-f1a4fe3c469a', 
    '<ArrayOfRegistryEntry><RegistryEntry Path="#\Service\Integration\Settings\NotificationJobDelay\\">' +
    '<Value>0</Value></RegistryEntry></ArrayOfRegistryEntry>'
);

This sets the job service delay to zero and you get instant notifications once again.

Regards,

Crispin Parker,
Senior Practice Consultant,
EMC Consulting.

Edit: Apparently I was using a sledge hammer to open a peanut with my first post on this subject. I have now altered the SQL script to be a little more gentle on the TFS infrastructure. Chris Sidi’s post explains it all in great detail and even gives you a Powershell script to run in place of the above SQL.

Scrum for Team System v3 – Release Candidate

crispin.parker — Fri, 26 Feb 2010 12:20:00 GMT

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.

What’s New?

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.

Event Service:

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.

Process Template:

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.

Final Thought.

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.

Links:

Regards,

Crispin Parker,
Senior Practice Consultant,
EMC Consulting.

Scrum for Team System v3 – Deep inside the Aggregation service

crispin.parker — Tue, 26 Jan 2010 14:03:02 GMT

This post relates to Team Foundation Server and the Scrum for Team System process template.

Previously I have described the Event Service and have taken a closer look at the Transition Service. In this instalment I’ll describe the Aggregation service and it’s configuration.

In order to enhance the features of TFS 2010, we have added a web service that subscribes to the TFS work item changed notification. This gives us the ability to update related work items when certain triggering events are detected. The TFS change notifications are queued into a central service controller which in turn distributes them to all the registered service processors. The default SfTS v3 installation gives you two service processors; Transition and Aggregation.

The Transition processor handles the actions that relate to single work item instances, while the Aggregation service handles updates that involve collections of work items. The aggregation service also offers an alternative linking method, inferred linkage by work item path. More about this below.

The Aggregation Service

Unsurprisingly, this service offers the ability to execute aggregated updates to work items. These updates can be either “Sum”, “Min”, “Max” or “Average”.

An excellent example of this service in action is the “Product Backlog Item” (PBI) Work Remaining value. PBIs describe a required feature of the project output. To break the feature requirement down into task actions, you create linked work items called “Sprint Backlog Tasks” (SBT). Each SBT is given a “Work Remaining” value that indicates the duration of effort remaining in order to complete the specified task. The aggregation service sums up the total of the linked SBTs and updates the PBI work remaining value. Each time any of the SBTs remaining duration is changed, the service will update the associated PBI.

When the service updates a work item, it also adds a description of the action to the work item history. The above example states that the sum of associated tasks work remaining has been applied.

In this manner, the aggregation services can update work items to show values based on other work items. This is not a feature of standard TFS, but one I like to think adds a great deal of depth to work item linkage.

Inferred Linking.

Because the aggregation of a work item value can potentially involve a large number of other work items, we have added an alternative way to specify linkage. Imagine that you want to roll up the total number of story points in a release. If you could only roll up linked work item values, you would have to directly link every PBI to the Release work item. A single release might contain hundreds of PBIs and maintaining all those links isn’t going to be fun task, even for a temp. To combat this, you can create aggregation rules that work by Inferred linkage.

The concept of inferred linkage is that you consider work item paths as an indication of a relationship. Looking at our “completed story points in this release” rule, we can say: “Rollup all PBI story Point values where the iteration path under this release”. No direct linkage is required to do this, so you can take an extra hour for lunch with the time you saved not adding hundreds of work item links (or get rid of the temp).

This is why it is very important to maintain the correct planning path structure in your SfTS v3 work items. If you alter the default path hierarchy (Project / Release / Work Stream / Sprint / Team Sprint), the inferred aggregation rules will not be able correctly ascertain the relationships. Of course you could update all the rules to work with your new path structure and you might want to bring back the temp to help out with the additional work load.

You can use both Iteration (planning) and Area (Feature) paths to indicate an inferred link.

What Changes Trigger an Update?

It’s not only the field values changing that can trigger the update service. The aggregated value can also be affected by changing work item linkages, paths and states. The service rule definitions also allow you to specify a list of excluded states. Moving a work item in or out of an excluded state will also trigger an update.

Triggers:

The aggregated field value is changed.
The work item state is change from or to an excluded state.
The work item linkage is changed (direct links).

or
The work item path value is changed (inferred links).

Where can I find the default Rule definitions?

The default installation location of the Aggregation rules file is located on the TFS AT at:

C:\Program Files\Scrum for Team System\Services\3.0\Rules\AggregationRules.xml

What does A Rule look like?

Below are two examples of aggregation rules. The first rule describes the PBI work remaining calculation and the second shows the PBI story point roll up.

PBI work remaining (using direct links)

<AggregateRule type="Sum">
<WorkItemType source="Sprint Backlog Task" target="Product Backlog Item" />
<Link linktypename="Scrum.ImplementedBy" isforward="true" />
<Field source="Scrum.WorkRemaining" target="Scrum.WorkRemaining" />
<ChangeNote>Sum of associated task(s) work remaining applied.</ChangeNote>
<ExcludedSourceStates>
<State>Deleted</State>
</ExcludedSourceStates>
</AggregateRule>

Release Story Points (using inferred linkage)

<AggregateRule type="Sum">
<WorkItemType source="Product Backlog Item" target="Release" />
<InferredLink path="IterationPath" type="Partial" depth="2" />
<Field
      source="Microsoft.VSTS.Scheduling.StoryPoints"
      target="Scrum.PlannedVelocity"
/>
<ChangeNote>Sum of planned backlog item(s) points applied.</ChangeNote>
<ExcludedSourceStates>
    <State>Deleted</State>
</ExcludedSourceStates>
</AggregateRule>

Rule Definition Breakdown

Let’s break the rule definition down into it’s component parts.

Aggregate Rule

The rule container element.

<AggregateRule type="Sum">
...
</AggregateRule>

Attributes:

type – Describes the aggregation action. Possible values are “Sum”, “Min”, “Max” and “Average”.

Work Item Type

Defines the work item types involved in this rule.

<WorkItemType source="Product Backlog Item" target="Release" />

Attributes:

source – The source work item type to be aggregated.

target – The target work item type to be updated.

Link

Details the work item link type to be used in the aggregation.

Note: Aggregation rules must specify either a “Link” or an “Inferred Link” but not both.
<Link linktypename="Scrum.ImplementedBy" isforward="true" />

Attributes:

linktypename – The linkage type name.

isforward – Boolean value to indicate if the target work item is on the forward side of the link.

Inferred Link

This element describes the inferred link for this rule.

Note: Aggregation rules must specify either a “Link” or an “Inferred Link” but not both.
<InferredLink path="IterationPath" type="Partial" depth="2" />

Attributes:

path – Details which work item path is going to be used to infer the relationship. This value can be either: “IterationPath” or “AreaPath”.

type – Describes the type of path matching to use. This can be either “Partial” or “Complete”. Partial paths match to a specified depth and complete matches the entire path.

depth – Used in conjunction with the “Partial” type to indicate the depth of path to match.

The example shows a depth of “2”. This means that only the “Project / Release” part of the iteration path will be matched between the target and source work items.

Field

This details which the the work item fields to use for this rule.

<Field source="Scrum.WorkRemaining" target="Scrum.WorkRemaining" />

Attributes:

source - The field on the source work item to aggregate.

target – The field on the target work item to update.

Change Note

The text to enter into the target work items history when a change is made.
<ChangeNote>Sum of associated task(s) work remaining applied.</ChangeNote>

Excluded Source States

A list of states that indicate a source work is ignored from aggregation.

<ExcludedSourceStates>
<State>Deleted</State>
</ExcludedSourceStates>

A Word of Warning!

When customising rules in either the Transition or Aggregation service, make sure you take extra care not to cause any circular references. If you set one rule to change a field value that in turn triggers another rule, that in turn triggers the original rule, that in turn triggers the other rule... Well I expect you get the picture. Take time to plan the relational updates between your work items and keep an eye out for circular rule references. Remember that an infinite loop might involve more than just two rules.

Handy Links

Regards,

Crispin Parker,
Senior Technical Consultant,
EMC Consulting.

Scrum for Team System v3 – Installer Environment Options.

crispin.parker — Fri, 22 Jan 2010 11:50:50 GMT

This blog relates to the Scrum for Team System version 3 template installation process.

The SfTS v3 installer includes some additional MSIEXEC command line switches that allow you to specify environment variables.

SQL Server Named Instance

Use this switch when your target SQL server is a named instance.

Switch:

TEAMFOUNDATIONSERVERDTSQLINSTANCENAME
Default Value:

This parameter value defaults to the target [Computer Name].

Team Foundation Server Web Site Description

Use this switch to target the TFS web site.

Note: This must be the TFS AT web site in order for the event service to gain the correct permissions.

Switch:

TEAMFOUNDATIONSERVERWEBSITEDESCRIPTION
Default Value:

”Team Foundation Server”

Team Foundation Server Web Site Port

This parameter lets you specify an alternative port number.

Switch:

TEAMFOUNDATIONSERVERWEBSITEPORT
Default Value:

8080

Event Service End Point

This value details the Event Service Work Item Changed notification end point.

Note: You must update this value to indicate any changes to the TFS port number.

Switch:

SFTSEVENTSERVICEENDPOINTURL
Default Value:

http://localhost:8080/ScrumforTeamSystem/3.0/WorkItemChangedEndpoint.asmx

Example Installation Command Line

The following example sets an alternative SQL Server instance name, web site name and port number.

MSIEXEC /i ScrumforTeamSystem.3.0.3621.03.msi /l*v install.log
TEAMFOUNDATIONSERVERDTSQLINSTANCENAME=”Named Server”
TEAMFOUNDATIONSERVERWEBSITEDESCRIPTION=”Alternative TFS Web Site”
SFTSEVENTSERVICEENDPOINTURL=
”http://localhost:8081/ScrumforTeamSystem/3.0/WorkItemChangedEndpoint.asmx”
TEAMFOUNDATIONSERVERWEBSITEPORT=8081

And Another Thing…

A recent forum post highlights another possible setup scenario. This time the SQL Server instance is not named, but the Reporting Services instance is. In this case you can use the “REPORTSERVERSERVICENAME” command line switch as demonstrated below:

msiexec /i "ScrumforTeamSystem.3.0.3698.00.msi" /l*v install.log
REPORTSERVERSERVICENAME="MyReportingServicesName"

Handy Links

Regards,

Crispin Parker,
Senior Technical Consultant,
EMC Consulting.

Edit: Added an extra parameter because the Event Service end point also needs updating.

Edit: Added an extra section to describe the REPORTSERVERSERVICENAME command line switch.

Scrum for Team System v3 – Work Item Relationships

crispin.parker — Thu, 21 Jan 2010 11:48:44 GMT

This post relates to Scrum for Team System version 3.

A recent comment revealed that there is some confusion on how the work items are linked in the new SfTS v3 template, so here is a quick reference guide:

Life cycle work items:

The life cycle work items deal with tracking the time lines of the project. They are closely related (and add meta data) to the project Iteration Path. These work items are not directly linked to the feature tracking work items, however some aggregated values are rolled up by using an inferred linkage based on the iteration path.

Release
Sprint
Team Sprint

Feature tracking work items

The feature tracking work items deal with the content and status of the product backlog. The main component of the feature tracking work items is the “Product Backlog Item” (PBI). The status and requirements of the PBI are described by the other linked work items.

Product Backlog Item
Sprint Backlog Task
Acceptance Test
Impediment
Bug Report

You can find a wealth of additional information on the new SfTS version 3 infrastructure in Simon Bennett's Blog.

Handy Links:

Scrum for Team System - V3.x Beta 2 Discussions

Scrum for Team System – Home Page

Scrum in the Enterprise - PDC Presentation Webcast

Regards,

Crispin Parker,
Senior Practice Consultant,
EMC Consulting.

Scrum for Team System v3 – Scrum Masters Workbench Task Board

crispin.parker — Wed, 20 Jan 2010 15:00:05 GMT

This post relates to Team Foundation Server, Scrum for Team System and the Scrum Masters Workbench.

One of the most asked questions about our new version 3 Scrum template is “where is the task board?”. The task board applications and our process templates seem to have become considered a single entity. Well it’s good news, as today we have released the first beta edition of a version 3 compatible task board application.

This time around the task board is a component of the Scrum Masters Workbench application.

So What’s New?

One of the limitations of the previous Task Board applications is that you couldn’t easily change the display layout or add customisations and it was only possible to connect to Scrum for Team System projects. So we’ve addressed all these points in the new version.

Now you can:

Control any TFS project (including SfTS v2, SfTS v3 or even MSFAgile)
Add custom work item states.
Create your own views for work item relationships.
Control multiple work item types in multiple tabs.
Instantly re-arrange swim lane columns by dragging the header text.
Easily control which states are displayed as columns.

All the displayed work item information is completely controlled by the TFS project definition. Add a new field control to a work item definition and it will appear in the task board. Add a new state and it will be available as a swim lane column. The whole application has been designed with customisation and flexibility in mind.

Download

To get your hands on the beta installers follow the below link:

Task board for SfTS version 3

Note: This application requires Visual Studio 2010 Team Explorer to be installed.

Handy Links

This is beta software so there maybe some issue. Please report any bugs or issues in the discussions forum.

Regards,

Crispin Parker,
Senior Practice Consultant,
EMC Consulting.

Scrum for Team System v3 – Deep inside the Transition Event Service

crispin.parker — Fri, 15 Jan 2010 18:23:40 GMT

This post relates to the Team Foundation Server Scrum for Team System process template event service. It assumes that you have a basic understanding of TFS work items and their fields.

In my last post I gave you an overview of the SfTS event service. Here I pick up the story again and look at the Transition service rules.

The event service code is written with extensibility in mind using the Microsoft Extensibility Framework. Out of the box it comes with two flavours of work item changed event processors; Transition and Aggregation. Both services have a set of rules that are defined in XML configuration files. The MEF plug-in assemblies and the controlling rules files can be found under the SfTS v3 installed web service folder on the TFS AT.

Default Installation Plug-in Folder:

C:\Program Files\Scrum for Team System\Services\3.0\Plugins
Default Installation Rules Folder:

C:\Program Files\Scrum for Team System\Services\3.0\Rules

The Transition Service

The transition service handles work item field changes from one value to another. Transition rules can be set to either update the source work item or work items linked to the source item.

Example Transition Rule

Scenario: In our SfTS project, we have a “Product Backlog Item” which links to several “Sprint Backlog Tasks” using the “Scrum.ImplementedBy” link type. When all the linked SBTs are set to a state of “Deleted” we want the Transition Service to automatically set the PBI to “Deleted”.

Here is sample of a XML transition rule that will apply our desired functionality:

<TransitionRule>
<WorkItemTypeName
      source="Sprint Backlog Task"
      target="Product Backlog Item" />
<Transition
      field="System.State"
      from="*"
      to="Deleted" />
<LinkType target="LinkedItem">Scrum.ImplementedBy</LinkType>
<ChangeNote>All tasks have been deleted</ChangeNote>
<EligibleTargetStates>
    <State>In Progress</State>
    <State>Done</State>
</EligibleTargetStates>
<Replacements>
    <Replacement
        targetfield="System.State"
        type="Specified"
        decimalplaces="0"
        >Deleted</Replacement>
</Replacements>
<SiblingConditions>
    <SiblingCondition
        comparison="All"
        field="System.State"
        value="Deleted"
        siblingtype="Sprint Backlog Task"
        link="Scrum.ImplementedBy">
      <ExcludedStates>
        <State>Ignored</State>
      </ExcludedStates>
    </SiblingCondition>
</SiblingConditions>
</TransitionRule>

Note: This isn’t a real rule that exists in the SfTS solution, its just an example.

Transition Rule Components Breakdown

So let’s break down the example rule to see what all the bits do.

Transition rule:

<TransitionRule>
- The container for the rule specification.
Work Item Type Name:
<WorkItemTypeName source="Sprint Backlog Task" target="Product Backlog Item" />
- Source. The type of the changed work item to match. The sample rule will match a source work item of type “Sprint Backlog Task”.
- Target. The type of linked work item to update. the sample will target work items of type “Product Backlog Item”.
Transition:
<Transition field="System.State" from="*" to="Deleted" />
- Field. The name of the source work item field to monitor for changes.
- From. The previous field value. The sample rule uses the wildcard “*” character, this means that any previous value will match the rule.
- To. The new field value. The “to” value of the sample transition is set to “Deleted”. This means that this rule will only match work items that have a new “System.State” value of “Deleted”.
Link Type:

<LinkType target="LinkedItem">Scrum.ImplementedBy</LinkType>
- Target. The work item to target. This value can be either “Self” or “LinkedItem”.
- The work item linkage type name. This is the type of linkage between the source and target work items.
Change Note:

<ChangeNote>All tasks have been deleted</ChangeNote>
- The note to be written to any updated work items change history.
Eligible Target States:
<EligibleTargetStates>
<State>In Progress</State>
<State>Done</State>
</EligibleTargetStates>
- A list of target work item states that are eligible to match this rule. This example will only target work items that are in a state of either “In Progress” or “Done”.
Replacements Collection:

<Replacements>
- This contains a collection of replacement specifications. A single rule can contain multiple replacements and update multiple fields on the target work item.
Replacement:
<Replacement targetfield="System.State" type="Specified" decimalplaces="0">Deleted</Replacement>
- Target Field. The field on the target work item to update.
- Type. The replacement value specification type. This can be either “Specified” or “Expression”.
- Decimal places. Used when specifying an expression to limit the precision of the returned value.
- Node content. The replacement value. If the type is “Specified” then the value is used as is. A type of “Expression” means that the value represents a calculation expression. More on expressions below.
Sibling Conditions:

<SiblingConditions>
- A collection of Sibling condition specifications. More on siblings below.
Sibling Condition:
<SiblingCondition comparison="All" field="System.State" value="Deleted" siblingtype="Sprint Backlog Task" link="Scrum.ImplementedBy">
<ExcludedStates>
<State>Ignored</State>
</ExcludedStates>
</SiblingCondition>
- Comparison. Specifies which sibling items to consider. This can be either “All” or “Any”.
- Field. The field on the sibling item to compare. The sample rules specifies that the “System.State” field value should be examined.
- Value. The field value to be matched. The sample rule checks for a value of "Deleted".
- Sibling Type. The sibling work item type of the. Example: "Sprint Backlog Task".
- Link. The work item linkage between the target and sibling work items. Example: "Scrum.ImplementedBy"
- Excluded states. A list of sibling work item states to ignore from the condition test.

Replacement expressions

The replacement component of the transition rule can specify two types of replacement value; Specified or Expression. “Specified” indicates that the value is used “as is” and “Expression” means that the value is interpreted as an expression.

Expressions allow you to specify a field name or a simple mathematical formula. Formulas can use the add, subtract, multiple and divide operator symbols (+, –, *, /) and the operand values can be either numerical or work item field names.

Expression Examples:

Scrum.BusinessValue / Microsoft.VSTS.Scheduling.StoryPoints

This expression divides the “Scrum.BusinessValue” field value by the “Microsoft.VSTS.Scheduling.StoryPoints” field value.

Note: When using mathematical expressions, only fields with a “Double” data type can be specified.
System.IterationPath

This expression returns the value of the “System.IterationPath” field.
Scrum.BusinessValue * 2.5 / 100

The above expression returns the “Scrum.BusinessValue” field multipled by 2.5 and divided by 100.

Note: Calculations are made in left to right operand pair sequence. So the above example will be the result of “Scrum.BuinessValue” multiplied by 2.5 that is then divided by 100.

Siblings

Transition rules can include a collection of “Sibling” conditions. Siblings are work items that share a common linked target work item. For example in our “Make PBI Deleted” scenario, we specify that all work item Sibs of type “Sprint Backlog Item” that are linked to the target PBI with by a “Scrum.ImplementedBy” linkage, must also be in a state of “Deleted”. From the PBI point of view, this means that all my linked SBTs must be in a state of “Deleted” before this rule can be applied.

You can add multiple sibling conditions that can the reference any work item type linked by any linkage type.

Sibling conditions also allow you to set a list of sibling states that exclude work items from comparison. This is useful in order to handle scenarios where some work items should be ignored.

Links

Next time I will delve into the Transition sister service; the Aggregation service.

Scrum for Team System v3 – Event Service

crispin.parker — Wed, 02 Dec 2009 16:56:00 GMT

This post relates to Team Foundation Server 2010 and the Scrum for Team System version 3 process template.

Now that the SfTS version 3 beta 2 is out the door, I have a chance to reflect back on some of the work that went into getting it this far. One component I am partially fond of is the Event Service.

The event service has been a component of the SfTS template solution since version 2. The chances are that you never noticed it busily working away in the background rolling up states and summing up work remaining figures. This much is also true in the version 3 template, it works quietly in background to make your project housekeeping easier and to give you useful figures. But in SfTS v3 it does a lot more heavy lifting.

So what is it?

The event service is a web application that is installed into the TFS AT (Team Foundation Server Application Tier) when you select the “Service” feature of the SfTS installer. The TFS AT passes a set of change data to the service endpoint whenever an altered work item is saved.

Using a set of configuration rules, the service examines the changes to determine if they affect any work items in the project. If changes to work items are required, the rules define the new values and the service updates the work item(s).

You can see the service changes made to your work items by examining the work item history. The name of the service and the action taken is included in the history details.

Controlling the service and synchronising work items:

The installed web application includes three service end points. The first is called by TFS in the event of a work item change, the other two are called manually by the TFS administrator.

Service Control

Unsurprisingly, this web service end point allows you to control the service! Actually, it allows you to start, stop and check the status of the work item changed service.

The service control end point is located at:

http://[TFSHOST]:[TFSPORT]/ScrumforTeamSystem/3.0/ServiceControl.asmx

Synchronise All

The “Sync All” service schedules a special job in the event service queue. Upon de-queuing a sync all request, the service will load all work items [in the specified project] and apply any rule matches. In this way, you can use this service to correct and synchronise all the work items. Obviously, this is a process intensive exercise and should only be executed when the TFS instance is not under any heavy load, possibly out of office hours.

This service end point requires two parameters;

tfsAddress – The project collection URL.
projectName – The project name to synchronise.

The sync all end point is located at:

http://[TFSHOST]:[TFSPORT]/ScrumforTeamSystem/3.0/SyncAll.asmx

Under the hood:

As the service runs in background, you can’t see much action while it’s working. However, you can get to see more by enabling event logging.

Event Logging

To set this up, you will need to create and edit files on the TFS AT.

Create an empty, accessible log file.

The event service runs under the same app pool as the TFS AT. In order to make log entries, the app pool user account must have write permission to the target log file. The easiest way to accomplish this is to create local file and give the “everybody” group full permission over it.

Example: c:\users\[Profile Name]\AppData\Local\Temp\SfTSEvent.log
Open the event service “web.config” file.

The configuration file is located at:

C:\[Program Files]\Scrum for Team System\Services\web.config

Note: You may have to open the file with elevated privileges.
Add the log file path to the relevant setting value.

Change:

<setting name="LogFilePath" serializeAs="String">
<value/>
</setting>

To:

<setting name="LogFilePath" serializeAs="String">
<value>c:\users\[Profile Name]\AppData\Local\Temp\SfTSEvent.log</value>
</setting>
Save the config file.

Now the details of the event service actions will be written to the log file.

Well that's it for a high level look at the event service. In future posts I'll discuss the Work Item Changed event, Transition rules, Aggregation rules and customisations.

Scrum for Team System Version 3 Beta 2 – Released!

crispin.parker — Mon, 30 Nov 2009 18:10:00 GMT

It’s out, in the wild and running free!

Grab the installers from the below linked forum post:

Scrum for Team System Version 3 Beta 2 released

Crispin Parker,
Senior Practice Consultant,
EMC Consulting.

Scrum for Team System v3 Beta 2 – Scrum Masters Workbench

crispin.parker — Fri, 27 Nov 2009 18:14:54 GMT

This post will give you a quick overview of the new Team Foundation Server 2010 (TFS) project setup utility entitled: Scrum Masters Workbench (SMW) and how it is used with the forthcoming Scrum for Team System version 3 (SfTS)process template.

The new SfTS process template offers the ability to support practically any type of TFS project team configuration. This ranges from a simple single team project to multiple teams working in multiple work streams at differing cadences on multiple releases and much, much more!

Obviously, this means that project setup can be a little overwhelming when using the standard Visual Studio tools*. In fact this is exactly the feedback reported by our Beta 1 testers.

* Formally known as Team Explorer and now included in Visual Studio 2010 Ultimate edition.

The SfTS Beta 2 template is imminent and to be released to a much wider audience than the Beta 1 edition. So we have produced a new project setup utility to help project administrators get new projects up and running with the minimum of hassle. The setup utility is a component of the SMW.

The “Project Setup” mode within the SMW gives you a visual representation of the project iteration path structure and [when connected to a SfTS v3 based project] the new project life cycle work items; * Release, Sprint and Team Sprint.

* See Simon Bennett’s blog for more information on the new project life cycle work items

SfTSv3 projects contain no pre-defined work item instances (unlike SfTS v2 projects). So to get you started the utility offers two setup modes; “Quick Setup” and “Advanced”.

Quick Setup Mode:

This mode gives you a limited set of options so that you need only enter the bear minimum of configuration data:

Project Start Date
Project End Date
Team Name
Team Capacity (hours of effort available per sprint)
Sprint Length (in days)

The project structure generated from this mode follows a single; Release, Work Stream, Sprint and Team pattern.

Quick Setup Project Structure

Advanced Mode:

This setup option is intended to help the project administrators of larger, multi-team projects.

It offers the ability to specify multiple Releases, Work Streams and Teams. Project structures created using this mode can be very complex:

Additional Setup Options:

Once the initial project setup is complete, you can tweak and adjust the various nodes as required. Right-clicking on a node gives you a context menu of further options:

New Associated Item (SfTS v3 projects only)

This option is available from nodes that match the iteration path depth of a life cycle work item but do not have an associated item. See Life Cycle Work Items and the Iteration Path below for more information on node branch depth.
Edit Associated Item (SfTS v3 projects only)

Opens the edit dialog for the associated work item. Note: This is also accomplished by clicking the node name link.
Show Descendents Only

Filters the visible nodes to the selected node and it’s children only.
Add Child

Adds a new iteration path child node to the selected item. If this is a SfTS v3 project and the new child node matches a life cycle work item depth, this will also create a new associated item.
Rename

Allows you to change the name of the node. Note: Changing an iteration path node name will affect all the child nodes (and associated work items). So make sure you save any work item changes prior to using this option.
Delete

Deletes the selected node and all it’s descendents. Note: This action will affect all existing work items that are associated with the deleted node and it’s child nodes. Make sure you save all work item changes prior to using this mode.

Life Cycle Work Items and the Iteration Path:

In SfTSv3 projects, life cycle work items have a strict dependency on iteration path nodes at set branch depths. This association is required in order to ensure that both the reporting and event service features of the template can work correctly.

Release Work Items (Level 2)

Must be associated to iteration path nodes at the level two branch depth.
Sprint Work Items (Level 4)

Must be association to iteration path nodes at the forth level depth.
Team Sprint Work Items (Level 5)

Must be association to iteration path nodes at the fifth level depth.

Finally:

The SMW beta release will be made available for download alongside the SfTS v3 Beta 2 template. Watch the forums for more information.

http://www.scrumforteamsystem.com/cs/Forums

Crispin Parker,
Senior Practice Consultant,
EMC Consulting.

Scrum for Team System Version 3 (Beta 2) – Project Collections and Template Deployment

crispin.parker — Thu, 26 Nov 2009 15:45:40 GMT

In this post I’ll discuss the TFS 2010 project collection structure and reveal the Scrum for Team System version 3 deployment utility.

Since the introduction of TFS 2010 (currently at Beta 2 release) Microsoft have introduced the concept of Project Collections. Project collections allow multiple TFS team projects to co-exist in a single database instance. This in turn means that you can do things like; write cross project queries and have better control over project security.

However, this does cause a few problems for the SfTS template and deployment. Each project collection holds its own group of deployed templates. So you must deploy the process template into each project collection that you wish to use with Scrum. That’s not all; our Scrum solution also requires a subscription to work item changed events. This too needs to be done for each collection.

Step forward the “SfTS Process Template Manager”.

The template manager offers two working modes; “Quick Deploy” and “Advanced”.

Quick Deploy:

This mode is displayed by default when all environment settings have been automatically detected. It is intended for standard TFS setups.

Note: Quick Deploy is dependent on the environment settings that can be seen under the advanced mode. If these settings are missing or incorrect, the quick deploy commands will be disabled.

Quick Deploy Commands:

Quick Deploy has three simple commands; List Collections, Deploy and Retract.

List Collections

Connects to the TFS instance and displays a list of all available project collections. The collection list also indicates the deployed status of the SfTS template.
Deploy

Adds the SfTS template to the selected collection and registers a Work Item Changed event subscription.
Retract

Removes the SfTS template from the selected collection and withdraws any existing event subscription.

Advanced:

The advanced mode offers greater control over deployment and subscriptions, the ability to specify environment settings and a view of the selected collections’ templates / subscriptions. This mode is intended for advanced administrators and complex deployment environments.

Environment Settings:

The environment settings section allows you to specify the: TFS instance to connect to, template meta data file and template content zip file.

TFS Url

By default the URL is set to “http://localhost:8080/tfs”. If you need to specify an alternative TFS address you can do so here.
List Collections

Clicking this button when a valid URL is specified loads a list of project collections. If the TFS URL is not specified of the URL is not valid, the project collection selection dialog will be displayed.
Meta Data File

This file contains information on the Process Template. This information is used to determine the deployed status [of the template] in the selected project collection. By default, the Meta data file is installed into the “[Program Files]\Scrum for Team System\ProcessTemplate\” folder.
Template Zip File

This file contains all the configuration parts of the template that will be deployed to the selected collection. The default installation location for this file is:

[Program Files]\Scrum for Team System\ProcessTemplate\ProcessTemplate.zip

Collection List:

A list of available process templates is displayed below the Environment Settings section once the “List Collections” button has been clicked. Select a collection in this list in order to interact with it.

Advanced Command Options:

Deploy

Uploads the specified template to the selected collection.
Retract

Removes the specified template from the selected collection.
Subscribe

Adds an event subscription to the selected collection. The event subscription end point is generated using the web address specified in the TFS Url environment settings section.
Unsubscribe

Removes all subscriptions from the selected collection that match the SfTS work item changed event end point.

Collection Templates:

The selected collections deployed process templates are listed here. This information is displayed for information only at the current time. The template that is deployed or retracted is controlled by the specified environment settings above.

Event Subscriptions:

The subscriptions present in the selected collection. As above, this list is for information purposes only.

Finally:

The Process Template Manager utility is intended to run on the target TFS application tier after the installation of the SfTS template. It is installed as part of the “Process Template” feature within the version 3 (Beta 2) “Scrum for Team System” installation process.

All this coming to a “Scrum for Team System 2010 Beta” release near you soon. Watch the forums for more news…

http://scrumforteamsystem.com/cs/forums/

Crispin Parker,
Senior Technical Consultant,
EMC Consulting.

Exporting TFS 2010 WIQL Queries

crispin.parker — Fri, 10 Jul 2009 09:57:00 GMT

During the recent (and ongoing) development of the "Scrum for Team System" 2010 template (version 3.0 Beta for those counting) we needed to export team project queries. A new facility of Team Explorer 2010 is the ability to "Save As" when editing the query and chose the local file system. Pretty neat.

However, when you have a large suite of queries, this is very time consuming. You also have to strip out the server and project details from the resulting files before you can load them into a template. Being a developer at heart, the thought of repeating a single tedious action more that twice fills me with an inner dread. So I have written a simple command line utility that extracts all the queries from the specified project, maintaining the project query folder structure and stripping off any project specific content.

The "tfsQueryExport.exe" utility (attached below) requires 3 command parameters:

Usage:

tfsQueryExport [tfs url] [project name] [output folder]
Example:

tfsQueryExport "http://tfshost:8080/tfs/DefaultCollection" "Project 1" "c:\temp\Queries"

The output will be written to the specified output folder within a directory named after the project.

Note: This utility makes use of the TFS 2010 Team Explorer assemblies, so you will needed TE installed before it will work.

Geeky Moment: I also needed to create the template query specification fragment in order to list the queries in our template, so I took a little time travel pill and wrote a batch file to traverse the exported query folder structure:

@ECHO OFF

cd.> Queries.txt

FOR /D %%D IN (.\*) DO (
    FOR /D %%X IN ("%%D\*") DO (
        (ECHO ^<QueryFolder name="%%X"^> >> Queries.txt)
        FOR /R . %%A IN ("%%X\*.wiq") DO (
            ECHO     ^<Query name="%%A" fileName="%%A"^> >> Queries.txt
        )
        (ECHO ^</QueryFolder^> >> Queries.txt)
    )
)

PAUSE

It's not perfect. You have to strip out the unwanted folder paths and file extensions. It only handles a single folder depth too, but I just fancied a little nostalgia! Please feel free to suggest some improvments, it's been a while since I wrote in DOS.

Crispin.

Scrum for Team System - Create a custom work item changed event processor.

crispin.parker — Mon, 06 Apr 2009 16:55:00 GMT

Scrum for Team System - Create a custom work item changed event processor.

Sharp eyed and observant Scrum for Team System (SfTS) users will have noticed that the changing a SBI work remaining value affects the linked PBI work remaining value. However, it is sometimes a bit of a surprise to users that this behaviour is not part of the default TFS feature set...

The ability to automatically alter related TFS work items is a custom feature added by the Scrum for Team System process template. And I bet you didn't know that this feature is also extensible did you?

In this blog I'm going to give an example of how to create a custom "work item changed" event processor and add it to the SfTS event processors collection.

The demonstration scenario:

For the purpose of this demonstration, I want to add some new behaviour to my SfTS Team Projects. The new behaviour will propagate the description value of my SBIs to the description value of the linked Bug work items. This means that whatever description changes I make to the SBIs will be visible in the parent bug description field.

Step 1 - Setting up the new process handler project:

Note: You will need to have Team Explorer 2008 installed on your development system.

Create a new Visual Studio class library project, entitled "DescriptionChangedProcessor".
Make a local copy of the "Conchango.TeamSystem.SubscribedEventHandler.Infrastructure.dll". This assembly is found on the TFS application tier.

The default installation location for this assembly is:

C:\Inetpub\wwwroot\ScrumforTeamSystem\bin

Add the following project references:

Microsoft.TeamFoundation.Client
Microsoft.TeamFoundation.WorkItemTracking.Client
Conchango.TeamSystem.SubscribedEventHandler.Infrastructure.dll

Step 2 - Creating the event handler instance class:

Create a new public class in the project entitled: "EventProcessor"
Set the new class to implement the "Conchango.TeamSystem.SubscribedEventHandler.Infrastructure .Interfaces.ITSEventProcessor" interface. This interface defines a single method: "Process"; the method accepts a single parameter: tfsEvent of type ITSEvent.
Implement the ITSEventProcessor interface by adding the "Process" method.

public void Process(ITSEvent tfsEvent)
{
}
The first thing we need to do in the "Process" method is check that the received event is a work item changed event for a "Sprint Backlog Item". To do this, add two new private methods to our ["EventProcessor"] class:

private static bool TryGetTypedEvent<T>(ITSEvent tfsEvent, out T typedEvent)
{
typedEvent =
    typeof(T).IsAssignableFrom(tfsEvent.EventSourceType)
      ? (T)tfsEvent.EventSource
      : default(T);

return !typedEvent.Equals(default(T));
}

private static bool IsWorkItemOfType(
WorkItemChangedEvent workItemChangedEvent,
string workItemTypeName)
{
return
    Helpers.GetCoreFieldString(
      ConstantStrings.WorkItemTypeCoreField,
      workItemChangedEvent)
      .Equals(workItemTypeName);
}
The first of the above check methods ["TryGetTypedEvent"] compares the type of the output parameter ["typedEvent"] to the type of the event source. If the types match the method returns true and sets the output parameter, otherwise the method returns false and set the out parameter to null.

The second method ["IsWorkItemOfType"] returns a Boolean to indicate if the changed work item is an instance of the specified work item type.
With our check methods in place, we can now validate the ["tfsEvent"] parameter.

public void Process(ITSEvent tfsEvent)
{
WorkItemChangedEvent wicEvent;
if (!TryGetTypedEvent(tfsEvent, out wicEvent) ||
!IsWorkItemOfType(wicEvent, "Sprint Backlog Item"))
{
return;
}
}
The next part of the ["Process"] method needs to determine whether the changed SBI is linked to a Bug work item. To do this we need to connect to TFS and retrieve any linked Bug work items.

public void Process(ITSEvent tfsEvent)
{
WorkItemChangedEvent wicEvent;
if (!TryGetTypedEvent(tfsEvent, out wicEvent) ||
      !IsWorkItemOfType(wicEvent, "Sprint Backlog Item"))
{
    return;
}

var tfs = new TeamFoundationServer(
    tfsEvent.ServerIdentity.Url,
    CredentialCache.DefaultCredentials);

var workItemStore =
    (WorkItemStore)tfs.GetService(typeof(WorkItemStore));

var sourceWorkItemId =
    Helpers.GetCoreFieldInt(ConstantStrings.WorkItemIdCoreField, wicEvent);

var sourceWorkItem = workItemStore.GetWorkItem(sourceWorkItemId);

var parentBug =
    Helpers.GetRelatedWorkItems(sourceWorkItem)
      .Where(wi => wi.Type.Name.Equals("Bug"))
      .FirstOrDefault();

if (parentBug == null)
{
    return;
}
}
Now we have both the child and parent work items, we can update the bug to include the child description text. So add a new method to handle the update.

private static void UpdateBugDescription(
WorkItem parentWorkItem,
WorkItem sourceWorkItem)
{
var prefix = string.Concat("<-- Linked Task: '", sourceWorkItem.Id, "': ");
var suffix = " -->";
var regEx = new Regex(string.Format(@"({0}[\s\S]*{1})", prefix, suffix));

var textToInsert =
    string.Concat(
      new object[]
      {
        prefix,
        Environment.NewLine,
        sourceWorkItem.Description,
        Environment.NewLine,
        suffix
      });

parentWorkItem.Description =
    regEx.IsMatch(parentWorkItem.Description)
      ? regEx.Replace(parentWorkItem.Description, textToInsert)
      : string.Concat(
          parentWorkItem.Description,
          Environment.NewLine,
          textToInsert,
          Environment.NewLine);
}

The above ["UpdateBugDescription"] example surrounds the child work item description text with some comment markers. Then checks to see if the child description text already exists; if it does exist, the previous text is replaced, otherwise the child description is appended.
Adding a call to the update method and saving the bug (if dirty) completes the code.

public void Process(ITSEvent tfsEvent)
{
WorkItemChangedEvent wicEvent;
if (!TryGetTypedEvent(tfsEvent, out wicEvent) ||
      !IsWorkItemOfType(wicEvent, "Sprint Backlog Item"))
{
    return;
}

var tfs = new TeamFoundationServer(
    tfsEvent.ServerIdentity.Url,
    CredentialCache.DefaultCredentials);

var workItemStore =
    (WorkItemStore)tfs.GetService(typeof(WorkItemStore));

var sourceWorkItemId =
    Helpers.GetCoreFieldInt(ConstantStrings.WorkItemIdCoreField, wicEvent);

var sourceWorkItem = workItemStore.GetWorkItem(sourceWorkItemId);

var parentBug =
    Helpers.GetRelatedWorkItems(sourceWorkItem)
    .Where(wi => wi.Type.Name.Equals("Bug"))
    .FirstOrDefault();

if (parentBug == null)
{
    return;
}

UpdateBugDescription(parentBug, sourceWorkItem);

if (parentBug.IsDirty)
{
    parentWorkItem.Save();
}
}

Step 3 - Copy the assembly into the SfTS bin folder.

With our new event processor all ready to go, the next step is to copy an instance of our new assembly ["DescriptionChangeProcessor.dll"] to the bin folder of the Scrum for Team System web application on the TFS application tier.

The default installation location of the "bin" folder is:

C:\Inetpub\wwwroot\ScrumforTeamSystem\bin

Step 4 – Update the SfTS web.config.

Finally, we need to tell the Scrum for Team System web application that we have a new event processor. To do this we will need to edit the web applications "web.config" file.

The default installation location of the "web.config" file is:

C:\Inetpub\wwwroot\ScrumforTeamSystem\web.config

In the configuration file, find the following xml fragment:

<setting name="EventServiceAssembles" serializeAs="Xml">
<value>
    <ArrayOfString xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
      <string>Conchango...StateTransitions.dll</string>
      <string>Conchango...RefreshPBIWorkRemaining.dll</string>
    </ArrayOfString>
</value>
</setting>
And add a new xml string node as shown below:

<setting name="EventServiceAssembles" serializeAs="Xml">
<value>
    <ArrayOfString xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
      <string>Conchango...StateTransitions.dll</string>
      <string>Conchango...RefreshPBIWorkRemaining.dll</string>
      <string>DescriptionChangedProcessor.dll</string>
    </ArrayOfString>
</value>
</setting>

The source code for the demo assembly is attached below.

Disclaimers, omissions and “get out jail” cards.

This example is for demonstration purposes only and is not the desired default behaviour for the Scrum for Team System template.
Making changes to your Scrum for Team System installation configuration is done completely at your own risk.
The above code doesn’t handle the changing a work item links, so linking and unlinking SBIs to bugs will not updated the description text.

Where to go next?

Please see the www.scrumforteamsystem.com web site for more information.

Task Board for Team System - Adding Custom States

crispin.parker — Wed, 08 Oct 2008 15:26:00 GMT

In this post I am going to explain how to add a new work flow state to the "Sprint Backlog Item" (SBI) work item type definition and how to enable [the new state] in the Task Board for Team System.

Why would you want to add a new state?

The default work flow of states (available to the SBI) when you install the Scrum for Team System process template are:

Not Done (work on task has not started)
In Progress (work on the task has started)
Ready for Test (the task functionality is complete and needs to be tested)
Done (the task is complete to your definition of "Done")
Deferred (the task has been put off until a subsequent sprint)
Deleted (the task is removed from the work flow)

The default states and workflow for Version 2 of the SfTS process template

This array of states is designed to give you all the required work flow options so that you may move SBIs through the sprint process from "Not Done" to "Done". For more information on the default states and what they all mean, please review the Scrum for Team System process guidance.

http://scrumforteamsystem.com/processguidance

But what happens if your company has different work flow needs or requires another step in the chain of events? How do you add your new requirement to the default process flow?

For this example, I’m going to add a new state to the work flow entitled "Blocked". The Blocked state will be an indicator that the SBI cannot be progressed and is Blocked the completion of the parent product backlog item.

The new proposed workflow with the added Blocked state.

As you can see the new state can only be entered from "In Progress" and can only be changed to either "In progress", "Ready for Test" or "Deleted".

Quick note on customising TFS projects

When you alter a work item definition, you are only altering the target project. Creating a new Team Project (from the SfTS process template) will use the default work item templates. Think of it as creating a new word document based on the fax template. Altering the new document isn’t going to change the fax template.

Step 1 - Exporting the work item template

The first step in applying our new state is to export the SBI work item template definition file from the TFS project so that we can edit it. This is accomplished by using the "WITEXPORT" command line utility.

Here is an example command line that exports the SBI work item template from a project entitled "DemoData" which resides in a TFS with a URL of "http://TFSRTM08:8080":

witexport /f "c:\temp\Sprint Backlog Item.xml" /t "http://TFSRTM08:8080" /p "DemoData" /n "Sprint Backlog Item"

Switches:

/f = local path to save the exported work item template file
/t = TFS URL (or machine name)
/p = the source project
/n = name of the work item type to export

Executing the command line will result in a new XML document being created at "c:\temp\Sprint Backlog Item.xml"

Next up, we need to add the new "Blocked" state to the work item definition. So, open the "Sprint Backlog Item.xml" document in your text editor of choice and follow the below instructions.

Navigate to the node: WITD / WORKITEMTYPE / WORKFLOW / STATES
Add a new child node:

<STATE value="Blocked" />
Next navigate to node: WITD / WORKITEMTYPE / WORKFLOW / TRANSITIONS
Add 4 child transition nodes:

<TRANSITION from="In Progress" to="Blocked">
  <REASONS>
    <DEFAULTREASON value="Item is blocked" />
  </REASONS>
</TRANSITION>
<TRANSITION from="Blocked" to="In Progress">
  <REASONS>
    <DEFAULTREASON value="Item is unblocked" />
  </REASONS>
</TRANSITION>
<TRANSITION from="Blocked" to="Ready For Test">
  <REASONS>
    <DEFAULTREASON value="Ready for testing" />
  </REASONS>
</TRANSITION>
<TRANSITION from="Blocked" to="Deleted">
  <REASONS>
    <DEFAULTREASON value="Item deleted" />
  </REASONS>
</TRANSITION>
Then save the document.

Step 2 - importing the altered work item template

Now we need to get the edited work item definition file back into the Team Project. For this we use a command line utility entitled "WITIMPORT".

Here is an example command line that will import our edited XML document back into the "DemoData" project.

witimport /f "c:\temp\Sprint Backlog Item.xml" /t "http://TFSRTM08:8080" /p "DemoData"

Switches:

/f = local path of the work item template file to import
/t = TFS URL (or machine name)
/p = the target project

Executing the command line will import our altered SBI work item definition template in the "DemoData" project. Once complete, you can test the new state through Team Explorer. Remember, you will only be able to select this state if the SBI is in a state of "In Progress".

Step 3 - updating the Task Board configuration file

Now we have altered SBI, we need to tell the Task Board for Team System (TBfTS) about it. This involves editing 2 xml configuration files in the TBfTS installation folder.

The default installation location is:

C:\Program Files\Conchango\SfTSv2TaskBoard\app

We need edit the "Conchango.TeamSystem.TaskBoard.WpfUI.exe.config" file. This amendment tells the task board application that SBI work items have a new state.

Open "Conchango.TeamSystem.TaskBoard.WpfUI.exe.config" in your chosen text editor.
Change text:

<setting name="WorkItemStates_SBI" serializeAs="Xml">
  <value>
    <ArrayOfString xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
      <string>Not Done</string>
      <string>In Progress</string>
      <string>Ready For Test</string>
      <string>Done</string>
      <string>Deferred</string>
      <string>Deleted</string>
    </ArrayOfString>
  </value>
</setting>
To equal:

<setting name="WorkItemStates_SBI" serializeAs="Xml">
  <value>
    <ArrayOfString xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
      <string>Not Done</string>
      <string>In Progress</string>
      <string>Ready For Test</string>
      <string>Done</string>
      <string>Deferred</string>
      <string>Deleted</string>
      <string>Blocked</string>
    </ArrayOfString>
  </value>
</setting>
Save the document.

Note: The sequence of the listed SBI states is important. This determines the colours and icons used in the task board. For example, the first state in the sequence will have the Exclamation icon and the second will have the right pointing arrow icon.

Step 4 - updating the Task Board default column layout file

Next, we need to edit the "DefaultColumnLayout.xml" file. This file controls the default appearence of the task board columns including display text, width and display order.

Open the file "DefaultColumnLayout.xml" in your text editor and you will be presented with the below XML:

<?xml version="1.0" encoding="utf-8"?>
<STATE_COLUMNS xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <MODE Name="Sprinting">
    <COLUMN DisplayText="User Story Title" Width="140" MinimumWidth="140" />
    <COLUMN DisplayText="Not Started" State="Not Done" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="In Progress" State="In Progress" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="Ready For Test" State="Ready For Test" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="Done" State="Done" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="Deferred" State="Deferred" Width="0" MinimumWidth="0" />
    <COLUMN DisplayText="Spare" Width="0" MinimumWidth="0" />
  </MODE>
  <MODE Name="Planning">
    <COLUMN DisplayText="User Story Title" Width="140" MinimumWidth="140" />
    <COLUMN DisplayText="Not Started" State="Not Done" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="In Progress" State="In Progress" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="Ready For Test" State="Ready For Test" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="Done" State="Done" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="Deferred" State="Deferred" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="Spare" Width="0" MinimumWidth="0" />
  </MODE> 
</STATE_COLUMNS>

As you can see from the above XML, the column layout data is split into 2 MODEs; Sprinting and Planning. These sections correlate with the task board modes, so when the task board is in "Sprinting Mode" the data under <MODE Name="Sprinting"> is used.

Each COLUMN node contains the following attributes:

DisplayText = the text to be shown along the column headings section of the task board.
Width = the actual width of the column (set to zero in order to hide that column)
MinumumWidth = the smallest possible width of the column (must be zero if you wish to hide a column)
State = the SBI state displayed in the column.

Note:
The sequence of the COLUMN elements determines the display position within the task board application.
The first column node is reserved for the backlog item row header and cannot be used as a state container.

Edit the XML to read as follows:

<?xml version="1.0" encoding="utf-8"?>
<STATE_COLUMNS xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <MODE Name="Sprinting">
    <COLUMN DisplayText="User Story Title" Width="140" MinimumWidth="140" />
    <COLUMN DisplayText="Not Started" State="Not Done" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="In Progress" State="In Progress" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="Blocked" State="Blocked" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="Ready For Test" State="Ready For Test" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="Done" State="Done" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="Deferred" State="Deferred" Width="0" MinimumWidth="0" />
  </MODE>
  <MODE Name="Planning">
    <COLUMN DisplayText="User Story Title" Width="140" MinimumWidth="140" />
    <COLUMN DisplayText="Not Started" State="Not Done" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="In Progress" State="In Progress" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="Blocked" State="Blocked" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="Ready For Test" State="Ready For Test" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="Done" State="Done" Width="140" MinimumWidth="100" />
    <COLUMN DisplayText="Deferred" State="Deferred" Width="140" MinimumWidth="100" />
  </MODE> 
</STATE_COLUMNS>

Note: Don't forget to delete the "Spare" column definition. There must be exactly 7 columns in each mode.

Save the document.

Nearly done

The required configuration changes are now complete and we can launch the task board application to see the new state in action. Well almost!

In order to apply the changes [made to the "DefaultColumnLayout.xml" file], you will need to reset the column layout in the task board application. This is accomplished via the "Edit" -> "Reset Column Layout" task board menu option.

And that’s it; you should now see the new Blocked column in the task board and be able move SBIs from an "In Progress" state into the "Blocked" state.

The "Blocked" state in the task board

Limitations and Disclaimers

The Task Board for Team System can support a maximum of 6 swim lane states.
The above example is based on the Task Board for SfTS v2.x application. The listed states will be different for Task Board for SfTS 1.2 applications.
Due to the inability to access the work item template data via SQL Reporting services, the Scrum for Team System reports (installed by default) will not auto-magically detect changes to the work item templates. Removing states and or fields that are required by the reports will cause incorrect functionality and possible reporting failure.
Conchango cannot offer support for customised instances of the Team Projects. Only unaltered Team Projects created from the Scrum for Team System template are supported.
It is your own responsibility to ensure the stability of your Team Foundation Server environment. Make backups where possible before attempting any of the changes described in this article.

Links

Scrum for Team System:

http://scrumforteamsystem.com/en/default.aspx

Task Board for Team System:

http://scrumforteamsystem.com/en/TaskBoardBeta/Default.aspx

Community Forum:

http://scrumforteamsystem.com/cs/forums/

What next?

To complete the process, you could also add a new "Blocked" state to the Product Backlog Item and alter the Scrum for Team System event handler process to auto change the PBI status whenever a child SBI is set to blocked. But that is a blog for another day...

Crispin Parker

New Task Board for Team System Beta Editions (SfTS version 1.2 support!)

crispin.parker — Wed, 08 Oct 2008 11:13:00 GMT

Great news for Team Foundation Server 2005!

Today I have released a new version of the Task Board for Team System that supports Team Projects created with the Conchango Scrum for Team System (SfTS) version 1.2 process template.

This means that SfTS users running on a TFS 2005 application tier can now enjoy the benefits of the rich UI WPF tool; Task Board for Team System.

In order to run the Task Board application, you will need Team Explorer (TE) 2008 installed on your client machine. There is no need to alter anything on your TFS application tier. TE 2008 can connect to both TFS 2005 and TFS 2008 environments, so you won't lose connectivity to your TFS 2005 team projects after you upgrade your client machine.

Also released today is the latest Beta version of the Task Board for SfTS version 2 projects. Both applications can be installed side by side to enable access to a mixed platform of Team Projects.

Beta 3.2 Change Log:

Bug Fix: Handler added for hung connection.

Previous Beta's would hang indefinitely if the TFS application tier did not respond to an authentication request. A 20 second timeout has now been added for TFS authentication.
Bug Fix: Save All tries to save clean items.

Testers have reported that, on occasion, the task board would display error messages when performing a "Save All" for work items that had not been altered. The "Save All" functionality has been changed in an attempt to stop this behaviour.
Spellingz mistakes: Description misspelt on "Sprint Backlog Item" and "Bug" edit panels.

The "descrition" spelling mistake has been corrected.
New Feature: Support added for additional customised SBI states.

It is now possible to include additional custom workflow states for the "Sprint Backlog Item" work item. Several beta users have noted that they cannot support customised SBI states through the task board. The need for additional work flow states can arise when a company requires additional process steps during the sprint process. A common requirement is to include a blocked state. I will publish a blog post that gives full coverage on how to include customised states very soon.

Please post you thoughts and comments in the Task Board Beta forum.

http://scrumforteamsystem.com/cs/forums/default.aspx?ForumGroupID=3

For more information on the Task Board for Team System and to sign for free, visit:

http://scrumforteamsystem.com/en/TaskBoardBeta/Default.aspx

You can download the Microsoft Team Explorer 2008 installation ISO from:

http://www.microsoft.com/DOWNLOADS/details.aspx?FamilyID=0ed12659-3d41-4420-bbb0-a46e51bfca86&displaylang=en

Regards,

Crispin Parker,
Technical Consultant,
Conchango.