Scaled Agile Framework: Using TFS to support epics, release trains, and multiple backlogs

Visual Studio 2013

Enterprise customers have seen the advantages of individual agile teams. However, scaling these practices across teams and implementing agility at an enterprise level presents several challenges. The Scaled Agile Framework® (SAFe™) provides a roadmap on how to meet these challenges and scale agility. And, if you have an on-premises deployment of TFS 2013, you can use SAFe.

You can use team projects that you created with out-of-the-box TFS process templates to track SAFe criteria. This paper walks you through how SAFe concepts map to TFS, how to plan and track SAFe projects in TFS, and how to configure and customize TFS to support SAFe.

If you’re familiar with Scrum but not familiar with SAFe, these videos at Scaled Agile Framework Foundations from Inbar Oren, the Lean Samurai are a good way to orient yourself.

Map SAFe concepts to TFS concepts

SAFe supports a portfolio view of multiple agile teams. SAFe illustrates how a portfolio vision is met by a hierarchy of teams, all of whom have their own specific objectives. This framework breaks down Epics into Features and Stories, which teams work on in Sprints and deliver through Program Increments (PIs) and Release Trains. Also, the portfolio backlog can track how deliverables map to Strategic Themes and associated budgets.

Image courtesy of Leffingwell, LLC.

The examples in this paper illustrate how to add the Epic WIT and backlog, configure a three-level team hierarchy, and map teams to their respective area and iteration paths. The examples build from the TFS Agile process template. However, the changes can be applied to any TFS process template.

SAFe Portfolios, Programs, and Teams map to TFS team projects and teams

Because TFS supports a hierarchical team structure, each team has its own view of their work which rolls up to the next level within the team hierarchy.

To support SAFe teams, you reconfigure the default team as the Portfolio team to manage your Epics. You then create sub-teams for program-level work and team-level work. Work can be tracked across teams and through the levels.

SAFe Backlogs map to TFS backlogs

Out of the box, TFS supports the Story and Feature Backlog levels. You can easily add a third level to track Epics. User Stories can be mapped to Features, which in turn can be mapped to Epics. A hierarchical view of the backlogs shows how progress on User Stories contributes to Epics.

SAFe Releases, Iterations, and Sprints map to TFS iterations

SAFe Release Trains, Releases, Iterations, Program Increments (PIs), and Sprints map easily to TFS iteration paths. By sharing iterations across the team hierarchy, you manage the releases in a cohesive manner.

The Portfolio team tracks Epics, which can span several Release Trains or PIs. Program teams track their Feature deliverables, which ship with a PI. And Feature teams work in Sprints to complete several Stories. With TFS, each team chooses which iterations will support them to track their team deliverables.

SAFe Strategic Themes and Budgets map to TFS tags and fields

You can use tags to map Epics to their Strategic Themes or associated budgets.

You can search and query tags in TFS, and you can create reusable queries and reports using tags.

For a more robust mapping of work to Strategic Themes and budgets, you can add a field to your work items to track which theme or budget each Epic, Feature, or Story supports.

SAFe Metrics and TFS reports

You can view SAFe metrics by adding or customizing a report. For example, the Feature Progress report, similar to a Stories Overview report, shows which features are nearing completion and which are just starting. As teams work on stories linked to features, a progress bar appears. It depicts a given feature’s percent (%) complete. Stakeholders have actionable data to manage scope, resources, and priority.

For a downloadable version of the Features Progress report, see Scaling Agile and SAFe TFS Reports.

Plan/track SAFe projects in TFS

Once you’ve configured TFS to support SAFe, create trace relationships from Stories all the way up to Epics. Additionally, you can view progress from the Portfolio, Program, and Feature team levels.

Map Features to Epics and Stories to Features

The Program team can map Features to Epics using the mapping pane. Feature teams can use the same experience to map their Stories to Features.

Portfolio team’s view of progress

To track the progress of Epics that span Releases, the Portfolio team’s backlog shows Epics. Each Epic can be expanded to show the Features and User Stories that support it.

The Portfolio team can also view the progress of Epics on their Kanban board.

Program team’s view of progress

Program teams, primarily concerned with Release Trains, can see the Features in their Backlog, along with the PIs with which they’re associated.

Just like the Portfolio team, Program teams can also toggle their view to see which Epics their Features support, the User Stories that support their Features, or both.

Another view available to Program teams shows query-based graphs of Release Train progress, Backlog Items, or active tasks during a shipping sprint. A customizable home page view is available to each team.

Because so much of a program team’s work revolves around PIs and Release Trains, a custom report that shows the scheduled shipping dates and what is projected to be on any given train might be useful. In addition, if your TFS deployment includes integration with SQL Server Reporting Services or Project Server, you can take advantage of the rich reporting options and the built-in reports that each of these services has to offer.

Feature team’s view of progress

For individual feature teams, their backlog view shows the Stories that they’re working on.

Because feature teams don’t own Epics or Features, Epics and Features don’t appear in their team-level backlog views. However, if the team wants to know which Epics and Features they’re Stories support, they can turn on those views from their Backlog.

They can also break down their work into tasks and use the task board to keep themselves on track during specific sprints.

The chart view of queries becomes very useful in the Innovation and Planning (IP) sprint, when feature teams work together to stabilize the features scheduled for a Release.

For everything else, it is very much business as usual for individual feature teams. They can sprint in their usual cadences. They can use their Kanban board and task board to track progress and break down work into manageable chunks.

However, now their progress on individual stories is visible to their program and portfolio management teams. The management view reflects what they do.

Configure TFS to support SAFe

In this section, we’ll go from having one project, named "Fabrikam,” and one team, which shares the name of the project, to the following structure of three levels and nine teams. The area path hierarchy and configuring each team’s area path supports each team’s backlog view and rollup of views within the hierarchy.

Each project in TFS has a default team. You can configure additional teams for program-level and feature team-level work. And, you can also redefine the default team as the portfolio team that manages Epics.

In this way, all teams can manage their own workload and priorities while clearly understanding how their work supports those Epics managed in the portfolio team’s Backlog. At the same time, the portfolio team can monitor progress of its Backlog on their own Kanban board, prioritize the items on their Backlog, and view progress across Release Trains.

All this might sound complicated, but it actually takes very little configuration to set up the teams and get started.

We’re starting with one project with one default team, area, and set of iterations. First, we’ll configure an area path structure to support the hierarchy of teams we want. Then we’ll make sure that the iteration paths support the Release structure we want and the program and feature teams to use. Finally, we’ll create, configure, and populate the membership of teams.

You’ll need to be a member of the Project Administrators group to configure and customize TFS.

Create areas to support your team hierarchy

1. Connect to the team project you want to configure to support SAFe, and use the gear icon to open the administration page for the default team.

2. On the Areas page, create a child under the top-level area path and name it to correspond to one of the program teams you’ll create.

   

3. Next, create a second area at the same child level, and name it after the second program team.

4. Under each program area, create a child area for each feature team that will support their respective program team. You should end up with a 3-level area path hierarchy.

   

Create iterations to support your release trains and sprints

To track progress towards Releases, create your iteration path structure. Unlike area paths, multiple teams can share the same iteration path structure. Sharing the iteration structure lets multiple teams work in the same Sprint cadence towards the same Release Trains.

If you already have iterations for your default team, you can rename them. You’ll want to create an iteration structure that supports your entire team structure, not just one team.

1. Under the default iteration, which shares the same name as the project, create a child iteration that will represent your first program increment (PI). Optionally, add a start and end date for the PI, but keep in mind that the iteration will be broken down further into sprints.

   

2. Next, create a child iteration for each Sprint within the PI. Set dates for these sprints to correspond your feature teams' cadences.

   

Create and configure your teams

In this section, we’ll configure a hierarchical team structure which maps to the hierarchical area paths we created previously.

This structure maps the following SAFe teams to TFS teams:

• Portfolio team -> default top-level team, the Fabrikam team

• Program teams -> secondary-level teams, Fiber Suite and Service Suite

• Feature teams -> tertiary-level teams defined under Fiber Suite and Service Suite.

If you need more-detailed guidance, see Agile Portfolio Management: Using TFS to support backlogs across multiple teams.

You’ll need to be a project administrator in TFS to perform these steps.

Create and configure each Program team

1. From the Overview page for the team project, create a new team. Make sure that you clear the checkbox for Create an area path with the name of the team.

   

2. Choose the team from the list, go to the Areas page, and select the check box next to the area path that you previously created for that team.

   

3. Use the context menu to exclude sub-areas. By excluding sub-areas, the team’s backlog only includes those items whose Area Path matches the team’s default area path.

   

4. Next, configure the iterations that will be active for the program team. In this example, we have configured three PIs, each with five two-week sprints. Four of the sprints are regular sprints and the last sprint is an Innovation and Planning (IP) sprint.

   

     

   Because the Fiber Suite program team is concerned with Release Trains, we choose PI 1, 2, and 3, but we don’t choose the individual sprints.

5. Once you’ve selected which iterations are active for the team, add users to the new team. Ideally, you would add the scrum masters for each feature team, product owners, as well as the Release Train Engineers (RTEs) to the program teams, such as Fiber Suite.

   

6. If you’ve more than one team at the program level, repeat steps 1 through 5 for each program team.

Create and configure each Feature team

Next, we’ll create some Feature teams to get work done at the third level of the team hierarchy. Each Feature team will contribute sprint work that rolls up into the PI. The number of teams you create will depend on the size of your organization.

1. Create a new team from the administration page for the original team, and name the team. Just like before, make sure you clear the check box next to Create an area path with the name of the team.

   

2. Choose the team from the list, go to the Areas page, and select the check box next to the area path that you previously created for that team.

   

3. Configure iterations for the team, using the PIs and sprints you created earlier. Unlike the program teams, this time select the individual sprints as the working iterations for the feature team.

   

4. Add the accounts for the developers, testers, and the scrum master for the team. TFS supports assigning a scrum master to multiple teams. The scrum master can track work across multiple teams.

   

5. Repeat steps 1 through 4 for each Feature team in your organization. Make sure that the default area path you configure for the team is a sub-area path under its corresponding program-level area path. This ensures rollup from feature teams to program teams.

Configure the Portfolio team

Now that your sub-team structure is configured, reconfigure the default team to act as the Portfolio team. Even though this team will continue to have the name of the project, the changes you make to this top-level team will help ensure that it effectively tracks Epics across PIs at the highest level.

1. On the Areas page for the team project, change the settings so that sub-areas are not included. Make sure you choose the team project and not the default team, Fabrikam.

   

2. On the Iterations page, clear the check boxes next to all iterations except for the root level, which cannot be cleared. Because the Portfolio team is only concerned with Epics that span PIs, it only uses the root iteration and not the PIs or sprints. Portfolio teams don’t work in sprints.

   

3. Add and remove users from the Portfolio team appropriate to this level. From the Overview page, choose the default team.

   

      

   Consider adding other personas, such as portfolio managers, enterprise-level architects, and Release Train Engineers (RTEs) at this level and remove everyone else.

   

Customize TFS process to support SAFe

In this section, we’ll add the Epic WIT to the portfolio backlog hierarchy. We’ll also add the Requirement Type field to all three backlog WITs. And, we’ll create some Epics and map Features to Epics.

If you’re more interested in how things work after you add the Epic Backlog level, go there now. Also, if you would rather not have to do the customization steps outlined in this section yourself, the ALM Rangers have a blog post and sample PowerShell script that demonstrates how to install these customizations on your project.

Add Epic to the portfolio backlog

As before, you’ll need to be a member of the Project Administrators group to do these steps.

First, we’ll export an existing WIT and use it create the new WIT, which we’ll name Epic. We’ll also add a Requirement Type field to track what kind of Epic it is: Architecture or Business. Next, we’ll add a category for the Epics. We’ll then modify existing WITs─Features and User Stories, even if they’re not named that─to include the Requirement Type field. The Requirement Type field tracks the kind of objective each work item supports. Last, we’ll add Epic to the Portfolio team backlog.

Add the Epic WIT

The easiest way to create a WIT is to copy an existing one, rename it, and then edit it.

We’ll export the Feature WIT and use it as the basis for the Epic WIT.

1. In administrator mode, open a Command Prompt window. Change the directory to where you installed Visual Studio (or Team Explorer).

   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 WIT definition and save it as Epic.xml.

   witadmin exportwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /n:Feature /f:"DirectoryPath/Epic.xml"

3. Open the Epic.xml file, replace <WORKITEMTYPE name="Feature"> with <WORKITEMTYPE name="Epic">, 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="Epic">
      <DESCRIPTION>Tracks an Epic that will span Releases. </DESCRIPTION>
   

4. Edit the <Tab Label="Implementation"> or for CMMI, <Tab Label="Requirements"> section, replacing the following lines with <Filter WorkItemType="Feature" />.

   • Agile: <Filter WorkItemType="User Story" />

   • Scrum: <Filter WorkItemType="Product Backlog Item" />

   • CMMI: <Filter WorkItemType="Requirement" />

     Making this change restricts the links control to support Features as child work items of Epics.

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

5. Add the Requirement Type field to the Epic WIT definition. For this, we are going to borrow an existing field (originally created to support CMMI projects, but equally useful here for our purposes) Microsoft.VSTS.CMMI.RequirementType, and add it to the Epic FIELDS section.

   Find the FIELDS section, and add this code:

   <FIELD name="Requirement Type" refname="Microsoft.VSTS.CMMI.RequirementType" type="String" reportable="dimension">
      <REQUIRED />
      <ALLOWEDVALUES>
         <LISTITEM value="Architecture" />
         <LISTITEM value="Business" />
      </ALLOWEDVALUES>
      <DEFAULT from="value" value="Business" />
      <HELPTEXT>Indicates whether this supports business or architectural objectives.</HELPTEXT>
   </FIELD>
   

6. Next, add the field to the form. Under the FORM section, add the field wherever you think it works best for your business. In the example below, we added the field below the Iteration field.

   <Group Label="Classification">
      <Column PercentWidth="100">
         <Control FieldName="System.AreaPath" Type="WorkItemClassificationControl" Label="&amp;Area" LabelPosition="Left" />
         <Control FieldName="System.IterationPath" Type="WorkItemClassificationControl" Label="Ite&amp;ration" LabelPosition="Left" />
         <Control FieldName="Microsoft.VSTS.CMMI.RequirementType" Type="FieldControl" Label="Type" LabelPosition="Left" />
   

7. Save and then import the file.

   witadmin importwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/Epic.xml"

Add the Epic category

Now that we have an Epic WIT, we’ll add a category for Epics. TFS manages backlogs based on categories.

1. Export the Categories definition to an xml file.

   witadmin exportcategories /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/categories.xml"

2. Open the file and add the Epic category. You can choose to replace Microsoft with the name of your company, to indicate that it is your customization.

   <CATEGORY name="Epic Category" refname="Microsoft.EpicCategory">
      <DEFAULTWORKITEMTYPE name="Epic" />
   </CATEGORY>
   

3. As before, import the file.

   witadmin importcategories /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/categories.xml"

Add the Requirement Type field to track Business/Architecture work

Next, we’ll add the Requirement Type field to Features and to the third level of Backlog Item, whether that is User Story, Product Backlog Item, or optionally Bug. You don’t have to add it to Requirement, because it’s already included in the default CMMI definition.

1. Export the Feature WIT definition.

   witadmin exportwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /n:Feature /f:"DirectoryPath/Feature.xml"

2. Add the Requirement Type field, just as you did previously with the Epic WIT. Find the FIELDS section and add this code:

   <FIELD name="Requirement Type" refname="Microsoft.VSTS.CMMI.RequirementType" type="String" reportable="dimension">
       <REQUIRED />
       <ALLOWEDVALUES>
           <LISTITEM value="Architecture" />
           <LISTITEM value="Business" />
       </ALLOWEDVALUES>
       <DEFAULT from="value" value="Business" />
        <HELPTEXT>Indicates whether this supports business or architectural objectives</HELPTEXT>
   </FIELD>
   

3. Add the field to the form in the same position you added it to Epic. For example:

   <Group Label="Classification">
      <Column PercentWidth="100">
         <Control FieldName="System.AreaPath" Type="WorkItemClassificationControl" Label="&amp;Area" LabelPosition="Left" />
         <Control FieldName="System.IterationPath" Type="WorkItemClassificationControl" Label="Ite&amp;ration" LabelPosition="Left" />
         <Control FieldName="Microsoft.VSTS.CMMI.RequirementType" Type="FieldControl" Label="Type" LabelPosition="Left" />
   </Column>
   

4. Save and then import the file.

   witadmin importwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/Feature.xml"

5. Repeat steps 1 through 4 for the User Story and Product Backlog Item WIT definitions. Optionally, edit the Bug WIT definition if you want to track which requirement bugs support, or if you track bugs on your backlog.

Add the Epic category to the portfolio backlog hierarchy

Next we’ll add Epics to the hierarchy of work items that make up the Backlog.

1. Export the process configuration XML definition file.

   witadmin exportprocessconfig /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/ProcessConfiguration.xml"

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

   Modify the metastate mappings as needed based on your process template. The following example supports both Agile and CMMI projects. In addition, add the Requirement Type field to the Columns section.

   <PortfolioBacklogs>
     <PortfolioBacklog category="Microsoft.EpicCategory" pluralName="Epics" singularName="Epic">
         <States>
         <State value="New" type="Proposed" />
         <State value="Active" type="InProgress" />
         <State value="Resolved" type="InProgress" />
         <State value="Closed" type="Complete" />
         </States>
   <Columns>
        <Column refname="System.WorkItemType" width="100"/>
        <Column refname="System.Title" width="400"/>
        <Column refname="System.State" width="100"/>
        <Column refname="Microsoft.VSTS.Common.BusinessValue" width="50"/>
        <Column refname="Microsoft.VSTS.CMMI.RequirementType" width="100"/>
        <Column refname="System.Tags" width="200"/>
   </Columns>
       . . .
   </PortfolioBacklog>        
   

   Scrum projects require you to map New, In Progress, and Done workflow states. These are the same States that are mapped for the Feature portfolio backlog item.

           <State type="Proposed" value="New" />
           <State type="InProgress" value="In Progress" />
           <State type="Complete" value="Done" />
   

   And, CMMI projects require you to map Proposed, Active, Resolved, and Closed workflow states.

           <State value="Proposed" type="Proposed" />
           <State value="Active" type="InProgress" />
           <State value="Resolved" type="InProgress" />
           <State value="Closed" type="Complete" /> 
   

3. Next, add parent="Microsoft.EpicCategory" to the PortfolioBacklog category="Microsoft.FeatureCategory". Also, add the Requirement Type field to the Columns section.

   <PortfolioBacklog category="Microsoft.FeatureCategory" parent="Microsoft.EpicCategory" pluralName="Features" singularName="Feature">
      . . .
   <Columns>
        <Column refname="System.WorkItemType" width="100"/>
        <Column refname="System.Title" width="400"/>
        <Column refname="System.State" width="100"/>
        <Column refname="Microsoft.VSTS.Common.BusinessValue" width="50"/>
        <Column refname="Microsoft.VSTS.CMMI.RequirementType" width="100"/>
        <Column refname="System.Tags" width="200"/>
   </Columns>
       . . .
   
   </PortfolioBacklogs>
   

4. Next, add the Requirement Type field to the Columns section of the RequirementsBacklog section.

   <RequirementBacklog singularname="User Story" pluralName="User Stories" category="Microsoft.RequirementCategory">
      . . .
   <Columns>
        <Column refname="System.WorkItemType" width="100"/>
        <Column refname="System.Title" width="400"/>
        <Column refname="System.State" width="100"/>
        <Column refname="Microsoft.VSTS.Scheduling.Effort" width="50"/>
        <Column refname="Microsoft.IterationPath" width="200"/>
        <Column refname="Microsoft.VSTS.CMMI.RequirementType" width="100"/>
        <Column refname="System.Tags" width="200"/>
   </Columns>
      . . .
   </RequirementBacklog>
   

5. Add the colors to use for Epic to the WorkItemColors section. You can choose any colors you want, but ideally, don’t use a color already in use by the system.

   The color we’ve picked corresponds to orange (Hexadecimal color code=FF7B00). Prefix the hexadecimal color code with FF.

   <WorkItemColor primary="FFFF7B00" secondary="FFFFD7B5" name="Epic" />
   

6. Save and import the file.

   witadmin importprocessconfig /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/ProcessConfiguration.xml"

Update the Area Path for existing work items

For any existing work items to show up on a team’s backlog, you must update the Area path of each work item to the team’s default area path. You can use the bulk edit feature from your web browser or you can use Excel.

1. Create a query that contains the work items you want to edit, select the ones you want to edit, and then open the context menu from any one of the selected items.

   

2. Select the area path that corresponds to the team’s default area path.

   

3. Bulk save all work items that you modified.

   

For more information about bulk modifying work items, go here.

Add Epics and map Epics to Features

Now that you’ve added the Epic WIT, you’ll want to create some. The process is just the same as creating any other backlog work item. From the Portfolio team’s Backlog page for Epics, add an Epic backlog item.

Add as many Epics as you need. To list items in their order of importance, drag them within the list.

The default Requirement Type for Epics is Business, but you can change an Epic from Business to Architecture.

You can also add tags to your Epics, to help you track the investment themes each Epic supports.

Now view your Epics on the Kanban board. To get this view, you need to customize the Kanban columns to rename and add intermediate workflow states. For a description of these states, see Business Epic Kanban Abstract.

However, this is not very interesting yet. Nothing is in progress, and you can’t drill down to see which Features support your Epics. You’ll want to map existing Features to the Epics you just created, and map User Stories to those Features, if they’re not already mapped.

Map multiple items if you’ve an existing Backlog

Mapping work items is easy when you use the mapping pane. From the Features or Stories Backlog page, turn on the mapping pane. In our example, we choose the Fiber Suite team and turn on both the mapping pane and the view to see the hierarchy of Features mapped to Epics.

Note that if you’ve already changed the area path of all your Features to the appropriate program-level team, the Features list will be empty, because the Portfolio team does not own any Features! In that case, switch to one of the program teams.

Drag items from the Backlog onto the item you want to associate as a parent. You can only map Features to Epics. Similarly, you can only map the third level of Backlog item (whether that is User Story, Backlog item, or Requirement) to Features.

Repeat this process at each Backlog level until you’ve created the hierarchy you want.

What about Features already in progress? They definitely won’t appear on the Portfolio team’s Backlog. They are the responsibility of the program teams, so they appear on that team's Backlog. (This is actually a function of the area path set for the work item; a work item will only appear on a team's Backlog if you assign it to the area path you created for that team.) You can map them from there.

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

Since an important aspect of SAFe is to map work to business or architecture goals, you’ll want to make sure to set the Requirement Type=Architecture for any Feature mapped to an architecture Epic. (Because the default choice is Business, you don’t have to change the type for any item that supports a business Epic.) You can also add tags to track the investment.

The same principles apply to User Stories in progress. You can map them to Features, change the requirement type to Architecture for work that you do to support architectural Epics, and add tags for tracking themes.

Resources

Resources mentioned in this white paper and a few more are provided here for convenient reference.

• SAFe enabled process templates: Link to a download of the three process templates that TFS provides─Scrum, Agile, and CMMI─which have the customizations documented in this white paper added.

• Upgrade/Publish TFS 2013 Process Templates with PowerShell: blog post by Gordon Beeming that provides a PowerShell script that can be used to apply the changes documented in this whitepaper.

• Scaled Agile Framework: SAFe resource site.

• SAFe in 7 minutes: video from Inbar Oren, the Lean Samurai.

• Scaling Agile and SAFe TFS Reports: Downloadable Feature Progress report that works with the Scrum process template for on-premises TFS 2012 and 2013 deployments.

• Agile Portfolio Management: Using TFS to support backlogs across multiple teams: white paper that shows how to configure TFS to support multiple teams and multiple backlogs.

• Support rollup of work and other fields: Describes how to configure TFS to support rollup, the summed values of select fields for all child work items of a parent. Because TFS supports multiple levels of nesting, when you perform rollup, you want to make sure you don’t double-count values.

• Out of the box Reports (SQL Server Reporting Services): Summarizes the reports TFS provides to monitor progress and code quality.

• Synchronize Team Foundation Server with Project Server: Describes how project managers and development teams can use the tools that they prefer and share information transparently by enabling data to flow from work items in TFS to tasks in enterprise project plans in Project Server.

• Track your work when assigned to two or more teams: Shows how a developer or tester can track work when they support more than one feature team.

About the authors

Gordon Beeming is a Software Developer at Derivco in the sunny city of Durban, South Africa. He spends most his time hacking away at the keyboard in Visual Studio or with his family relaxing. His blog is at 31og.com and you can follow him on Twitter at twitter.com/gordonbeeming.

Brian Blackman is a principal consultant with Microsoft Premier Developer, focusing on affecting ISV partners and Enterprises success in engineering and the marketplace. He has an MBA, and is a CSM, CSP, MCSD (C++), and MCTS and is a Visual Studio ALM Ranger. When he is not Ruck Mastering and contributing to Visual Studio ALM Ranger projects, he spends his time writing code, creating and delivering workshops, and consulting in various concentrations, especially helping organizations in their quest for business agility.

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

Kathryn Elliott is a senior technical writer at Microsoft.

Susan Ferrell is a senior technical writer and a Visual Studio ALM Ranger.

Willy-Peter Schaub is a program manager with the Visual Studio ALM Rangers at the Microsoft Canada Development Center. Since the mid-’80s, he has been striving for simplicity and maintainability in software engineering. His blog is at blogs.msdn.com/b/willy-peter_schaub and you can follow him on Twitter at twitter.com/wpschaub.