Backlogs, boards, and plans

Last Update: 4/7/2017

Team Services | TFS 2017 | TFS 2015

What can you do from a backlog view versus a board view? How do these differ from plans? How do changes you make in one show up on the other? What customizations can you make for each?

Which view should you use to work with Agile methods?

In a nutshell...

  • Backlogs display work items as a list and boards display them as cards
  • You use your product backlog to quickly plan and prioritize your work
  • You use your sprint backlogs and task boards when you work in Scrum
  • You use your Kanban board to update work status and when you employ Kanban methods
  • Each backlog is associated with a board, changes to priority order you make in one are reflected in its corresponding board
  • Plans allow you to review the deliverables for several teams across sprints and a calendar schedule (Plans are in preview for Team Services. You access them by installing the Marketplace Plans extension.)
  • Backlogs, boards, and plans are configurable for each team

With list backlogs you can quickly develop your project plan; group and prioritize work; and perform bulk updates on selected work items. With boards, you can quickly update status and fields displayed for each work item.

And with plans, you can monitor progress, deliverables, and dependencies across several teams.

You access your backlogs and boards from the Work hub. When you work from the Stories (Agile) or Backlog items (Scrum) pages, you have access to the product backlog and Kanban board. When you work from a sprint page, you have access to the sprint backlog and task board. For an overview of working in Scrum or Kanban, see Get started with Agile project management.

Work hub, product backlog page

Three classes of backlogs, two types of boards

To manage work, you have access to three classes of backlogs—portfolio, product, and sprint—and two types of boards—Kanban and task. Backlogs list work items, boards display work items as cards. Backlog and board views provide similar and distinct features to support planning and tracking.

You use work items to share information, assign work to team members, track dependencies, organize work, and more. You can apply different filters to your backlogs and boards to just show those items of interest.

Portfolio, product, and sprint backlogs

Portfolio backlogs typically track high-level features, scenarios, or epics. Your product backlog contains a prioritized list of user stories, deliverables, or work you plan to build or fix. Portfolio backlogs help you organize your product backlog into a hierarchy of elements. Sprint backlogs contain just those items that each team is working on during a scheduled sprint or iteration period.

For details about working in each type of backlog, see Create your backlog, Organize your backlog (with portfolio backlogs), and Sprint planning (sprint backlogs).

TIP

You can't sort a backlog by column. However, you can use the Create Query option on each backlog to create a query that you can sort on any field column you choose. To learn more about queries, see Use the query editor to list and manage queries.

Kanban and task boards

Kanban and task boards support visualizing the flow of work and monitoring metrics to optimize that flow. Kanban boards track requirements, are sprint-independent, and you monitor the flow through the cumulative flow chart. Task boards track tasks defined for a sprint and you monitor the flow via the sprint burndown chart.

For details about working in each type of board, see Kanban basics and Task board.

Feature support across backlogs and boards

The following table indicates those elements or tasks associated with each type of backlog and board.

Associated element or task Backlog type:
Portfolio
Backlog type:
Product
Board type:
Kanban
Backlog type:
Sprint
Board type:
Task
Corresponding backlog or board type Kanban Kanban Portfolio or product Task Sprint
Add items and child items
(see notes 1, 2)
Yes Yes Yes Yes Yes
Reorder items Yes Yes Yes Yes Yes
Map items Yes (except the top-level portfolio backlog) Yes No No No
Filter Text or tags Text or tags Text or select fields Text Backlog items or people
Show/hide parents Yes (except the top-level portfolio backlog) Yes No No No
Show/hide in progress items
(see note 3)
Yes Yes No No No
Forecast No Yes No No No
Customize: show bugs (see note 1) No Yes Yes Yes Yes
Customize: Columns Yes, see Column options Yes, see Column options Yes, see Add columns Yes, see Column options Yes, see Customize workflow
Customize: Add more backlog or board views Yes, see Select backlog navigation levels Yes, when you add another team (see note 4) Yes, see Select backlog navigation levels Yes, see Define sprints Yes, see Define sprints
Customize: cards n/a n/a Yes n/a Yes
Charts Cumulative flow
Velocity
Cumulative flow
Velocity
Cumulative flow
Velocity
Sprint burndown Sprint burndown
Duration (see note 5) Project or release Project Project Sprint Sprint

Notes:

  1. Each team can determine how they want to track bugs: as requirements, as tasks, or not at all. When tracked as requirements, they appear in your product backlog, sprint backlogs, and Kanban board. When tracked as tasks, they appear in your sprint backlogs and task boards. For details, see Show bugs on backlogs and boards.
  2. Work items that appear on each team backlog and board meet the criteria defined for the team selected area and iteration paths.
  3. The "In progress items Show/Hide" control is another filter you can apply to your product and portfolio backlogs. This control essentially shows or hides those work items where work has begun. It's useful to show/hide In Progress items when forecasting sprint work.
  4. When you add a team, you essentially add another product backlog associated with that team. Each team can then manage their own set of sprint backlogs and portfolio backlogs. See Configure team settings for details.
  5. Duration refers to how you use your backlog or board to plan and track work over time. Once you change the State of a work item to done or completed, it no longer appears on a portfolio or project backlog. As you complete each sprint, the system maintains a history of your activity. You can review past sprints and sprint burndown charts by choosing the sprint listed under the Past section. For more information, see Sprint burndown.

Review team deliverables using plans

With delivery plans, you gain tailor-made views across several teams and their development backlogs—stories, features, or epics. You can use these views to drive alignment across teams by overlaying several backlogs onto your delivery schedule.

NOTE

Feature availability: Delivery plans, a Visual Studio Marketplace extension, is currently supported for Team Services only.

When you configure a plan, you select the team or teams and backlog levels of interest. To learn more about Plans, see Review team plans.

Example plans view

Work item tracking, Agile tools, and team default assignments

What work items appear on team backlogs and boards? When you add work items to a backlog or board, how are team defaults used to assign field values?

Depending on the size of your organization and your tracking needs, you can set up a team structure similar to the one shown. You do this by defining teams and their associated area path(s).

Each team has its own view of the work

For example, each feature team can be associated with a single feature area path—such as Customer Profile, Shopping Cart, Email—or several area paths. Each management team, which focuses on a set of features, can choose several area paths to monitor. This allows each feature team to have their distinct backlog to plan, prioritize, and track their work. And, portfolio or product owners can create their vision, road map, and goals for each release, monitor progress across their portfolio of projects, and manage risks and dependencies. To learn more, see Portfolio management.

NOTE

Some features are available only from Team Services or TFS 2017 or later versions. For details, see Set team defaults.

When you define a team, you define the team's:

  • Selected area path(s)
  • Default area path
  • Selected iteration path(s)
  • Backlog iteration path
  • Default iteration path

All Agile tools reference the area path(s) defined for a team. For example, one team might handle all work assigned to Customer Profile and Shopping Cart, while another team only manages work assigned to the Email area path. Also, the set of work items that appear on a backlog or board depend on the current State of a work item or it's parent-child status.

In addition, several tools reference the team's default iteration and associated iteration paths or sprints. For example, when you add new work items from a backlog or board view, or from a team dashboard, the system assigns the team's default area path and default iteration path to these work items.

Agile tool Area path (see note 1)

Iteration path

State

Portfolio or product backlogs Selected area path(s) Equal to or under team's backlog iteration path Active (corresponds to a Proposed or InProgress state category, see notes 2, 3)
Kanban boards (see note 4) Selected area path(s) Equal to or under team's backlog iteration path Any state (see notes 3, 5)
Sprint backlogs (see note 4) Selected area path(s) Team's selected iteration paths Any state (see notes 3, 5)
Task boards (see note 4) Selected area path(s) Team's selected iteration paths Any state (see notes 3, 5)
New work item widget Default area path Default iteration path n/a

Notes:

  1. Agile tools filter items based on the team's selected area path(s). Teams can choose whether to include or exclude items assigned to subarea paths.
  2. Work items whose State equals Closed, Done, or Removed (corresponding to a Completed category state) don't appear on portfolio and product backlogs.
  3. You can add custom workflow states and assign them to one of three state categories. The state categories determine which work items appear on backlog and board views.
  4. Kanban boards, sprint backlogs, and task boards only show the last node in a hierarchy, called the leaf node. For example, if you link items within a hierarchy that is four levels deep, only the items at the fourth level appear on the Kanban board, sprint backlog, and task board. To learn more, see parent-child links between items.
  5. Work items whose State equals Removed don't appear on boards.

Fix "Ordering backlog items is disabled"

When a sprint backlog contains same-category, nested work items—as described in the next section, How backlogs and boards display hierarchical (nested) items—the system disables the drag-and-drop reorder feature. It does this as it determines that not all items display under these circumstances.

To fix this, take the following actions:

  1. Click the Create query link on the backlog page.

    Create query of backlog

  2. Open the query (click the link that appears).

  3. Review the list of items to determine which items are nested. For example, the following query shows that a bug is a child of a user story. Because the team has configured their backlog to display user stories and bugs at the same level (Requirements category), this corresponds to a nested item that disables the ordering feature.

    Query of backlog with a nested item

  4. Remove all parent-child links that exist among nested items.

  5. Return to the backlog page and refresh the page.

How backlogs and boards display hierarchical (nested) items

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 task board 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 task board.

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. Use the Feature work item type when you want to group user stories (Agile), product backlog items (Scrum), or requirements (CMMI). You can quickly map product backlog items to features, which creates parent-child links in the background.

Create work items using different hiearchy

When you track bugs as requirements

As mentioned previously, each team can choose how they want to track bugs to behave like requirements, or tasks, or as neither.

When you make a bug or requirement a child of another bug or requirement, all items appear on the product backlog page, but only the child bug or requirement appears on the Kanban board. For example, the third user story, Interim save on long form, has a child bug, Save takes too long.

The child bug, Save takes too long, appears on the Kanban board, but not the parent user story.

All bugs and requirements appear on the backlog

Child bug appears on backlog

Only leaf nodes appear on the Kanban board

Kanban board, leaf node bug appears

When you track bugs as tasks

When you choose to have bugs appear in the backlog with tasks, linking tasks and bugs to their parent requirements groups them accordingly on the sprint backlog and task board.

However, if you create parent-child links between a requirement and a bug, and the bug and a task, as shown here, the task will appear on the sprint backlog and task board, but not the bug.

Hierarchy of items assigned to the sprint backlog

Sprint backlog query shows linked bug and task

Only leaf nodes appear on the sprint backlog

Sprint backlog, leaf node task

Only leaf nodes appear on the task board
Sprint board, leaf node task appears

Is there a workaround to display intermediate nodes within a hierarchy? Not at this time. You can always check the entire list of items assigned to a sprint by using the Create Query link.

Now that you understand how backlogs, boards, and plans work, get started using them to plan and track your work.

A few things to keep in mind...

Additional topics of interest:

Additional tools from the Marketplace

You may find additional tools to help plan and track your work from the Visual Studio Marketplace.

Switch team project or team focus

Several features depend on the team project or team that you have selected. For example, dashboards, backlogs, and board views will change depending on the context selected.

For example, when you add a work item, the system references the default area and iteration paths defined for the team context. Work items you add from the team dashboard (new work item widget) and queries page are assigned the team default iteration. Work items you add from a team backlog or board, are assigned the team default backlog iteration. To change team defaults, see Set team defaults.

Also, several hubs enable you to set team favorites. The favorites you set and see are dependent on the team context you've chosen.

You navigate to your team context from the top navigation bar. The method changes slightly depending on the platform/version you work from.

NOTE

Feature availability: The Account Landing Page feature is in preview mode for Team Services and enabled for all users from web portal for TFS 2017.1 and later versions. To learn more about this feature, see Work effectively from your account hub. To enable or disable the feature, see Enable preview features.

You can switch your team focus to a team project or team you've recently viewed from the team project/team drop-down menu. If you don't see the team or team project you want, click Browse… to browse all team projects and teams. Your selection will open the Dashboard hub for the team project/team.

To access your account hub, click the Team Services icon Team Services icon. If you haven't yet enabled the Account Landing Page, you'll be taken to the account home page.

To go directly to the project vision and status page, choose the project home icon from the drop-down menu, for example, project home icon.

Choose another team from the team project menu

To switch your team focus to a team project or team you've recently viewed, hover over the Team Services icon Team Services icon and choose from the drop-down menu of options. If you don't see the team or team project you want, choose Browse… to browse all team projects and teams. Your selection will open the project vision and status page for the team project.

To access your account hub, click the Team Services icon Team Services icon. If you haven't yet enabled the Account Landing Page, you'll be taken to the account home page.

Choose another team from the team project menu

Open the team project/team drop-down menu and select the team project/team that you've recently visited. If you don't see the team or team project you want, choose Browse all to browse all team projects and teams.

Choose another team from the team project menu

Open the team project/team drop-down menu and select the team project/team that you've recently visited. If you don't see the team or team project you want, choose Browse all to browse all team projects and teams.

Choose another team from the team project menu

Column options

From each backlog page, you can add or remove columns. Or, you can drag a column to a new position. Start by opening the Column Options. Unlike a query result, you can't sort a backlog by column. However, you can use the Create Query option on each backlog to create a query that you can sort on any field column you choose.

Each user can set their own column options which persist for each product or portfolio backlog across user sessions.

Open column options

Task board items versus query list items

You may notice and wonder why the items shown on the task board may differ from those listed in a query created from its corresponding sprint backlog.

It's possible to assign tasks to an iteration but not have them linked to a parent backlog item. These items will show up in the created query, but might not show up on the task board itself. The system runs the query and then applies a few background processes before displaying the task board items.

NOTE

Appearance of task and child items on the task board may differ depending on whether you work in Team Services or TFS.

These reasons can cause work items that belong to the Task Category to not appear on a sprint backlog or task board:

  • The task hasn't been linked to a parent backlog item. Only those bugs and tasks that you have linked to a parent product backlog item (Scrum), user story (Agile), or requirement (CMMI) whose iteration path is set to the sprint will appear on the sprint backlog page.

    NOTE

    In Team Services and TFS 2015.2 and later versions, tasks not linked to a parent appear under an Unparented section.

  • The task is a parent of another task, or the user story is a parent of another user story. If you've created a hierarchy of tasks or user stories, only the child-level tasks or the child-level stories at the bottom of the hierarchy appear.

  • The task's linked parent corresponds to a backlog item defined for another team. Or, the area path of the task's parent backlog item differs from the task's area path.

    NOTE

    In Team Services and TFS 2015.2 and later versions, tasks linked to a parent work item assigned to another team's area path will appear under the Unparented section.

In Progress items filter

The In progress items Show/Hide filter causes some backlog items to display or not display. Bugs and other backlog items aren't listed when In progress items=Hide and their assigned State corresponds to In Progress metastate. Bugs in a New state will display, however, bugs in an Assigned state won't.

Set In progress items=Show to see all active bugs and other items on your backlog. See also Create your backlog and Backlogs and board views.