Chia sẻ qua

Terms and concepts used when tracking work items in Azure Boards

  • Bài viết

TFS 2018

The Microsoft Agile glossary is a short dictionary of terms used in tracking work using Azure Boards. More terms are defined in the following articles:

Agile methods

A family of engineering best processes with a goal of enabling rapid delivery of high-quality software and a business approach that aligns development with customer needs and company goals. In this paradigm, frequent inspection and adaptation are necessary, with team work, self-organization, and accountability all critical to project success.

Agile tools

A suite of web-based tools used to track work and support Agile methodologies. Agile tools support the core Agile methods—Scrum and Kanban—used by software development teams today. Learn more: About Agile tools and Agile project management.

Area path

Area paths are used to group work items by team, product, or feature area. Iteration paths are used to group work into sprints, milestones, or other event-specific or time-related periods. You can use area paths to define a hierarchy of paths. To learn more, see About area and iteration paths.

Bugs

A type of work item that records a potential source of dissatisfaction with the product. The common name of a work item type for tracking code defects. Each team can choose how they want to manage bugs. Some teams like to track bugs along with requirements on the backlog. Other teams like to track bugs as tasks performed in support of a requirement. The bugs then appear on their Taskboard. Learn more: Manage bugs.

Categories

Groups one or more work item types to support flexible reporting, queries, and other functions made available through Agile tools. Categories support the process configuration used by the web portal backlog and taskboard pages. For example, you can add custom work item types to the Requirements category and manage them using the product backlog and Kanban boards. For more information, see Use categories to group work item types.

Collections

A collection is a container for a number of projects in Azure DevOps. A default collection is created when you sign up with Azure DevOps Services or install Team Foundation Server. Within Azure DevOps Services, a collection corresponds to an organization. For on-premises TFS deployments, you can add and manage collections to specify the logical and physical resources available to the projects within the collection.

Learn more: About projects and scaling your organization, Manage organizations or Manage project collections in Team Foundation Server.

Dashboards

Dashboards are user-configurable interactive signboards that provide real-time information. Dashboards are associated with a team and display configurable widgets to show information. To learn more, see Add and manage dashboards.

Discussion

Area within a work item form that supports adding and reviewing comments made about the work being performed. This way, you capture all comments within the work item rather than maintaining a long email thread. Within the discussion section, you can use the @mention control to notify another team member about the discussion. Simply type @ and their name.

Favorites

Tagging an object as a favorite is a method used to support quick navigation by yourself or other team members. You can tag work item queries and build definitions as personal and team favorites. Other objects you can tag as a favorite for yourself only include code branches, delivery plans, test plans, and teams or projects. To learn more, see Set personal or team favorites.

Fields

Fields support tracking a piece of information about the work to perform. Values you assign to a field are stored in the work tracking data store that you can query and generate charts to view status and trends. Your project contains 100 or more data fields. You update data by modifying the data field within a work item. Each work item is associated with a work item type (WIT), and the data you can track corresponds to the fields assigned to the WIT. For a definition of each predefined field, see Work item field index.

Follow

Tagging specific work items or pull requests to follow them is a method used to receive email updates about changes that are made to them. To learn more, see Follow a work item or pull request.

Global lists

Defines a list of menu items or picklist items that are shared across WITs and projects within a project collection. Global lists help to minimize the work that is required to update lists. You can define global lists within WITs that you upload with your process template. Learn more: Manage global lists for work item types. (Only supported for Hosted XML and On-premises XML process models)

Global workflow

Specifies both work item fields and global lists that multiple projects and types of work items can share. Learn more: Manage global workflow (Only supported for On-premises XML process model).

Hidden types categories

Specifies the set of work item types that you don't want users to create manually. By default this set includes:

You can use TFS Team Project Manager, an open-source client available from GitHub to quickly determine which WITs belong to the Hidden Types Category.

Hosted XML process model

The Hosted XML process model provides support for customizing work tracking objects and Agile tools for a project by modifying and importing a process template. This process model is only available for select accounts hosted on the Azure Boards cloud platform. For more information, see Hosted process model.

Issues or impediments

A type of work item that helps track unplanned activities. Resolving an issue or impediment requires more work beyond what was scheduled based on actual requirements. Using the issue (Agile or CMMI process) or impediment (Scrum process) work item type helps you track and manage these issues until you can resolve and close them. Learn more: Manage issues and impediments.

Inheritance process model

The Inheritance process model provides support for customizing work tracking objects and Agile tools for a project through the user interface. This process model is only available for accounts hosted on the Azure Boards cloud platform. Projects inherit the customizations made to a process. For more information, see Inheritance process model.

Issue

Agile process: An issue is a type of work item that defines an item that you want to track as it may impact the completion of other work. It's defined for the Agile process and doesn't appear on any backlog or board. See Manage issues and impediments.

Basic process: An issue is a type of work item that defines some work or code defect that needs to be tracked. It's defined for the Basic process and appears on the product backlog and Issues Kanban board.

Note

The Basic process is available when you add a project to Azure DevOps Services or Azure DevOps Server 2019 Update 1. For earlier on-premises deployments, choose Agile, Scrum, or CMMI process.

Iteration paths (aka sprints)

A time period, usually two to three weeks, used to group work items to be completed during that time period. Sprints are used in Scrum methods to support sprint planning, sprint burndown, and other Scrum processes. Iteration paths allow you to group work into sprints, milestones, or other event-specific or time-related period. Learn more: About area and iteration paths.

Kanban board

An interactive, electronic sign board that supports visualization of the flow of work from concept to completion and lean methods. Azure DevOps provides a Kanban board for each product and portfolio backlog. Learn more: Kanban overview and Kanban board features and epics.

Links support defining relationships between work items and other objects—such as commits, branches, pull requests, and more—using different link types. For more information, see Link work items to other objects and Link types reference.

On-premises XML process model

The On-premises XML process model provides support for customizing work tracking objects and Agile tools for a project. With this model, you can update the XML definition of work item types, the process configuration, categories, and more. You can also update the attributes of fields. This process model is only available for on-premises Azure DevOps. For more information, see On-premises process model.

Pick lists

A picklist specifies an enumerated set of values that appear within a drop-down menu in a work item form. Values also appear in the Value column within the query editor. The method you use to customize a picklist varies. It depends on the field and the process model. For more information, see Customize work.

Plans (also known as delivery plans)

A plan is a configurable view that displays work from multiple teams and projects laid out within a calendar based on each team's iterations. Each row in the view represents the work from a team's product or portfolio backlog. Each card corresponds to a work item, such as user story, feature, or epic. To learn more, see Review team delivery plans.

Portfolio backlog

An interactive list of work items, similar to the product backlog, that supports organizing or grouping work under features, epics, or scenarios. Portfolio backlogs work similarly to product backlogs in that you can prioritize work and view the tree hierarchy of work. Learn more: Define features and epics.

Process configuration

Specifies the default configuration and functional capabilities that your teams can access using the Agile tools. These web portal tools include the product backlog, sprint backlogs, Kanban board, and taskboard. (Only supported for Hosted XML and On-premises XML process models)

Process model

The work tracking customization method supported by your organization or collection. One of three process models are supported, Inheritance and Hosted XML for Azure Boards and On-premises XML for on-premises Azure DevOps. Learn more: Customize your work tracking experience

Process template

Specifies an inter-related set of files that contain the XML definitions for tracking work and defining the initial configuration of other functional areas. The system provides three default process templates—Agile, Scrum, or CMMI. You can create a project and then customize it, or customize a process template that you then use to create a project. (Only supported for Hosted XML and On-premises XML process models)

Product backlog

An interactive list of work items that corresponds to a team's project plan or roadmap for what the team plans to deliver. The product backlog supports prioritizing work, forecasting work by sprints, and quickly linking work to portfolio backlog items. You can define your backlog items and then manage their status using the Kanban board.

Each product backlog can be customized by a team. Learn more: Create your backlog.

Product backlog item (PBI)

A type of work item that defines the applications, requirements, and elements that teams plan to create. Product owners typically define and stack rank product backlog items which are defined with the Scrum process. Learn more: Scrum process work item types and workflow.

Projects

A project, which was previously known as a team project, provides a repository for source code. A project provides a place where a group of people can plan, track progress, and collaborate on building software solutions. A project is defined for an Azure DevOps Services organization or within a TFS project collection. You can use it to focus on those objects defined within the project. To learn more, see About projects and scaling your organization.

Queries

Queries are used to find and list work items. Queries support managed searches, which are used to triage work, versus ad-hoc searches, which are used to find a specific work item. Flat-list queries also support status and trend charts. To learn more, see About managed queries.

Rollup

Rollup refers to the sum of Remaining Work, Story Points, or other numeric field of child and descendent work items within a hierarchy. Azure Boards supports some native rollup features. To learn more, see Rollup of work and other fields.

Sprints (also known as iterations)

A sprint is a time period of usually two to three weeks that's used to group work items to be completed during that time period. Sprints are used in Scrum methods to support sprint planning, sprint burndown, and other Scrum processes. Sprints are defined via iteration paths. To learn more, see About area and iteration paths (aka sprints).

Sprint backlog

An interactive list of work items that have been assigned to the same sprint or iteration path for a team. The sprint backlog supports teams that use Scrum methodologies. Learn more: Sprint planning.

Taskboard

A taskboard is an interactive board of work items that you can use to review and update tasks defined for the sprint backlog. The taskboard supports teams that use Scrum methodologies. To learn more, see Update and monitor your taskboard.

Teams

A team corresponds to a selected set of project members. With teams, organizations can subcategorize work to better focus on all the work they track within a project. Each team gets access to a suite of Agile tools. Teams can use these tools to work autonomously and collaborate with other teams across the enterprise. Each team can configure and customize each tool to meet their work requirements. To learn more, see About teams and Agile tools.

User story

A type of work item that defines the applications, requirements, and elements that teams plan to create. Product owners typically define and stack rank user stories. User story is defined with the Agile process. Learn more: Agile process work item types and workflow.

Widgets

Widgets display information and charts on dashboards. Many of them can be configured. Many widgets display information available from one or more data stores or charts created by the system. To learn more, see Widget catalog.

Work item types (WITs)

A WIT specifies the fields, workflow, and form used to track an item of work. Each WIT is associated with more than 30 system fields and several more type-specific fields. You use work items to plan and track the work required to develop your project. For an overview of predefined WITs provided with the default processes, see About processes and process templates.

Workflow

A workflow is an integral aspect of a work item. It's defined by its corresponding work item type. The workflow determines the logical progression and regression of work items. For the Agile process, it tracks the status of work as the work progresses from a New or Active state to a Closed or Completed state. For the Basic process, all work item types use the To Do, Doing, and Done states to track workflow status.

The workflow also specifies the values that appear in the State and Reason drop-down menus. For more information, see Workflow states and state categories.