Update your Overview and Progress reports to support the Portfolio backlogs

Update your Overview and Progress reports to support the Portfolio backlogs

Rate This
  • Comments 4

In TFS 2010 we released the reports to show the overview of the backlog and the progress of the these items. It depends on your process template which reports were installed for you:

Scrum

Backlog Overview

Agile

Stories Overview

Stories Progress

CMMI

Requirement Overview

Requirement Progress

 

The reports contain logic to rollup information to PBI, User Story or Requirement which does not have a parent. However with the introduction of the Portfolio Backlogs in TFS 2013, this logic is no longer valid. When you create a portfolio, backlog items are now the child items of the Feature portfolio backlog work item type. Because the reports that shipped in 2010 and 2012 do not support these hierarchies, any backlog item that is now a child of a portfolio item does not show up in the report.

We have fixed this issue in the reports that ship with TFS 2013. To fix the issue for your team project, you can follow the steps as described in this article, which relies on the TFS Power Tools. If you have multiple team projects based on the same process template, and you want to update the reports for all these team projects, you can use the following PowerShell script as a base.

If you want to use the script, don’t forget to update the highlighted variables. And please first run it on a test environment, to ensure it works as expected.

Note: Please be aware with the power tools, all the reports are replaced! If you only want to overwrite the Overview and Progress report, you can always manually upload the rdl files to your reporting server.

#set the variables
$server=http://<your_server_name>:8080/tfs
$template="MSF for Agile Software Development 2013"

#add the OM Assembly
add-type -Path "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.TeamFoundation.Client.dll"
add-type -Path "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.TeamFoundation.VersionControl.Client.dll"

#Get authenticated credentials
$cred = get-credential <your_user_name>

$collecions=[Microsoft.TeamFoundation.Client.RegisteredTfsConnections]::GetProjectCollections() | ? {
    $_.Uri.AbsoluteUri.StartsWith($server)
} | % {
        $col=New-Object -TypeName Microsoft.TeamFoundation.Client.TfsTeamProjectCollection -ArgumentList (new-object URI -ArgumentList $_.URI), $cred
        $vc=$col.GetService([Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer])
        $projects=$vc.GetAllTeamProjects($false) | % {
            tfpt addprojectreports /collection:"$($col.Uri)" /teamproject:"$($_.Name)" /processtemplate:$template /force
        }
}

Leave a Comment
  • Please add 2 and 1 and type the answer here:
  • Post
  • Thanks Ewald!  Love the fact that this solution is in PowerShell!

  • Why process template upgrade wizard does not do this automatically? Will this implemented to 2013.1 version of the TFS process template upgrade wizard?

  • @Joonate: The "Configure Features" wizard is not a "Process Template Upgrade" wizard. It only adds the *minimum* amount of artifacts to ensure the new features are correctly configured. The reports are not part of the set of that minimum set. We don't update the team projects, because a customer can customize their team project, including the reports. And we don't want to overwrite any user customizations.

    That said, we have heard the feedback for a "Process Template Upgrade" loud and clear. We want to add this to the product at some point, but that effort needs a long runway.

  • In case others encountered these same issues...

    - The PS script requires PowerShell 3.0 or newer.  When running in PS 2.0, I got an assembly error in that PS was running under the .NET 2.0 run-time, but the TFS assemblies use the .NET 4.0 run-time. Installing PowerShell 3.0 or newer resolves this issue.

    - For the $server variable, be sure to specify the server name. "http://Localhost:8080" does not work with the given script; we had to specify the actual server name. So you'll need to update the script if you plan to re-use it across servers or production/non-production environments.

    Thanks,

    Matt

Page 1 of 1 (4 items)