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 cost of having to resolve or work with unfinished, unclean, undone or defect code once it has been released into production.

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