Create your backlog

Visual Studio Team Services | Visual Studio 2015 | Previous versions

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.

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.

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.

Note: Depending on the process template you chose when creating your team project--Scrum, Agile, 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

Open the backlog

The URL follows this pattern:

  • Visual Studio Team Services: https://{account}.visualstudio.com/DefaultCollection/{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

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 connect to a Visual Studio Team Services account, then you can switch to the new work item tracking experience. You can add a custom field, change the form layout, and access new form features when you make the switch.

Add details to a work item

FieldUsage
EffortProvide a relative estimate of the amount of work required to complete a PBI. Use any unit of measurement your team prefers. Some options are t-shirt size, story points, 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 ValueSpecify 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 CriteriaDefine 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 when you connect to Team Services or an on-premises application server that has been upgraded to TFS 2015 Update 1. 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 menu of one of the items.

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

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

The menu options change based on whether you have selected a single work item or several.

Single-select menu optionsMulti-select menu options
Backlog single-select menuBacklog multi-select menu
Feature availability: The Delete and New branch (Git repository required) options are currently only available from VS Team Services.

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

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

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.

Related notes

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

For more info on the work item form sections and controls, see Add work items and Drive Git development for a work item (VS Team Services only).

To copy, clone, tag, or delete work items, quickly create work items using a template, or look up the definition of a work item field, see these topics:

Backlog controls

ControlFunction
BacklogSwitch to backlog view
BoardSwitch to Kanban board view
ForecastTurn forecasting Off/On
MappingTurn mapping Off/On
ParentsShow/Hide parents
In progress itemsShow/Hide in progress items
Settings iconConfigure team settings: Backlogs, Working days, Working with bugs
full screen icon / exit full screen iconEnter or exit full screen mode
expand icon / collapse iconExpand or collapse one level of the tree hierarchy
mail iconEmail a copy of your backlog
FilterTurn 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.

Filter your backlog or board

If you have many items on your backlog or Kanban board and want to focus on a subset of them, you can filter the set.

Filter based on keywords

You can filter both product and portfolio backlogs and the Kanban board using keywords. 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 backlog items, you can filter your backlog list using the tag filter icon tag filter. You can use tags to filter backlogs and queries.

To filter the Kanban board using tags, make sure that you first customize cards to Show tags. make sure that you first customize cards to Show tags.

Assign 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 when you connect to VS Team Services or to an on-premises application server that's been upgraded to TFS 2015 Update 1.

Role of the product owner

Product owners play an important role in Scrum, primarily as the interface between customers and the team. Their primary responsibilities include:

  • 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

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.

You can read more about estimates here.

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

You can read more about acceptance criteria here.

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.

You can read more about spikes here.

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