Welcome to EMC Consulting Blogs Sign in | Join | Help

Crispin Parker's Blog

About Scrum for Team System and .Net development

  • Scrum for Team System v3 - SharePoint 2010 Portal

    In this post I will tell you how to add a SharePoint 2010 compatible solution to your Scrum for Team System version 3 Team Foundation Server setup.

    The current SfTS v3 installer (version 3.0.3784.03) does not support SharePoint 2010 environments. The installer simply skips the SharePoint portion of the process. When attempting to create a new SfTS v3 project [that includes a project portal], SP 2010 users suffer a project creation failure. The project creation log file contains an error message like:

    “TF249033: The site template is not available for the locale identifier (LCID).”
    ”The site template name is: SCRUM.”



    To correct this error condition, follow the below steps.


    1. Download the SharePoint 2010 solution zip.


    2. Extract the zipped “ScrumForTeamSystem.SharePoint.Dashboards.wsp” file to a working folder.

    3. Deploy the solution to your SharePoint instance by executing the following PowerShell script:

      Add-SPSolution -Filename "scrumforteamsystem.sharepoint.dashboards.wsp"
      Install-SPSolution scrumforteamsystem.sharepoint.dashboards.wsp
      -GACDeployment –AllWebApplications





    Crispin Parker,
    Senior Practice Consultant,
    EMC Consulting.

  • Scrum for Team System v2 projects in TFS 2010

    After upgrading your TFS 2008 instance to TFS 2010, some features of SfTS version 2 projects will stop working. The SfTS v2 event service (that controls work remaining roll ups) and project reports are not compatible with the TFS 2010 infrastructure. Unfortunately, the reports cannot be saved, but it is possible to restore the event service functionality using a customised SfTS v3 event service solution. Here’s how to do it.

    How to restore the SfTS v2 event service.

    1. Uninstall SfTS v2.
      Note: Only relevant for severs that have had in-place TFS 2010 upgrades.

    2. Download the replacement Event Service source.
      Download from: Services2008.zip 

    3. Extract the services zip on to your TFS AT.
      Unzip the contents of the “Services2008.zip” file to “c:\Program Files\ScrumforTeamSystem”.

    4. Create a new web application for the service.
      Site: Team Foundation Server
      Alias: ScrumforTeamSystem2008
      Application Pool: Microsoft Team Foundation Server Application Pool
      Physical Path: c:\Program Files\ScrumforTeamSystem\Services2008

      IIS Management Console.

      Creating a new web applicaiton.

    5. Create a new work item changed event subscription in TFS.
      The “Services2008.zip” also contains a PowerShell script that creates the required work item changed event subscription. To execute the script:
      1. Launch an elevated command prompt on the TFS AT:
        Press: [Windows Key]
        Type: cmd
        Press: [Ctrl] + [Shift] + [Return]

      2. (If required) Enable PowerShell script execution:
        powershell set-executionpolicy remotesigned

      3. Execute the script:
        powershell "c:\Program Files\ScrumforTeamSystem\Subscribe.ps1"

      4. When promoted, enter the team project collection name and press [Return]:

        The PowerShell script.

    You should now have a working event service for your migrated SfTS version 2 project.


    Creating new Version 2 projects in TFS 2010.

    Another issue you may run into after a TFS2010 upgrade is that you can no-longer create new SfTS v2 projects. The project creation process fails at the report creation step:

    Exception Message: The item '/TfsReportDS' cannot be found. (type ReportingServiceException)

    To fix this issue, you should remove the report specifications from the process template definition.

    1. Use the Visual Studio Team Explorer panel to download the SfTS v2 process template.
      Right click on the project collection name and select “Team Project Collection Settings \ Process Template Manager” from the context menu.

      Visual Studio Team Explorer context menu.

      Download: Agile Software Development with Scrum - v2.2.14216.001

      Process Template Manager dialog.

    2. Edit the report task configuration file as shown below.
      File location:
      [Export Folder]\Agile Software Development with Scrum - v2.2.14216.001\Reports\reports.xml

      <?xml version="1.0" encoding="utf-8"?>
        <task id="Site" plugin="Microsoft.ProjectCreationWizard.Reporting" completionMessage="Project Reporting site created.">
          <dependencies />
              <site />
        <task id="Populate Reports" plugin="Microsoft.ProjectCreationWizard.Reporting" completionMessage="Project site created.">
            <dependency taskId="Site" />
                      ... Excluded for clarity

    3. Finally, use the Process Template Manager to upload the altered template.
      Select the downloaded template folder root and agree to overwrite the template.

      Confirm overwrite template.


    You should now be able to create new SfTS v2 projects in your upgraded TFS 2010 environment.




    Crispin Parker,
    Senior Practice Consultant,
    EMC Consulting.

  • Scrum for Team System v3 and the product backlog.

    A recent question in the Scrum for Team System Q & A site has highlighted that there is a lack of advice on how to accomplish backlog management with the SfTS v3 template. I’ve been working with the template for some time and it all seems very obvious to me, but taking a step back reveals that some of the details are not instantly discoverable. So I’ve decided to dust off live writer and explain how I manage a backlog in SfTS v3…

    Note: I briefly describe backlog management in my Getting Started With Scrum for Team System Version 3 blog post. If you haven’t read the getting started guide, I suggest you do so before continuing. Throughout this blog post I will use screen shots from the TFS Workbench utility provided for free by EMC and written by me!


    Creating and sizing the backlog.

    One of the first steps in the project (long before any development work starts), is to get the ideas buzzing around in product owners head into a list of features that can be worked on by the team. The team then looks at each feature and decides how big it is in relation to all the other features. I can recommend planning poker as a great way to size a backlog.

    SfTS v3 suggests that “Story Points” are used to describe the size of the backlog items. Story points are excellent for this purpose as they follow a Fibonacci (ish) sequence (the next number being the sum of the previous 2) and give you a ruff description on the comparative size without an exact figure.

    The comparative size of the backlog items is very important. Without knowing the cost, the product owner cannot decide which items should take priority. The backlog generation process should be:

    1. Product owner creates the initial backlog wish list.
      The initial backlog resides at the project planning scope level. Product owners will likely need guidance on describing the feature requests as user stories and should involve the team to ensure that everyone understands the meaning of the story.

      A sample backlog

      A sample backlog

      In SfTS the user stories are described by the “Product Backlog Item” (PBI) and “Acceptance Test” (AT) work items. The PBI describes the story requirements and the ATs describe the contract or “condition of acceptance” for the PBI.

      Backlog items with linked Acceptance Tests

      Backlog item with linked Acceptance Tests Backlog item with linked Acceptance Tests - Task Board mode

    2. Team sizes the backlog.
      The team iterates over the backlog items and sets a comparative size to each story. The PBI “Story Point” field is used to capture the size and provides a drop down list of story point values.

      Backlog with story points and calculated ROI.

      Backlog items with story points

    3. Product owner prioritises the backlog.
      Only when the backlog is sized can the product owner see the cost of implementing features. Once the cost is known, prioritisation should be easier. The PBI “Business Value” field is used to contain the importance of the backlog item and the “Delivery Order” field is used to define the actual sequence of implementation.

      Note: The higher the business value the more important the feature.

      Backlog with delivery order.

      Backlog items with delivery order

    4. Release planning.
      The product release schedule should be known and the team should have a ruff idea of how many story points they hope to complete in a release. Using this information, the product owner then decides which backlog items should be processed in which release.

      Backlog with release schedule set.

      Backlog items with release schedule 

      The release work item stores the “Estimated Capacity” of story points, sum of planned points and sum of completed (burned) points. 

      The release work item.

      The release work item

    This process is sometimes known as “Sprint Zero”. A pre-sprint process used to get the project scope defined and ready for development.


    Epics, themes and stories in SfTS

    Your sized backlog will contain a list of stories. A story describes a user centric view of a product feature and is often described using the “User Story” paradigm.

    As a <Role> I want <Goal> so that <Benefit>.

    The initial product backlog is most likely to be a list of epic stories.  An epic is a feature requirement that cannot be completed within a single sprint. This is very normal and expected behaviour, but it does mean that your backlog isn’t going to be very useful for sprint planning. The team needs an appropriately sized backlog in order to select which stories to work on in the next sprint.

    What is “appropriately sized”?

    Your backlog has a desired sequence of completion, described by a combination of Business Value, Story Points and Delivery Order. The highest priority items are the next to be worked on, so they need to be small enough to fit into a sprint and contain enough detail to describe (in full) the requirement. Future features should be less detailed and larger in size. Future requirements are going to change (this is the nature of agile development), so keeping the requirements general but vague mean that you don’t need to pin down the fine details before they are known.

    So when I say “appropriately sized” I mean that the backlog items are sized corresponding to their backlog position. High priority are small with lots of detail, lower priority are large with less detail.

    What about themes?

    Themes are used to group backlog items that share a common goal. The SfTS template uses “Feature Scope” (AKA Area Path) to describe the backlog item theme. We can use this feature when breaking apart epics to group the smaller stories together.


    Splitting epics / backlog grooming

    So, you’ve got your epic prioritised backlog. The next step is to groom your backlog by breaking down the high priority epics into bite sized stories that will fit into the sprints. If you were using record cards to model your backlog, then you would write out all the sub stories onto separate cards, rip up the original epic card and toss it in the bin. However, in TFS we have an issue with this. TFS work items are immutable and cannot be thrown out. Once you create a work item cannot be removed. We work around this limitation in SfTS by having a “Deleted” status. Setting a work item to “Deleted” excludes it from the reports and queries.

    So, to follow the record card method, here’s how we split the epics.

    1. Create a new PBI to describe the sub story.
    2. Assign a feature scope to the new story. (Used to group or theme the sub story with it’s new siblings).
    3. Assign the story point value to the new story. (The story point value should be comparative to the rest of the backlog).
    4. Assign acceptance tests to the new item.
    5. Repeat steps 1 and 4 for each sub story.
    6. Finally, mark the original epic as “Deleted”.

    What if I want to keep my original epic?

    If you decide to split off sub stories and maintain your original epic, then make sure you reduce the source epic story point value to reflect the changes. Otherwise, your total backlog story point value will increase with the duplicated cost of both stories!

    The backlog will need to be groomed in this manner on a regular basis. This is an important aspect of the backlog life cycle. l like to think of it like a warehouse breaking up a container load of parts ready to be delivered to the factory for processing. It also highlights why the product owner needs to be involved with the backlog through out the life time of the project. The product owner plays the role of warehouse manager feeding the factory with parts.

    An example of splitting a backlog item.

    In our sample backlog, the highest priority item is “Product browsing and search”. The team has estimated that this story is worth 20 story points. The team also estimate that they can complete 10 story points worth of work in a single sprint. This means that the story is an epic and needs to be broken down before it can be moved in to a sprint.

    1. Break the epic into logical components.
      This story obviously contains “Browsing” and “Search” components. So the product owner (with the teams help) creates 2 new backlog items: “Browsing” and “Search”.

      The epic backlog item

    2. Set the new sizes.
      The team estimate that “Browsing” is worth 13 story points and “Search” is worth 8. Hang on a moment that’s 21 points and the epic was only 20! Don’t panic, remember that story points are a ruff guide to scale and not an exact measurement of size. No harm done.

      The split stories

    3. Ensure appropriate sizes.
      The “Browsing” story is still too big, so the feature is split once again into “Product pages” (5 points)  and “Site Structure” (8 points). Now all the items are small enough to fit into a single sprint.

      The appropriate sized stories

    4. Theme the stories.
      The product owner and team want to track the new backlog items as a single unit, so they create a new project Feature Scope (Product Browsing and Search) and assign it to all browse and search backlog items.

      Backlog items with theme set

    5. Prioritise the new backlog items.
      Now that the backlog items have been split and sized, the product owner can set the business value and chose delivery order of the items.

      Prioritised split stories

    6. Redistribute the acceptance tests and create new ones as required.
      Remember that the backlog is described by both the PBIs and the linked ATs. The original epic had two linked acceptance tests: “Users can browse…” and “User can search…”. So we need to move these tests to the new backlog items. Using the workbench task board mode, drag the ATs to the new backlog items. We also need another test for the new “Site Structure” backlog item, so create a “User can navigate the products” test item.

      New backlog with linked acceptance tests

    7. Clean up.
      The original story still exists on the backlog and the sum of it’s story points is contributing to the release planned total. To clear this up, the epic status is set to deleted.

      The deleted epic story

    Sprint planning

    The backlog is now prioritised and sized appropriately, so it’s time to do some sprint planning.

    1. Estimate Sprint Velocity.
      The team estimate how many story points they can accomplish in the forthcoming sprint. 

    2. Select Backlog Candidates.
      The team select backlog item candidates up to the sum of their estimated velocity. The backlog item iteration path is set to the team level for the sprint.

      Moving the backlog items into sprint

    3. Generate Backlog Tasks and Estimate Effort.
      Generation of the sprint backlog tasks takes place for each selected user story. This includes the not only the tasks needed to develop the feature, but also to those need to test and any other tasks. The sprint backlog tasks should describe all the work needed to complete the backlog item.

      The backlog with tasks

    4. Acceptance Tests and Bugs in sprint planning.
      By default, acceptance tests and bugs do not automatically get updated when the linked PBI iteration path is changed. This can cause an issue if you are using the workbench application. The workbench allows you to filter  work items by iteration path. If your acceptance tests reside on the root path and you have selected a lower level path workspace then you won’t be able to see the test items. To combat this, you can either manually update the linked tests and bugs paths or create some new Transition Service rules to do it automatically.

      A backlog item with tasks and test

    De-scoping backlog items

    De-scoping work from a sprint in SfTS v3 needs to follow a specific pattern in order for the reports to function correctly.

    1. Set the backlog item state to “Descoped”.
    2. The event service automatically updates all “Not Started” tasks to “Descoped”.
    3. If the backlog item has “In Progress” work, either finish it or manually set it to “Descoped”.
    4. Save the work items.
    5. Finally, set the backlog item iteration path back to the release level, ready for inclusion is a subsequent sprint.

    Descoped backlog item and tasks

    Simon Bennett discusses the logic behind de-scoping in his Descoping work in Scrum for Team System Version 3.0 blog post.

    That’s it for this post. I hope you found it useful. This guide details how I use the template to manage a backlog. As with nearly all aspects of the SfTS template, you are free to change the behaviour as needed to fit your requirements. So if my way of doing things doesn’t fit well with you, then feel free to adopt your own conventions.

    More information on SfTS can be found at: https://www.scrumforteamsystem.com/


    Crispin Parker,
    Senior Practice Consultant,
    EMC Consulting.

  • Unit testing a WPF DispatcherTimer method.

    Yesterday, I spent a couple of frustrated hours creating a unit test for a method that made use of a DispatcherTimer. For the sake of sanity (and to hopefully help out some other poor soul) I have written a helper class that encapsulates my testing solution.

    using System;
    using System.Threading;
    using System.Windows.Threading;
    /// <summary>
    /// The dispatcher helper class.
    /// </summary>
    public static class DispatcherHelper
        /// <summary>
        /// The stop execution callback.
        /// </summary>
        private static readonly EventHandler stop;
        /// <summary>
        /// Initializes static members of the <see cref="DispatcherHelper"/> class.
        /// </summary>
        static DispatcherHelper()
            stop = (s, e) =>
        /// <summary>
        /// Executes the on dispatcher thread.
        /// </summary>
        /// <param name="test">The test method.</param>
        /// <param name="secondsToWait">The seconds to wait.</param>
        public static void ExecuteOnDispatcherThread(Action test, int secondsToWait = 5)
            Action dispatch = () =>
                    Dispatcher.CurrentDispatcher.BeginInvoke(DispatcherPriority.Normal, test);
                    StartTimer(secondsToWait, Dispatcher.CurrentDispatcher);
        /// <summary>
        /// Executes the on dispatcher thread.
        /// </summary>
        /// <typeparam name="T">The test result type.</typeparam>
        /// <param name="test">The test to execute.</param>
        /// <param name="secondsToWait">The seconds to wait.</param>
        /// <returns>The test result.</returns>
        public static T ExecuteOnDispatcherThread<T>(Func<T> test, int secondsToWait = 5)
            var result = default(T);
            Action execute = () => result = test();
            ExecuteOnDispatcherThread(execute, secondsToWait);
            return result;
        /// <summary>
        /// Starts the timer.
        /// </summary>
        /// <param name="secondsToWait">The seconds to wait.</param>
        /// <param name="dispatcher">The dispatcher.</param>
        private static void StartTimer(int secondsToWait, Dispatcher dispatcher)
            var timeToWait = TimeSpan.FromSeconds(secondsToWait);
            var timer = new DispatcherTimer(timeToWait, DispatcherPriority.ApplicationIdle, stop, dispatcher);
        /// <summary>
        /// Executes the specfied action on a seperate thread.
        /// </summary>
        /// <param name="dispatcherAction">The dispatcher action.</param>
        private static void ExecuteOnNewThread(Action dispatcherAction)
            var dispatchThread = new Thread(new ThreadStart(dispatcherAction));


    How to use:

    To use the helper class, you need to wrap your test execution into either an Action (or if you want to return a result, a single parameter Func) and then pass the anonymous method to the DispatcherHelper.ExecuteOnDispatcherThread method.

    By default the helper will wait for five seconds and then kill the dispatcher instance. You can adjust the wait duration if your DispatcherTimer method needs longer to execute.



    using System;
    using System.Windows.Controls;
    using System.Windows.Threading;
    using NUnit.Framework;
    using Rhino.Mocks;
    using SharpArch.Testing.NUnit;
    public class DispatcherHelperDemo
        public void Calling_a_dispatcher_helper_non_return_method()
            // Arrange
            var hasBeganLoading = false;
            Action test = () =>
                    var testRepository = MockRepository.GenerateMock<IRepository>();
                    testRepository.Expect(cr => cr.BeginLoad())
                        .WhenCalled(mi => hasBeganLoading = true);
                    var control = new MyUserControl();
            // Act
            // Assert
        public void Calling_a_dispatcher_helper_method_with_return_value()
            // Arrange
            var hasCalledRepositoryLoad = false;
            Func<bool> test = () =>
                var testRepository = MockRepository.GenerateMock<IRepository>();
                testRepository.Expect(cr => cr.BeginLoad())
                    .WhenCalled(mi => hasCalledRepositoryLoad = true);
                var control = new MyUserControl();
                return control.HasStartedLoad;
            // Act
            var hasStartedLoading = DispatcherHelper.ExecuteOnDispatcherThread(test);
            // Assert
    public class MyUserControl : UserControl
        public bool HasStartedLoad { get; private set; }
        public void BeginLoad(IRepository customerRepository)
            EventHandler callback = (s, e) =>
            var dispatcherTimer = new DispatcherTimer(
                TimeSpan.FromSeconds(1), DispatcherPriority.Normal, callback, Dispatcher.CurrentDispatcher);
            this.HasStartedLoad = true;
    public interface IRepository
        void BeginLoad();


    How does it work?

    In order for the DispatcherTimer tick event to be processed, there needs to be a running Dispatcher instance. However, a Dispatcher will block execution on the calling thread until all frames have been released. To get around the blocking issue, the dispatcher is run on a separate STA thread.

    The next issue is that UI elements can only be accessed on the thread that created them. So, the element creation and test actions are encapsulated into an anonymous method which is then executed on the dispatcher thread.

    The final hurdle is that the Dispatcher will continue to block the execution thread after the anonymous test method has run. The solution for this was to create another timer event that shutdown the Dispatcher after a specified time.


    Right, now back to my technical debt repayment…



    Crispin Parker,
    Senior Practice Consultant,
    EMC Consulting.

  • Extending Microsoft Visual Studio Scrum v1.0 with auto rollups.

    In continuation of my series on the Scrum for Team System event service I would like to show you how you can use the service to extend other templates. In this post I will show you how to create an auto rollup field in the new Microsoft Visual Studio Scrum v1.0 template.

    You will need access to a TFS environment that includes both SfTS v3 and MS Scrum v1.0. All set? Then let’s get started…

    Step 1 - Create a copy of the SfTS event service web.

    Each instance of the event service can only have a single set of rules. To maintain the default SfTS rules, we need to create a copy of the event service and edit the rules in that copy.

    1. On the TFS AT, create a copy of the SfTS service directory.

      Copy directory and contents:

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


      C:\Program Files\Scrum for Team System\Services2

    2. Specify a work item cache location.


      C:\Program Files\Scrum for Team System\Services2\web.config.


      <add key="WorkItemTrackingCacheRoot" value="C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\WorkItemStoreCache\"/>


      <add key="WorkItemTrackingCacheRoot" value="C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\WorkItemStoreCache2\"/>

    3. Clear the Transition Rules configuration file.

      Replace the contents of:

      C:\Program Files\Scrum for Team System\Services2\3.0\Rules\TransitionRules.xml

      <?xml version="1.0" encoding="utf-8" ?> 
      <ArrayOfTransitionRule xmlns="http://schemas.ScrumforTeamSystem.com/TransitionService/RulesCollection" /> 

    4. Update the Aggregation Rules configuration file.

      Replace the contents of:

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

      <?xml version="1.0" encoding="utf-16"?> 
      <ArrayOfAggregateRule xmlns="http://schemas.ScrumforTeamSystem.com/AggregationService/RulesCollection">
        <AggregateRule type="Sum">
         <WorkItemType source="Task" target="Product Backlog Item" />
         <Link linktypename="System.LinkTypes.Hierarchy" isforward="true" />
         <Field source="Microsoft.VSTS.Scheduling.RemainingWork" target="Custom.WorkRemainingRollup" />
         <ChangeNote>Sum of associated task(s) work remaining applied.</ChangeNote>

    5. Using the IIS console; Create a new web application that targets the copied service folder.


      Alias: MSScrumService
      Application Pool: Microsoft Team Foundation Server Application Pool
      Physical Path:  C:\Program Files\Scrum for Team System\Services2

    Step 2 – Edit the PBI work item definition.

    We need to add a new field to the PBI work item definition. The new field will to be the target of the event service roll up. For this example I’m using the TFS 2010 Power Tools plug-in. You could also do this using the TFADMIN command line tool and then editing the raw XML work item definition.

    1. In visual studio, click “Tools / Process Editor / Work Item Types / Open WIT from Server”, select your target TFS instance and project collection.


    2. Select the “Product Backlog Item” work item type in the target project.


    3. Add a new field:

      Name: Work Remaining Rollup
      Type: Double
      Reference Name: Custom.WorkRemainingRollup
      Help Text: The sum of work remaining for this instance.
      Reportable: Measure


    4. Update the work item layout information to include the new field:

      Add a new control to the “Group – Details” node.

      Field Name: Custom.WorkRemainingRollup
      Label: Work Remaining (Calculated)
      Read Only: True


    5. Save the altered template back to the source project.

    Note: If you want to apply the new rollup rule to all new MS Scrum projects in this collection, you should use the “Process Template Manager” to download, edit and upload the altered project template.

    Step 3 - Create an event subscription to the new service web.

    Now we need to add a new event subscription to the project collection. TFS 2010 no-longer ships with the handy BisSubscribe command line tool, so I have written a little PowerShell script that uses the Team Explorer APIs.

    Execute the below PowerShell script, replacing the project collection name (“MyProjectCollection”) and TFS Uri as required. Ensure that the network account used has access to the target TFS. Alternatively, you could run this script directly on the TFS AT.

    [Reflection.Assembly]::Load("Microsoft.TeamFoundation, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
    [Reflection.Assembly]::Load("Microsoft.TeamFoundation.Client, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
    $collectionName = "MyProjectCollection"
    $tfsUri = new-object Uri("http://localhost:8080/tfs/")
    $tfs = [Microsoft.TeamFoundation.Client.TfsConfigurationServerFactory]::GetConfigurationServer($tfsUri)
    $collectionService = $tfs.GetService([Microsoft.TeamFoundation.Framework.Client.ITeamProjectCollectionService])
    Foreach($collection in $collectionService.GetCollections()) 
        if($collection.Name -eq $collectionName)
            $collectionId = $collection.Id
    if($collectionId -ne $NULL)
        $projectCollection = $tfs.GetTeamProjectCollection($collectionId)
        $eventService = $projectCollection.GetService([Microsoft.TeamFoundation.Framework.Client.IEventService])
        $deliveryPreference = new-object Microsoft.TeamFoundation.Framework.Client.DeliveryPreference
        $deliveryPreference.Type = "Soap"
        $deliveryPreference.address = "http://localhost:8080/MSScrumService/3.0/WorkItemChangedEndpoint.asmx"
        $eventService.SubscribeEvent("WorkItemChangedEvent", "", $deliveryPreference)


    And that’s it. The Microsoft Visual Studio Scrum project now has an auto rollup feature.



    For more information on Scrum for Team System please see:


    Crispin Parker
    Senior Practice Consultant,
    EMC Consulting.

  • Scrum Masters Workbench Version 2 Goes Gold

    The next version of the Scrum Masters Workbench application has now been released and is available for download.


    What is the Scrum Masters Workbench?

    The workbench application is the next evolution of the massively successful Task Board for Team System (released by Conchango in 2008)providing a rich user interface and intuitive gesture control over your Team Foundation Server projects. This dashboard application offers you a unique view of your project work items and their relationships to one and another.

    This time around, we have aimed to include the best possible customisation options in order to allow you to interact with your team projects in a way that works for you.

    Compatible with nearly all TFS project templates and including native support for some of the most widely used; including:

    How much does this cost?

    Now for the news you have been dreading, the cost… It’s FREE! We offer this application completely free of charge. You can download your copy now for no cost at all.

    “It’s FREE!”

    What’s new in version 2?

    Over time, we have been iteratively improving the feature set of the workbench. The initial release was purely to support the SfTS v3 project setup, then came the multiple tab task board mode, followed by an item list display mode. This release includes a unique new display mode (Hierarchy mode) and some of the core productivity features that made the original Task Board such a hit.

    • Hierarchy Mode:
      This new and unique display mode allows you to see and interact with the entire work item relationship hierarchy on a single screen. See Hierarchy Guidance for more information.

    • Change Polling:
      The workbench now supports auto refresh functionality to ensure your loaded data is always up to date. See Change Polling Guidance for more information.

    • Improved common template support:
      The native support for common TFS templates (SfTS v2, SfTS v3, MSF Agile v5 and TFS Scrum v1) has been improved. The template type identification and default project layout has been improved to get you up and running without the need to drag columns into order and define views.

    • Reset Default Layout:
      This new feature allows you reset the project work item relationship views to the default setting. This also allows users of previous workbench versions to quickly update their project layouts to the new format.

    • Search:
      You can now find work items using the search feature. See Search Guidance for more information.

    • Highlight In:
      Auto switch between workbench display modes to view your work item data by selecting the "Highlight In" option. See Highlight In Guidance for more information.

    • Adjustable task board row height:
      You can now adjust the height of rows in the task board view by dragging the row footer. See Task Board Guidance for more information.

    • Task card size:
      The size of the task board cards can now be selected. See Task Board Guidance for more information.

    • Customisable context menus:
      Select which work item fields are accessible in the context menus. See Item Context Options Guidance for more information.

    • Customisable display fields:
      You can now select which work item fields are visible in the workbench display. See Item Context Options Guidance for more information.

    • TFS Web Access integration:
      Links to the TFS web access pages are now included to enable quick access to all TFS features not natively supported in the workbench.

    • Multi-select editing:
      The item list mode now supports multi-select editing. Use the [Ctrl] or [Shift] keys to select a range of cells to edit simultaneously. See Item List Guidance for more information.

    Over the coming few days I will recording and releasing webcasts to demonstrate the new features and give you some tips on getting the most of work bench application.

    For more information and to see the latest Scrum for Team System news, head over to:


    Crispin Parker,
    Senior Practice Consultant,
    EMC Consulting.

  • Scrum for Team System v3 – Release dates rollup fix.

    In the current SfTS v3 release (Scrum for Team System v3.0.3784.03), the “Release” work item “Actual Start Date” and “Actual End Data” fields are not being correctly updated by the rollup service. The cause has been tracked back to an issues with the event notification subscription. This error will be fixed in the next SfTS v3 release, but in order to correct the issue now you can follow the below detailed steps.


    1. Using SQL Serve Management Studio, connect to your TFS application tier database using an account with administrative db permission.

    2. Execute the following SQL command:

      UPDATE [Tfs_DefaultCollection].[dbo].[tbl_EventSubscription]
      SET [Expression] =
              '|Product Backlog Item|Sprint Backlog Task|',
              '|Product Backlog Item|Sprint|Sprint Backlog Task|'
      [Expression] LIKE '%|Product Backlog Item|Sprint Backlog Task|%'

    3. Repeat step 2 for each project collection that has SfTS v3 deployed, replacing [Tfs_DefaultCollection] with the relevant database name.

    4. Restart the TFS IIS service in order to pick up the subscription changes.

    Note: The event subscription will be overwritten if you use the Deployment tool.




    Crispin Parker,
    Senior Practice Consultant,
    EMC Consulting.

  • Scrum for Team System v3.0, MSF Agile v5.0 and Team Foundation Server Scrum v1.0 (beta)

    With the recent launch of the new Microsoft Scrum template, I am often asked about a feature comparison between the Microsoft templates and SfTS. So, below I will look into the features available in each of the process templates.

    Project Life Cycle Tracking.

    One important feature of any scrum process template is the ability to track and plan the project life cycle. In Scrum the project life cycle is split into two main hierarchical components; Release and Sprint. So how do the templates stack up in tracking the life cycle:


    SfTS v3

    MSF v5

    TFSS v1 (beta)

    Tracking Concept Base True
    Planning Scope
    (AKA Iteration Path)
    Iteration Path
    Iteration Path
    Project pre-populated with sprints False True True
    Multi-Team / Multi-Cadence support True
    Includes a concept of
    Work Stream
    False False
    Release Detail Item True image False False
    Sprint Detail Item



    False True
    Sprint Team Detail Item True
    False False
    Sprint Retrospective True
    False True
    Cadence and Team Tracking Queries True False False
    Team Capacity Tracking True False False
    Planned Work Tracking True False False
    Work Item Auto Rollup * True False False

    You can see that the SfTS template offers a wealth of features to help you model your project life cycle. The downside to this advanced modelling is the one off effort required to set up your project. Release work items must be linked to Sprint work items which in turn must be linked to Team Sprint work items. Both MSF Agile and TFS Scrum create a default hierarchy of project nodes upon project creation. SfTS just gives you an empty node tree after project creation.

    To aid with the overhead of creating the project life cycle in SfTS, we have supplied a free utility entitled the Scrum Masters Workbench. This includes setup wizards to help you create your project life cycle structure in a matter or seconds. To get a free copy: Click Here.

    Project Feature Tracking.

    The most important aspect tracked in a process template is the required project features. In Scrum the project features are tracked on a prioritised and comparatively sized list known as the Project Backlog. The product backlog lists all the features that are required in the project, the importance of those features [to the business] and the comparative size [cost in effort] of implementing that feature.


    SfTS v3

    MSF v5

    TFSS v1 (beta)

    Backlog Item True
    Product Backlog Item
    User Story
    Product Backlog Item
    Sprint Task Item True
    Sprint Backlog Task
    Acceptance Criteria Item True
    Acceptance Test
    No implicit
    backlog integration
    Test Case
    Bugs True
    Impediment True
    Bugs live on the backlog False
    Bugs not used to
    track effort
    False True
    Bugs used to
    track effort
    Bugs linked into feature tracking True
    Bugs linked to
    features by tests
    False False
    Feature linked to all influencing items True False False
    Compatible with Microsoft Test Manager True True True
    Work Item Auto Rollup ** True False False

    As you can see from the above table, Scrum feature tracking is handled well in both SfTS v3 and TFSS v1 (beta). The main difference between them is the way in which Bugs are handled. In TFSS v1 bugs include the concept of effort. This field is used to track the remaining amount of effort needed in order to correct the bug. This makes TFSS bugs dual purpose, tracking both error description and work time. In SfTS v3, bugs have a single responsibility which is to describe the error condition. Tracking of the effort is done using the existing backlog constructs of PBI and SBT.

    See this bug blog post for a more detailed guide to bug modelling in SfTS v3



    Project management isn’t just about data entry. The project data needs to be visualised so that trends can be spotted and all stake holders have an idea of the projects status. This is mainly accomplished through reporting.


    SfTS v3

    MSF v5

    TFSS v1 (beta)

    Bug Reporting True True False
    Build Reporting True True False
    Product Feature
    Burn Down Reporting
    True False True
    Sprint Backlog
    Burn Down Reporting
    True True True
    Backlog Management Reporting True True False
    Test Case Reporting True True False
    Multi-team Comparison Reporting True False False
    Sprint Planning Reporting True True False
    Story Point to Hours Effort Reporting True False False
    Velocity Reporting True False True
    Warehouse Status Reporting True False False

    This table does not give you an exhaustive list of all reports available in each of the templates. Instead I have listed the main reporting concepts. The main loser in this comparison is TFSS v1. However, this is to be expected as it is still very new beta software. No doubt a full suite of reports will be released at some point in the future as the template matures.

    Project Portals

    All three templates include a project portal. This portal (SharePoint) site is used as the common review point and documentation repository for the project.


    SfTS v3

    MSF v5

    TFSS v1 (beta)

    Team Web Access Link True True True
    Personalised Dashboard False True True
    Project Level Dashboard True True True
    Excel Reports False True False
    Embedded Status Reports True True False
    Link to all Project Reports False True True
    Team Wiki True True True
    Document Repository True True True
    Project Calendar True True True

    The project portal is one of the weaker points of the SfTS template. The winner here is MSF Agile, having a mature portal that includes some excellent features and a whole suite of pre-defined excel reports. TFSS lacks integrated reports, but as I said earlier, I’m sure this will be redressed as the product matures.

    In Summary

    I’m sure there are many other comparative aspects that I have overlooked. But I think I have clearly demonstrated that each of the templates offers features that will be just right for someone. Whether you are looking for a simple quick start scrum setup, mature project management that nods towards scrum or a complete enterprise level scrum adoption, there is something there for you.

    One of the big wins for the SfTS template is the advanced Auto Rollup feature. The ability for values on linked work items to directly effect values on other work items cuts out a massive amount of administration work and is only available in the SfTS template. The rollup features give you a richer experience and makes the whole project hang together in a logical way. The process that controls the auto rollup functionality is (like the rest of the SfTS template) completely customisable. If you needs to change the rollup behaviour, you just edit the associated rules file contained within the installed SfTS web service.

    For more information on the rollup features see these blog posts.

    * In project lifecycle management, the auto rollup feature calculates team capacity and the duration dates between the linked Release, Sprint and Team Sprint work items. Amount of work planned and amount of work burned are also inferred from the use of planning scope.

    ** The SfTS auto rollup feature is used extensively in the feature tracking work items. Providing a rich interactive work item environment that brings the whole system to life using the new named linkage types made available in TFS 2010.



    Comments are open an welcome.



    Crispin Parker,
    Senior Practice Consultant,
    EMC Consulting.

  • Scrum for Team System Version 3 – How to model BUGS

    I was recently asked how to use the bug work item in a SfTS v3 project and as this is something I have been meaning to write about it got me thinking. Here is the result of my rambling thoughts…

    Adoption of Convention.

    In the SfTS v3 template we have chosen to be a facilitator and not a rule master. By this I mean that we have provided a framework to allow you to perform scrum and not a set of rules on how you should perform scrum.

    This of course leads to the eternal question: How do I…?

    The answer is implement an internal “Adoption of Convention”. As a company, Department, Team, or whatever type of group you are, you should discuss and decide upon a course of action that models the behaviour you require and then ensure that everyone involved follows that practice. This could be performed when scrum adoption is implemented. Once in place, you can periodically get together and review the convention. If you find it does not cover all the situations you require, then change it. Which, I hope you will agree, is all very agile.

    Sooooo, how do I manage Bugs then?

    Firstly, what is the behaviour you are trying to model? Here’s an example of what that question might mean to you:

    • As a scrum team I want to manage software bugs so that I can ensure they get the correct attention they require.

    In SfTS v3, bugs are a description of a failure condition and not a description of work required to fix the problem. So when a failure condition is discovered, we need to create a bug work item (including all the relevant information we need to describe the bug) and adjust our backlog to describe the work needed to fix the issue.

    In order to accomplish this we need to consider the bugs affect on our product backlog. When the effect is known, we then decide how we track and schedule the work to fix the bug.

    “The bug describes the error condition.
    The backlog describes the work.
    And bugs influence backlogs.”

    Modelling the Bug in your backlog.

    Here is an example work flow on how you might create a bug and show how it affects your product features:

    Workflow to create a bug


    So lets break down that work flow a little in order to understand what actions it describes.

    1. A failure condition is discovered. This could happen at any point during the project lifecycle.
    2. A bug is created to describe the failure condition.
    3. Now we check which product features are affected by this bug.
      1. If no features are affected, then the bug has highlighted a hole in the backlog. To fix this we create a new PBI.
      2. If feature(s) are discovered, then select them for the following actions.
    4. Do the selected PBIs contain Acceptance Tests that check the failure condition? (If so who let the bugs get out!)
      1. If no test exists, create a new linked AT for the affected PBI(s).
      2. If we already have tests, select them for the following actions.
    5. Finally, link the bug to the test.

    Tracking Bugs.

    So far all we have done is describe the bug and how it affects our backlog features. If we want to progress and describe the cost of fixing these bugs, then we are going to have to do a little more work. By linking the bugs into our backlog, we have changed the backlog behaviour. If the linked PBI was in a state of “Done” it will be updated to a state of “Broken”. If the PBI is not “Done”, then the presence of an active Bug will prohibit the PBI from automatically being set to “Done”.

    How the affected PBIs are now handled depends on their current project lifecycle position. Are they:

    • Currently active in a sprint?
    • From a previous sprint?
    • Scheduled for some future sprint?

    Below is another example workflow of how you might choose to handle tracking bugs.

    Tracking a bug


    Once again, I’ll break down the actions of the work flow to show what it describes.

    1. The “Active” Bug is linked to an Acceptance Test.
    2. The status of the AT is automatically set to “Failed”.
    3. Is the tested PBI “Done”?
      1. If “Done”, then PBI status is automatically set to “Broken”.
        • The Product Owner is consulted to confirm if the PBI is still relevant.
          1. If true, the PBI is scheduled for further work (maybe in a subsequent sprint)
          2. If false, the PBI is set to “Deprecated” and ignored. This may occur if the historical PBI has been superseded.
      2. If not “Done”, then the action to automatically set “Done” will be blocked.
        • Is the PBI currently in an active sprint?
          1. If not, leave it on the future backlog. You might want to bring it to the attention of the Product Owner.
          2. If active; does the PBI already contain tasks that cover the bug?
            1. If true, extend the remaining duration of the task to cover bug fix the work.
            2. If false, add a new task to track the work needed to fix the bug.

    It may all look horribly complicated, but when you drill down it amounts to 3 possible outcomes:

    1. The PBI is no-longer relevant (deprecated).
    2. The PBI is scheduled for future work.
    3. The PBI tasks are updated to include the actions needed to fix the bug.

    So in fact it is pretty simple.

    After following this Tracking workflow, you should have all the information needed to track and schedule fixing the bug. Of course, you may want to do more in your adoption of convention. For example, you might want to create tasks for future PBIs (not currently “in sprint”), so that the time cost of the bug fix is know straight away. The best solution is the one that works for your company.

    Fixing the Bugs.

    When you’ve confirmed the effect the Bug has on our backlog and scheduled the work, you’re ready to fix the bug. This fix might occur during the current sprint or in some future sprint. It all depends on the impact of the bug and features it effects. As Bugs are linked to PBIs via an Acceptance Test, the test should be used to confirm the bug has been rectified. The work flow for fixing bugs could be:

    Fixing a bug


    This looping work flow shows how the work items are passed around the team(s) until the bugs are resolved.

    Ignoring Bugs.

    If bugs seem like a lot of hassle, then why not just ignore them? If only that was possible! Joking aside, sometimes a bug might not be relevant and should be ignored. This is why the Bug work item type includes a status of “Ignored”. The reason a bug might not relevant could be that it affects retired functionality or maybe in the eyes of the Product Owner, the bug is in fact a design feature! What ever the reason, ignoring bugs should only be done if all the stake holders agree that the bug is in fact a red herring.

    Final thoughts.

    So there you have it a guide to implementing Bug handling that isn’t really a guide at all. This is only and example of what you could do. I’ve tried to add lots of “you could do it like this” or “this is one way you might do it” into the text. The version 3 template is provided to facilitate your scrum and not force you down a certain route. The nuts and bolts that make scrum work in your organisation are up to you discover. Whatever you decide to do, remember that it has to be flexible, if something doesn’t work, change it. Just make sure you let everyone know the conventions have changed!



    Crispin Parker,
    Senior Practice Consultant,
    EMC Consulting.

  • Task Board for Team System Version 2.1 released

    Today we have released a new version of the Task Board for Team System. This version is compatible with Team Foundation Server projects created from the Scrum for Team System version 2 template (TFS 2008).

    New in this version; a new visual skin and several bug fixes.


    To download the installer:


    Note: Your existing task board version 2 License files will continue to work with the new version 2.1 task board.



    Crispin Parker,
    Senior Practice Consultant,
    EMC Consulting.

This Blog



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