Backlogs, portfolios, and Agile project management

Azure Boards | Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013

You plan and track your project using the suite of Agile tools you access from the web portal. Agile tools support the core Agile methods—Scrum and Kanban—used by software development teams today. Scrum tools support defining and managing work within sprints, setting capacity, and tracking tasks. Kanban tools allow you to manage a continuous flow of work via an interactive sign board.

If you're new to Agile, see What is Agile? for an overview.

In a nutshell you use Backlogs to:

Note

To understand the differences between backlogs, boards, taskboards, and Delivery plans, see Backlogs, boards, and plans. If you're backlog or board doesn't show the work items that you expect or want, see Set up your backlogs and boards.

Note

To understand the differences between backlogs, boards, and taskboards, see Backlogs, and boards. If you're backlog or board doesn't show the work items that you expect or want, see Set up your backlogs and boards.

Product and portfolio backlogs

Backlogs present work items as lists. A product backlog represents your project plan, the roadmap for what your team plans to deliver. Your backlog also provides a repository of all the information you need to track and share with your team. Portfolio backlogs allow you to group and organize your backlog into a hierarchy.

Boards>Backlogs

"Web portal, choose Boards>Backlogs

Boards>backlogs, TFS 2015, 2013 web portal

Backlog configuration

Each backlog is associated with a team. Team configuration settings determine the work items that will appear on the team backlog. Specifically, the team administrator defines the following for their team:

  • Selects the Area Paths that are active for the team, only work items assigned to these area paths appear on the team's backlog
  • Sets the default Area Path and Iteration Path used when defining work items from the team backlog
  • Selects the Iteration Paths that are active for the team
  • Determines which backlog levels are active for the team
  • Defines how bugs will be treated, as requirements or as tasks.

For details, see the following articles:

Define work items and create your backlog

You build your project plan by creating a backlog of work items that represent the features, requirements, user stories, or other work to perform. Portfolio backlogs provide support for organizing work in a hierarchical fashion and tracking major product initiatives or scenarios that rely on many stories or requirements. Different types of work items help you track different types of work, such as user stories, tasks, bugs, issues, and more.

Define storiesOrganize backlogManage bugsManage issues

Backlog priority or stack rank order

The sequence of items on each backlog is determined according to where you have added the items or moved the items on the page. As you drag and drop items within the backlog list, a background process updates the Stack Rank (Agile and CMMI processes) or Backlog Priority (Scrum process) fields. These fields are used by the system to track the relative ranking of items on the product, feature, epic, or other portfolio backlog. By default, these fields don't appear on the work item form.

Reorder work items

You should refrain from using the bulk modify function to change the value of the backlog priority field. While you can assign a value to these fields, you'll be assigning the same value to all items you've selected for bulk edit.

The preferred method for bulk edit is to use multi-select to move items to the top, bottom, or specific position within the page. If you must perform a bulk edit of one of the backlog order fields to get a large number of work items in the priority order you want, use Excel. You can export a query containing the backlog items, update either the Backlog Priority or Stack Rank fields, and then publish your changes.

In Progress items and work listed on the backlog

Backlogs are designed to display work that corresponds to a Proposed, In Progress, or Resolved category state. Once you've completed work and its state enters a Done, or Closed state, then it falls off the backlog view. You can always create a query to view completed work, or view the Recently completed pivot from the Work Items page.

Backlogs are designed to display work that is in progress. Once you've completed work and it's state enters a Done, Completed, or Closed state, then it falls off the backlog view. You can always create a query to view completed work.

In general, you'll want to display all items that are in the In Progress category state, which corresponds to the Active and Committed states. To focus on work that is proposed but not in progress, you can toggle the backlog view to turn off In Progress. This is useful when forecasting your product backlog.

If your backlog is missing items, you might check if the In Progress view has been turned off. For additional information, see Workflow states and state categories.

Organize your backlog, mapping and reparenting backlog items

When you have a number of initiatives your teams are working on, you often times want to group the work according to these initiatives. By defining features and epics, you can group your work into a three-tiered hierarchy consisting of epics, features, and backlog items.

For example, here the Customer Service team has organized several backlog items under two features and one epic.

Backlog that shows parents and multi-team ownership

Work with multi-team ownership of backlog items

When you have several teams, your hierarchical views may show items that belong to other teams.

View backlog items and parent items owned by other teams

Your team's product backlog lists only those items whose area path matches those assigned to your team. For details, see Define area paths and assign to a team. However, if you show parents, you'll see the parent epic of the features and backlog items, even if the epic or feature is owned by another team.

Items that are owned by other teams appear with an information icon,  .

Backlog that shows parents and multi-team ownership

Tip

Add the Node Name field as a column to identify the area path/team associated with the work items.

Items that are owned by other teams appear with an information icon,  .

Backlog that shows parents and multi-team ownership

Tip

Add the Node Name field as a column to identify the area path/team associated with the work items.

Backlog displays with work item icons is supported for TFS 2017.2 and later versions. For TFS 2017.1 and earlier versions, items that are owned by other teams appear with hollow-filled bars.

Team backlog is filtered based on area path ownership

Items that are owned by other teams appear with hollow-filled bars.

Team backlog is filtered based on area path ownership

View Epics and child items owned by other teams

Here's another example that shows the Epics backlog for the Management team. Drilling down, you can see all the backlog items and features, even though they belong to one of three different teams: Customer Service, Phone, and Web.

Backlog that shows parents and multi-team ownership

Here's another example that shows the Epics backlog for the Management team. Drilling down, you can see all the backlog items and features, even though they belong to one of three different teams: Customer Service, Phone, and Web.

Backlog that shows parents and multi-team ownership

Drill-down of Epics showing features and backlog items owned by other teams

From these views, you can reparent items, both those that you own and those owned by other teams. However, you can't reorder items that another team owns.

This enables management teams to focus on high level features and epics, and development teams to focus on just those backlog items they're responsible to deliver.

To make this work for you, you'll need to add teams and set their area paths. For example, you can create a team structure similar to this one with two management and three development teams.

Conceptual image of backlogs and multi-team ownership

To learn more about hierarchical team and backlog structures, see Portfolio management.

Display of leaf node work items

When a product or portfolio backlog contains same-category, nested work items, only the last child item within the nested set displays on the Kanban board, sprint backlog, or taskboard.

While you can create a hierarchy of backlog items, tasks, and bugs—we don't recommend that you create same-category hierarchies. That is, don't create parent-child links among work items of the same type, such as story-story, bug-bug, task-task. The reason is that the Kanban board, sprint backlog, and taskboard only show the last node in a same-category hierarchy, called the leaf node. For example, if you link items within a same-category hierarchy that is four levels deep, only the items at the fourth level appear on the Kanban board, sprint backlog, and taskboard.

Instead of nesting requirements, bugs, and tasks, we recommend that you maintain a flat list. In other words, only create parent-child links one level deep between items that belong to a different category.

To learn more, see Fix "Ordering backlog items is disabled".

Permissions and access

As a member added to the Contributors group of a project, you can use most features provided under Boards or Work. Users with Basic access have full access to all features. Users with Stakeholder access are limited to certain features. For details, see Work as a Stakeholder.

To learn more about permissions and access, see Permissions and access for work tracking and About access levels.

To add users to a project, see Add users to a project or team.

Add portfolio backlog levels and boards

If you need more than two portfolio backlogs, you can add up to two more for a total of five backlog levels.

You can add them by customizing your process, adding new work item types, and then configuring your backlogs and boards. You can also add or modify the fields defined for a work item type (WIT) or add a custom WIT. For details, see Customize an inheritance process and Customize your backlogs or boards (Inheritance process).

You can add them by either customizing your inherited process or modifying your XML definition files. You can also add or modify the fields defined for a work item type (WIT) or add a custom WIT. To learn how, see the following articles based on the process model used to update your project:

Inheritance process model:

On-premises XML process model:

You can add them by defining additional work item types and then customizing your process configuration. You can also add or modify the fields defined for a work item type (WIT) or add a custom WIT. To learn more, see Customize the On-premises XML process model and Add a portfolio backlog level.

Try this next

If you're just getting started, see Start using Azure Boards.