Sprints and Scrum key concepts in Azure Boards
TFS 2018
This article provides a short dictionary of terms and available tools used in tracking work using Sprints and Scrum methods. Other resources to review are Agile glossary and Project management and navigation glossary.
Agile tools
A suite of web-based tools used to track work and support Agile methodologies. Agile tools support the core Agile methods—Scrum and Kanban—used by software development teams today. Learn more: About Agile tools and Agile project management.
Bugs
A type of work item that records a potential source of dissatisfaction with the product. The common name of a work item type for tracking code defects. Each team can choose how they want to manage bugs. Some teams like to track bugs along with requirements on the backlog. Other teams like to track bugs as tasks performed in support of a requirement. The bugs then appear on their Taskboard. Learn more: Manage bugs.
Burndown or burnup charts
Burndown and burnup charts support project management to visually track work completed over time. Burndown charts begin with the total amount of planned work. As work is completed, the burndown graphs the remaining work. With the progression of time, the amount of to-do work decreases. Burnup charts track work as it is completed over time. They are useful to show the rate at which work is getting completed.
For more information, see Burndown and burnup guidance
Team and individual capacity
Capacity correlates to actual task time, either hours or days, that an individual or a team has to work. Azure DevOps provides a Capacity tool for each team's sprint to set capacity. Teams typically set capacity when they plan to create tasks and estimate the time it takes to complete a task.
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. Setting capacity for each team member working during a sprint causes the capacity bar for that individual to appear. Learn more: Set sprint capacity.
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.
| Capacity colors | Capacity bars |
|---|---|
 |
 |
For more information, see Adjust work to fit sprint capacity.
Daily scrum meetings
Daily Scrum meetings help teams stay focused on what they need to do to maximize their ability to meet their sprint commitments. The team's Scrum Master should enforce the structure of the meeting and ensure that it starts on time and finishes in 15 minutes or less. Learn more: Scrum best practices, Daily scrum meeting.
Forecast
The forecast tool helps teams plan their sprints. The tool shows teams the backlog items that can be completed in future sprints based on work item estimates and a set velocity. As shown here, a velocity of 20 indicates that it will take five sprints to complete the work shown. Learn more: Forecast your product backlog.
Iteration paths (aka sprints)
A time period, usually two to three weeks, used to group work items to be completed during that time period. Sprints are used in Scrum methods to support sprint planning, sprint burndown, and other Scrum processes. Iteration paths allow you to group work into sprints, milestones, or other event-specific or time-related period. Learn more: About area and iteration paths.
Product backlog
An interactive list of work items that corresponds to a team's project plan or roadmap for what the team plans to deliver. The product backlog supports prioritizing work, forecasting work by sprints, and quickly linking work to portfolio backlog items. You can define your backlog items and then manage their status using the Kanban board.
Each product backlog can be customized by a team. Learn more: Create your backlog.
Product backlog item (PBI)
A type of work item that defines the applications, requirements, and elements that teams plan to create. Product owners typically define and stack rank product backlog items which are defined with the Scrum process. Learn more: Scrum process work item types and workflow.
Product owner role
The role of product owners is to act as the interface between customers and the team. A product owner can reduce the need for detailed specifications. They reduce the need by being more responsive to the team's questions about implementation details. Also, they clearly define acceptance criteria within each requirement.
Scrum Master role
Scrum Masters help build and maintain healthy teams by employing Scrum processes. They guide, coach, teach, and assist Scrum teams in the proper employment of Scrum methods. Scrum Masters also act as change agents to help teams overcome impediments and to drive the team toward significant productivity increases. Learn more: Scrum best practices, Role of the Scrum Master.
Sprints (also known as iterations)
A sprint is a time period of usually two to three weeks that's used to group work items to be completed during that time period. Sprints are used in Scrum methods to support sprint planning, sprint burndown, and other Scrum processes. Sprints are defined via iteration paths. To learn more, see About area and iteration paths (aka sprints).
Sprint backlog
An interactive list of work items that have been assigned to the same sprint or iteration path for a team. The sprint backlog supports teams that use Scrum methodologies. Learn more: Sprint planning.
Sprint burndown chart
The sprint burndown chart reflects the progress made by a team in completing all the work they estimated during their sprint planning meeting. Team's monitor it to mitigate risk and check for scope creep throughout their sprint cycle. The ideal trend line always indicates a steady burndown. The blue area, as shown in the following chart, 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. Learn more: Monitor sprint burndown.
Sprint goals
Sprint goals are used to focus sprint activities. The goal summarizes what the team wants to accomplish by the end of the sprint. Learn more: Scrum best practices, Set sprint goals.
Sprint planning
The Sprint planning meeting occurs at the start of a sprint and is when the product owner and team agree on a set of sprint goals and work. Learn more: Scrum best practices, Sprint planning meetings.
Sprint retrospective meetings
The Sprint review or retrospective meeting occurs at the end of a sprint. This meeting is when the team demonstrates the work that they completed during the sprint. The product owner, customers, and stakeholders accept the user stories that meet their expectations and identify any new requirements. Customers often understand their needs more fully after seeing the demonstrations and may identify changes that they want to see. Learn more: Scrum best practices, Sprint retrospective meeting.
Task
A task is a type of work item used to track estimated and remaining work. In Scrum, a task is defined to range between four and twelve hours. Defining tasks are essential for monitoring sprint burndown, working with team capacity, and using the Taskboard. Tasks are linked to their parent product backlog items or user stories. Learn more: Add tasks to backlog items.
Taskboard
A taskboard provides an interactive progress board for work required to complete a team's 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 sprint burndown chart. Learn more: Taskboard.
Teams
A team corresponds to a selected set of project members. With teams, organizations can subcategorize work to better focus on all the work they track within a project. Each team gets access to a suite of Agile tools. Teams can use these tools to work autonomously and collaborate with other teams across the enterprise. Each team can configure and customize each tool to meet their work requirements. To learn more, see About teams and Agile tools.
Team member
A member who has been added to a project or organization who has been added to a specific team. Project members can be added to several teams. Several Agile tools, such as capacity planning, team alerts, and dashboard widgets are team-scoped. That is, they automatically reference the users that have been added as members of a team to support planning activities or sending alerts.
To add users to a team, see Add users to a project or specific team.
Technical debt
Technical debt includes anything the team must do to deploy production quality code and keep it running in production. Examples are bugs, performance issues, operational issues, accessibility, and others. Learn more about how to minimize technical debt: What is Agile Development?.
Triage meetings
Triage meetings are used to review and organize the backlog and bugs assigned to a team. Other details, such as estimates, acceptance criteria, and more may be added to the work items. Typically, a product owner runs triage meetings, and team leads, business analysts, and other stakeholders who can speak about specific project risks attend them.
User story
A type of work item that defines the applications, requirements, and elements that teams plan to create. Product owners typically define and stack rank user stories. User story is defined with the Agile process. Learn more: Agile process work item types and workflow.
Velocity and velocity chart
Velocity provides a useful metric for gaining insight into how much work your team can complete during a sprint cycle. After your team has worked several sprints, they can use the velocity chart and forecast tool to estimate work that can be accomplished in future sprints.
Velocity is a measure of how much work a team can complete based on their sprint cadence. The built-in velocity chart measures velocity by summing the Story Points (Agile), Effort (Scrum), or Size (CMMI) defined for a sprint.
For example, in the chart shown below the green bar indicates the total estimated effort (story points) of the user stories completed within each sprint. Blue corresponds to the estimated effort of items not yet completed. Learn more: View and work with the built-in team velocity chart.
Each team is associated with one and only one velocity chart. 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. Learn more: Add tasks to backlog items.