Create your backlog

Last Update: 4/7/2017

Team Services | TFS 2017 | TFS 2015 | TFS 2013

Your product backlog corresponds to your project plan, the roadmap for what your team plans to deliver. Once defined, you have a prioritized list of features and requirements to build. Your backlog also provides a repository of all the information you need to track and share with your team.

A great backlog conveys customer needs and value. Over the course of the project, your team will add detailed information to each backlog item, break them down into smaller items, prioritize and estimate them, and finally, implement them and deliver the results to your customers.


Your product backlog is one of three classes of backlogs available to you. For an overview of the features supported on each backlog and the two types of boards, see Backlogs, boards, and plans.

Here's a view of a backlog based on the Scrum process template. This particular backlog includes both product backlog items (PBIs)--shown here with blue bars--and bugs--shown with red bars. These are just two of several work item types that you have available to plan and track your project. Because each work item type has its own color assignment, you can quickly differentiate the types of work in the list.


The images you see from your web portal may differ from the images you see in this topic. These differences result from updates made to Team Services or your on-premises TFS, options that you or your admin have enabled, and which process was chosen when creating your team project—Agile, Scrum, or CMMI. However, the basic functionality available to you remains the same unless explicitly mentioned. For an overview of changes in the navigation experience and working within the user and administration contexts, see Work in the web portal.

Product backlog

Your backlog consists of a list of work items. You use work items to share information, assign work to team members, track dependencies, organize work, and more. Because the most important work appears at the top of the list, your team always knows what to work on next.


Depending on the process you chose when creating your team project—Agile, Scrum, or CMMI— the items in your backlog may be called product backlog items (PBIs), user stories, or requirements. All three are similar: they describe the customer value to delivered and the work to be performed.

By default, PBIs and bugs appear on Scrum backlogs, user stories on Agile backlogs, and requirements on CMMI backlogs. Each team can choose how they want to treat bugs: either as requirements or tasks.

Convert ideas into backlog items or stories

Building your backlog starts by quickly capturing the requirements you want for your product.

Open your backlog from the web portal

You access your team's backlog from the Work hub, Backlog page. you can open it from the Overview page as shown.

Open the backlog

The URL follows this pattern:

  • Visual Studio Team Services: https://{account}{project}/_backlogs
  • Team Foundation Server (on-premises): http://{server}:8080/tfs/{collection}/{project}/_backlogs

If you don't have a team project yet, create one in Visual Studio Team Services or set one up in an on-premises TFS. If you don't have access to the team project, get invited to the team.

Build your backlog

Begin building your backlog by entering a title and click Add. Repeat this step until you've captured all your main ideas.

Add work items to the backlog

If you've already defined a long list of items, you don't have to reenter them one at a time. Instead, use Microsoft Excel to quickly import them to your backlog.

Move items into priority order

After you've got some items on your backlog, you can order them and create a prioritized list of work. Frequently reviewing and prioritizing your backlog can help your team know what's most important to deliver next.

Reorder your backlog by simply dragging work items. Or, if you prefer the keyboard, hold the Alt key and use the up and down arrows.

Reorder work items


You can't sort your backlog on a column. If you want to view a sorted listed, click Create query, save and open the query, and then sort the query results. To learn more about queries, see Use the query editor to list and manage queries.

Add details and estimates

Getting your backlog built and prioritized provides the high level roadmap. However, before your team can actually start work on any item, they'll need more details. You capture these details within the work item form.

Open each item (double-click, or press Enter to open the selected item) and add all the info you want to track. Enter as much detail as the team needs to understand the scope, estimate the work required, develop tests, and ensure that the end product meets acceptance criteria.


Feature availability: If you use Team Services or the web portal for TFS 2017, you'll have access to new form features. Also, with Team Services, you can add a custom field, change the form layout, and more.

Product backlog work item form (Team Services)

For details on adding work items in Team Services, see add work items.

Product backlog item - Team Services - Add details to a work item

Product backlog work item form (TFS)

For details on adding work items in TFS, see add work items (TFS).

Product backlog item - TFS - Add details to a work item

Field Usage
Effort Provide a relative estimate of the amount of work required to complete a PBI. Use any numeric unit of measurement your team prefers. Some options are story points, time, or other relative unit.
For user stories and requirements, you capture estimates in the Story Points and Size fields. These fields support usage of the velocity and forecast tools.
Business Value Specify a priority that captures the relative value of a PBI compared to other PBIs. The higher the number, the greater the business value.
Use this field when you want to capture a priority separate from the changeable backlog stack ranking.
Description (PBIs) Provide enough detail to create shared understanding of scope and to support estimation efforts. Focus on the user, what they want to accomplish, and why. Don't describe how to develop the product. Do provide sufficient details so that your team can write tasks and test cases to implement the item.
Acceptance Criteria Define what "Done" means by describing the criteria that the team should use to verify whether the PBI or the bug fix has been fully implemented.
Before work begins on a PBI or bug, describe the criteria for customer acceptance as clearly as possible. Conversations between the team and customers to determine the acceptance criteria help ensure a common understanding within the team to meet customers' expectations. Also, this info provides the basis for acceptance testing.

Use multi-select to bulk modify items and other options


Feature availability: Multi-select of work items on the backlog and sprint backlogs is currently supported from Team Services or the web portal for TFS 2015 Update 1 or later version. This feature works in the same way as multi-select works within query results.

With multi-select, you can change the backlog priority of several items, or assign them to a team member, move them to a different sprint, or map them to a feature.

To select several items in a sequence, hold down the shift key. To select several non-sequential items, use the Ctrl key. Then, you can either drag the selected items to a new position within the backlog, to a different sprint, or select an option from the context (context icon) or action (actions icon) menu of one of the items.

Here, we use the context menu to move several non-sequential items to the current sprint.


Feature availability: The menu options change based on the platform you're working from and whether you have selected a single work item or several. To learn more, see Bulk modify work items. Several options, such as Change type and Move to team project, are currently only available from Team Services.

Backlog multi-select several non-sequential items and open context menu

Use list hotkeys and keyboard shortcuts to quickly navigate within the backlog. Enter ? to open the Global keyboards pane.

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.

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


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

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

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

Organize your backlog

In addition to adding items to your backlog, you may want to group items in your backlog, break backlog items into smaller items, or capture and manage spikes in your backlog. Breaking backlog items into smaller items minimizes the size variability of estimates. When estimates around effort or story points vary widely, it's harder to plan consistently and gain good metrics around team velocity.

To organize your backlog, you can map PBIs /User Stories/Requirements to Features and Features to Epics. This also groups backlog items within a hierarchy. Another way to group items and filter your backlog is by tagging items.

  • Use Features to track a related set of backlog items/stories that together comprise a major feature to be delivered.
  • Use Epics to track a related set of Features that together deliver a major scenario.

Defining Features or Epics is entirely optional. You define them when they support your ability to group and track work.

Lastly, if you work with several teams, and each team wants their own backlog view, you can create additional teams. Each team gets access to a set of Agile tools focused on their work based on their team's default area path.

Try this next

Now that you've got a working backlog in place, your team can begin work on the top priority items. From here, it's time to make the decision on how you want to work as a team: Scrum or Kanban? You can use these methods independently or together.

Teams that want the least overhead in terms of tracking and estimating may prefer Kanban. Teams that like to work at a steady cadence and plot the details of their sprint plan may prefer Scrum.

With Kanban, teams focus on the flow of work from start to finish - limiting work in progress in order to optimize flow and deliver the highest priority items as quickly as possible.

Using Scrum methods, teams define a sprint schedule: a time-boxed set of periods for planning and developing. Using the sprint backlog, they plan their sprints by assigning items to the sprint and defining the tasks required to develop each item. Task boards, capacity charts, and sprint burndown charts all help to keep the team aware of progress throughout the sprint cycle.

As you can see, your backlog is the best place to start to plan and manage your project. A few things to keep in mind…

To add fields or work item types, see Customize your work tracking experience.

To track your work and use other resources available to you, see these topics:

Backlog controls

Control Function
Backlog Switch to backlog view
Board Switch to Kanban board view
Forecast Turn forecasting Off/On
Mapping Turn mapping Off/On
Parents Show/Hide parents
In progress items Show/Hide in progress items
Settings icon Configure team settings
full screen icon / exit full screen icon Enter or exit full screen mode
expand icon / collapse icon Expand or collapse one level of the tree hierarchy
mail icon Email a copy of your backlog
Filter Turn tag filtering On/Off

Note that even if you have show parents turned on, the Create query and mail mail icon controls will only list items at the currently selected level.

See also Keyboard shortcuts.

Filter backlogs, boards, and queries

If you have many items listed in your product or portfolio backlog, Kanban board, or query results—and you want to focus on a subset of them—you can filter the set.

Filter based on keywords

You can use keywords to filter your backlogs, Kanban boards, and query results. The filter function picks up work items based on any visible/displayed column or field, including tags, based on the keyword that you enter. Also, you can enter a value for an ID, whether or not the ID field is visible.

Here, we filter the backlog to only show items that include 'Web' in any one of the displayed column fields.

Filter using search

The filtered set is always a flat list, even if you've selected to show parents.

The filter criteria ignores the following characters when the field value starts with the character: {, (, [, !, @, #, $, %, ^, &, *, ~, `, ', ".

Filter based on tags

If you've added tags to your work items, you can filter your backlogs, Kanban boards, and query results using the tag filter icon tag filter. For backlogs and query results, add Tags as a column option prior to filtering on tags.

To filter the Kanban board using tags, make sure that you first customize cards to Show tags. See also, Filter the Kanban board for additional options.

To learn more about filtering using Tags, see Add tags to work items to categorize and filter lists and boards, Filter lists using tags

Move work items to a sprint from any backlog or board

You can drag any work item from any backlog or board to a sprint. Even when working from the Kanban or task board, you can drag a work item onto a sprint to change it's iteration path.

Feature availability: This feature is currently supported from Team Services or the web portal for TFS 2015 Update 1 or later version.

Track progress with queries

To monitor progress of your project, you can open and modify shared queries. Available predefined queries differ based on the process used (Agile, Scrum, CMMI) to create your team project. See Use the query editor to list and manage queries to learn more about customizing and defining new queries.


  • Product Backlog
  • Product Planning


  • Product Backlog


  • Customer Requirements
  • Open Requirements
  • Product Requirements

Role of the product owner

Product owners play an important role in Scrum, primarily as the interface between customers and the team. To enable product owners to perform the following responsibilities, they need to be added to the Contributors group.

  • Analyzing customer requirements and articulate them as user stories, features, or requirements
  • Building, prioritizing, and refining the product backlog
  • Representing customer and stakeholder requirements to the team and responding to questions your team has about them
  • Meeting regularly with stakeholders to address their needs and keep them informed
  • Helping stakeholders understand the decisions underlying the priority order of your backlog
  • Responding to any and all requests from your team for more information concerning backlog priorities and requirements

If they will also be responsible for configuring team settings, add them as a team administrator.

A product owner can reduce the need for detailed specifications by being more responsive to the team's questions about implementation details and clearly articulating acceptance criteria within each requirement.

Estimation techniques

Most Agile methods recommend setting estimates for backlog items based on relative size of work. Such methods include t-shirt sizes (S, M, L, XL, and too big), powers of 2 (1, 2, 4, 8), and the Fibonacci sequence (1, 2, 3, 5, 8, etc.). You can use any method that works for your team.

The estimates you set for Effort, Size, or Story Points are used in calculating team velocity and in forecasting sprints.

Acceptance criteria

Acceptance criteria define what "Done" means by describing the conditions that the team should use to verify whether a requirement or bug fix has been fully implemented. You can capture these criteria in the work item. Clear acceptance criteria help with estimating and developing requirements and with testing.

Product owners are the ultimate deciders of the criteria that create customer value.

Tips from the trenches: Start to love and embrace acceptance criteria.

Ask 10 mature agile teams "How do you know when you're 'done done'?" and you'll get the same answer from each one. . . get serious about writing acceptance criteria.

Acceptance criteria are the handshake between the product owner and the team on what "done done" really means.
Until the acceptance criteria are met, the team isn't done with the story. Period. However, the value of acceptance criteria only starts here.

Acceptance criteria provide the stage for some of most meaningful conversations and interactions that can happen on an agile team. On my own team we routinely have some of our best interactions as we start digging into the acceptance criteria for each story on our backlog. Inevitably we all start with our own ideas about what "done" means for a given story.

However, as we begin to discuss the acceptance criteria presented by the product owner what ensues is a series of "ah-ha moments." A shared understanding of the story begins to emerge. A comment one team member might elicit the following response from someone else. . . "Ah-ha, great point. . . I never thought of that."

Regardless of who is being enlightened, the power is in the fact that the product owner and the team are building together a shared understanding of what "done" means for each backlog item. And, this is happening before the team has written a single line of code. . . before any work has been done. . .
before commitments have been made. . . and before the sprint has begun.

By collaborating on acceptance criteria the team is minimizing risk and greatly increasing the chance of delivering successfully. I don't think it's a coincidence that the first bullet in the Agile Manifesto states ". . . we have come to value individual and interactions over processes and tools". Agile teams work together. And by working together, they create better software.

Start learning to love acceptance criteria and see if your team isn't more successful delivering software.

--Aaron Bjork, Principal Product Manager, Visual Studio Cloud Services, first published in the blog post: Agile Tip #5 – Learn to Love Acceptance Criteria

Capture and manage spikes

In addition to new features and requirements to build, you can capture non-feature work that still needs to be done for a healthy ecosystem of delivery. This work can include necessary research, design, exploration, or prototyping. Any work done that doesn't directly lead to shippable software can be considered and captured as a spike.

As the need to perform this work arises, capture it along with other items on your backlog.

Treat bugs like requirements or tasks

You have a choice as to how you 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, and have them appear on their task board.

If you're using the Scrum process, your default setup is to track bugs along with PBIs. However, if you're working in a team project based on the Agile or CMMI processes, bugs don't automatically appear on your backlog.

Talk with your team to determine how they want to manage bugs and then change your team settings accordingly.

Manage issues or impediments

If you have known issues you want to track, you can do so by defining an impediment or issue.

Create a new impediment

Impediments don't appear on your backlog. Instead, you track them using queries.

Don't confuse impediments with bugs. You track impediments that may cause problems with delivering one or more requirements. For example, you may have to address feature ambiguity, personnel or resource issues, problems with environments, or other risks that impact scope, quality, or schedule. Other issues that deserve tracking are decisions that require several stakeholders or product teams to weigh in on. Impediments and issues represent unplanned activities. Resolving them requires more work beyond what's tracked for actual requirements. Using the impediment work item type helps you track and manage these issues until you can resolve and close them.

Feedback and support

We welcome your feedback.

Send suggestions on UserVoice, and follow us on Twitter @VSTeam. Or, tell us what you think with Send-a-Smile on the title bar ... Send-a-Smile.

Or, see our comprehensive feedback and support page.