How to do it...

Sprint planning is a real team effort and a great way to get everybody aligned. The planning is kicked off by discussing the sprint goal. The Product Owner then shares the vision of the sprint goal with the team. The appropriate PBIs (which should be on top of the backlog by now) are selected to meet this sprint goal. Follow these steps to get started:

1. Begin your planning efforts by moving prioritized items from your backlog to your current sprint, one item at a time.
2. Simply drag each item from the product backlog into the sprint, as shown in the following screenshot:

The Product Owner then starts reading the stories out and going through the acceptance criteria. This is a great opportunity to briefly discuss and clarify any requirements or acceptance criteria. Team velocity is a good measure of how many story points of backlog items the team takes into the sprint. The TFS marketplace features the quick calc extension (https://marketplace.visualstudio.com/items?itemName=duffy.vsts-quick-calcs), a free extension that was developed by Mike Duffy and allows you to quickly see total effort, % complete, and other metrics for a selection of work items. This is especially useful during a sprint planning meeting when you want quick answers on the total count of story points for the selected work items. This extension is shown in the following screenshot:

Next, the team needs to know the total available capacity within the sprint. The availability of each individual and their role can be tracked using the capacity tools in TFS. Whereas velocity correlates your team estimate requirements, capacity correlates to actual task time. Capacity takes into account variations in work hours of team members, as well as holidays, vacation days, and non-working days. Most teams specify the capacity in terms of hours, but you can also specify it in days if you so wish:

Now, you have a clear view of how much work your team can commit to. In the next part of the sprint planning meeting, the team creates a plan of work by breaking the requirements into tasks and then estimating them. Tasks capture the plan of action and add as many tasks as needed to capture the work required to complete each item. Tasks can represent different work that needs to be done, such as design, code, test, content, and sign off. TFS makes the process of adding tasks friction free, giving you the ability to access and add task functionality from multiple entry points without any overhead. Tasks can be added right from the sprint backlog, the sprint board, and the product backlog board:

You can capture as much detail as you need in the task, including the effort estimate to complete the work. The effort estimate is netted against the actual capacity to provide a view of whether the work has been overscheduled: