A chart which shows the amount of work which is thought to remain in a backlog. Time is shown on the horizontal axis and work remaining on the vertical axis. As time progresses and items are drawn from the backlog and completed, a plot line showing work remaining may be expected to fall. The amount of work may be assessed in any of several ways such as user story points or task hours. Work remaining in Sprint Backlogs and Product Backlogs may be communicated by means of a burn-down chart.

A chart which shows the amount of work which has been completed. Time is shown on the horizontal axis and work completed on the vertical axis. As time progresses and items are drawn from the backlog and completed, a plot line showing the work done may be expected to rise. The amount of work may be assessed in any of several ways such as user story points or task hours. The amount of work considered to be in-scope may also be plotted as a line; the burn-up can be expected to approach this line as work is completed.

The Daily Scrum is a 15-minute event for and by the Developers of the Scrum Team, taking place each working day of the Sprint. The Daily Scrum is for realignment between Developers on the Sprint work progress and plan adjustments. The purpose of Daily Scrum is for the Developers to inspect progress toward the Sprint Goal, highlight any impediments, and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. Developers only highlight the impediments, challenges, and problems during the Daily Scrum, as this is not a problem-solving event. The Daily Scrum improves team collaboration and enables faster decision-making. To simplify complexity, the Daily Scrum is held at the same time and place.

“Definition of Done” describes the quality goal/commitment for the
Increment. The Definition of Done is a formal description of the state of the Increment when it meets the appropriate quality measures/standards required for the product in that context.

An Increment is created when a Product Backlog item fulfills the Definition of Done. The Definition of Done promotes transparency by presenting everyone with a shared understanding of the work accomplished as part of the Increment. A Product Backlog item cannot be released or even presented at the Sprint Review if it does not fulfill the Definition of Done.

Any Scrum Team member dedicated to creating any aspect of a useable increment each Sprint, regardless of their skillset or capabilities. “Developers” is a joint accountability, not an individual.

"Done" refers to the state of the Increment when it meets the quality measures required for the product to be usable (at a minimum). While referring to Increment in Scrum, “Done” means “Usable” at a minimum. If something can’t be used, it’s not done yet.

Evolution. The process through which new facts or understanding about a fact appear or become evident unexpectedly. Scrum supports emergent requirements, architecture, design, and all supporting processes and team structures.

The concept that all knowledge comes through experiences and observations. Empiricism in Scrum refers to the belief that addressing complex issues or performing complex tasks can only be accomplished through an empirical approach rather than overly depending on preconceived plans. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making. Forecast: the selection of items from the Product Backlog Developers deems feasible for
implementation in a Sprint.

An Agile software development methodology focused on incremental development, continuous testing, simplicity, good quality design, and frequent releases.

An Increment is a thing of value, a working piece of the product that can be used. An Increment is some concrete stepping-stone toward the Product Goal. Each Increment is an improvement in the value of the product. The product is the sum of all Increments. Increment raises transparency about work Done or value created through a working (usable and valuable) product. An Increment is created when a Product Backlog item fulfills the Definition of Done. Each Sprint requires at least one Increment to enable Empiricism or the feedback loop.

Kanban framework is used to design, manage, and improve flow systems for knowledge work. It helps organizations evolve by tracking, optimizing and visualizing workflow, limiting work in progress (WIP), and focusing on finishing tasks.

A Product Backlog Item (PBI) is a miniscule feature within the product backlog. It includes user stories, epics, specifications, bugs, or change requirements. The Product Owner prioritizes the backlog, ensuring the most critical PBIs are addressed first.

An ongoing activity or set of activities to prepare the top-order items in the Product Backlog for selection in the next Sprint Planning. Through regular Product Backlog Refinement, the Product Owner and Developers enhance the transparency and level of detail in the Product Backlog. Product Owner: Product Owner is the Product Success Owner. In Scrum, this accountability is responsible for maximizing a product's value by progressively managing and optimizing the Product Backlog while managing the expectations of the product’s stakeholders. Like the Captain of a Sports Team, the Product Owner steers the team toward product success and decides where the product should be heading.

A single source of all work that could be done to enhance the value of a Product. The items in the Product Backlog are ideas and assumptions that could improve the product. Product Backlog raises transparency about the work to be done or that could be done to enhance product value. The Product Backlog is an ordered and emergent list that is regularly refined as more is known.

Narrating the long-term, future product state, the Product Goal is the reference for the Scrum Team plans to enhance the product. The Product Goal is part of the Product Backlog; the rest of the Product Backlog emerges to define the specifics of the product being built. The Scrum Team focuses on and commits to one Product Goal at a time and must fulfill (or abandon) one [objective] Product Goal before taking on the next.

The definitive rule book of Scrum, co-authored by Ken Schwaber and Jeff Sutherland. The Scrum Guide is the only right source of the rules and elements of Scrum; there is no other version of Scrum.

An accountability within the Scrum Team entrusted with guiding, coaching, educating, and altruistically aiding the Scrum Team and the larger organization in effectively adopting Scrum. Scrum Master fosters an environment conducive to self-management and, generally, for Scrum Adoption in the organization. Scrum Master cultivates trust and safety. Scrum Master challenges the status quo if it comes in the way of the Scrum Team’s effectiveness.

A Scrum Team is a cohesive unit of professionals responsible for all productrelated activities [from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required], focused on one goal at a time. They are structured, empowered, and trusted by the organization to manage their work by themselves. They are cross-functional and self-managing as a cohesive unit. A Scrum Team comprises three accountabilities: a Scrum Master, a Product Owner, and Developers.

A foundational set of human values and attributes underlying the Scrum framework: commitment, focus, transparency, respect, and courage. Like a Navigation compass, the Scrum values guide the work, practices, and behaviors of organizations adopting Scrum. When an organization wants to adopt and benefit from Scrum, the Scrum Values are to be embodied by the Scrum Teams and the people they work with. Incorporating Scrum Values by the Scrum Team and the people they work with helps create a safe working environment. While the Scrum values are the foundation, a Working Agreement aligned with the Scrum Values is the first step for Scrum Teams. Before the Scrum Team gets to work, they can co-create and mutually agree on their working methods and the acceptable and unacceptable behaviors aligned with the five core Scrum Values.

A lightweight framework designed to create value through adaptive solutions for complex problems effectively. The Scrum Framework is domain and technology-agnostic and can be effectively applied to all complex problems in various fields: Marketing to organizational change, scientific research to software development, etc.

Scrum Teams are cross-functional, meaning each member possesses the skills to contribute value during each Sprint. Moreover, they are self-managing, enabling internal allocation of tasks, scheduling, and approach.

A Scrum Artifacts representing work being done in the current Sprint. The Sprint Backlog is a plan by and for the Developers. It could also have a tracking mechanism as agreed upon by the Developers. The Sprint Backlog raises transparency about the current Sprint Goal and the work undertaken for the current Sprint.

The primary purpose of the Sprint. A concise expression of Sprint's purpose, often addressing a business challenge. The Sprint Goal is the single value objective for the Sprint. The “Sprint Goal” is a commitment to the Sprint Backlog, against which the progress of work in the Sprint can be measured. It is defined as co-created by the Scrum Team during Sprint Planning. The scope of Sprint may be adapted during the Sprint to attain the Sprint Goal.

A Scrum Event that launches a Sprint. Sprint Planning is for the Scrum Team to create a Plausible Goal and Plan for the Sprint. What best could be achieved for their stakeholders during the Sprint? This Scrum event enables the Scrum Team to assess the most valuable Product Backlog items for immediate attention and incorporate them into the Sprint Backlog.

A Scrum Event marking the conclusion of a Sprint. The Sprint Retrospective is an opportunity for both “Retrospective” and “Prospective” for the Scrum Team. The Scrum Team explores and plans ways to improve team effectiveness and product qualit. The Scrum team reflects, introspects, and prospects for self-correction and self-improvement concerning individuals, interactions, processes, and tools.

Sprint Review is for feedback (product value validation) and feed-forward (What next for the product?). This event allows the Scrum Team and stakeholders to assess the product Increases, appraise its impact on overall progress toward the Product Goal, and update the Product Backlog to optimize forthcoming phases. It’s also an opportunity to get product assumptions validated by the stakeholders. It’s also an opportunity for the Scrum Team to empathize with customers and listen to understand them. It helps to build a trusting relationship with the Stakeholders and enhances transparency about the progress toward the Product Goal.

The “container” Scrum Event, typically lasting one month or less, where all Scrum Events, development, and refinement work happens. Sprints are contiguous “Learning Cycles” where ideas are turned into value for stakeholders in the form of Increments. Sprints are not delivery cadence. These are planning and learning cadence. Sprints are the heartbeats of Scrum and are executed sequentially without intervening breaks. **Note: There is no Sprint 0, Testing Sprint, Integration Sprints, Hardening Sprint, etc. Every Sprint must deliver some value as usable Increment(s). **

A stakeholder is an external individual with specific knowledge and interest in a product. In Scrum, Stakeholders are the people the Scrum Team creates value for. They play a pivotal role in the incremental discovery of product value and actively engage with the Scrum Team during the Sprint Reviews. In the context of Scrum, all the Stakeholders are outside the Scrum Team. However, they can be both internal and external to the development organization.

**Note: Technical Debt is not a Scrum term.** Technical Debt is a metaphor that refers to the eventual consequences of “Quick and Dirty” solutions. Technical debt refers to the implied cost of deferred work for the product, often due to decisions made to trade speed over quality, contributing to the overall cost of ownership. It may exist unintentionally within the Increment or be intentionally introduced to expedite value realization.

**Note: Velocity is not a Scrum term.**An optional but frequently used measure indicating the number of Product Backlog Items (or something equivalent) transformed into Increments of the product during a Sprint by the Scrum Team. The Developers monitor this metric for internal use within the Scrum Team.