Set up your Backlogs and Boards

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

In most cases you can start using your product and portfolio backlogs once your project is created. A default team is created along with associated backlogs and boards. You can start adding work items to your product backlog using the Backlog or Board.

However, if you have added a team and want to start using the team backlogs and boards, you may need to ensure you've configured your backlogs and boards correctly. Also, over time, changes may be made to a project or team configuration which can impact the work items that appear on your backlog and boards.

For an overview of the tools associated with your team, see Manage and configure team tools.

Default backlog and board work items

The first thing you need to understand is that your product Backlog and Board display work items which meet the following criteria:

  • Work item type belongs to the Requirements category. The types differ depending on the process selected for your project:
    • Basic : Issue, Backlog name=Issues
    • Agile: User Story, Backlog name=Stories
    • Scrum: Product Backlog Item, Backlog name=Backlog items
    • CMMI: Requirement, Backlog name=Requirements
  • Work item Area Path matches one of the selected team's Area Paths
  • Work item Iteration Path is under the team's Default Iteration Path

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.

  • Work item type belongs to the Requirements category. The types differ depending on the process selected for your project:
    • Agile: User Story, Backlog name=Stories
    • Scrum: Product Backlog Item, Backlog name=Backlog items
    • CMMI: Requirement, Backlog name=Requirements
  • Work item Area Path matches one of the selected team's Area Paths
  • Work item Iteration Path is under the team's Default Iteration Path

You can determine the work item types that belong to your Requirements category by opening your product Backlog and checking the product backlog name.

Product backlog level, Backlog items, Stories, or Requirements

As shown in the following image, (1) choose the team, (2) Work, (3)Backlogs, and then the product backlog.

Product backlog level, Backlog items, Stories, or Requirements

To look up your team's Area Path(s) and Iteration Paths, see Define area paths and assign to a team and Define iteration paths (aka sprints) and configure team iterations.

Checklist for work items, backlogs, and boards

If you don't see the work items you expect on your product Backlog or Kanban Board, perform the following checks:

  1. Make sure you have selected the team backlog or board of interest. To learn how, see Use breadcrumbs and selectors to navigate and open artifacts.

  2. Create a query of your backlog items, specifying the work item types that belong to your Requirements category and the Area Path associated with your team, for example:

    Requirement category query

  3. Add the State, Area Path and Iteration Path fields to the column options.

  4. Check the query results and that the values of the work items you expect to show up on your backlog meet these criteria:

    • Area Path belongs to your team's area path(s)
    • Iteration Path belongs under your team's default iteration path
    • State isn't Closed, Completed, Done, or Removed.

Note

You can also filter your product backlog to show or hide work items that are in an In Progress state category, corresponding to an Active, Resolved, Committed, Doing workflow state.

Add bugs to your backlogs and boards

For all processes except the Basic process, each team can manage the way bugs are tracked. You can track bugs as belonging to the Requirements category and they show up on the Backlog and Kanban Board, or the Tasks category and they show up on the Taskboard, or the Bugs category where they don't appear on either backlogs or boards.

Note

Bug work item types aren't available with the Basic process. The Basic process tracks bugs as Issues and is available when you create a new project from Azure DevOps Services or Azure DevOps Server 2019.1.

Each team can manage the way bugs are tracked. You can track bugs as belonging to the Requirements category and they show up on the Backlog and Kanban Board, or the Tasks category and they show up on the Taskboard, or the Bugs category where they don't appear on either backlogs or boards.

If you want bugs to show up on your Backlog and Board, choose Bugs are managed with requirements.

Working with bugs options

For details, see Show bugs on backlogs and boards.

Correct your Kanban Board configuration

If you see the following error when you open your Kanban board, you need to correct the configuration. The main reason for this error is that the workflow states of work item types that have been added to the Requirements category aren't mapped to the column.

Kanban board, Configuration error message

Choose the Correct this now link to open the Settings dialog. To map the workflow states, refer to Add columns to your Kanban board, Update Kanban column-to-State mappings.

Customize your Kanban Board checklist items

Checklists are a great way to create work items that are automatically linked with a parent-child link to another work item on a Kanban board. You can customize the work item types that you can add as a checklist by opening the Board Settings, choose Annotations, and enable the work item types you want to appear on the board. For details, see Customize cards.

For example, here we've chosen to track bugs along with tasks, and enable Task, Bug, GitHub objects, and Tests to appear within checklists.

Kanban board, Settings, Annotations

Note

The GitHub annotations require Azure DevOps Server 2019 update 1 or later version.

For example, here we've chosen to track bugs along with tasks, and enable Task and Bug to appear within checklists.

Kanban board, Settings, Annotations

To learn more about checklists, see the following articles:

Add other work item types to your Kanban Board checklist items

If you added work item types to the Task Category as described in Add custom work item types to your Taskboard later in this article, you can choose whether or not these types appear within a checklist on your product Kanban board. You do this by opening the Board Settings, choose Annotations, and enable the work item types you want to appear on the board. For details, see Customize cards.

For example, here we've chosen to track bugs along with tasks, and we enable Issue and Ticket as well as Task and Bug. To learn more about checklists, see Add task checklists and Add, run, and update inline tests.

Kanban board, Settings, Annotations

Hide or show backlog levels

Your team can also choose to hide or show one or more backlog level. Often times feature teams manage backlog items, while management teams manage features and epics. In this situation, you can enable or disable a backlog level.

Backlog navigation levels

For details, see Select backlog navigation levels for your team.

Add custom work item types to your backlogs and portfolio backlog levels

If you want to track different work item types on your product backlog, you can do that by adding custom work item types and adding them to a specific backlog level.

You can also add custom work item types and add them to portfolio backlogs. You can add up to five portfolio backlogs.

For example, here we've added Initiatives, 4th level, and 5th level work item types to support five levels of portfolio backlogs. We've also added a custom work item type named Ticket and added that to the product backlog.

Backlog navigation levels

For details, see the following resources:

Add custom work item types to your Taskboard

For on-premises deployments that use the On-premises XML process model to customize work tracking, you can add existing and custom work item types to the sprint Taskboards. For example, if you want to track Issues (or Impediments for the Scrum process) and a custom work item type, Tickets, along with Tasks and Bugs, you would perform the following tasks:

  1. Define the Ticket custom work item type. See Add or modify a work item type.

  2. Add Issue and Ticket work item types to the Task Category by modifying the Categories XML file. For details, see Categories XML element reference.

    For example, here we add Issue and Ticket to the Task Category.

      <CATEGORY name="Task Category" refname="Microsoft.TaskCategory">
        <DEFAULTWORKITEMTYPE name="Task" />
      <WORKITEMTYPE name="Issue" / 
      <WORKITEMTYPE name="Ticket" / 
      </CATEGORY>
    
  3. Make sure that the Issue and Ticket workflow states are mapped to category states. As needed, modify the ProcessConfiguration XML file to add Issues and Tickets to the TaskBacklog section.

    For example, here the New, Active, and Closed states are mapped for the Task Category.

      <TaskBacklog category="Microsoft.TaskCategory" pluralName="Tasks" singularName="Task" workItemCountLimit="1000">
        <States>
          <State value="New" type="Proposed" />
          <State value="Active" type="InProgress" />
          <State value="Closed" type="Complete" />
        </States>
    . . .
      </TaskBacklog>
    
  4. To verify your changes, open a Sprint backlog and make sure you can add an Issue or Ticket in the same way you add a Task. See Add tasks.

Note

If your project collection uses the On-premises XML process model to customize work tracking, you can enable work item types that you add to the Task Category to appear as a checklist on your product Kanban board. To learn how, see Customize your Kanban Board checklist items provided earlier in this article.

Other factors that can affect which work items appear

The following settings can impact on the type and number of work items that will appear in your backlogs and boards.

  • In your Kanban board, newly added work items may not appear if they are stack ranked lower within the product backlog. By choosing the Show more items link, you can cause the board to refresh and display these additional items.

    Boards, Show more items

  • If you have nested work items that belong to the same category, only leaf nodes may appear on the Kanban board (for TFS 2018.1 and earlier versions). For this reason, we recommend that you don't nest work items of the same work item type or belonging to the same category. To learn more, see Fix re-ordering and nesting issues, How backlogs and boards display hierarchical (nested) items.

  • If you have turned off the In Progress view, then those work items where work has started won't appear in the backlog list.

    Backlogs, View Options, Hide In Progress

    Backlogs, View Options, Hide In Progress

    Backlogs, Hide In Progress

  • Work items appear in the priority order in which they are added or moved to. This order or sequence is managed by the Stack Rank (Basic, Agile, and CMMI processes) or Backlog Priority (Scrum) field. To learn more, see Backlogs, portfolios, and Agile project management, Backlog priority or stack rank order.

  • Each backlog can display up to 999 work items. If your backlog exceeds this limit, then you may want to consider adding a team and moving some of the work items to the other team's backlog.

  • Sprint backlogs show only those work items that meet the team's area path and the Iteration Path defined for the sprint.

  • (Inheritance process model) If an administrator disables or deletes a work item type, it will no longer appear on backlogs and boards.

  • (On-premises XML process model) If an administrator deletes or destroys a work item type, it will no longer appear on backlogs and boards.