Professional Scrum Developer Glossary

This glossary represents an overview of terms specific to software development teams using Scrum and agile software development
techniques.

To learn more about the Scrum framework, we highly recommend that you reference the Scrum Guide™ and the Scrum Glossary.

A
ALM (Application Lifecycle Management): holistic view on the management of software applications and systems, accounting for
all stages of the existence of a software product.

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.

B
BDD (Behavior-Driven Development): agile software development practice adding to TDD the description of the desired functional
behavior of the new functionality.

Branching: creating a logical or physical copy of code within a version control system so that this copy might be changed in
isolation.

C
Clean Code: software code that is expressed well, formatted correctly, and organized for later coders to understand. Clarity is
preferred over cleverness.

Code Coverage: a measurement indicating the amount of product code that is exercised by tests.

Cohesion and Coupling: coupling refers to the interdependencies 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 codebase are jointly responsible for the code in its entirety.

Continuous Delivery: a software delivery practice similar to Continuous Deployment except a human action is required to promote
changes into a subsequent environment along the pipeline.

Continuous Deployment: 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.

Cyclomatic Complexity: a measure of code complexity based on the number of independent logical branches through a code base.
Cyclomatic complexity is expressed as a simple integer.

Cross-functional: 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.

D
Definition of Done: a shared understanding of the expectations that software must live up to in order to be releasable into
production, with a purpose of providing transparency over the software created. Managed by the Development Team.
Developer: any member of a Development Team, regardless of technical, functional or other specialty.

DevOps: 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.

Development Team: the self-organizing role within a Scrum Team accountable for managing, organizing and doing all work required
to create a releasable Increment of product every Sprint. All work is called development.

DRY (don’t repeat yourself): software development principle to avoid repetition of the same information in one system, preventing
the same code from being produced multiple times on a code base.

E
Engineering Standards: a shared set of development and technology standards that a Development Team applies to create
releasable Increments of software, and against which a Development Team can inspect and adapt.

Extreme Programming (XP): agile software development framework with an extreme focus on programming and taking engineering
practices to an extreme in order to create and release high quality code. Highly complementary to the Scrum framework.

F
Feature Toggle: software development practice that allows dynamically turning (parts of) functionality on and off without impacting
the overall accessibility of the system by its users.

I
Increment: a fully functional piece of working software, living up to the definition of Done, that adds to previously created Increments,
where the sum of all Increments - as a whole - form a product. An Increment typically is the result of a Sprint.

P
Pair Programming: agile software development practice popularized by Extreme Programming in which 2 team members jointly
create new functionality.

R
Refactoring: 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.

S
Scout Rule: the practice of always leaving the code base in a little better state than it was found before modifications. A means to
progress towards Clean Code.

Scrum: 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™.

Scrum Board: a board to visualize information within the Scrum Team primarily, often used to manage Sprint Backlog. Scrum
boards are an optional implementation within Scrum to make information visible and thereby increase transparency.

Scrum Guide™: the definition of Scrum, written and provided by Ken Schwaber and Jeff Sutherland, co-creators of Scrum.
The Scrum Guide consists of Scrum’s roles, events, artifacts, and the rules that bind them together.

Scrum Team: a self-organizing team consisting of a Product Owner, Development Team and Scrum Master.
Self-organization: the organizational principle that teams autonomously organize their work. Teams choose how best to accomplish
their work, rather than being directed by others outside the team. Self-organization happens within boundaries and toward goals.

Specification by Example: agile software development practice based on TDD and ATDD that calls for using realistic examples
from past experience instead of untested or abstract statements in the description of the desired functional behavior.

T
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.

Technical Debt: 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.

U
User Story: agile software development practice from Extreme Programming to express requirements from an end user perspective,
emphasising verbal communication. In Scrum, it is often used to express functional items on the Product Backlog.

Unit Test: 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.

V
Velocity: an optional but often used indication of the amount of Product Backlog turned into an Increment of product during a Sprint.
It is tracked by the Development Team for use within the Scrum Team.