TSM Knowledge Base
Plain-English definitions of the technical concepts Scrum Masters encounter most. Not everything an engineer or architect needs to know, what you need to know to follow technical conversations and ask the right questions.
The on-demand delivery of computing power, storage, and services over the internet. Rather than owning and maintaining physical servers, organisations rent infrastructure from providers like AWS, Azure, or Google Cloud and pay for what they use.
What this means for delivery
When your team talks about 'spinning up an environment' or 'scaling to handle traffic', they are often using cloud infrastructure. Understanding this helps you ask the right questions about lead times, costs, and deployment risk.
Three models of cloud service. Infrastructure as a Service (IaaS) provides raw compute and storage. Platform as a Service (PaaS) adds a managed runtime so developers focus on code. Software as a Service (SaaS) delivers a finished application over the internet.
What this means for delivery
The model your team uses affects how much infrastructure work sits in your backlog. IaaS means more ownership; SaaS means almost none. This shapes how you plan and what risks you need to track.
The ability of a system to automatically scale up or down based on demand, adding or removing compute resources in real time without manual intervention.
What this means for delivery
Elasticity is why cloud teams can handle traffic spikes without pre-provisioning hardware. It also means your team can work in short bursts without waiting weeks for infrastructure to be set up.
A way of packaging an application and all its dependencies into a single portable unit called a container. Docker is the most common tool. Containers run consistently across different environments.
What this means for delivery
When your team says 'it works in my container' or talks about Docker images, this is what they mean. Containers reduce the 'works on my machine' problem and make deployments more predictable.
An open-source platform for managing and orchestrating containers at scale. It handles deployment, scaling, and recovery of containerised applications automatically.
What this means for delivery
Kubernetes is complex infrastructure that adds significant operational overhead. If your team is adopting it, expect it to generate substantial backlog items and require specialised knowledge to operate.
An automated sequence that moves data from one system to another, usually transforming it along the way. Raw data goes in one end; processed, structured data comes out the other.
What this means for delivery
Pipelines are the invisible plumbing of data work. When a dashboard stops updating or shows stale numbers, a broken pipeline is usually the cause. They can fail silently for days without anyone noticing.
Extract, Transform, Load. The standard pattern for moving data between systems: extract it from the source, transform it into the right shape, and load it into the destination.
What this means for delivery
ETL jobs are a common source of delivery risk. A source system change, a schema update, or a timeout can break an ETL job silently. Ask your team how failures are monitored and alerted.
A structured, organised store of data optimised for querying and reporting. Data is cleaned and shaped before it arrives, making it reliable and fast to query.
What this means for delivery
Data warehouse work typically involves significant upfront design and long feedback loops. Stories that depend on warehouse data need to account for pipeline latency and data freshness.
A large store of raw, unstructured data in its original format. Unlike a warehouse, data is stored first and structured later. Useful for exploration and machine learning but harder to query directly.
What this means for delivery
Data lakes are great for experimentation but can become hard to govern. If your team is building on a lake, ask how data quality and discoverability are managed.
A measure of how accurate, complete, timely, and consistent data is. Poor data quality is usually systemic: it points to problems in how data is captured or transformed, not a one-off error.
What this means for delivery
Data quality issues are supply chain problems, not dashboard problems. Fixing the dashboard without fixing the upstream source means the same issue returns with different numbers.
Two ways of processing data. Batch processing runs on a schedule (nightly, hourly) and processes data in chunks. Streaming processes data continuously as it arrives, in near real-time.
What this means for delivery
The choice directly affects data freshness. A dashboard fed by a nightly batch job will always be at least a day behind. This expectation gap is worth surfacing before a dashboard is built.
Continuous Integration and Continuous Delivery (or Deployment). CI is the practice of merging code changes frequently and running automated tests on each merge. CD extends this to automatically deploying passing builds to production or staging.
What this means for delivery
CI/CD is the technical backbone of frequent delivery. Teams with mature CI/CD can deploy multiple times per day safely. Teams without it often hold changes back, creating batch releases with higher risk.
Four metrics identified by the DevOps Research and Assessment team as predictors of software delivery performance: Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Recovery (MTTR).
What this means for delivery
DORA metrics give delivery professionals an objective lens on team performance. If your team is not tracking these, introducing them as a retrospective topic can surface real systemic issues.
One of the DORA metrics. How often a team successfully releases to production. High-performing teams deploy on demand, multiple times per day. Low performers deploy monthly or less.
What this means for delivery
Low deployment frequency is often a signal of underlying problems: manual processes, fear of failure, large batch sizes, or weak test coverage. Each of these is a delivery conversation worth having.
A mechanism that allows code to be deployed to production but kept inactive until deliberately enabled. Features can be turned on for specific users, regions, or percentages of traffic.
What this means for delivery
Feature flags decouple deployment from release. A story can be 'done' in the technical sense (deployed) without being 'released' to users. This changes how you think about sprint goals and acceptance criteria.
The ability to understand what is happening inside a system from its external outputs. The three pillars are logs (what happened), metrics (how much / how fast), and traces (the path a request took).
What this means for delivery
Without observability, teams are flying blind in production. If your team cannot tell within minutes that something has broken, that is a delivery risk. Observability tooling is a legitimate backlog investment.
The accumulated cost of shortcuts, quick fixes, and deferred decisions in a codebase. Like financial debt, it accrues interest over time: the longer it is left unaddressed, the more it slows future development.
What this means for delivery
Technical debt is one of the most common causes of velocity decline in mature teams. Making it visible in the backlog and giving it a regular allocation of sprint capacity is a practical way to manage it.
A type of AI model trained on large amounts of text to understand and generate human language. Chat-GPT, Claude, Deepseek, Mistral and Gemini are all LLMs. They predict the most likely next token based on the input they receive.
What this means for delivery
LLMs are increasingly embedded in products your team builds. They introduce new acceptance criteria challenges: outputs are probabilistic, not deterministic, which means traditional pass/fail testing does not apply cleanly.
When an AI model generates a confident but factually incorrect response. The model is not lying; it is producing the statistically likely next token, which can sometimes be wrong or entirely fabricated.
What this means for delivery
Hallucination is not a bug that can be fixed with a patch. It is a fundamental characteristic of how LLMs work. Any feature that surfaces LLM output to users needs human review or confidence thresholds built into the acceptance criteria.
The practice of crafting inputs to an AI model to produce more accurate, consistent, or useful outputs. Prompt design is increasingly treated as a first-class engineering concern.
What this means for delivery
Changes to prompts are changes to system behaviour. They should be treated like code changes: versioned, tested, and reviewed. If your team is shipping AI features, prompt management belongs in your definition of done.
A technique that combines an LLM with a search or retrieval system. Instead of relying solely on what the model learned during training, RAG retrieves relevant documents at query time and provides them as context.
What this means for delivery
RAG is how teams ground LLM outputs in specific, up-to-date knowledge bases. It reduces hallucination on domain-specific queries. If your product uses RAG, the quality of the retrieval system is as important as the model itself.
A design pattern where a human reviews or approves AI outputs before they take effect. Used where errors are costly, outputs affect real people, or confidence thresholds are not yet high enough to automate fully.
What this means for delivery
Human-in-the-loop is not a temporary measure while AI matures. For many use cases it is the appropriate permanent design. Scrum Masters should ask: what is the human review process, and is it accounted for in capacity planning?
Training is the process of teaching an AI model using large datasets. It is expensive, slow, and usually happens before deployment. Inference is the process of using a trained model to generate outputs. This is what happens in production.
What this means for delivery
Most teams work at the inference layer: they use pre-trained models via APIs rather than training their own. Understanding this distinction helps you ask better questions about cost, latency, and vendor dependency.
The degradation of an AI model's performance over time as the real-world data it encounters diverges from the data it was trained on.
What this means for delivery
Unlike traditional software, AI systems can degrade gradually without any code change. Monitoring model performance in production is a non-negotiable operational requirement, not an optional enhancement.
Ready to go deeper?
Four free learning areas covering Cloud, Data, DevOps, and AI written specifically for Scrum Masters.
Start Learning Free