Agility Software

Agile training, coaching, and consulting

Scrum Glossary


Glossary of Scrum terms 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, timeboxed 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 abbrieviated 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 Shippable.
Emprical 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 Shippable Product Backlog attribute Each Increment of software completed at the end of every Sprint is "Potentially Shippable." 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 funtionality 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 likley timeframe 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 optimmize 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 timebox 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 timebox 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 businss 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.
Timebox Scrum attribute The maximum amount of time that will be spent on a Scrum event. Timeboxes 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 timeboxes.
Transparent Scrum attribute Tranparency 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.