Ubiquitous Language

Terms defined within the Modern XP domain. Each entry links to the document where the term originates.

A

Acceptance Criteria

Pass/fail conditions that define when a behaviour is complete. Exist on Use Cases (as Gherkin scenarios), Tasks, or lightweight Stories. Must exist somewhere before building.

Actor

Entity that starts an interaction with the system. Primary actor starts the Use Case.

ADR (Architecture Decision Record)

Document that captures an architectural decision, its context, and trade-offs. Output of Studies and domain boundary changes.

Agent Cost

The running cost of agentic work: tokens, compute, and tool usage. FinOps tracks it like any infrastructure cost and budgets per service and per process.

Aggregate

Cluster of domain objects treated as one unit for changes. Defines a consistency boundary. One Use Case maps to one Aggregate.

Aggregate Boundary

The scope within which consistency is guaranteed. Crossing boundaries in one Use Case signals the Story is too broad.

Aggregate Design

DDD technique to define consistency boundaries. Use when data integrity problems surface.

Agile Manifesto

Foundational values and principles this guide builds on. When contradiction occurs, the Manifesto wins.

AI-assisted

Use of tools (Cursor, Copilot) for rapid prototyping, boilerplate, and test generation. Review output.

Analytics

Website visitor data collection via Umami. Privacy-focused, no cookies, no PII. Compliant with GDPR, CCPA, PECR.

Application Layer

Coordinates between Aggregates when a scenario crosses aggregate boundaries. Use Case does not handle this.

B

Big Picture Event Storming

Domain exploration technique to map domain events, commands, actors, and pain points. Use when the team lacks a shared mental model.

Blameless Post-mortem

Incident analysis that focuses on system causes, not individual blame. Run soon after each incident.

Blueprint

Deployment strategy family: switching traffic between environments. See Blue-green Deployment, Canary Deployment, and Rolling Deployment.

Blue-green Deployment

Deployment strategy that runs two environments (blue and green) to switch traffic atomically.

Bounded Context

DDD concept for a boundary within which a particular model applies. Identified via Context Mapping.

Build Phase

Core delivery moment where Stories evolve to needed fidelity, acceptance scenarios are written, Tasks defined, and Tests written. Execution follows.

Business Readiness

Go/No-Go gate check that the business is ready for release.

Business Rules

Domain constraints that apply across all Use Case scenarios.

C

Canary Deployment

Gradual release to a small subset of users before full rollout.

Candidate Issue

Potential Issue found during Event Storming. No requirement to link every observation.

Capture

First stage of Issue lifecycle. An Issue enters the system from any source.

CCPA

California Consumer Privacy Act. Privacy regulation this site’s analytics comply with.

Change Failure Rate

DORA metric for the percentage of deployments that cause a failure.

Chore

Work Item that supports delivery without direct user value. Examples: dependency upgrades, CI fixes, test infra. Tracked under parent Story or Use Case.

CI/CD (Continuous Integration and Continuous Delivery)

Automated pipeline for integration and delivery of code. Maturity enables longer delivery cycles safely.

Close

Final stage of Issue lifecycle. Issue is resolved, abandoned, or parked. Searchable but not actionable.

Code Review

Async review technique for small, safe changes. Suits remote teams.

Command

DDD concept for an intent to change state. Mapped to Use Case flows: main scenario uses primary command, extensions use alternate commands.

Complexity

The enemy of delivery speed. Contain it with deliberate boundaries on scope, consistency, and responsibility.

Consistency Boundary

See Aggregate and Aggregate Boundary.

Constraints

Boundaries, business rules, and design decisions documented on a Task.

Context Mapping

DDD technique to identify bounded contexts and their relationships. Use when service boundaries are unclear.

Cost Management

Review infrastructure costs once per cycle. Act when cost grows faster than user growth or one service exceeds 20% of the budget.

Cost of Delay (WSJF)

Prioritisation pattern that uses user value, time criticality, and risk reduction divided by job size. Use for high-stakes disagreement.

Cyclical / Round-robin

Prioritisation pattern where each stakeholder picks one must-have per cycle. Use with multiple sponsors or customer groups.

D

Decision Record

See ADR.

Definition of Done

Checklist on a Task for completion verification.

Delivery

Continuous loop that turns Features into working, released software via Stories and Use Cases.

Delivery Activities

Coding, testing, designing, shipping. Measured against process activities in the Friction Budget.

Delivery Cycle

Period from work selection to its release. Size determined by context, not rule. Has Build, Review, and Retro moments.

Demo

Review moment that shows stakeholders what shipped. Keep short.

Deployment Frequency

DORA metric for how often the team deploys to production.

Direction

Shared understanding of where the team goes and why. Answers “what issues is this team here to resolve?” Revisable.

Domain

The problem space the team operates in. Exploration techniques (Event Storming, Context Mapping) used when unfamiliar.

Domain Event

Something that happened in the domain. Mapped during Event Storming.

Domain Object

Entity or value object inside an Aggregate boundary.

DORA Metrics

DevOps Research and Assessment metrics: deployment frequency, lead time, change failure rate, time to restore.

E

Engineering Stability

Go/No-Go gate check that confirms readiness. Includes rollback plan.

Error Budget

The gap between an SLO and actual performance. Use it to decide between features and reliability.

Estimate

Optional prediction of effort. Default: no estimates. Use impact ranking instead.

Event Storming

DDD workshop technique. Two levels: Big Picture (discovery) and Process/Design (design).

Expected Result

What passing means for a Test.

Extension

Alternative flow, error condition, or exception in a Use Case scenario.

F

Face-to-face Conversation

Most efficient communication method. Favour over tickets when co-located. Use synchronous calls when remote.

Feature

Narrative that describes a user intent. Current flow, pain points, desired flow, success measurement. Exists on the Roadmap.

Feature Adoption

Production signal that shows whether users engage with a Feature. Creates or deprioritises Issues.

Feature Flag

Mechanism that decouples deploy from release. Off by default. Skipped for invisible changes or early stage.

Feedback

The only ground truth. Production data, user behaviour, team sentiment override plans. Closes the loop from Direction to Issues to Work Items to Release.

FinOps

Tracks cost per service as part of monitoring.

First Response

Target time for initial acknowledgement of an incident. Defined per severity level.

Fix Target

Target time to resolve an incident. Defined per severity level.

Friction Budget

Guideline that caps process activities at 20% of cycle time. Estimate at retro, cut one item if exceeded. Cut meetings with no agenda, gates that never fail, reports no one reads, approvals always approved.

Future (bucket)

Intentionally absent from the Roadmap. Ideas live in Issues (Idea type). Removed to force explicit “no” decisions.

G

Gate

Process checkpoint that consumes energy. Earns its keep or gets removed.

Gatekeeper

No gatekeeper between team and stakeholder. Anyone can talk to users directly.

GDPR

General Data Protection Regulation. Privacy regulation this site’s analytics comply with.

Gherkin

Given/When/Then syntax for writing acceptance scenarios from Use Case flows. Each scenario becomes one Test.

Go/No-Go Gate

Lightweight release gate that checks engineering stability, QA acceptance, security scan, and business readiness. Skip for low-risk releases.

Goals

Short-term concrete outcomes (1-2) that make Missions actionable. Changed at team discretion.

Guiderails

Boundaries set by Direction that Issues exist within. Vision defines class of problems. Missions name what to achieve.

I

Idea

Issue type for something that could be better. Example: “Add real-time shipment tracking.”

Impact Ranking

Default prioritisation method. Sort by gut-checked impact-to-effort. Disagreement resolved by conversation.

Incident

Issue type for something that failed in production. Example: “Payment gateway timeout.”

Incident Response

Process with SEV1-4 severity levels, response targets, and runbooks. Run a blameless post-mortem after each incident.

Inputs

What a Task needs to start execution.

Integration Tests

Quality gate on every push. Automated. Verify system components work together.

Issue

Gap between current state and desired state. Types: Problem, Idea, Question, Incident. Everything starts with an Issue.

Issues Backlog

Holds everything the team is not actively working on. The inbox. Moves to Work Item only when the team decides to act.

J

Judgment over Rules

Core principle. No rule applies in all contexts. Team decides when to follow, bend, or break any practice.

K

Kano Model

Prioritisation model rejected for cycle-level decisions. Too abstract. At most a quarterly direction input.

L

Lead Time

DORA metric for time from commit to production.

Level

Use Case classification per Cockburn: Summary, User Goal, or Subfunction.

Logs

Records of system events. Part of monitoring, alongside metrics and traces.

M

Main Success Scenario

Step-by-step happy path of a Use Case.

Maintenance

Continuous activity after first Release. Includes monitoring, incident response, and feedback loops.

Metrics

Quantitative measurements of system performance. Part of monitoring, alongside logs and traces.

Missions

Medium-term descriptions of what the team works towards now. Change with environment shifts.

Monitoring

Logs, metrics, traces. Continuous observation of the system in production.

Monte Carlo

Forecasting method that turns historical throughput into a probability range for delivery dates. Used instead of estimates when the team plans releases.

MoSCoW

Must/Should/Could/Won’t. Rejected as a Roadmap method. “Should” and “Could” are Future in disguise.

N

Next (Roadmap bucket)

Features the team works on after Now finishes.

Now (Roadmap bucket)

Features the team works on actively.

Numeric Scores

RICE, ICE, weighted matrices. Rejected for false precision. Weights are subjective but feel objective.

O

Observation

Output of domain exploration techniques. Can become Issues but no requirement to link.

On-call

Fair rotation for incident response. Name primary and secondary escalation. Track toil. Automate if toil exceeds 30%.

Operation

Continuous activity after first Release. Includes monitoring, incident response, FinOps, and feedback.

Orchestrator

The coordination role in agentic teams. Routes work between agents, holds shared state, validates output, and escalates failures to a human. In human teams, the Engineering Lead covers this.

Outputs

What a Task produces.

P

Pain Point

Friction or problem in the current domain. Mapped during Event Storming.

Pair Programming

Technique for complex or critical code. Junior-senior pairing for learning.

Parent (Task)

Use Case ID or Story ID that the Task belongs to.

PECR

Privacy and Electronic Communications Regulations. Privacy regulations this site complies with.

Peer Review

Catch predictable team errors. Prefer over process overhead.

Postconditions

What must be true after successful Use Case execution.

Practice

A technique the team applies, such as TDD or a retrospective. Practices serve the values. The team decides when a practice applies.

Preconditions

What must be true before a Use Case or Test executes.

Primary Actor

Who starts the Use Case interaction.

Prioritisation

Conversation, not formula. Default: impact ranking. Production data decides when available.

Privacy

Data collection limited to business communication response. No selling or sharing for marketing.

Problem

Issue type for something that is wrong. Example: “30% of orders miss the delivery window.”

Process

Has cost. Every gate, review, and meeting consumes energy. Cut what does not earn its keep.

Process Activities

Gate reviews, meeting attendance, preparation. Measured against delivery activities in the Friction Budget.

Process/Design Event Storming

Design-level Event Storming for Features with unclear internal flows. Outputs detailed flows, aggregate design, acceptance criteria.

Production Readiness

Checklist a new service passes before it receives production traffic: logging, alerts, deploy/rollback process, backup strategy.

Production Data

Ground truth that overrides plans. Drives feedback loops from Delivery back to Direction and Issues.

Production Monitoring

See Monitoring.

Prototype

Possible Study output. Working model to evaluate an approach, not production code.

Q

QA Acceptance

Go/No-Go gate check that verifies Feature Flag behaviour (on and off).

Quality Gates

Automated checks on every push: unit tests, integration tests, SAST, SCA. Zero manual gates for routine changes.

Question

Issue type for something that is unknown. Example: “What triggers payment settlement?”

R

Red-Green-Refactor

TDD cycle. Write failing test (red), make it pass (green), improve design (refactor).

Refactor

Improves design without behaviour change. Part of TDD and Technical Debt management.

Release

Business decision to flip a Feature Flag from off to on. Not a technical event.

Resolve

Issue lifecycle stage. Issue is resolved directly, promoted to Work Item, or parked.

Retrospective (Retro)

Blameless review that produces 1-3 fix items. Skip for small cycles.

Review

Core delivery moment with Demo and DORA check. After coherent batch of work.

Roadmap

Lightweight two-bucket (Now/Next) plan for Features. Changes freely based on learning. No Future bucket.

Role

A responsibility, not an individual. One person can hold several roles. In agentic teams, a role becomes an agent with a system prompt.

Rollback Plan

Part of engineering stability gate. Exists for failure scenarios, not routine deploys.

Rolling Deployment

Incremental replacement of instances across a cluster.

Rule Governance

If a rule takes longer than the work it governs, abolish immediately.

Rotation

Schedule for on-call shifts. Fair rotation with documented handover. Minimum two people per shift (primary + secondary).

Runbook

Documented procedure for handling a specific operational situation. The team writes one when it expects an incident type to come back.

S

SAST (Static Analysis)

Quality gate for automated code analysis of security and quality issues.

SCA (Dependency Scanning)

Quality gate for automated scanning of dependencies for known vulnerabilities.

Scenario

A single flow through a Use Case. Each scenario (main success and extensions) becomes a Gherkin test.

Scope

Aggregate or system boundary for a Use Case.

Security Scan

Go/No-Go gate check. Passed before release.

Service Layer

Coordinates between Aggregates across Use Case boundaries.

SEV1-4

Incident severity levels. SEV1 = user-facing outage, SEV2 = degraded subset of users, SEV3 = no user impact, SEV4 = cosmetic or internal.

SLO (Service Level Objective)

One or two metrics that matter most to users. Track the gap as error budget to decide features vs reliability.

Source (Test)

Use Case ID and scenario name, or Story ID that a Test traces to.

Study

Timeboxed investigation for technical, domain, or architectural unknowns. Produces decision record, prototype, or ADR. No production code.

Stakeholder

Person or group with interest in the team’s output. No gatekeeper between team and stakeholder.

Story

Lightweight value placeholder for a slice of a Feature. Title, value statement, priority. Independent. No estimates required.

System Prompt

The instruction set that defines an agent’s role: mission, responsibilities, capabilities, and input/output contracts. Process context is appended at dispatch time.

T

Task

Concrete, technology-agnostic implementation instruction. Breaks down a Use Case or Story into actionable steps. One per discrete behaviour change.

TDD (Test-Driven Development)

Red-Green-Refactor cycle. Default for new logic when behavioural correctness matters.

Team API

A contract between teams: services provided, SLOs met, communication channels, and change notification. Without one, teams step on each other.

Team Sentiment

Ground truth input that overrides plans alongside production data and user behaviour.

Technical Debt

Design or implementation shortcuts that slow future delivery. Reserves time after release. Prioritise over features when blocking speed.

Test

Versioned reference point for acceptance, integration, or system-level verification. One per Gherkin scenario. Not a Task (verify versus build).

Time to Restore

DORA metric for time to recover from a production failure.

Timebox

Fixed short duration for a Study. If exceeded, rescope or run Go/No-Go on parent Feature.

Toil

Repetitive operational work. If on-call spends more than 30% of time on toil, automate the task. If more than 50%, change the system.

Traces

Part of monitoring. Track request flow through distributed systems.

Triage

Issue lifecycle stage. Understand, label (Problem/Idea/Question/Incident), decide action.

Trivial Work

Typo, 1-line config. Build directly. Skip full Use Case structure.

U

Ubiquitous Language

This glossary. Shared domain vocabulary used consistently across all team communication and documentation.

Umami

Privacy-focused analytics platform used by this site. No cookies, no PII.

Unit of Delivery

Use Case. What the team builds, tests, and accepts.

Unit Tests

Quality gate on every push. Live in the codebase, not as Work Items.

Unknowns

Kill delivery. Find them early. Study before commit.

Use Case

Full structured specification per Cockburn/Jacobson template. Actor, preconditions, postconditions, scenarios, acceptance criteria, business rules. Unit of delivery.

User Behaviour

Ground truth that overrides plans. Changes Missions, Goals, and prioritisation.

V

Value

One of the five XP values: Communication, Simplicity, Feedback, Courage, Respect. Values say what matters. Practices are how the team honours them.

Value Stream

The end-to-end sequence of work that turns an idea into value for users. A stream-aligned team owns one from start to end.

Value Statement

The “why” on a Story. Describes the value this slice delivers.

Vision

Long-term guiding statement. Changes slowly, if at all. Not a plan.

W

“What Hurts Most?” (pattern)

Pain-driven prioritisation. Feature that removes the biggest current pain wins.

Work Item

How the team resolves Issues. Types: Feature, Story, Use Case, Study, Chore, Task, Test.

Working Software

The only ground truth. Software that runs outranks documentation.