Agile Portfolio Management: Using TFS to support backlogs across multiple teams

In Team Foundation Server (TFS) 2012, you managed your team’s work in a backlog. In Team Foundation Server 2013, you can manage your work in a portfolio backlog that provides a management team insight into work across several agile teams. A management team defines the high-level goals and tracks work across multiple agile teams. Agile teams are the ones doing the work, breaking down items into tasks, fixing bugs, and contributing to the overall picture. All teams will have their own backlogs and boards, and will also have a roll-up view of the customer experiences supported by their work. When you're done, you'll be able to manage your portfolio of projects by grouping work according to backlog levels and see how it's being accomplished across multiple teams.

Each team works on its own backlog, while the hierarchy of backlog work item types enables managers to view a roll-up of progress at a higher level. In this whitepaper, we'll walk you through how to set up this kind of structure by following the hypothetical example of the Phone Saver management team and the agile teams working on specific areas of the overall project.

The Phone Saver management team defines work as high-level initiatives and breaks them down into features important to their customers. At that point, work is assigned to agile teams, who further break down and define the work to be done. As the project progresses, the management team drills down to see the progress at any level of detail they prefer. For example, they can view the backlog items associated with each feature item in a Scrum project.

In this screenshot, you can see the management team's view of their features backlog, with the product backlog items that support those items also shown. The management team does not own those product backlog items; they are assigned to one of the agile teams. However, because they are children of those items, the filter displays them. This way, the management team can track progress.

The informational graphic shows the conceptual level of information displayed in the above screenshot.

Each agile team, such as the Customer Team, has its own team home page, backlog, Kanban board, and task board. These pages only show the information relevant to that team.

In this screenshot, you can see the agile team's view of their sprint backlog, showing the product backlog items they are working on that sprint and the associated tasks they've created to break down and track the work. They do not see the features or initiatives they're working to support in this view. As before, the informational graphic shows the conceptual level of information displayed in this screenshot.

Set up teams and backlog levels

When you create a team project in TFS, a default team is automatically created for that project. By configuring additional teams for the agile teams to use to manage their day-to-day work, and redefining the default team into the team that the management team will use to manage work at their level, agile teams can manage their own workload and priorities. The management team view will show the progress for all of the work across the agile teams. It takes very little configuration to set up the teams and get started.

In addition to using agile teams to roll up progress, you can use backlog levels to create a hierarchical view of the work. In TFS 2013, you have immediate access to two levels of backlog. But if you need to add another level to support portfolio management, you can do that, too. It takes a little more configuration than creating agile teams, but it's still pretty straightforward. We'll walk through both setting up agile teams and creating an additional backlog level.

First, let's create the agile and management team structure, as seen in the example organization.

Create agile teams and configure the management team

1. From the home page for the default team, use the gear icon to open the administration page and choose New team to create an agile team.

   

2. Give the team a name, and make sure Create an area path with the name of the team is selected.

   

   This will be a sub-area of the area path for the management team–but more importantly, it provides both the separation of work across agile teams, and much of the automated roll-up of progress to the management team.

3. Configure sprints for the agile team.

   

4. Add members to the new agile team and remove unnecessary members from the management team.

   As a best practice, membership in the management team should be limited to the managers and team members who own initiatives and features. Members of the agile teams will still be able to see the management team's home page and backlog, just as the management team will be able to see agile teams' home pages and backlogs.

5. Change the areas for the management team so that sub-areas are not included.

   

Create as many agile teams as you need. When work items are assigned to an agile team, each of those teams will see those items on its backlog, and manage them on their Kanban board and/or task board, just as before.

An agile team's backlog showing backlog items and tasks

The management team will see all work items assigned to all agile teams in the backlog, Kanban board, and task board views, providing a master view of work in progress, as well as work yet to be started.

A management team's backlog showing features and agile team backlog items

Now that you've got your team structure set up, let's go ahead and add another level of backlog.

Add another backlog level

Adding another backlog level takes a little time, but is fairly easy to do. Let's walk through the process. You'll need to be a member of the team project administrator group to perform these steps. First you're going to export an existing work item type and edit it to create the new work item type, which we call Initiatives. Then you'll add a category for the initiatives. Lastly, you'll add initiatives to the portfolio backlog.

If you're more interested in how things work after you add the Initiative backlog level, click here to jump ahead.

Create the Initiative work item type

The easiest way to create a work item type is to copy an existing one, rename it, and then edit it. In the procedure below, you'll export the Feature work item type and use it as the basis for the Initiative work item type. Throughout the examples, the project name is Phone Saver, and the server name is Fabrikam. The team project collection name is the default name, DefaultCollection.

1. Open a Command Prompt window in administrator mode and change directories to where Visual Studio (or Team Explorer) is installed.

   cd %programfiles%\Microsoft Visual Studio 12.0\Common7\IDE
   

   On 64-bit editions of Windows, use %programfiles(x86)%.

2. Use the witadmin tool to download the Feature work item type definition and save it as Initiative.xml.

   witadmin exportwitd /collection:"http://fabrikam:8080/tfs/DefaultCollection" /p:"Phone Saver" /n:Feature /f:%userprofile%\documents\Initiative.xml
   

3. Open the Initiative.xml file, replace <WORKITEMTYPE name="Feature"> with <WORKITEMTYPE name="Initiative">, and update the description.

   <witd:WITD application="Work item type editor" version="1.0" xmlns:witd="https://schemas.microsoft.com/VisualStudio/2008/workitemtracking/typedef">
   <WORKITEMTYPE name="Initiative">
      <DESCRIPTION>Tracks an initiative that will be released with the product. </DESCRIPTION>
   

4. Edit the Tab element labeled Implementation. Replace <Filter WorkItemType="Product Backlog Item" /> with <Filter WorkItemType="Feature" />. This will show features as children work items of initiatives.

   <Tab Label="Implementation">
    <Control Type="LinksControl" Name="Hierarchy" Label="" LabelPosition="Top">
      <LinksControlOptions>
         <LinkColumns>
            <LinkColumn RefName="System.Id" />
            <LinkColumn RefName="System.Title" />
            <LinkColumn RefName="System.AssignedTo" />
            <LinkColumn RefName="System.State" />
         </LinkColumns>
         <WorkItemLinkFilters FilterType="include">
            <Filter LinkType="System.LinkTypes.Hierarchy" FilterOn="forwardname" />
         </WorkItemLinkFilters>
         <ExternalLinkFilters FilterType="excludeAll" />
         <WorkItemTypeFilters FilterType="include">
            <Filter WorkItemType="Feature" />
         </WorkItemTypeFilters>
      </LinksControlOptions>
    </Control>
   </Tab>
   

5. Import the file.

   witadmin importwitd /collection:"http://fabrikam:8080/tfs/DefaultCollection" /p:"Phone Saver" /f:%userprofile%\documents\Initiative.xml
   

Create the Initiative category

Now that you have an Initiative work item type, you'll want to add a category for initiatives to the set of categories visible in the team project.

1. Export the Categories definition to an xml file.

   witadmin exportcategories /collection:"http://fabrikam:8080/tfs/DefaultCollection" /p:"Phone Saver" /f:%userprofile%\documents\categories.xml
   

2. Open the file and add the Initiative category. Here's an example, where the Initiative category uses the company name to identify it as a customization:

   <CATEGORY refname="Fabrikam.InitiativeCategory" name="InitiativeCategory">
     <DEFAULTWORKITEMTYPE name="Initiative" />
   

3. Just as you did before, import the file.

   witadmin importcategories /collection:"http://fabrikam:8080/tfs/DefaultCollection" /p:"Phone Saver" /f:%userprofile%\documents\categories.xml
   

Add the Initiative category to the portfolio hierarchy

Now all that's left to do is to add your initiatives to the hierarchy of work items that make up the portfolio backlog.

1. Export the process configuration definition to an xml file.

   witadmin exportprocessconfig /collection:"http://fabrikam:8080/tfs/DefaultCollection" /p:"Phone Saver" /f:%userprofile%\documents\MyProcessConfiguration.xml
   

2. Open the file and add a PortfolioBacklog section for Initiatives within the PortfolioBacklogs section. At the same time, modify the PortfolioBacklog element for FeatureCategory so that Initiatives will be parent work items for Features.

     <PortfolioBacklogs>
     <PortfolioBacklog category="Fabrikam.InitiativeCategory" pluralName="Initiatives" singularName="Initiative">
         <AddPanel>
           <Fields>
             <Field refname="System.Title" />
           </Fields>
         </AddPanel>
         <Columns>
           <Column width="100" refname="System.WorkItemType" />
           <Column width="400" refname="System.Title" />
           <Column width="100" refname="System.State" />
           <Column width="50" refname="Microsoft.VSTS.Common.BusinessValue" />
           <Column width="100" refname="Microsoft.VSTS.Scheduling.TargetDate" />
           <Column width="200" refname="System.Tags" />
         </Columns>
         <States>
           <State type="Proposed" value="New" />
           <State type="InProgress" value="In Progress" />
           <State type="Complete" value="Done" />
         </States>
       </PortfolioBacklog>          
   <PortfolioBacklog category="Microsoft.FeatureCategory" parent="Fabrikam.InitiativeCategory" pluralName="Features" singularName="Feature">
   

3. Add the color to use for Initiative to the WorkItemColors section.

   <WorkItemColor primary="FFFF6600" secondary="FFFEB380" name="Initiative" />
   

   This assigns a bright orange color as the primary color to use in list displays, and a paler orange color to use on the task board and Kanban board.

4. Import the file.

   witadmin importprocessconfig /collection:"http://fabrikam:8080/tfs/DefaultCollection" /p:"Phone Saver" /f:%userprofile%\documents\MyProcessConfiguration.xml
   

And you're done! You‘ve added a third backlog level called Initiatives.

Define the Initiatives

Now that you have defined Initiatives, it's time to create some items. Members of the management team can quickly add one directly from the Initiatives backlog view. It's the same experience as adding backlog items to any backlog.

You can also create new features directly from the Initiatives work item by creating a new work item from the Implementation or Links tabs. That has the added advantage of creating the parent-child relationship at the same time you create the feature.

You could also choose to add an initiative as a parent of an existing features work item, if you already have some. That has the advantage of automatically associating that feature with the initiative that it supports. And from the feature, you can create backlog items and assign them to individual agile teams.

Map multiple items if you have an existing backlog

If you already have an existing backlog, you'll want to create the parent-child relationships between these items in order to support the automatic reporting of progress. You'll want to map backlog items to features, and map features to initiatives. Fortunately, the mapping pane makes this easy. First, turn on the mapping pane.

Now drop items from the backlog onto the mapping pane feature you want to associate as a parent.

Repeat this process at each backlog level until you've created the hierarchy you want.

You can also bulk edit work items and manage their hierarchy in Microsoft Excel.

View Progress

Now that you've associated your work items with the appropriate parent-child links, it's time to see how that view of progress applies across the various levels.

Management view of progress

At the management, the Initiatives backlog for the Phone Saver team shows the initiative work items for all teams in the Phone Saver project.

You can toggle the view to show the associated features…

…or drill down further, all the way to the backlog item or task level.

Tip: Add the Area Path column to see what team is working on which item.

Also, you can view progress on the Kanban board. The management team can see which initiatives and features are in progress.

Team view of progress

For the individual agile teams, the view is very different. As a member of one of those teams, if you browse to the Initiatives or Features backlogs, you won't see anything there. That's because agile teams don't create or work directly with items at that level. Agile teams will never see the full list of initiatives or features. However, if the team wants to know what initiatives and features they are supporting, they can turn on those views from the Backlog items backlogs, and they will see what features and initiatives are supported by the items they're working on.

For everything else, it's very much business as usual for the individual teams. They can use the Kanban board, task board, and other features just as they've always done, but now their progress is visible to their management without having to manually report on anything. What they do is reflected in the management view.

About the Authors

Gregg Boer is a principal program manager at Microsoft. Gregg is the product owner for the Agile Management experience in TFS.

Susan Ferrell is a senior technical writer at Microsoft.

Kathryn Elliott is a senior technical writer at Microsoft.