Create your backlog

Last Update: 7/14/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.

Work items are denoted with icons for Team Services and TFS 2017.2 and later versions. 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 be 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.

To define or manage the product backlog, you should be a member of the team and belong to the Contributors group. If you don't have access to the team project, get invited to the team.

Open your backlog from the web portal

You access your product backlog from the Work hub, Backlogs page.

Web portal, choose Work hub, Backlogs

The URL follows this pattern:

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

If you don't see the team or team project you want, click the Team Services icon Team Services icon to browse all team projects and teams.

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.

Open the backlog

The URL follows this pattern:

http://{server}:8080/tfs/DefaultCollection/{project name}/_backlogs

If you don't see the team or team project you want, 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

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.

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.


Your backlog shows work that you are planning to do or have started working on. As soon as the State of a work item is set to Done or Completed, the work item no longer shows up on your backlog. You can use the backlog controls to filter or change your view.

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.


To plan a sprint, at a minimum you should estimate the effort involved to implement each backlog item. You capture effort in the following fields within the work item form: Effort (Scrum), Story Points (Agile), or Size (CMMI) fields.

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: From the web portal for Team Services and TFS 2017, you'll have access to the new form with the new work tracking experience. For TFS 2015 and earlier versions, the old form is supported.

For details on adding work items using the new form, see add work items.

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

For details on adding work items using the old form, see add work items (TFS).

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

Provide a relative estimate of the amount of work required to complete a PBI. For user stories and requirements, you capture estimates in the Story Points and Size fields.

Most Agile methods recommend setting estimates for backlog items based on relative size of work. Such methods include 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.

Use any numeric unit of measurement your team prefers. Some options are story points, time, or other relative numeric value. The estimates you set for Effort, Size, or Story Points are used in calculating team velocity and in forecasting sprints.

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

Group backlog items under parent features

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 group backlog items within a hierarchy, you can use the mapping feature to map PBIs/user stories/requirements to features. 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 and sprint planning.

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.

With Sprint planning, 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

Once you've defined your backlog, you can use the following controls to change or filter the view.


If you set the In progress control to Hide, then items that are no longer in the New, Approved, or Proposed states won't appear in the backlog.

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

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

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.

Apply text filter

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 supported from Team Services and the web portal for TFS 2015.1 and later versions.

Use multi-select to bulk modify items


Feature availability: Multi-select of work items on the backlog and sprint backlogs is currently supported from Team Services and TFS 2015.1 and later versions. This feature works in the same way as multi-select works within query results.

With multi-select, you can perform several actions on several work items at once, such as:

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.

To learn more, see Bulk modify work items.

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.

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. To track that it is a spike, you can either preface the title with the word "[Spike]" or add the tag "Spike" to the work item.

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 (Scrum) or issue (Agile or CMMI).

From the Work hub, choose Impediment from the New Work Item list of options. Click the pin icon pin icon to have it show up within the Work hub drop down menu.

Team Services, TFS 2017 - Add an impediment

Or, from the Queries page, you can add a new work item.

Create a new impediment

From the Queries page, choose Impediment from the New drop down menu.

TFS 2015, TFS 2013 - Add an impediment

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.

Impediments and issues don't appear on your backlog. Instead, you track them using queries. If you want them to appear on your backlog, or you want to track other work item types on your backlog, see Customize your work tracking experience.

Feedback and support

We welcome your feedback.

Send suggestions on UserVoice, and follow us on Twitter @vsts.

See also our comprehensive feedback and support page.