A Glossary of Scrum Terms

Posted by Mark Noneman on 1 March 2017

This glossary of Scrum terms is derived from the Scrum Guide by Ken Schwaber and Jeff Sutherland.

Term Refers to Description

Acceptance Criteria

Product Backlog attribute

Clarifying description for Product Backlog items to help stakeholders, users, and the Development Team understand the correct functionality of each item.

Adapt

Scrum attribute

A fundamental empirical attribute. To adapt means to change based on what has been learned. See also Inspect, Transparent, and Empirical.

Adapts to Environment

Development Team attribute

The Development Team adapts to the environment. As a self-managed team, they are not authorized to do anything they want. The development team does decide "how" to accomplish Product Backlog items within the constraints of the organization.

Cross-Functional

Development Team attribute

The Development Team has all the skills necessary to achieve the Definition of Done every Sprint.

Daily Scrum

Scrum event

A daily meeting for the Development Team, time boxed to 15 minutes. The purpose of the Daily Scrum is for the Development Team to update their Sprint Backlog to deliver as much "Done" incremental value as possible by the end of the current Sprint. Any impediments to delivering that value are identified and the Development Team and Scrum Master work to remove them.

Development Team

Scrum role

The Development Team is responsible for delivering software value every Sprint via a "done" increment. They are authorized and responsible for determining how they will deliver the most value possible every Sprint.

Definition of Done

Scrum attribute

Owned by the Development Team, the Definition of Done (often abbreviated DoD) identifies the key practices that will be accomplished to develop Product Backlog items of value. Although the DoD is owned by the Development Team, the Product Owner "accepts" the work every Sprint.

Done

Scrum attribute

The term "done" in Scrum mean no work remains for a Product Backlog item to be Potentially Releasable.

Empirical

Scrum attribute

Also empiricism. Wiktionary: "Pertaining to or based on experience." The scientific method is an empirical process. Scrum is an empirical framework. An empirical approach requires transparency, inspection, and adaptation based on what has been learned.

Grooming

Product Backlog process

This term is no longer used. See Refinement

Increment

Scrum artifact

The most important artifact in Scrum. The Increment of software, developed by the Development Team, includes only Done value-added functionality as identified by the Product Owner jointly with the Development Team. Each Sprint's increment is built upon all previous increments so that the value is cumulative at the end of every Sprint.

Inspect

Scrum attribute

Literally: to look at. Inspection is required for Empirical approaches. Inspection in Scrum occurs throughout the framework and requires Transparency for learning through inspection.

Ordered

Product Backlog attribute

Items on the Product Backlog are Ordered. Items may be rank ordered or ordered by relative priority (for example, high, medium, low). The most basic ordering is "now" and "not now." The Product Owner is responsible for ordering items on the Product Backlog. The PO relies on stakeholders, users, customer, the Development Team, and their own experience to order the Product Backlog.

Points

Product Backlog attribute

(Often called Story Points.) The relative estimate of effort for each Product Backlog item. Points are estimated by the Development Team only.

Potentially Releasable

Product Backlog attribute

Each Increment of software completed at the end of every Sprint is "Potentially Releasable." That is, it may or may not be delivered to users at the Product Owner's discretion.

Process Manager

Scrum Master attribute

The Scrum Master is said to manage the process of the Scrum Framework. The SM is NOT a personnel manager.

Prioritized

Product Backlog attribute

See Ordered

Product Backlog

Scrum artifact

An ordered list of value-added items to be implemented in software by the Development Team(s). Each item describes the functionality to be added and "acceptance criteria" describing how the Development Team will know they have implemented the functionality correctly. The relative effort for each item is estimated by the Development Team.

Product Burndown/Burnup

Product Backlog attribute

Optional. Usually in chart form. Depicts the amount of estimated effort (see Points) remaining (or completed in a Burnup chart) in a release or project. The sum total of all known remaining work is graphed at the end of each Sprint. Changes in known work may also be depicted. The chart helps the Product Owner, Development Team and stakeholders understand the likely time frame for completing a desired set of functionality. The Burndown/Burnup charts are usually derived directly from the Product Backlog; the charts are owned by the Product Owner.

Product Owner

Scrum role

The Product Owner (PO) role is responsible for the return on investment in the software product or system. The Product Owner role is part of the bigger Product Management role and focuses on identifying and clarifying the valuable features and functionality needed by users, customers, stakeholders and the organization that owns the software asset. Specifically, the Product Owner is responsible for the items on the Product Backlog, refining them with stakeholders and the Development Team, ordering the items on the Backlog, ensuring the Development Team estimates the relative effort of the items, and delivering the most value possible for the investment the organization is making for the product/system.

"Ready"

Product Backlog attribute

Items on the Product Backlog are said to be Ready when they are well enough understood by the Development Team for them to plan the item into a Sprint. That implies they are small enough to be completed (Done) in one Sprint and that the Product Owner will get what they expected from the Development Team.

Refinement

Product Backlog process

A process whereby the Product Owner and the Development regularly review, refine, update, breakdown into smaller items, and estimate the relative effort of items on the Product Backlog. Refinement reviews items to be implemented in future Sprints (not currently planned items). No more than 10% of the Development Team's capacity should be spent in regular Product Backlog refinement.

Scrum

Scrum role

An empirical framework developed by Ken Schwaber and Jeff Sutherland in the 1990s. Scrum is an iterative, incremental approach to optimize predictability and control risk. The basic framework identifies 3 roles, 3 artifacts, and 5 events and basic rules for the framework. The Scrum Guide is the definitive description of Scrum.

Sprint Backlog

Scrum artifact

Owned by the Development Team, the Sprint Backlog identifies the Product Backlog items to be implemented in a Sprint along with how the Development Team will implement them. There is a new Sprint Backlog for each Sprint.

Scrum Master

Scrum role

The Scrum Master (SM) role guides the Product Owner, the Development Team, and the rest of the organization into ever improving and optimizing use of the Scrum Framework. The Scrum Master ensures that the people in the roles understand the authority and responsibility and helps them improve their skills in fulfilling their roles. The SM also ensures the Scrum artifacts are created and maintained in the most optimum way possible according to the Scrum Framework. And the Scrum Master works with the Development Team to help them remove impediments to delivering the most value possible in Done increments of software every Sprint.

Scrum Team

Scrum definition

The Scrum Team consists of the Product Owner, the Development Team, and the Scrum Master.

Self-Managed

Development Team attribute

Development Teams are structured and empowered by the organization to manage their own work. They determine "how" the Product Backlog items will be implemented within the constraints of the environment in which they work. Impediments in the environment are identified by the Development Team and, together with the Scrum Master, are removed to optimize the Development Team's work.

Self-Organized

Development Team attribute

The Development Team alone has the authority and responsibility to organize their work and produce Done increments every Sprint. There are no titles and no "sub-teams" (like testing or business analyst) on the Development Team--no exceptions! Individuals on the Development Team will have special skills and abilities but the accountability remains with the Team as a whole.

Servant Leader

Scrum Master attribute

The Scrum Master is said to be a Servant Leader. The SM's purpose is to optimize the PO and Development Team roles, the Scrum artifacts, and the Scrum events. The Scrum Master also helps those outside the Scrum Team to understand which interactions with the Team are helpful and which are not. The SM helps everyone change those interactions to maximize the value delivered.

Sprint

Scrum event

Each Sprint is a fixed-length iteration during which the Scrum Team forecasts the work, executes the work and inspects and adapts the work. It is always one month or less and should be the same amount of time every Sprint to help the Team achieve a development cadence. The Sprint contains all other Scrum events and there are no time gaps between Sprints.

Sprint Burndown

Sprint Backlog attribute

An optional view of the work remaining during the Sprint. The Development Team may choose to use a Burndown chart to gain better insight into where they are in delivering the most value possible by the end of the current Sprint. The Sprint Burndown chart is usually derived directly from the Sprint Backlog and is owned and managed by the Development Team

Sprint Goal

Scrum event

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog items. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal.

Sprint Planning

Scrum event

At the start of every Sprint, the Scrum Team plans the Sprint in two parts: First, the Development Team estimates which Product Backlog items they can complete to be available in the Done increment at the end of the Sprint. The Sprint Goal is crafted as part one of Sprint Planning.  Second, the Development Team identifies how they will achieve the Done increment.  The guideline time box for Sprint Planning is 2 hours for every week of Sprint (e.g., a 2 week Sprint should spend no more than 4 hours planning the Sprint).

Sprint Retrospective

Scrum event

After the Sprint Review, the Scrum Team reviews the processes by which they worked during the Sprint (inspecting themselves) with a goal of changing (adapting) those processes to make the next Sprint work better. The Sprint Retrospective reviews and modifies the State of the Process. The guideline time box for Sprint Retrospective is 1 hour for every week of Sprint (e.g., a 2 week Sprint should spend no more than 2 hours in a retrospective).

Sprint Review

Scrum event

The Sprint Review occurs at the end of every Sprint. In addition to the Scrum Team, the Product Owner invites stakeholders and others that would benefit from understanding the current State of the Product. During the Review, the Product Owner will review the Product Backlog items completed by the Development Team in the Done increment and accept them (or not). The Development Team may demonstrate items that are Done this Sprint. Any items not completed during the Sprint are not demonstrated and are returned to the Product Backlog and ordered appropriately. Changes in the market and business conditions which could affect the items or ordering on the Product Backlog are reviewed. The Product Owner reviews the budget and schedule for the investment in the product. And finally, the group collaborates on what is to be done next.

Stakeholders

Extended role

Anyone outside of the Scrum Team with a vested interest in the investment and delivered value of the product/system. Usually includes users, paying customers, organizational managers, and investors.

State of the Process

Scrum attribute

At the Sprint Retrospective, the State of the Process is reviewed and modified.

State of the Product

Scrum attribute

At the Sprint Review, the State of the Product is reviewed and decisions made based on the current state.

Time box

Scrum attribute

The maximum amount of time that will be spent on a Scrum event. Time boxes are established by the PO or Development Team or both in order to manage the overhead of the Scrum framework. The Scrum Master helps the Scrum Team maintain their time boxes.

Transparent

Scrum attribute

Transparency is an essential pillar of empirical processes. It means that everyone understands what is actually happening. Transparency is required for good decision making in empirical inspection and adaptation. The opposite of transparency (opacity), inhibits inspecting and adapting the product, processes, roles, artifacts, events, and operating rules of Scrum and will result in poor decision making.

Topics: Scrum, Agile, Glossary