Implement Scrum practices for your team in Azure Boards
TFS 2017 | TFS 2015 | TFS 2013
Your Sprints tools include a filtered backlog based on an Iteration Path and a similarly filtered taskboard. These tools are useful for implementing Scrum practices. With Scrum, you can schedule and plan sprints, update your taskboard, and monitor your sprint burndown.
Scrum methods use Iteration Paths, also referred to as sprints, to plan work to be performed by a team within a specific time period and cadence. To get started, several sprints are predefined for your team. If you're new to Scrum, get an overview from What is Scrum?.
Note
To understand the differences between backlogs, boards, and taskboards, see Backlogs, and boards. If your backlog or board doesn't show the work items that you expect or want, see Set up your backlogs and boards.
Use Azure Boards to implement Scrum
The general sequence of steps for implementing Scrum using Azure Boards is as follows:
Configure teams and sprints
- Define project-level Iteration Paths and set dates
- (Optional) Add project-level Area Paths (Or, add an area path when you configure each team)
- Add teams
- Select team-level Iteration Paths.
Create team backlog
Implement a sprint
You can quickly assign work items to a sprint by dragging and dropping them from the product backlog to the sprint.
- Assign backlog items to a sprint
- Add tasks to backlog items
- Set sprint capacity
- Adjust work to fit sprint capacity
- (Optional) Share your sprint plan
- Update the Taskboard
- Monitor your sprint burndown
Sprint backlogs and taskboards overview
Sprint backlogs and taskboards provide a filtered view of work items a team has assigned to a specific iteration path, or sprint. Sprints are defined for a project and then selected by teams. From your backlog, you can map work to an iteration path using drag-and-drop, and then view that work in a separate sprint backlog.
How selected sprints show up on the backlog
Each sprint that you select for your team provides access to a sprint backlog, taskboard, and other Agile tools for planning and tracking work.
For example, by selecting Sprints 1 through 4, the Fabrikam Fiber team gets access to four sprint backlogs. They also get access to capacity planning tools and a taskboard for each sprint.
Track team capacity
Once you've defined iteration (sprint) paths and configured team iterations, you can start using the following tools to plan your sprint.
At the start of each sprint, you'll want to plan the work that your team can commit to. The three Agile tools that support this work include the sprint backlog, capacity planning, and capacity bars. The sprint backlog contains a filtered subset of backlog items whose iteration path corresponds to the current sprint.
Team capacity planning tool
By setting team capacity, the team knows exactly the total number of work hours or days the team has for each sprint. With this tool, you set individual team member capacity and days off. And, conveniently, you can set holidays or shared days off taken by the entire team.
Setting capacity for each team member working during a sprint causes the capacity bar for that individual to appear.
You set recurring days off, such as weekends, through team settings.
Individual and team capacity bars
With capacity bars, you can quickly see who is over, at, or under capacity. Capacity bars update with each of these activities:
Tasks are assigned with non-zero remaining work
Change in remaining work
Date change within the sprint cycle. Individual and team capacity always reflects their capacity from the current day until the end of the sprint.
Here's how to interpret the capacity colors:
Update tasks and monitor burndown
During a sprint, use the taskboard and sprint burndown chart to track their progress. Your sprint burndown chart provides you with an at-a-glance visual to determine if your team is on track to meet their sprint plan.
Taskboard
Your Taskboard provides an interactive progress board for work required to complete the sprint backlog. During your sprint, you'll want to update the status of tasks and the remaining work for each task.
Updating tasks daily or several times a week yields a smoother burndown chart.
Sprint burndown chart
You use the sprint burndown chart to mitigate risk and check for scope creep throughout your sprint cycle. The burndown chart reflects the progress made by your team in completing all the work they estimated during their sprint planning meeting.
The ideal trend line always indicates a steady burndown. The blue area, however, represents what's actually going on. It shows the buildup of work as team members add tasks and the reduction of work as team members complete those tasks.
Use velocity and forecast tools to predict work effort
Use sprint planning and tracking tools for each sprint. Also, use the velocity and forecast tools to estimate work that can be completed in future sprints.
Velocity provides a useful metric for gaining insight into how much work your team can complete during a sprint cycle. And, the forecast tool provides a means for determining how much work your team can complete within a sprint. This amount is based on a specified team velocity.
After several sprints, use the Velocity chart and Forecast tool tool to estimate work that can be accomplished in future sprints.
Velocity chart
Each team is associated with one and only one velocity chart. The green bar within the chart indicates the total estimated effort (story points or size) of backlog items (user stories or requirements) completed within the sprint. (Blue corresponds to the estimated effort of items not yet completed.)
Velocity will vary depending on team capacity, sprint over sprint. However, over time, the velocity should indicate a reliable average that can be used to forecast the full backlog.
By minimizing the variability of backlog item size—effort or story points—you gain more reliable velocity metrics.
Forecast tool
You can use the forecast tool to get an idea of how many and which items you can complete within a sprint.
By plugging in a velocity, you can see which items are within scope for the set of sprints the team has selected. As shown here, a velocity of 15 indicates that it will take three sprints to complete the work shown.*
Query sprint scope changes
There isn't a sprint scope change chart or widget. However, you can query for work items added to a sprint or moved out of a sprint after the start of the sprint. Use the steps provided next.
List work items added after the start of the sprint
Open the velocity chart for the team and choose the Planned bar for the sprint of interest. You can use the Planned bar for a velocity chart widget or the team backlog velocity chart.
The Query Results page opens with a list of work items defined for the sprint at the start of the sprint, the first day of the sprint. This list is an itemized list of work item IDs.
Choose the Editor page to edit the query.
List the items that were added to the sprint after the sprint's start. To do so, change the query to add and change the following clauses:
- Add a clause at the top to specify the Work Item Types of interest
- Change the Operator for the ID Field to Not In.
- Add the Iteration Path for the sprint of interest.
- Add the Area Path for the team.
The updated query should look similar to the following image.
Add Created Date as a column option, and sort by that field. You can then view the existing work items that were added to the sprint and what newly created work items were added.
List work items moved out of the sprint
Open the velocity chart for the team and choose the Planned bar for the sprint of interest. You can use the Planned bar for a velocity chart widget or the team backlog velocity chart.
The Query Results page opens with a work item list defined for the sprint at the sprint's start, the first day of the sprint. This list is an itemized list of work item IDs.
Choose the Editor page to edit the query.
List the items that were moved out of the sprint after the sprint's start. To do so, change the query to add and change the following clauses:
- Add a clause at the top to specify the Work Item Types of interest
- Add the Iteration Path for the sprint of interest, specify Not Under operator
- Add the Area Path for the team.
The updated query should look similar to the following image.
For other options to determine changes to the sprint scope, see Query by date or current iteration, List work items moved out of a sprint.
Next step
Related articles
If you work with several teams, and each team wants their own backlog view, you can create more teams. Each team then gets access to their own set of Agile tools. Each Agile tool filters work items to only include those assigned values under the team's default area path and iteration path.