ערוך

שתף באמצעות


Implement Scrum practices for your team in Azure Boards

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

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 for 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

For more information, see Backlogs, boards, and plans. In case you don't see the desired work items on your backlog or board, 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:

1. Configure teams and sprints

  1. Define project-level Iteration Paths and set dates
  2. (Optional) Add project-level Area Paths (Or, add an area path when you configure each team)
  3. Add teams
  4. Select team-level Iteration Paths.

2. Create team backlog

  1. Create and organize your team backlog.
  2. (Optional) Forecast your team backlog.

3. Implement a sprint

Quickly assign work items to a sprint by dragging and dropping them from the product backlog to the sprint.

  1. Assign backlog items to a sprint
  2. Add tasks to backlog items
  3. Set sprint capacity
  4. Adjust work to fit sprint capacity
  5. (Optional) Share your sprint plan
  6. Update the Taskboard
  7. Monitor your sprint burndown

Close out a sprint

  1. End of sprint activities
  2. Sprint retrospective meetings

Sprint backlogs and Taskboards overview

Sprint backlogs and Taskboards provide a filtered view of work items a team 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.

Screenshot of Web portal, Open Boards, Sprints, 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.

  1. Gain an overview of your sprint planning by turning on the Planning view option. From the product backlog or any sprint backlog, choose the view options icon and select Planning.

    Screenshot of Sprints backlogs Planning pane.

    Note

    The Planning pane only shows the current sprint and the next 10 future sprints in the list, even if more have been selected for the team.

    The set of sprints selected for your team appears. If you don't see any sprints listed, you can add sprints or select existing sprints for your team's use. To learn how, see Define sprints.

  2. To select a sprint backlog, you can choose one of the sprint links from the Planning pane, or from a Sprint backlog, choose a sprint from the sprint selector.

    Screenshot showing how to select a sprint.

Track team capacity

Once you define iteration (sprint) paths and configure team iterations, you can start using the following tools to plan your sprint.

At the start of each sprint, 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.

For more information, see Set capacity for the team and team members.

Screenshot of Team capacity planning tool.

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 nonzero 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.

Screenshot of Capacity bars.

Here's how to interpret the capacity colors:

Screenshot of capacity board that help distinguish capacity.

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, 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.

Screenshot of Taskboard.

Sprint burndown chart

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.

Screenshot of Sprint burndown chart.

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 varies 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.

Screenshot of Velocity chart.


Forecast tool
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 selected. As shown here, a velocity of 15 indicates that it takes three sprints to complete the work shown.*

Screenshot of Forecast tool.


Query sprint scope changes

There isn't a sprint scope change chart or widget. But, 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

  1. Open the velocity chart for the team and choose the Planned bar for the sprint of interest. Use the Planned bar for a velocity chart widget or the team backlog velocity chart.

    Screenshot of team velocity chart, choose a planned work bar.

  2. 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.

  3. Choose the Editor page to edit the query.

  4. 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.

    Screenshot of Query Editor, Work Items added to a sprint after the start of the sprint.

  5. Add Created Date as a column option, and sort by that field. View the existing work items that were added to the sprint and what newly created work items were added.

For more information, see Query fields, operators, and macros in Azure Boards.

List work items moved out of the sprint

  1. Open the velocity chart for the team and choose the Planned bar for the sprint of interest. Use the Planned bar for a velocity chart widget or the team backlog velocity chart.

    Screenshot of team velocity chart, choose a planned work bar, second instance.

  2. 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.

  3. Choose the Editor page to edit the query.

  4. 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 and specify Not Under operator.
    • Add the Area Path for the team.

    The updated query should look similar to the following image.

    Screenshot of Query Editor, Work Items moved out of a sprint

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

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.