Sprint planning

Last Update: 7/12/2017

Team Services | TFS 2017 | TFS 2015 | TFS 2013

Your team builds the sprint backlog during the sprint planning meeting, typically held on the first day of the sprint. Each sprint corresponds to a time-boxed interval which supports your team's ability to work using Agile processes and tools. During the planning meeting, your product owner works with your team to identify those stories or backlog items to complete in the sprint.

Planning meetings typically consist of two parts. In the first part, the team and product owner identify the backlog items that the team feels it can commit to completing in the sprint, based on experience with previous sprints. These items get added to the sprint backlog. In the second part, your team determines how it will develop and test each item. They then define and estimate the tasks required to complete each item. Finally, your team commits to implementing some or all of the items based on these estimates.


Your sprint backlogs are 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.

For a beginner's guide to planning and tracking work, see Get started with Agile tools.

Here's an example of a sprint plan that consists of backlog items and the tasks required to complete each item. By setting team capacity and estimating tasks, the team can see when the team or a team member is at, under, or over capacity.

Sprint planning


Sprint planning doesn't need to be challenging. It can be fun and a time for the entire Scrum team to build camaraderie by working together to answer the question of "What can we commit to?" For examples and strategies to keep your sprint planning focused and effective, check out the Sprint Planning white paper.

When you've completed your sprint plant, your sprint backlog should contain all the information your team needs to successfully complete work within the time allotted without having to rush at the end.

First pass: identify an initial set of work to complete


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.

To plan sprints, 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.

  1. Before you start planning your sprint, you'll want to have created, prioritized, and estimated your backlog.

  2. Also, you'll want to have set the start and end dates for your sprint.

  3. Begin your planning efforts by moving items from your backlog to your current sprint, one item at a time. Simply drag each item from the product backlog onto the sprint.

    Product backlog page, drag work items to sprint or assign to sprint through the context menu

    If you don't see any links listed under Current or Future, your team admin needs to select your team's sprints.

    That's your initial guess at what you'll be able to do in the sprint. Next, you'll define tasks, estimate that work, and use your team's capacity to make sure it fits in the sprint.

  4. Next, check the total level of effort of your sprint items. For example, the Fabrikam Fiber team has four members with a total velocity of 40 effort points per three week sprint cycle. So, they're in good shape to commit to the 6 items in the Sprint 1 backlog.

    Sprint backlog page, determine total level of effort

    If you don't see the Effort, Story Points, or Size fields, you can add them by clicking Column Options. For a description of how these fields are used, see Create your backlog, Add details and estimates.

    Your initial plan should identify the subset of requirements that's within your team's capacity based on estimated effort and team velocity. Velocity corresponds to the total Effort or Story Points a team can complete within the sprint time period.

Set your team's capacity

As a next step, you'll want to determine your team's actual capacity. Whereas velocity correlates to how your team estimates requirements, capacity correlates to actual task time - either hours or days. Capacity takes into account variation in work hours by team members as well as holidays, vacation days, and non-working days.

Because days off and time available for each team member can vary from sprint to sprint, you set capacity for each sprint. The capacity tool helps you make sure your team isn't over or under committed for the sprint. Also, as you work day-to-day, you'll be able to see if your team is on track.

From the Capacity page, enter the capacity and days off for each member of your team. For details on setting capacity, see Capacity planning.

Most teams specify capacity in terms of hours, however, you can also specify it in days. For example, .5 days would correspond to 4 hours for a typical 8 hour day. Choose the same unit you will use to estimate the time a task will take to complete. You only have to indicate planned days off. You manage weekend days or other recurring days off under team settings.


The user interface is slightly different depending on the platform and version you work from.

For example, Christie Church's capacity is 6 hours/day for design work.

Additional options available from the Capacity page include copying capacity from the previous iteration, adding team members, adding multiple activities. See Capacity planning for these and more settings.

Team Services, Set Capacity

If you don't see a team member listed, either add them to the team then press the button to add all missing team members to this sprint's capacity planning, or add the user individually.

Capacity page

Additional options available from the Capacity page include copying capacity from the previous iteration, adding team members, adding multiple activities. See Capacity planning for these and more settings.

TFS 2015.1, Set Capacity

Define tasks to complete each item

The capacity tool tells you how much work your team can commit to. However, to compare capacity with actually planned work, you need to define and estimate tasks for each backlog item.

Add as many tasks as needed to capture the work required to complete each item. Tasks can represent different work to be performed - such as design, code, test, content, signoff. Usually, each team member adds their own tasks and sets estimates for the work. However, a development lead could define the initial tasks for a requirement.

  1. In the sprint backlog, add a task.

    Sprint backlog page, add task

    Creating tasks from the sprint backlog automatically links the task to its parent backlog item.

  2. Name the task and enter an estimate for Remaining Work. Also, if you know who'll perform the work, go ahead and assign the task to that team member.


    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 ealier versions, the old form is supported.

    New task form
    Web portal, Task form, oldform

    At the planning stage, Remaining Work corresponds to an estimate of how long it will take to complete the task.

    A good rule of thumb is to size tasks to take no more than a day to complete. If a task is too large, the team should break it down. In some cases, you may not be able to estimate some tasks effectively until other tasks have been completed. Create the task now, but estimate it when you have enough information.

    During the sprint, team members update remaining work to continually reflect the time required to complete the task. This value can actually increase after work begins. For example, after working 4 hours on a task that was estimated to take 8 hours, the team member realizes he needs 16 hours over what he estimated. He would update the Remaining Work field with 20 (8-4+16). As you perform a task, you might find that more time is required. Always update the task with your best estimate of remaining work. That way, you help accurately reflect the total amount of work remaining in the sprint.

  3. As you define tasks and estimate the work, you'll see capacity charts start to fill in for each team member. Capacity bars track the remaining work against the capacity for each team member as well as the entire team.

    You'll also see a roll-up of the remaining work required to complete each requirement or bug.

    Capacity charts

    From this view, you can easily see which individuals are at or near capacity. Teams can determine if work needs to be moved out of the sprint or to reassign tasks.


    Define tasks that take a day or less to complete. This helps mitigate the risks that come from poor estimates.

    Also, don't divide tasks into subtasks as the task board will only show leaf node tasks. If you do divide a task into subtasks, specify Remaining Work only for the subtasks, as the system rolls up summary values to the parent task.

Second pass: adjust work to fit team capacity

After you've defined all the tasks for all the items, check whether your team is at or over capacity. If under capacity, you can consider adding more items onto the sprint. If over capacity, you'll want to remove items out of the backlog.

Next, check whether any team member is under, at, or over capacity. Or, if someone hasn't even been assigned any work. Use the capacity bars to make these determinations.

Over capacity

Team over capacity: move items out of the sprint

If your team's over capacity, drag items from the bottom of the list onto Backlog items. This will reset the Iteration Path to the default set for your team. Or, you can move the item into the next sprint your team will work in. All the tasks that you've defined for that item will move with it.

Drag items back to product backlog


Dragging a backlog item to the backlog or another sprint reassigns all child tasks to the same iteration path. Also, you can multi-select several items and drag them to the backlog or another sprint.

Load balance work across the team

To quickly reassign tasks, drag the task onto the new assignee's capacity bar. As you reassign tasks, capacity bars automatically update.

Reassign tasks

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.

Try this next

Now that you've defined your sprint plan, your team's ready to begin work on the sprint tasks. Use your task board during your daily scrum meetings to perform these tasks:

  • Update task status and remaining work (daily updates of remaining work leads to smoother burndown charts)
  • Review progress with the team during the daily Scrum meetings
  • Update items and address uncompleted work at the close of the sprint

Also, you can monitor your burndown chart to make sure your team remains on track throughout the sprint.

You can use hotkeys and keyboard shortcuts to navigate within the backlog list.

If you need to add or rename the sprints your team uses, you must first define them at the project level and then select them for your team. See [Define and

To copy, clone, or delete work items, or to quickly create work items using a template, see these topics:

Share your sprint plan

Any stakeholder on your team (someone with permissions to connect to your team project) can view your sprint plan. Simply send them the URL of your sprint backlog page. But also, you can share it with them through email or print a version.

To email it, create and save the query for the sprint backlog.

Share plan

Then, open the query and click the email icon.

Email query

In the form that appears, enter the name(s) of valid users (ones who have access to the team project).

Or, you can select all the items in the list, choose Copy as HTML, and paste the formatted list into an email form or Word document. See Share plans for more ways to share work with your team.

Order, re-parent, and reassign items to different sprints

When you need to change the order of an item, simply drag the item to its new location. Also, you can re-parent an item using the mapping pane, or simply drag it within the hierarchy to change its parent.

Hierarchical view of backlogs

Ordering and re-parenting backlog items requires that you don't nest items of the same type within each other. That is, you don't create product backlog items that are children of other product backlog items, or tasks that are children of tasks. You can only re-parent tasks under backlog items, backlog items under features, and features under epics.

If you receive the following message, you can fix it by removing nested child items.

Can't reorder with nested backlog items message

Refine your backlog

Backlog refinement supports your sprint planning efforts and helps minimize these often seen challenges:

  • Long, unfocused, and ineffective sprint planning meetings
  • Insufficient thought given to design requirements
  • Poor sprint planning and execution
  • Defocus on the business value team wants to achieve
  • Inability to forecast

A meeting to refine the backlog should occur separate from the sprint planning meeting. Use this meeting to perform these activities:

  • Right-size backlog items by splitting larger items into smaller items. No backlog item should be larger than it will take to complete in a single sprint.

  • Identify and fill in gaps in the product backlog. Capture new ideas and stories, architecture and design requirements, and other spikes.

  • Reorder the backlog to represent today's priorities and business value focus.

  • Ensure well defined acceptance criteria has been added to each item.

  • Revisit estimates made to backlog items and adjust upwards or downwards based on recent understanding about scope and acceptance criteria.

  • Review all potential backlog items to consider for the upcoming sprint to make sure they are well understood and that any additional work required to support their development is well understood by both product owner and the team.

You'll know that you've done a good job refining your backlog when your sprint planning meetings run smoothly and efficiently. Such meetings shouldn't contain a lot of surprises, and your team should feel they can contribute fullly.

Refining your Agile backlogs for success provides a nice quality checklist to guide your backlog refinement efforts

Sprint planning meetings

Much of sprint planning involves a negotiation between the product owner and the team to determine the focus and work to tackle in the upcoming sprint. It's useful to time-box the planning meeting, restricting it to 4 hours or less.

In the first part of the meeting, your product owner meets with your team to discuss the user stories that might be included in the sprint. Your product owner will share information and answer any questions that your team has about those stories. This conversation might reveal details such as data sources, user interface layout, response time expectations, and considerations for security and usability. Your team should capture these details within the backlog items form. During this part of the meeting, your team learns what it must build.

As you plan your sprints, you may discover additional requirements that you should capture and add to your backlog. Before your sprint planning meeting, you'll want to refine your backlog to make sure that it is well defined and in priority order.

Also, setting a sprint goal as part of your planning efforts can help the team stay focused on what's most important for each sprint.

After you've planned your sprint, you may want to share the plan with key stakeholders.

You can learn more about conducting your sprint planning meeting from these resources:

Set sprint goals

Scrum teams use sprint goals to focus their sprint activities. They often set this goal during their sprint planning meeting. The goal summarizes what the team wants to accomplish by the end of the sprint. By explicitly stating the goal, you create shared understanding within the team of the core objective. The sprint goal can also help guide the team when conflicts arise around priorities.

Tips from the trenches: Define sprint goals

The sprint goal defines what the product owner and the team consider as the ultimate target to accomplish that sprint. It's not a random selection of backlog items that don't really have a relationship, but a short piece of text that captures what the team should try to accomplish. Normally the product owner comes up with the sprint goal before selecting a number of items for the next sprint. The items for that sprint should all fit that common goal.

Sprint goals can be feature oriented, but might also have a large process component such as deployment automation or test automation. For example:

  • This sprint we will focus on a very simple user story and we will use it to prove that the proposed solution will work.
  • This sprint will revolve around implementing the security features that will properly secure the administration section of the website.
  • This sprint will be about integrating the most important payment gateways so that we can start collecting money.

Setting the sprint goals helps the team to stay focused. It will make it easier to define priority of tasks within a sprint and it will probably help limit the number of stakeholders and end-users that are involved.

During the sprint review the most important question you should ask yourself is whether you managed to achieve the sprint goal. How many stories you actually completed comes second. If the goal is accomplished, the sprint succeeds, even if not all stories were finished.

Contributed by Jesse Houwing, Visual Studio ALM Ranger and a senior consultant working for Avanade Netherlands.