Preparing and planning a sprint

The product backlog shows the list of work that has been planned by the team, and the items at the top are usually more valuable. A product team constantly reviews the backlog and pre-prioritizes the backlog based on user feedback and changing business priorities. Agile planning tools in TFS support defining and managing work within sprints.

This process is started off by defining a time box, referred to as a sprint, that corresponds to the cadence your team delivers. Many teams choose a two or three-week cadence. However, you can specify a shorter or longer sprint cycle. TFS also allows you to wrap multiple sprints into a release schedule. The sprint backlog represents a subset of the backlog; the team builds the sprint backlog during the sprint planning meeting. 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 competing in the sprint. 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 that are required to complete each item. Finally, your team commits to implementing some or all of the items based on these estimates.

Getting ready

Let's start off by prioritizing the product backlog. To do this, navigate to the Backlog view for the PartsUnlimited example team. 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. Alternatively, if you prefer the keyboard route, hold the Alt key and use the up and down arrows:

A prioritized backlog without an estimate of how big the work is only half as good. It is suggested that software development teams review and resize the backlog multiple times in a sprint, as this keeps the backlog in a ready state for future sprint planning sessions. While there are many sizing techniques, Fibonacci numbers are a good way to size the work into logical buckets. Once the work items have an estimate, you can use the Forecast tool to get an idea of how many items you can complete within a sprint. By plugging in velocity, you can see which items are within scope for the set of sprints the team has activated. Teams use the forecast tool to help their sprint planning efforts. By plugging in a value for the team velocity, the Forecast tool will show which items in the backlog can be completed within future sprints. Both tools are team-specific tools that rely on the team's ability to estimate backlog items:

With a sized and prioritized backlog in place, there is just one more thing left to do before you start to plan the sprint. To quickly get started, you can use the default sprints, also referred to as iterations, that were added when your team project was created. Note that you must be a member of the Project Administrators group in order to add sprints and schedule sprint dates. Choose Iteration under the Backlog tab and then click the dates to edit them. With the dates configured, you are now ready for sprint planning:

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:

 

How it works...

With the team capacity set up, the product backlog decomposed, and the tasks estimated, the sprint plan is ready. The team members can now allocate work to themselves by dragging the tasks to their names:

After you've defined all the tasks for all the items, check whether your team is at or over capacity. If your team is under capacity, you can consider adding more items to the sprint. If your team is 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 determine this. Once you have done this, the sprint backlog provides a view that should allow you to start delivering your sprint with confidence:

There's more...

The TFS marketplace features the Sprint Goal extension (https://marketplace.visualstudio.com/items?itemName=keesschollaart.sprint-goal), a free extension that was created by Kees Schollaart allows you to record the sprint goal in sprint planning tools. Once you've installed the extension, you'll see a new tab called Sprint goal in the sprint planning tools. This is a great way to make the sprint goal visible to the entire team. 

Sometimes, people with unique skills are shared across multiple teams, which makes it hard to track their available capacity. The TFS marketplace features the team capacity management extension (https://marketplace.visualstudio.com/items?itemName=tfc.team-capacity), which was created by TFS consulting and provides an overview of the assigned capacity of individual team members across multiple teams within a team project. This gives you a bird's-eye view of capacity across all the teams in the team project. It provides a single pane of glass so that you can see where the team members are active and how much of their time has been allocated: