While your product backlog maintains the full set of requirements to build your product, sprint backlogs show a filtered subset of these requirements. Scrum teams use sprint backlogs to target what they’ll build during the sprint.
Sprints can be of any length, but typically last from one to four weeks. Teams use sprints to plan and deliver shippable software at a regular cadence.
You’ll want to use your sprint backlog to make sure that your team has all the information they need to successfully plan and complete work within the time allotted without having to rush at the end.
At the beginning of each sprint, teams plan the work they can commit to. The planning process generally occurs in two parts. The first part considers what the team believes they can deliver based on estimates (Effort or Story Points) made to each requirement. The second part identifies more details about how each requirement will be built, breaking the requirement down into a set of tasks. Estimating each task equips team with the level of detail they need to compare the total amount of planned work against their team capacity.
Successful planning leads teams to neither overcommit nor under commit.
Teams new to Agile methods often gravitate to Scrum practices to reap the benefits of a regular sprint cadence and to improve their ability to estimate, forecast, and commit as a team.
To get started, first set the sprint dates to match your sprint cadence.
Define sprints, set your schedule
Does your team already work in sprints? Then all you need to do is define the dates that match the cadence you’ve been working to. If you’re new to working in sprints, you’ll need to pick a sprint cadence as well. You might start with a 3 or 4 week cadence.
Once you know your cadence, you’re ready to get your schedule defined.
From the Backlogs view, you can click on the first sprint that appears under Current. Or, open your sprint backlog from the following URL.
You already have several sprints predefined, they’re listed under Current and Future. Actual sprint titles vary based on the process template used to create your team project.
However, calendar dates haven’t been assigned.
To set the calendar dates, choose the first sprint under Current and set its dates. You can even rename the sprint.
You can do the same for the remaining sprints listed. Also, it’s important to understand that each team controls their sprint schedule. You can even set up a release cadence which includes several sprints.
Pull items off the backlog onto your sprint
Now, with your sprint dates set, choose the subset of requirements you want to work on during the sprint. Simply drag each item from the product backlog onto the sprint.
Of course, this requires that you've created, prioritized, and estimated your backlog.
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.
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.
If the total amount of effort exceeds your team’s velocity, simply drag items from the bottom of the list onto Backlog items.
After your team has worked a few sprints, you can monitor the velocity of the team sprint-over-sprint and use that to forecast the subset of work that can be built during a sprint.
Set team capacity
The next step in planning requires determining your team’s actual capacity. Whereas velocity correlates to how the team estimates requirements, capacity correlates to actual time – either hours or days. Capacity takes into account variation in work hours by team members as well as holidays and vacation days. Because this can vary from sprint to sprint, you set capacity for each sprint.
Open the Capacity page and enter the capacity and days off for each member of your team. For example, Christie Church's capacity is 6 hours hours/day.
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 report remaining work.
Break down work into tasks
Capacity provides you with detailed knowledge of how much work team members and the team can commit to.
To compare capacity against actual planned work, you next break down each requirement into tasks that you estimate in hours or days.
Add as many tasks for each requirement to capture the work required to complete the 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.
Give the task a name, and estimate the amount of time it will take to complete. Enter the value in Remaining Work.
At the planning stage, Remaining Work corresponds to an estimate of how long it will take to complete the task. 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. 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.
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 the remaining work totals for each requirement and bug.
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.
To quickly reassign tasks, drag the task onto the new assignee's capacity bar. As you reassign tasks, capacity bars automatically update.
To move items out of the sprint, simply drag them back into the backlog or another sprint. All tasks assigned to the item will move as well. Or, you can move a task to appear under a different requirement, called re-parenting.
We’ve covered a lot of the features that support sprint planning. In addition to these features, you can also create tasks from the task board and set and use capacity per team activity.
Burn down work, track progress throughout the sprint cycle
Once the team completes the sprint plan, their ready to tackle their sprint tasks and burn down the work.
The task board provides the best tool for tracking and sharing progress through the sprint cycle. During daily scrum meetings, teams can refer to the task board to discuss what they accomplished, what they plan to work on next, and any blocking issues they need help with.
Prior to the meeting, they can update the remaining work and the status of their tasks.
Another great tool for monitoring team progress is the burndown chart. To open it, click the image at the upper right of the sprint backlog or task board.
Your burndown chart reflects the progress made by completing tasks and updating remaining work. The ideal trend line always indicates a smooth and steady burndown. The blue area, however, represents what’s actually going on. It shows the buildup of remaining work as team members add tasks, and the reduction of remaining work as team members complete those tasks.
Updating the remaining work daily helps you and your team to stay on track and will contribute to a smoother burndown chart. You can also create additional views of your team’s progress – such as active bugs, reactivated bugs, completed test cases, and more – with query charts.
One last item – once you’ve completed all tasks for a requirement, update its status to Done or Closed. This way, the item moves off your backlog.
We just walked through the basic Scrum tools and tasks. These included defining your sprints, planning a sprint, setting capacity, defining tasks, and updating the task board to show burndown of work.
If you’re new to Visual Studio Online and want to start using these tools, you’ll need to create a team project. All work in Visual Studio Online occurs by connecting to a team project. If you don’t have access to your team’s backlog, get invited to the team.