Scrum Glossary (EN)
This glossary is meant to represent an overview of Scrum-related terms. Some of the mentioned terms are not mandatory in Scrum, but have been added because they are commonly used in Scrum. The original versions can be found at:
– Scrum Guide
– Scrum Glossary
– Professional Scrum Developer Glossary
Acceptance criteria are a formalized list of requirements that ensure that all user stories are completed and all scenarios are taken into account. Put simply, acceptance criteria specify conditions under which a user story is fulfilled.
ATDD (Acceptance Test-Driven Development)
Test-first software development practice in which acceptance criteria for new functionality are created as automated tests. The failing tests are constructed to pass as development proceeds and acceptance criteria are met.
BDD (Behavior-Driven Development)
Agile software development practice adding to TDD the description of the desired functional behavior of the new functionality.
Creating a logical or physical copy of code within a version control system so that this copy might be changed in isolation.
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.
Software code that is expressed well, formatted correctly, and organized for later coders to understand. Clarity is preferred over cleverness.
A measurement indicating the amount of product code that is exercised by tests.
Cohesion and Coupling
Coupling refers to the inter-dependencies between modules, while cohesion describes how related the functions within a single module are.
Collective Code Ownership
A software development principle popularized by Extreme Programming holding that all contributors to a given code-base are jointly responsible for the code in its entirety.
A software delivery practice similar to Continuous Deployment except a human action is required to promote changes into a subsequent environment along the pipeline.
A software delivery practice in which the release process is fully automated in order to have changes promoted to the production environment with no human intervention.
Continuous Integration (CI)
Agile software development practice popularized by Extreme Programming in which newly checked-in code is built, integrated and tested frequently, generally multiple times a day.
Characteristic of a team holding that all the skills required to successfully produce a releasable Increment in a sprint are available within the team, where releasable refers to making the software available in production.
Daily, time-boxed event to re-plan the development work during a Sprint. It serves for the Development Team to inspect the daily progress and update the Sprint backlog.
Definition of Done
A shared understanding of expectations that the Increment must live up to in order to be releasable into production. Managed by the Development Team.
An organizational concept serving to bridge the gap between development and operations, in terms of skills, mind-set, practices and silo-mentality. The underlying idea is that developers are aware of, and in daily work consider implications on operations, and vice versa.
The role within a Scrum Team accountable for managing, organizing and doing all development work required to create a releasable Increment of product every Sprint.
Empiricism or Empirical Process
Process control type in which only the past is accepted as certain and in which decisions are based on observation, experience and experimentation. Empiricism has three pillars: transparency, inspection and adaptation.
A shared set of development and technology standards that a Development Team applies to create releasable Increments of software.
The selection of items from the Product Backlog a Development Team deems feasible for implementation in a Sprint.
An impediment in Scrum is a factor that blocks the (Development) team in its creation of a valuable piece of software in a Sprint, or that restricts the team in achieving its intrinsic level of progress. It is the responsibility of the Scrum Master to remove impediments.
A piece of working software that adds to previously created Increments, where the sum of all Increments -as a whole – form a product.
Agile software development practice popularized by Extreme Programming in which 2 team members jointly create new functionality.
An ordered list of the work to be done in order to create, maintain and sustain a product. Managed by the Product Owner.
Product Backlog Refinement
The activity in a Sprint through which the Product Owner and the Development Teams add granularity to the Product Backlog.
The role in Scrum accountable for maximizing the value of a product, primarily by incrementally managing and expressing business and functional expectations for a product to the Development Team(s).
A shared understanding by the Product Owner and the Development Team regarding the preferred level of description of Product Backlog items introduced at Sprint Planning.
Agile software development practice popularized by Extreme Programming in which code is adjusted within the code base without impacting the external, functional behavior of that code.
A framework to support teams in complex product development. Scrum consists of Scrum Teams and their associated roles, events, artifacts, and rules, as defined in the Scrum Guide
A physical board to visualize information for and by the Scrum Team, often used to manage Sprint Backlog. Scrum boards are an optional implementation within Scrum to make information visible.
The definition of Scrum, written and provided by Ken Schwaber and Jeff Sutherland, co-creators of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together.
The role within a Scrum Team accountable for guiding, coaching, teaching and assisting a Scrum Team and its environments in a proper understanding and use of Scrum.
A self-organizing team consisting of a Product Owner, Development Team and Scrum Master.
A set of fundamental values and qualities underpinning the Scrum framework; commitment, focus, openness, respect and courage.
The management principle that teams autonomously organize their work. Self-organization happens within boundaries and against given goals. Teams choose how best to accomplish their work, rather than being directed by others outside the team.
Time-boxed event of one month or less, that serves as a container for the other Scrum events and activities. Sprints are done consecutively, without intermediate gaps.
An overview of the development work to realize a Sprint’s goal, typically a forecast of functionality and the work needed to deliver that functionality. Managed by the Development Team.
A short expression of the purpose of a Sprint, often a business problem that is addressed. Functionality might be adjusted during the Sprint in order to achieve the Sprint Goal.
Indicate the time-box of a sprint, see Sprint
Time-boxed event of 8 hours, or less, to start a Sprint. It serves for the Scrum Team to inspect the work from the Product Backlog that’s most valuable to be done next and design that work into Sprint backlog.
Time-boxed event of 3 hours, or less, to end a Sprint. It serves for the Scrum Team to inspect the past Sprint and plan for improvements to be enacted during the next Sprint.
Time-boxed event of 4 hours, or less, to conclude the development work of a Sprint. It serves for the Scrum Team and the stakeholders to inspect the Increment of product resulting from the Sprint, assess the impact of the work performed on overall progress and update the Product backlog in order to maximize the value of the next period.
A person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review.
TDD (Test-Driven Development)
Test-first software development practice in which test cases are defined and created first, and subsequently executable code is created to make the test pass. The failing tests are constructed to pass as development proceeds and tests succeed.
The typically unpredictable overhead of maintaining the product, often caused by less than ideal design decisions, contributing to the total cost of ownership. May exist unintentionally in the Increment or introduced purposefully to realize value earlier.
Agile software development practice from Extreme Programming to express requirements from an end user perspective, emphasizing verbal communication. In Scrum, it is often used to express functional items on the Product Backlog.
Low-level technical test focusing on small parts of a software system that can be executed fast and in isolation. The definition and boundaries of a ‘unit’ generally depends on the context and is to be agreed by the Development Team.
An optional, but often used, indication of the amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team.