Scrum/Agile Glossary

Continuous Delivery is 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 is 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) is an 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.

Traditional approaches of quality assurance are often based on getting all implementation finished before verifying the latest build of the product before delivering it to production. In contrast continuous testing is a practice of integrating testing as a fundamental and ongoing part of development. It helps to identify and fix issues much earlier and so lowers risk drastically. Continuous testing is especially powerful if combined with practices like test automation, clean code and others which help to reduce regression testing efforts.

Cycle Time is the time between working on an item that has been started and the item is finished (usually delivered to real end-users). Cycle Time defines how fast work can flow through a system and minimizing Cycle Time helps not only to make the system more efficient but also to increase predictability and the ability to quickly respond to changes or new insights.

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

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

Definition of Done is 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.

A Developer is any member of a Scrum Team, that is committed to creating any aspect of a usable Increment each Sprint regardless of technical, functional or other specialty.

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

Dev & Ops collaboration is at the core of the DevOps movement. Instead of separating development and operations, collaboration is key. Instead of developing something and then make running this in production someone else’s problem, we try to achieve end-to-end responsibility. This not only helps with smoothening the delivery process, but it also closes the feedback loop. A closer collaboration strengthens learning how we could support robust operation already in the design and implementation operations.

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

Engineering Standards are a shared set of development and technology standards that the Developers apply to create releasable Increments of software, and against which those Developers can inspect and adapt.

How mistakes are handled has an important impact on an organizations ability to innovate. If people feel that errors are something negative and try to avoid them, they might be much less likely to take a risk and try something new. Instead encouragement for experimentation and learning is important while at the same time considering how to tame risks and decrease the impact of failures.

Extreme Programming (XP) is an 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.

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

The basic idea behind Hypothesis Driven Development is that in a complex environment we do not know where to invest in order to achieve the highest possible value: we formulate hypotheses about that. Once we accept uncertainty and agree that the assumptions our plans are based on can be wrong, it makes sense to change our approach to the development of new features. Validating our assumptions gets high priority and finding small and fast experiments to get more insights becomes an important part of work.

An Increment is 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. The moment a Product Backlog item meets the Definition of Done, an Increment is born.

Instead of setting up and configuring infrastructure and environments, this process can be automated by scripts and parameter files. While this approach is not faster for the initial setup of the infrastructure (it might even be slower), it provides a lot of advantages. The scripts and configuration files can be stored in version control together with the source code of the software. This allows to create exactly the matching environment for a given version of the software. Changes to the environment are documented in version control as they are no longer executed on the environment directly but by changing and executing a script. And new instances of an exact copy of the production environment can easily be created, for example for testing purpose.

Mean Time to Detect (MTTD) is the time it takes to identify that there is a problem. The MTTD should not be determined by the first call of an angry customer at the hotline. Monitoring tools can help to reduce it.

Mean Time to Recover (MTTR) is the average time it takes from when a problem occurs until the problem is fixed and the system is back to normal operations. There are various techniques helping with MTTR as defensive programming and self-healing systems that can switch to an emergency mode to keep the basic functionality of the system up and running. As MTTD is usually a significant portion of MTTR, reducing MTTD will also help with MTTR.

One practice to achieve Hypothesis Driven Development is the Minimum Viable Product (MVP). The MVP is the smallest implementation of our product or a feature which allows to learn more about how users will react to it or technical behavior like performance.

Obviously, it is helpful to know the current state of your system. While most systems support logging to analyze what happened during an outage or a problem, monitoring is used to check the current state continuously. Once one or more parameters get out of a healthy range, alarms can be triggered to initiate some actions.

Non-functional requirements define criteria to evaluate a product's operation, not its specific behaviors. They describe conditions for the product's effectiveness or qualities it must possess. Common types include availability, reliability, regulatory compliance, maintainability, and safety.

Pair Programming is an agile software development practice popularized by Extreme Programming in which two team members jointly create new functionality.

Refactoring is an agile software development practice popularized by Extreme Programming in which code is adjusted within the codebase without impacting the external, functional behavior of that code.

Automating the steps from code commit into version control to delivery in production help increasing speed and reliability of this process. This practice is often referred as Release-Pipelines as this pictures the ideal of a steady stream of changes delivered.

The Scout Rule is the practice of always leaving the codebase in a little better state than it was found before modifications. A means to progress towards Clean Code.

Scrum is a framework to support teams in complex product development. Scrum consists of Scrum Teams and their associated accountabilities, events, artifacts, and rules, as defined in the Scrum Guideâ„¢.

A Scrum Board is a board to visualize information within the Scrum Team primarily, often used to manage Sprint Backlog. Scrum boards are a complimentary practice within Scrum to make information visible and thereby increase transparency.

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

A Scrum Team is a self-managing team consisting of a Product Owner, Development Team and Scrum Master.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

Specification by Example is an 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.