Work with team project artifacts, choose a process template

Go here to open the Visual Studio 2015 version of this topic.

Anytime you create a team project, you must choose its process template. The process template defines the set of work item types (WITs), queries, and reports that you’ll use to plan and track your project. Choose the template that offers the tools your team needs and reduces overhead so that your team can focus on quality.

To create a team project, go here.

To access the latest versions of Team Foundation Server (TFS) process templates, install Visual Studio Team Foundation Server (TFS). Then download them using the Process Template Manager.

The main distinctions between the three default process templates are in the work item types they provide for planning and tracking work. Visual Studio Scrum is the most light-weight and MSF for Capability Maturity Model Integration (CMMI) provides the most support for formal processes and change management.

Microsoft Visual Studio Scrum 2013 Choose Visual Studio Scrum if your team manages bugs along with product backlog items during sprint planning. The Scrum template is designed to support the Scrum methodology as defined by the Scrum organization. This process template tracks Bugs at the same level as Product Backlog items and tracks estimates using an Effort field. The system automatically zeroes out the Remaining Work field when the task State is set to Done.
MSF for Agile Software Development 2013 Choose Agile if your organization triages bugs separately from the product backlog and resolves work items before closing them. Also, choose Agile if your team allocates time for bugs with each sprint. The Agile template is designed to support Agile development for teams that don’t want to be restricted by Scrum. It supports estimating User Stories by using Story Points. Tasks contain fields to track Original Estimate, Remaining, and Completed work fields. Bugs aren't tracked on any backlog page. For more information about Agile methodologies, see http://www.agilealliance.org/.
MSF for CMMI Process Improvement 2013 Choose CMMI if your organization triages bugs separately from the product backlog, resolves work items before closing them, and tracks changes to requirements formally. The CMMI template is designed to support formal change management processes. This template supports estimating Requirements by using a Size field. Tasks contain fields to track Original Estimate, Remaining, and Completed work fields. Bugs aren't tracked on any backlog page. Go here to learn more about CMMI processes.

Main distinctions among the default process templates

The default templates are designed to meet the needs of most teams. All of them support using the Agile planning tools to create the product backlog and work in sprints with the task board. If your team has unusual needs, you can customize a template and then create the team project, or you can create a team project from a template and then customize the project.

The following table summarizes the main distinctions between the work item types and states used by the three default process templates.

Process area	Visual Studio Scrum	Agile	CMMI
Workflow states	New Approved Committed Done Removed	New Active Resolved Closed Removed	Proposed Active Resolved Closed
Product planning (see note 1)	Bug Product Backlog Item	User Story	Requirement
Portfolio backlog (2)	Feature	Feature	Feature
Task and iteration planning (3)	Task	Task	Task
Bug backlog management (4)	Bug	Bug Triage Workbook	Bug Triage Workbook
Project management (4)	Impediment	Issue Issues Workbook	Issue Risk Review Issues Workbook

Notes:

1. You can define these WITs using the Product backlog. The product backlog page shows a single view of the current backlog of work that can be dynamically re-ordered and grouped. Product Owners can quickly prioritize work and outline dependencies and relationships.

2. You can create Features and link them to backlog items to manage the portfolio backlog. With portfolio backlogs you can define a hierarchy of backlogs to understand the scope of work across several teams and see how that work rolls up into broader initiatives.

3. You can define tasks using the Sprint backlog and task board. The sprint backlog page reflects—in real time—the data you input. Data includes work items assigned to the iteration path, remaining work, individual work capacity, and work interruptions both for the team and individuals. Teams can get instant feedback on the rate of burndown and where they are over capacity.

4. Workbooks are only available when the team project is configured with a SharePoint project portal. However, you can create your own workbook by opening a corresponding query in Excel.

Workflow states

Workflow states support tracking the status of work as it moves from a new state to a closed or a done state. The following diagrams show the typical forward progression of those WITs used to track work and code defects for the three default TFS process templates. They also show some of the regressions to former states and transitions to removed states. Each image shows only the default reason associated with the transition.

Scrum	Agile	CMMI
Feature	Feature	Feature
Product Backlog Item	User Story	Requirement
Bug	Bug	Bug
Task	Task	Task

The Scrum and Agile WITs used by Agile planning tools support any-to-any transitions. You can update the status of a work item using the Kanban board or the task board by dragging it to its corresponding state column.

Workflow states, reasons, and transitions

The workflow defines the logical progression of tasks to be performed and by whom. Each workflow consists of a set of states, the valid transitions between the states, and the reasons for transitioning the work item to the selected state. You can change the workflow to support additional states, transitions, and reasons.

Removed, Closed, and Done states

When you change the state of a work item to Removed, Closed, or Done, the system responds like this:

• Closed or Done: Work items in this state don’t appear on the portfolio backlog and backlog pages. However, they do appear on the sprint backlog pages, Kanban board, and task board. Also, when you change the portfolio backlog view to show backlog items, for example, to view Features to Product Backlog Items, items in the closed and done state will appear.

• Removed: Work items in this state don’t appear on any backlog or board.

Work items are maintained in a team project as long as the team project is active. Even if you set them to Closed, Done, or Removed, a record is kept in the data store. You can use a record to create queries or reports. If you need to permanently delete work items, you can use the witadmin destroywi command-line tool.

Work item types added to all process templates

The following WITs are the same across all process templates.

Teams create and work with these types using the corresponding tool:

• Test Plan, Test Suite, Test Case Shared Steps, and Shared Parameters: Microsoft Test Manger.

  Shared Parameters became available when you upgraded your on-premises deployment to TFS 2013.2.

  Test Plan and Test Suite WITs become available when you upgrade your on-premises deployment to TFS 2013.3.

• Feedback Request and Feedback Response: Request feedback.

• Code Review Request and Code Review Response: My Work (from Team Explorer) and Code Review Request.

Work items from these type definitions are not meant to be created manually and therefore are added to the Hidden Types category. Work item types that are added to the Hidden Types category don’t appear in the menus used to create new work items.

Note

If you upgraded your team project from TFS 2012 or an earlier version to the current version of TFS, you might have to add WITs that didn’t exist in the earlier versions. For more information, see Configure features after a TFS upgrade.

WITs that support the test experience

WITs that support the test experience and work with Test Manager and Team Web Access are linked together using the link types shown in the following picture.

Using Team Web Access or Test Manager, you can view which test cases are defined for a test suite, and which test suites are defined for a test plan. However, these objects aren’t connected to each other through link types.

As noted above, the test plan and test suite WITs appear after you have upgraded your application-tier server to TFS 2013.3. You can customize these WITs as you would any other WIT. See Customize work tracking objects to support your team's processes.

If you change the workflow for the test plan and test suite, you might need to update the process configuration as described here.

For definitions of each test field, see Build and test integration field reference.

To learn about changes made to Test Manager and Team Web Access with the upgrade to TFS 2013.3, see Opening test plan and test suite work item types.

Questions to ask your team

To track work effectively, team members need to agree on how they will use the work item types and tools. Here are a few questions for your team to answer.

Question	Team choices
How does your team track work?	If your team primarily tracks progress by updating the status of backlog items, they can use the Kanban board. Your team can also customize the Kanban board to track progress across several swim lanes. If you team breaks down backlog items into tasks for each sprint and estimates remaining work, they can use the sprint task board. Although remaining work is typically estimated in hours, you can use whatever time unit you want as long as you agree about the unit. By estimating and updating remaining work, your team can track progress through the burndown chart provided with each sprint.
Does your team track capacity per individual or by activity?	If your team tracks remaining work through tasks, they can assess the capacity for a sprint for individual team members or for different team activities such as development, test, and design.
How does your team group work?	You can group work in a number of ways. Items you create from the backlog page are automatically assigned to your team's area path. Items assigned to a sprint are assigned to the sprint's iteration path. Also, you can assign tags to work items to filter a backlog or a query result list.
Does your team use velocity and forecasting?	To support forecasting, your team can use the Effort (Scrum), Story Points (Agile), or Size (CMMI) fields to determine how many items can be completed for a sprint. Also, the velocity chart will show team progress sprint over sprint.
How does your team share information?	Team members can attach files to work items, check in files into source code, or share work using the team project portal. When a project portal is configured, your team has access to all the features a SharePoint site has to offer, including document libraries, wiki pages, blog, and event calendar.
Does your team support rollup of progress across several teams?	Portfolio backlogs let you quickly view a rollup of work in progress across several teams. If a team member works on more than one team, he can allocate his capacity accordingly for each team.

Q & A

Q: What if I’m updating a team project?

A: To use new features that were added when you install the latest version of TFS, see Configure features after a TFS upgrade.

To customize existing team projects, see Customize work tracking objects to support your team's processes.

Q: Which process template should I use with the Kanban board?

A: You can use the Kanban board with any process template, default or customized.

Q: How can I get the latest process templates?

A: The latest versions of the default process templates are automatically uploaded when you install or update to the latest version of TFS. Use the Upload, download, and delete process templates for a team project collection to download them.

Also, you can download Team Foundation Server 2013 Process Template Samples - Support for Scaled Agile Framework (SAFe). These templates contain the customizations described in this white paper: Scaled Agile Framework: Using TFS to support epics, release trains, and multiple backlogs.

Q: Is there a tool that supports visualizing the workflow state diagram?

A: Yes. You can use the Process Editor provided with Team Foundation Server Power Tools.

Q: What else is defined in a process template?

A: In addition to defining team project artifacts, the process template defines the initial configuration of many elements used to track work and support test activities. These elements include:

• Area and iteration paths

• Work item queries

• Test variables, configurations, resolution states, and default test settings

• Group and member definitions and permission assignments

• How Microsoft Project fields map to Team Foundation fields

All elements can be configured or customized after a team project is created from the process template.

Q: Can I customize a process template?

A: Yes. The default templates are designed to meet the needs of most teams. If your team has unusual needs, you can customize a template and then create the team project, or you can create a team project from a template and then customize the project.

Q: How have the process templates changed since the previous release?

A: See Changes made to team projects and default process templates during upgrade of Team Foundation Server.

Q: What if I need more than one portfolio backlog?

A: You can define additional portfolio backlogs for a total of five portfolio backlogs.

Q: Where can I learn more about storyboarding?

A: The Storyboards tab in the PBI form allows you to link to storyboards that you've uploaded to a shared network location. You can link to any URL that your team can access. Also, you can link to storyboards that you created using PowerPoint Storyboarding.

Q: Where can I go if I have more questions?

A: You can post a question or search for answers in the Team Foundation Server – Team Project and Work Item forum.