Anytime you create a team project in Visual Studio TFS, you must choose a process or process template based on the process model you use. A process or process template defines the building blocks of the work item tracking system as well as other sub-systems.
If you have some experience with TFS, this was known as a process template in older releases; now it just refers to what creates the process. A process is an extensible system that you can customize to match your existing application lifecycle management process. It is fairly easy to work with processes, which are based in XML (extensible markup language).
Basic is the most lightweight and is in a selective Preview. Scrum is the next most light-weight. Agile supports many Agile method terms, and CMMI, which stands for Capability Maturity Model Integration, provides the most support for formal processes and change management.
The work tracking objects contained within the default processes and process templates—Basic, Agile, CMMI, and Scrum—are the same and are summarized below.
Choose Basic when your team wants the simplest model that uses Issues, Tasks, and Epics to track work.
Tasks support tracking Remaining Work.
Choose Agile when your team uses Agile planning methods, including Scrum, and tracks development and test activities separately. This process works great if you want to track user stories and (optionally) bugs on the Kanban board, or track bugs and tasks on the taskboard.
Tasks support tracking Original Estimate, Remaining Work, and Completed Work.
Choose Scrum when your team practices Scrum. This process works great if you want to track product backlog items (PBIs) and bugs on the Kanban board, or break PBIs and bugs down into tasks on the taskboard.
Tasks support tracking remaining work only.
Choose CMMI when your team follows more formal project methods that require a framework for process improvement and an auditable record of decisions. With this process, you can track requirements, change requests, risks, and reviews.
This process supports formal change management activities. Tasks support tracking Original Estimate, Remaining Work, and Completed Work.
The Scrum process supports the following work item types (WITs) to plan and track work, tests, feedback, and code review. With different WITs you can track different types of work—such as product backlog items, tasks, bugs, and more. These artifacts are created when you create a project using the Scrum process. They are based on Scrum principles and values.
The default processes are designed to meet the needs of most teams. If your team has unusual needs and connects to an on-premises server, you can customize a process and then create the project. Or, you can create a project from a process and then customize the project.
The following table summarizes the main distinctions between the WITs and states used by the three default processes.
Workflow states support tracking the status of work as it moves from a new state to a closed or a done state.
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.
The following diagrams show the typical forward progression of those WITs used to track work and code defects for the three default processes. 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.
Product backlog item
Out of the box, you get a choice of three: Scrum, Agile, and they are all pretty similar at the core, but provide different work item types (WIT) to help with planning and tracking work.
There are also some third-party processes that you may want to search and explore. More information on customizing the process templates is at https://msdn.microsoft.com/en-us/library/ms243782.aspx.
© 2021 Digcode.com