The agile glossary

269 terms from agile, lean, flow, product, platform and delivery governance — defined precisely rather than circularly. Where a term is routinely misused, the entry says so.

Back to the library

269 of 269 terms

A

A/B test: A controlled experiment in which users are randomly assigned to two or more variants and a predefined metric is compared between groups. Randomisation is what allows a causal claim, which is why it is the strongest routinely available evidence that a change helped.; It needs enough traffic to detect the effect you care about, a metric and a duration fixed in advance, and the discipline not to stop the moment the result looks good. Peeking repeatedly until significance appears manufactures results.; See
Acceptance criteria: The specific, testable conditions that must hold for a backlog item to be accepted, agreed between the Product Owner and the Developers before or during the work. They are item-specific, unlike the Definition of Done which applies to everything, and they describe observable behaviour rather than implementation.; Criteria written after the work, to match what was built, are documentation of a decision rather than a specification of one. Criteria that specify how to build it remove the discretion that made the team useful.; See
Acceptance test-driven development: Agreeing automated acceptance tests for a backlog item before implementation begins, written collaboratively by the people who understand the requirement, the implementation and the risks. The agreed tests become the definition of the item being complete, removing the interpretation gap between what was asked for and what was built.; It overlaps heavily with behaviour-driven development; the practical difference is emphasis, with ATDD focused on the acceptance criteria of a specific item rather than on a shared language for the domain.; See
Access control vulnerability: A defect in which a privileged function can be called by someone who should not be able to call it: a missing modifier, an uninitialised owner, a role granted too widely, or an upgrade path reachable without the intended authorisation. Because every function of a deployed contract is callable by anyone, an omitted check is immediately exploitable.; This is consistently among the most common causes of loss, and it is dull rather than clever — the usual root cause is a function nobody listed as privileged. Enumerate every state-changing entry point and state, in the tests, who may call it.; See
Agent: A design pattern in which a model is given a goal, a set of tools and the authority to decide its own sequence of steps, rather than following a path fixed by the application. The distinguishing feature is control flow: an agent chooses what to do next, where a pipeline has that decided in advance.; An agent is a design choice, not a capability tier or a mark of sophistication, and it is the right choice only when the sequence of steps genuinely cannot be determined in advance. Where the path is known, a fixed pipeline is cheaper, faster, testable and far easier to debug.; See
Agent loop: The cycle an agent runs: observe the current state, decide on an action, execute a tool, incorporate the result, and repeat until a stopping condition is met. Its behaviour is governed by the quality of the stopping condition, the step and cost limits, and what the loop is allowed to see between iterations.; Every loop needs a hard iteration cap, a spend cap and a defined failure exit, because the common pathology is not a wrong answer but an expensive one: the loop retries a failing step indefinitely, or oscillates between two states, and nobody notices until the bill arrives.; See
Agentic coding: Delegating a bounded task to a model that plans, edits multiple files, runs tests and iterates on its own output until a stated condition is met. Its value depends almost entirely on the quality of the stopping condition: a strong test suite, a type checker or an explicit property gives the loop something real to converge on.; Without a trustworthy verification signal, the loop converges on whatever makes the checks it can see turn green, which is not the same as the task being done. Delegate tasks with sharp success criteria, not tasks whose difficulty lies in deciding what success means.; See
Agile: An adjective describing an organisation or team that can change direction cheaply and quickly in response to new information, and that produces the evidence needed to know when to change. Agility is a property of a system of work, observable in how fast a decision can be reversed and how small a commitment can be made. It is not a method, a certification or a department.; Beware the noun. "Doing an agile", "the agile", and "our agile team" usually signal that a process has been adopted without any change to funding, architecture or decision rights, which are the things that actually determine agility.; See
Agile Manifesto: A short statement published in 2001 by seventeen software practitioners, consisting of four value statements and twelve supporting principles. Each value prefers one thing over another without discarding the second: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan. It describes preferences, not a method, and prescribes no roles, events or artefacts.; The Manifesto cannot be implemented, audited or certified. Any claim that an organisation is "compliant with the Manifesto" is a category error.; See
Agile release train: In SAFe, a long-lived virtual organisation of typically five to twelve teams, usually fifty to one hundred and twenty-five people, aligned to a common mission and a shared cadence, delivering on a fixed programme increment rhythm. The train has its own roles, backlog and planning event.; The size is justified by the number of dependencies that must be coordinated. If the architecture allowed teams to release independently, most of the train's coordination machinery would be unnecessary, which is the question worth asking before the train is formed.; See
AI pair programming: Working with a model that proposes code continuously while a person drives, reviews and accepts. The interaction resembles pairing in cadence but not in kind: the model has no stake in the outcome, no memory of yesterday's decision unless given it, and no ability to say that the task itself is a bad idea.; It does not substitute for human pairing, because it transfers no knowledge between people and raises no bus factor. A team that replaces pairing with assistance should expect knowledge silos to deepen rather than dissolve.; See
AI-assisted migration: Using generation to perform a large mechanical transformation — a framework upgrade, a language port, a pattern replacement — across a codebase. It works where the transformation is repetitive and verifiable, and it fails where the old system's behaviour was never characterised, because there is then nothing to check the new one against.; Characterisation tests come first, and the migration still proceeds in small integrated steps behind an abstraction. A machine-generated rewrite landed as one enormous change is the same bet as a hand-written one, taken faster and understood less.; See
Andon: A signal that any worker can raise to indicate a problem, which brings help immediately and, if the problem cannot be resolved, stops the line. Its purpose is to make defects visible at the moment they occur and to prevent defective work from being passed downstream. The software equivalent is a red build that halts new commits until it is fixed.; An andon nobody dares pull, or that produces blame rather than help, is worse than none: it makes stopping the line an act of career risk and teaches everyone to pass the defect along.; See
ANR: A platform-detected condition in which an application fails to respond to input for longer than the system tolerates, on Android surfaced as an application-not-responding event and on iOS as a hang or a watchdog termination. It is almost always blocking work on the main thread: disk access, a synchronous network call, an oversized database query or a lock held too long.; It is counted separately from crashes and is easy to miss entirely on a dashboard that reports only crash-free sessions, despite being at least as damaging to the user. Platform owners also use these rates in their own quality assessments of listed applications.; See
App store review: The gate through which a native application build must pass before a platform owner will distribute it. It is a discretionary review against the platform's own guidelines, performed by a third party on their schedule, and it can reject a build for reasons unrelated to whether the software works.; Review turnaround, fees and policy specifics are set by each vendor and change without notice, so treat any figure you have internalised as stale and check the current policy. What matters architecturally is the shape: an external, variable-latency approval sits between your pipeline and your users, and it cannot be automated away.; See
Architecture decision record: A short document, versioned alongside the code, capturing one significant decision: its context, the options considered, the decision taken, its status and its consequences. Records are immutable once accepted and are superseded rather than edited, so the history of reasoning survives even when the decision is reversed.; The value is in recording why, including the options rejected. A record that states only what was decided saves the reader nothing when the question returns eighteen months later with a new team.; See
Assumption mapping: Listing the assumptions on which an idea depends and plotting each by importance and by the strength of the evidence behind it. The assumptions that are both critical and unevidenced are the riskiest, and testing the riskiest one with the cheapest experiment that could disprove it — the riskiest assumption test — is the fastest way to avoid building the wrong thing.; The experiment must be able to fail. A test designed so that any result justifies continuing is a reassurance exercise, not evidence.; See
Asynchronous communication: Communication that does not require participants to be present at the same time: written proposals, recorded demonstrations, decision records, threaded discussion with an explicit deadline. Done well it is more inclusive and produces a durable record; done badly it introduces a full day of latency into every exchange.; Asynchronous work fails without explicit response expectations and a default decision. "No reply by Thursday means we proceed" is what turns a thread into a decision rather than a queue.; See
Attrition: The rate at which people leave a team or organisation. In delivery terms it is a capability measure as much as a staffing one: every departure removes domain knowledge that is rarely written down, and the replacement takes months to reach the same effectiveness.; Sustained high attrition in one team is a diagnosis of that team's conditions, not of the labour market. Team-level attrition, not organisation-level, is the number that tells you something actionable.; See
Audit: A time-boxed review of a specific commit by external security specialists, producing findings by severity and a record of what was and was not examined. It is one input to a security posture alongside internal review, invariant testing, monitoring and a rehearsed incident response.; An audit covers a commit, not a protocol: code changed afterwards is unreviewed, and an unresolved finding remains unresolved however good the summary looks in marketing. "Audited" on a landing page is not a security property, and no reputable report claims the absence of bugs.; See

B

Backend-for-frontend: A server-side layer dedicated to one client type, shaping and aggregating responses from downstream services to suit that client's specific needs. For mobile it is particularly valuable because it moves logic to a place that can be changed without a store review, and it lets a single endpoint serve several client versions with different expectations.; It is the principal tool for keeping old clients working, which is why ownership matters: a backend-for-frontend maintained by a separate team becomes a cross-team dependency on the critical path of every mobile change. It should belong to the team that owns the client.; See
Backlog refinement: The continuous activity of breaking down, clarifying, ordering and sizing Product Backlog items so that upcoming work is understood well enough to be selected. It is an activity, not a Scrum event, and has no prescribed timebox or format; the Scrum Guide suggests it should not consume more than a modest share of the team’s capacity.; Refinement run as a weekly two-hour estimation meeting is usually the most disliked hour in the calendar. Small, frequent conversations between the people who will build the item work better and cost less.; See
Batch size: The quantity of work transferred between stages or released at one time: the size of a story, a pull request, a release or a planning commitment. Small batches shorten feedback, reduce risk per release, lower variability and make problems cheap to diagnose, because fewer changes are in flight when something breaks. The economically optimal batch size balances transaction cost against holding cost.; Batch size is the most underrated lever in software delivery. Almost every argument for large batches is really an argument that transaction costs are high, which is a fixable engineering problem.; See
Behaviour-driven development: A practice, originated by Dan North, of specifying software through concrete examples of behaviour expressed in shared business language, typically in a given-when-then form, and using those examples to drive both conversation and automation. The point is the conversation between business, development and testing that produces the examples; the automation is the by-product.; Teams frequently adopt the tooling and skip the conversation, ending up with a slow, brittle test suite written in stilted English and read by nobody outside the team.; See
Blockchain: A replicated append-only ledger whose state is agreed by a consensus protocol among mutually distrusting participants, so that no single operator can unilaterally rewrite history. The property it buys is shared state without a trusted intermediary; the price is low throughput, high latency relative to a database, public visibility of data, and a deployment model in which changes are expensive and mistakes may be permanent.; If every participant already trusts one operator, a database is faster, cheaper and easier to fix. The engineering question is always whether the absence of a trusted party is a genuine constraint or a stated preference.; See
Blocker clustering: A technique for improving flow by recording every blocker with its cause and duration, then grouping the records to find which few causes account for most of the blocked time. It converts a stream of individually forgettable interruptions into an evidence base for systemic change, and typically shows that a small number of dependencies or approvals dominate.; This only works if blockers are recorded when they happen. Reconstructing them at the retrospective yields the memorable ones, not the expensive ones.; See
Blue-green deployment: Running two production environments, one live and one idle, deploying the new version to the idle environment, verifying it there, then switching traffic across. Rollback is a switch back, which makes recovery fast and predictable.; The hard part is never the traffic switch; it is the database. Schema changes must be made backward and forward compatible for the switch to be genuinely reversible.; See
BM25: A well-established ranking function for keyword retrieval that scores documents by term frequency, inverse document frequency and length normalisation. It is fast, cheap, interpretable, needs no model, and remains a strong baseline that many semantic systems fail to beat on precise queries.; Measure against it before adopting anything more complicated. A vector pipeline that cannot outperform BM25 on your own evaluation set is expensive infrastructure delivering a downgrade.; See
Bottleneck: The step in a system with the lowest capacity relative to demand, which therefore sets the throughput of the whole system. Work accumulates in front of it and downstream steps are starved behind it, so it is usually visible on a board or a cumulative flow diagram as the place where queues grow.; A bottleneck that is a person — the only database expert, the only approver — is a staffing and knowledge problem, not a scheduling one. Adding work to their queue faster does not help.; See
Bounded context: In domain-driven design, an explicit boundary within which a particular model and its vocabulary apply consistently. The same word may mean different things in two contexts, and the boundary is what allows each model to stay coherent rather than collapsing into one universal model that fits nobody.; Bounded contexts are the most defensible basis for service and team boundaries available, because they follow the language people already use. Boundaries drawn along technical layers instead guarantee that every feature crosses all of them.; See
Branch by abstraction: A technique for making a large change incrementally on the mainline: introduce an abstraction over the component being replaced, migrate callers to the abstraction, build the new implementation behind it, switch over, then remove the old implementation and, if appropriate, the abstraction. Each step is small, integrated and releasable.; It is the practical answer to "this change is too big for trunk-based development". It takes more discipline than a long-lived branch and far less time than the merge that branch eventually requires.; See
Burndown and burn-up charts: Two ways of plotting progress against remaining work. A burndown chart shows work remaining falling towards zero by a date; a burn-up chart plots completed work as a rising line against a separate line for total scope, so that scope changes are visible rather than hidden inside the slope.; Prefer the burn-up. On a burndown, scope added and work completed cancel out, so a team can be running flat out while the line stays level, and nobody can tell whether the problem is delivery or demand.; See
Bus factor: The number of people who would have to be unavailable before a piece of work or a system could no longer be maintained. A bus factor of one names a specific, common and entirely preventable operational risk.; Documentation raises it a little; pairing, rotation and ensemble work raise it a lot. The person who is the bus factor is usually also the bottleneck, and is usually exhausted.; See

C

Canary release: Releasing a change to a small subset of traffic or users first, monitoring the chosen health signals, and then either widening the rollout progressively or withdrawing it. It converts a binary release decision into a controlled experiment and bounds the blast radius of a fault to the canary population.; A canary without automated monitoring and an automated abort is just a slow release. Decide the signals and the thresholds before you start, not while the incident is running.; See
Capacity and utilisation: Capacity is how much work a team can take on in a period, best derived from its own recent completed throughput rather than from available hours. Utilisation is the proportion of available time that is occupied by work. The two are routinely confused, and planning to high utilisation is what converts a team with capacity into a team with queues.; Utilisation above roughly eighty per cent makes wait times rise sharply, so a fully allocated organisation is a slow one. Capacity figures built by summing individual hours and applying a productivity factor describe an availability spreadsheet, not a delivery system.; See
Capitalisation: The accounting treatment under which certain software development costs are recorded as an asset and depreciated over time, rather than expensed in the period incurred. The rules distinguish research and maintenance, which are expensed, from development of new capability, which may be capitalised, and the boundary depends on the applicable standard and the organisation's policy.; Capitalisation rules quietly shape behaviour: if only new features can be capitalised, refactoring and defect work become visibly expensive and get squeezed. This is an accounting policy question with real delivery consequences, and worth raising with finance rather than routing around.; See
CD3: A prioritisation calculation that divides an item’s cost of delay by its expected duration, so that work is sequenced by the rate at which it sheds economic loss rather than by its total value. Under the assumptions of the model it produces the sequence that minimises total cost of delay across the portfolio, which usually means doing urgent small items before valuable large ones.; CD3 is sensitive to duration estimates, so it rewards splitting work into genuinely smaller pieces — and punishes teams that game duration downward without changing the work.; See
Change acceptance cost: The full cost of taking a candidate change from existing to running safely in production: review, test execution, security and licence checks, integration, rollout, monitoring and the expected cost of the defects that get through. It is the number that actually governs delivery economics once generation is cheap, and it is mostly made of activities that no model performs.; Budgeting for generation while leaving acceptance cost unmeasured is how organisations buy a faster pen and wonder why the letter still takes a fortnight to post.; See
Change advisory board: A body that reviews and authorises proposed changes to production systems, drawn from ITIL practice, intended to assess risk and coordinate timing. It typically meets on a fixed schedule and assesses changes submitted in advance.; The DORA research found external approval bodies to be associated with slower delivery and no better stability, because reviewers lack the context to assess risk. Peer review, automated policy checks and progressive delivery provide stronger control with far lower latency, and satisfy the same regulatory intent when the evidence is generated by the pipeline.; See
Change failure rate: The proportion of deployments to production that result in degraded service and require immediate remediation such as a rollback, a fix forward or a patch. It is a stability measure, and the research consistently finds that high performers deploy far more often with a lower failure rate, not a higher one.; The definition of failure must be written down before the metric is used, or it will quietly narrow until the rate looks acceptable. Failures caught before production are not change failures; they are the pipeline working.; See
Chapter and guild: Terms from Spotify's 2012 description of its engineering organisation. A chapter is a functional grouping of people with the same skill working within an area, usually with a line manager who is also a practitioner; a guild is a voluntary, open interest group that crosses the whole organisation. Together they were the mechanism for professional development and consistency alongside autonomous delivery squads.; This was a snapshot of one company mid-evolution, not a model Spotify itself claims to still run. Copying the vocabulary without the trust, tooling and autonomy that surrounded it produces renamed departments.; See
Chunking: Splitting source documents into retrievable units before indexing. The size and boundaries determine what a retrieval hit actually contains: chunks too small lose the context that makes a passage meaningful, chunks too large dilute the embedding and waste context window on irrelevant text.; Chunking on a fixed character count is the most common silent defect in retrieval systems, because it cuts tables, code blocks and clauses in half. Split on document structure where it exists, and keep the heading path with the chunk.; See
Class of service: A policy that groups work items by their cost-of-delay profile and assigns each group different handling rules. Common classes are expedite, fixed date, standard and intangible, each with an agreed capacity allocation, WIP limit and pull policy. Making the classes explicit prevents every urgent-feeling item from being treated as an emergency.; If the expedite class has no hard limit, it will expand until it is the only class, at which point the system has no prioritisation policy at all.; See
Code freeze: A deliberate halt to changes on the branch that will be deployed, held from the start of an external review until deployment, so that the artefact reviewed is the artefact shipped. In an environment where deployment is effectively irreversible, the freeze is what makes the review evidence rather than an anecdote about an earlier version.; This is the one context where a freeze is sound engineering rather than a symptom of an inability to release safely, and it should be scoped tightly to the deployment artefact. A freeze that drifts into weeks of queued changes reintroduces every large-batch problem it was not meant to cause.; See
Cognitive load: The total mental effort a team must sustain to work effectively with everything it owns: the domains, the systems, the tools and the interactions. Team Topologies argues that a team's responsibilities should be bounded by the cognitive load it can carry, and that exceeding it produces shallow understanding, slow change and defects.; Cognitive load is usually increased by accident — one more service, one more legacy system, one more integration — and never subtracted. Ask what a team will stop owning before adding to its remit.; See
Cold start time: The elapsed time from launching an application with no existing process to the first frame the user can interact with. It is the most visible performance figure a mobile application has, it correlates strongly with abandonment, and it is dominated by work done eagerly at startup — initialising libraries, reading configuration, restoring state, blocking on the network.; Measure it on the oldest hardware you still support and on a cold file cache, not on a recent developer device with everything warm. The percentiles are the story: a good median with a poor ninety-fifth percentile means a substantial group of users experiences a different product.; See
Communities of practice: Voluntary cross-team groups formed around a shared craft — testing, security, design, a technology — that maintain standards, share what has been learned and develop people. They provide the functional depth that cross-functional delivery teams cannot maintain internally, without reintroducing functional silos into delivery.; Communities need time, a purpose and a sponsor. Mandated attendance with no agenda kills them faster than neglect.; See
Complex and complicated domains: In the complicated domain, cause and effect are knowable in advance by someone with sufficient expertise: analysis then action is the right sequence, and good practice exists. In the complex domain, cause and effect are only coherent in hindsight, so the right sequence is a safe-to-fail probe, then observation, then response. Most product development is complex; most infrastructure and compliance work is complicated.; The common error is treating complex work as merely complicated and responding to failure by demanding more upfront analysis, which raises cost without reducing uncertainty.; See
Complicated-subsystem team: A team owning a part of the system that requires deep specialist knowledge to change safely — a pricing engine, a video codec, a risk model — where the specialism genuinely cannot be spread across stream-aligned teams. It exists to reduce the cognitive load those teams would otherwise carry.; This is the rarest of the four types and the easiest to overuse, because every team believes its subsystem is complicated. The test is whether mastery genuinely requires years of specialist background, not whether the code is currently messy.; See
Conceptual integrity at volume: The problem of keeping one coherent set of ideas, names and patterns in a codebase when the rate of change rises faster than the rate at which humans form a shared mental model of it. Generated code is locally plausible and globally divergent by default: each change is reasonable on its own and the system slowly acquires three ways to do everything.; The defences are unglamorous and pre-existing: a ubiquitous language, recorded architectural decisions, a small number of enforced patterns, and someone whose job includes reading the whole thing. Volume does not create incoherence on its own; volume without a maintained model does.; See
Context window: The maximum number of tokens a model can attend to in one request, covering the system prompt, the conversation, any retrieved material, tool definitions and the generated output together. Exceeding it forces truncation or summarisation, both of which silently discard information the task may have depended on.; A large window is a capacity, not a strategy. Retrieval quality usually degrades as irrelevant material is added, so filling the window because it is available tends to make answers worse and requests more expensive at the same time.; See
Continuous delivery: Keeping software in a state where it could be released to production at any time, on demand, through an automated and repeatable pipeline. Every change proves its own releasability as it moves through the pipeline, so the decision to release becomes a business choice rather than a technical event.; Continuous delivery is about the ability to release, not the act. Its real test is whether releasing is boring, not whether it happens hourly.; See
Continuous deployment: Automatically releasing to production every change that passes the pipeline, with no manual gate. It is a strict superset of continuous delivery and demands strong automated verification, fast rollback, feature flags for incomplete work and good production observability.; The two terms are not interchangeable, and conflating them causes organisations to reject the far more broadly applicable discipline of continuous delivery because they are not ready for automatic release.; See
Continuous discovery: Teresa Torres's formulation of discovery as a continuous habit rather than a project: the trio of product manager, designer and engineer conducting customer touchpoints at least weekly, and using what they learn to update their view of the opportunity space and their next experiments.; The cadence is the mechanism. Quarterly research produces a report; weekly contact produces a changing mental model, which is the thing that actually affects decisions.; See
Continuous integration: The practice of every developer merging their work into the shared mainline at least daily, with an automated build and test suite verifying each integration. Its purpose is to keep the distance between any two people's code small, so that conflicts are trivial and defects are found within minutes of being introduced.; Running a build server against long-lived feature branches is not continuous integration, however the tool is labelled. If the mainline is not being integrated into daily, the integration problem has only been deferred and concentrated.; See
Conway's Law: Melvin Conway's 1968 observation that organisations which design systems are constrained to produce designs that copy the communication structures of those organisations. Interfaces form where teams must negotiate, and integration is hardest exactly where the organisation chart is thickest.; It is an observation, not advice, and it is remarkably robust. If the architecture you want does not match the organisation you have, one of the two will change, and it will not be the law.; See
Core hours: An agreed window during which everyone on a distributed team is available for synchronous contact, with the rest of the day free for focused or local work. The overlap window is the portion of the working day two sites genuinely share, and it is the scarce resource in distributed delivery, so it should be spent on the things that only work live.; Filling the overlap with status meetings is the classic error: it consumes the only time available for collaboration and leaves the decisions to be made asynchronously, which is exactly the wrong way round.; See
Cost of delay: The economic loss caused by a unit of delay in delivering a piece of work, expressed in money per unit of time. It combines the value that is not being earned while the work is late with any value that expires permanently, and it is the only quantity that allows the urgency of different items to be compared on one scale. Donald Reinertsen argues it is the single most useful number a product development organisation can estimate.; Estimating cost of delay to a rough order of magnitude changes prioritisation decisions; estimating it to two decimal places changes nothing and costs a fortnight. The point is the shape of the urgency profile, not the precision.; See
Crash-free session rate: The proportion of application sessions that complete without a crash, normally reported per release and per platform version. It is the primary stability signal governing a staged rollout, and it is read as a change against the preceding release rather than as an absolute figure.; The headline number hides the failures that matter: a crash concentrated on one device family, one locale or one migration path can be catastrophic for those users and invisible in the aggregate. Segment before concluding a release is healthy, and track handled errors and ANRs alongside it.; See
Cross-functional team: A team holding all the skills needed to take work from idea to running in production without depending on another team. Cross-functionality is a property of the team as a whole, not of each individual, and it is what makes a short delivery cadence possible at all.; The usual gaps are testing, operations, data and security. A team that is cross-functional for building but not for releasing has a boundary in the wrong place and will discover it at every release.; See
Cross-platform framework: A toolkit for building applications for several platforms from one codebase, trading some access to platform capability and some fidelity to native conventions for a large reduction in duplicated work. The decision is an organisational one as much as a technical one: it determines whether you staff one team or two, and how deep the platform expertise on them needs to run.; The shared-code proportion is high for ordinary screens and falls sharply at the edges — background execution, notifications, permissions, hardware access, accessibility — which is where the schedule risk concentrates. You still need people who understand each platform, particularly for store review and upgrade behaviour.; See
Cumulative flow diagram: A stacked area chart showing the cumulative count of items that have entered each workflow state over time. The vertical distance between two bands is the work in progress between those states, the horizontal distance is the approximate average time in them, and the slope of the top band is arrival rate while the slope of the bottom is throughput.; Widening bands mean a queue is growing; parallel bands mean a stable system. A CFD built on states that people update in batches on Friday afternoon shows the reporting habit, not the flow.; See
Cycle time: The elapsed time from when work starts on an item to when it is finished, measured in calendar time including every wait, weekend and holiday. The start and finish points must be defined explicitly for the number to mean anything, because moving them changes the figure without changing the system. It is best reported as a distribution with percentiles rather than as an average.; Cycle time is skewed, not normal: a few items take many times the median. Quoting the mean hides the long tail, which is precisely the part stakeholders care about.; See
Cynefin: A sense-making framework developed by Dave Snowden that sorts situations by the nature of the relationship between cause and effect: clear, complicated, complex, chaotic, and a central state of not knowing which applies. Each domain calls for a different decision approach, so the framework is used to choose a method rather than to classify work for its own sake. Its practical value in delivery is to stop teams applying analysis where they need experiments, and experiments where they need expertise.; Cynefin is not a maturity model and the domains are not ranked. Moving work from complex to complicated is a legitimate goal; pretending it has already moved is the usual failure.; See

D

Daily scrum: A fifteen-minute daily event for the Developers to inspect progress towards the Sprint Goal and adapt the Sprint Backlog, producing an actionable plan for the next working day. Its structure is entirely up to the Developers; the three questions often associated with it were removed from the Scrum Guide in 2020. Anyone may observe, but it is not a meeting held for observers.; The most common failure is the status round-robin addressed to a manager or Scrum Master. If the conversation would be unchanged with the goal removed from the wall, it is not a Daily Scrum.; See
Definition of done: The shared, explicit standard of quality that work must meet to be considered complete and releasable. It applies to every item, is owned by the Developers (subject to any wider organisational minimum), and typically covers testing, review, integration, security, accessibility, documentation and deployability. It exists to make "done" mean the same thing to everyone who hears it.; If "done" excludes anything that must happen before a user benefits, the excluded work becomes invisible inventory and the team will appear fast right up to the moment of release.; See
Definition of ready: An agreed checklist of conditions a backlog item should meet before a team commits to it in a Sprint, typically covering a clear outcome, acceptance criteria, known dependencies and a size the team can complete. It is not part of Scrum. Used as a heuristic during refinement it is harmless and sometimes useful.; Used as a gate it is corrosive: it creates a formal handover between whoever prepares items and whoever builds them, licenses the team to refuse work rather than collaborate on it, and reintroduces a mini-waterfall upstream of the Sprint.; See
Definition of workflow: The explicit, shared statement of how a team’s work flows: what counts as an item, where work starts and finishes for measurement, what each state means, the pull criteria and WIP limits for each state, the classes of service, and the service level expectation. It is the Kanban analogue of the Definition of Done for the process itself.; Without an agreed start and finish point, cycle time figures from two teams cannot be compared and neither can the same team’s figures from two quarters.; See
Dependency: A relationship in which one piece of work cannot proceed or complete without something from elsewhere: a person, a decision, a component, an environment, or an approval. Cross-team dependencies are the dominant source of delay at scale, because each one inserts a queue whose length is governed by the other team's priorities, not yours.; Dependencies grow roughly with the square of the number of teams that must coordinate, which is why coordinating them harder scales badly and removing them scales well. Count them, cluster them by cause, and treat the top causes as architecture and funding problems.; See
Deployment frequency: How often an organisation successfully releases changes to production. It is a proxy for batch size: frequent deployment is only possible when each change is small, automated and independently releasable, so the number describes the health of the whole pipeline rather than the enthusiasm of the team.; Deploying to a staging environment does not count, and neither does a deployment behind a flag that nobody enables if the change never reaches a user. Be explicit about which you are counting.; See
Descaling: Reducing the coordination load of an organisation rather than managing it: splitting products, decoupling architecture, removing handover functions, shrinking the number of teams that must move together, and pushing decisions to the people doing the work. It treats the need for a scaling framework as a symptom to be diagnosed rather than a requirement to be met.; Ask what a scaling framework is coordinating before adopting one. Much of the coordination in large organisations exists to manage dependencies that the organisation itself created and could remove more cheaply.; See
Design sprint: A structured five-day process, developed at Google Ventures, that takes a team from a framed problem through sketching, deciding and prototyping to testing with five users by the Friday. Its value is compressing months of debate into a week by forcing a decision and putting a prototype in front of real users at the end of it.; It is an intervention for a specific big question, not a repeatable delivery cadence. Running design sprints back to back exhausts the team and starves delivery.; See
Developers: In Scrum, everyone on the Scrum Team who is committed to creating any aspect of a usable increment each Sprint, regardless of discipline. Testers, designers, analysts, data engineers and writers are Developers in this sense. They are accountable for creating the Sprint plan, instilling quality through the Definition of Done, adapting their plan daily, and holding each other accountable as professionals.; The word is a deliberate flattening, not a claim that everyone writes code. Reading it narrowly recreates the specialist silos the single term was chosen to remove.; See
Device farm: A pool of real physical devices, hosted locally or by a provider, against which automated tests and manual checks are run across the supported matrix. Emulators cover logic adequately; real hardware is what surfaces vendor customisations, thermal and memory limits, camera and sensor behaviour, and genuine startup timings.; Device time is a constrained resource, so run the full matrix on the release candidate and a representative subset per commit, rather than making every developer wait for a queue. Choose the subset from your own adoption data and refresh it when the data moves.; See
Device fragmentation: The spread of hardware capability, screen geometry, operating-system version and vendor customisation across the devices a product must support. It determines the real test matrix, and it means a build verified on current flagship hardware has been verified against a small and unrepresentative corner of the installed base.; Choose the support boundary from your own analytics rather than from market share reports, and revisit it on a schedule. Each retained version and device family carries an ongoing cost in testing, workarounds and conditional code that is rarely accounted for when the decision is made.; See
Disciplined Agile: A toolkit originated by Scott Ambler and Mark Lines, now stewarded by the Project Management Institute, that catalogues process goals and the decision points within them, offering options and trade-offs rather than a prescribed process. Teams assemble a way of working suited to their context and evolve it deliberately.; Its breadth is a genuine strength for experienced practitioners and a genuine obstacle for teams new to agile, who need a starting configuration rather than a menu of several hundred options.; See
Distillation: Training a smaller model to reproduce the behaviour of a larger one, using the larger model's outputs as the training signal. The result is cheaper and faster to serve and can approach the teacher on the narrow distribution it was distilled for, while giving up generality outside it.; Distilled models fail differently from their teachers, usually at the edges of the distribution they were trained on. Evaluate them on your own hard cases rather than trusting an aggregate similarity figure, and check the teacher model's terms of use before distilling from it.; See
Domain-driven design: Eric Evans's approach to complex software, centred on modelling the business domain in close collaboration with its experts and letting that model drive the design. Its strategic patterns — bounded contexts, context maps and the ubiquitous language — are the parts most relevant to organisation design, because they determine where the seams in a system should lie.; The tactical patterns are often adopted without the strategic ones, producing entities and repositories layered over a model nobody discussed with a domain expert. The conversation is the method; the patterns are its residue.; See
DORA metrics: Four measures of software delivery performance identified by the DevOps Research and Assessment programme and described in Accelerate: deployment frequency and lead time for changes, which describe throughput, and change failure rate and failed deployment recovery time, which describe stability. The research finding that matters is that throughput and stability rise together rather than trading off, because both are produced by the same underlying practices.; They measure the delivery system, not individuals or teams, and they say nothing about whether the software was worth building. Using them as a team scorecard reliably produces smaller, emptier deployments and reclassified incidents.; See
Drift: Change in a system's behaviour or in its measured quality over time without a corresponding change in its code. It arises from the supplier updating or deprecating a model, from the input distribution shifting as users find new uses, and from the underlying corpus or world moving away from what the prompts assume.; Drift is invisible without a harness run on a schedule rather than only on change. A system that was evaluated at launch and never since has an unknown current quality, whatever the launch report said.; See
Dual-track agile: Running discovery and delivery as two continuous parallel tracks within one team, with discovery feeding validated items into delivery and delivery feeding evidence back. It is a description of how one cross-functional team works, not an instruction to create a discovery team and a delivery team.; Split the tracks across two groups of people and you have recreated analysis and build phases with a backlog in between, complete with handovers and a requirements queue.; See

E

Embedding: A fixed-length numeric vector representing a piece of text, an image or another item, produced so that items with similar meaning lie close together under a distance measure. Embeddings are what make similarity search possible without keyword overlap.; Vectors from different models are not comparable, so changing the embedding model requires re-embedding the entire corpus. Budget for that migration before choosing one, and record which model produced each index.; See
Empiricism: Making decisions from what has been observed rather than from what was predicted. It rests on three conditions: the work and its results must be visible (transparency), they must be examined frequently against a goal (inspection), and the process or the plan must change when the examination warrants it (adaptation). Remove any one condition and the remaining two produce ceremony rather than control.; Inspection without the authority to adapt is reporting. Most failing agile adoptions have transparency and inspection in abundance and no mandate to change anything.; See
Enabling team: A team of specialists who help other teams acquire a missing capability — test automation, security practice, continuous delivery — and then deliberately withdraw. Its output is the increased capability of others, so it is measured by what the teams it helped can now do alone.; The withdrawal is the defining feature. An enabling team that becomes permanently embedded has turned into a dependency, and one that does the work rather than teaching it has guaranteed its own indefinite employment.; See
Epic: A large body of work that cannot be completed within a single sprint and will be broken into smaller items. The word describes a size relationship, not a level in a mandatory hierarchy; in SAFe it has a specific and much larger meaning as a portfolio-level initiative requiring a business case.; Epics that survive for years are not epics but programmes, and the sunk-cost reasoning they attract is the main reason bad initiatives outlive their evidence.; See
Evaluation harness: An automated, repeatable measurement of a system's behaviour on a fixed set of cases with defined scoring, run on every change to a prompt, a model, a retrieval configuration or a tool. It is the continuous integration of a probabilistic system: without it no change can be shown to be an improvement.; "We evaluated it" must mean a harness produced a score on a held-out set, not that someone tried a few prompts and was pleased. Eyeballing outputs is a smoke test; it cannot detect a two per cent regression, and two per cent is what most regressions look like.; See
EVM: The stack-based execution environment that defines how contract bytecode runs and how its costs are metered, and the de facto interface standard adopted by many chains beyond the one it was built for. Targeting it means a contract, its tooling and its auditors transfer across every chain that implements it.; Compatible does not mean identical. Chains differ in precompiles, opcode pricing, block timing and reorganisation behaviour, so a contract that is safe on one may not be on another and must be re-tested per target.; See

F

Failed deployment recovery time: How long it takes to restore service after a deployment causes a failure in production. It is the metric that makes frequent deployment safe: if recovery is fast and routine, the expected cost of a bad change is low, and the organisation can rationally choose to move quickly.; Optimising it by never deploying is the degenerate solution. Read it alongside deployment frequency, never on its own.; See
Feature flag: A runtime switch that determines whether a code path is active, allowing incomplete or risky work to be merged and deployed while remaining invisible to users. Flags separate deployment from release, which makes small frequent deployment compatible with coordinated feature launches, staged rollout and instant disabling of a bad change.; Flags are inventory with a carrying cost: each one doubles the number of code paths and every combination is a configuration nobody has tested. Give every flag an owner and a removal date, and delete it when the decision is made.; See
Feature team and component team: A feature team is cross-functional and cross-component, able to deliver an end-to-end customer-visible slice without waiting for anyone else. A component team owns one technical layer or module and delivers parts of features that other teams must assemble. Component teams optimise for local expertise and reuse; feature teams optimise for flow and reduce cross-team dependencies.; Component teams generate dependencies structurally, and adding coordination machinery to manage those dependencies is far more expensive than teaching feature teams to work in unfamiliar code. Where a component genuinely needs specialist stewardship, a platform or complicated-subsystem team is the better shape.; See
Finality: The point at which a transaction can no longer be reversed by a reorganisation of the chain. Some protocols provide deterministic finality after a defined interval; others provide probabilistic finality that strengthens with each subsequent block, so applications choose a confirmation depth appropriate to the value at risk.; Acting on a transaction the moment it appears in a block is the classic integration bug: the block can be replaced and the payment un-happen. Choose the confirmation depth by value, write it down, and apply it in the indexer as well as the user interface.; See
Fine-tuning: Continuing training on a curated set of examples to adjust a model's behaviour towards a particular format, style, domain or task. It changes how the model responds far more reliably than it adds facts, and it requires a dataset good enough that every example is one you would be content to see imitated.; Fine-tuning is the wrong tool for injecting knowledge that changes — that is retrieval's job — and it creates a model you now own and must re-evaluate, re-tune and migrate whenever the base changes. Exhaust prompting and retrieval first.; See
Fixed price and time and materials: The two common commercial shapes. A fixed-price contract sets scope and price in advance, transferring delivery risk to the supplier, who prices that risk into the quote and defends the scope through change control. Time and materials pays for effort at agreed rates, leaving the client to direct the work and carry the risk, which requires the client to actually exercise that direction.; Neither is inherently more agile. Useful middle grounds exist — capped time and materials, target cost with shared pain and gain, or fixed price per increment — all of which fix the budget and cadence while allowing scope to flex.; See
Flow efficiency: The proportion of an item’s total elapsed time that was spent being actively worked on, rather than waiting. It is calculated as touch time divided by total cycle time and expressed as a percentage. Knowledge-work systems that have never measured it commonly find figures between five and twenty per cent.; Low flow efficiency means the improvement opportunity is in the waiting, not in the working. Pushing people to work faster in a system that is eighty-five per cent waiting is both futile and insulting.; See
Follow the sun: Arranging work across widely separated time zones so that it passes from one site to another as each working day ends, in the hope of continuous progress. It demands near-perfect written handover, clear ownership and genuinely separable work, and it adds a handover cost to every cycle.; It works for well-defined operational work such as incident response and rarely for development, where the handover cost usually exceeds the elapsed-time gain. Overlapping hours with shared ownership almost always outperforms it.; See
Forced upgrade: A mechanism by which an application checks a server-supplied minimum version and blocks use until the user updates. It is the only way to retire a client version on a defined timetable, and it is used when an older client is insecure, incompatible with the current back end, or generating unacceptable failures.; It is a blunt instrument that locks out anyone unable to update — an unsupported device, no storage, no connectivity — so it should be reserved for genuine incompatibility rather than for tidiness. Warn well in advance, and prefer a backend-for-frontend that keeps old clients working to a policy that ejects users.; See
Formal verification: Mathematically proving that a contract's bytecode or source satisfies a specification for all possible inputs, rather than sampling behaviour through tests. Where a proof succeeds it is far stronger evidence than any amount of testing, and the scope of what was proved is precisely the scope of what it covers.; A proof is only as good as its specification and its assumptions about the environment, so verified code with an incomplete spec can still be exploited exactly as written. Read what was proved before treating a verification report as assurance about the whole system.; See
Foundation model: A model trained broadly on unlabelled data at scale, intended to be adapted to many downstream tasks rather than built for one. The term describes the intended role in a supply chain — a general substrate others build on — rather than a level of capability or a modality.; Building on a foundation model is a supplier dependency with the usual consequences: version changes alter behaviour, availability is somebody else's problem, and your evaluation harness is the only thing that will tell you when the ground moved.; See
Frontier model: A loose label for the most capable general-purpose models available at a given moment, usually the largest and most expensive to serve. The set changes continuously and membership is a claim about the present state of a fast-moving field, not a stable property of a product.; Architectural decisions should not depend on today's capability ranking. Design so the model behind an interface can be swapped, and let the evaluation harness decide which one is in use rather than a procurement conversation held once.; See

G

Gas: The unit metering computation and storage in a transaction, paid for at a market price that varies with network demand. It bounds execution so that no transaction can run indefinitely, and it makes efficiency a direct, user-visible cost rather than an abstraction.; Gas turns ordinary design decisions into pricing decisions: a loop over an unbounded array is not slow, it is a denial-of-service vector once the array grows past what fits in a block. Bound every iteration that a caller can influence.; See
Gemba: The actual place where work is done, and by extension the practice of going there to observe it directly rather than relying on reports. A gemba walk is an observation and a set of questions, not an inspection or a review.; For knowledge work the gemba is the pull request, the ticket history, the support queue and the pairing session — not the status meeting where the work is described.; See
Generation cost: The cost of producing a candidate change — the compute, tooling and human prompting time required to obtain a diff that plausibly does the job. It is one component of the total cost of a change and, in an assisted workflow, usually the smallest one. Tracking it separately is what makes the size of the remaining components visible.; Generation cost is routinely quoted as though it were the cost of the change. A change that takes minutes to generate and a week to review, test, roll out and support did not cost minutes.; See
Golden dataset: A curated set of inputs with agreed expected outputs or grading criteria, used as the fixed reference for evaluation. It should be drawn from real traffic, weighted towards the cases that matter and the ones that have failed before, and versioned alongside the code.; A golden set that the team tunes against for months stops measuring generalisation and starts measuring memorisation. Keep a portion unseen, refresh it from production regularly, and add every incident as a new case.; See
Grounding: Constraining a model's output to material supplied in the request — retrieved documents, tool results, database rows — and requiring it to cite or quote what it used. The point is to make the claim checkable: a reader or a downstream check can follow the reference and confirm the source says what the answer says it does.; Supplying a source does not guarantee the answer came from it. Verify that cited spans actually support the claim, because a citation that is present but unsupportive is more dangerous than no citation at all.; See
Guardrails: Checks applied around a model rather than inside it: input filtering, output validation, schema enforcement, policy classifiers, permission limits on tools and confirmation steps for consequential actions. They are deterministic code enforcing the properties the application must hold whatever the model produces.; Instructions in a prompt are not guardrails, because the same channel that carries them can carry an instruction to disregard them. If a property matters, enforce it outside the model in code that a prompt cannot reach.; See

H

Hallucination: Output that is fluent, well-formed and confidently wrong: invented citations, plausible but non-existent functions, fabricated figures. It is not a malfunction to be patched out but a direct consequence of generating a likely continuation, which is why it appears most readily where the model is asked for specifics it was never reliably given.; Fluency and confidence carry no information about accuracy, so human spot-checking catches the implausible errors and misses the plausible ones. The engineering answer is grounding plus verification against a source, not instructing the model not to make things up.; See
Handover note: A written record passed with a piece of work when it changes hands across time zones, shifts or people: current state, what was tried, what is known, what is uncertain, the next intended step and where the artefacts are. It is what makes a handover a continuation rather than a restart.; Every handover loses information, so the cheapest improvement is usually fewer handovers rather than better notes. Where handovers are unavoidable, a standard template beats individual conscientiousness.; See
Hardware security module: A tamper-resistant device that generates and stores private keys and performs signing internally, so the key material never exists in the memory of a general-purpose machine. It bounds the damage from a compromised host to what can be signed while the device is available and authorised.; The device protects the key, not the intent: an operator who approves a malicious transaction on a screen they cannot fully read has signed it just as effectively. Pair it with independent verification of what is being signed and with a signing policy that requires more than one person.; See
Hybrid search: Running lexical and vector retrieval together and combining the result sets, commonly by reciprocal rank fusion or a weighted score, so that literal matches and semantic matches both reach the candidate pool. It is the pragmatic default for retrieval over real corpora because the two methods fail on different queries.; The fusion weights need tuning against your own query distribution, and the only way to tune them is a labelled set of queries with known good answers. Copying weights from a blog post is guessing with extra steps.; See

I

Immutability: The property that deployed bytecode at an address cannot be altered, so the code that runs tomorrow is the code that was deployed. It is what allows a counterparty to reason about a contract's behaviour without trusting its author, and it is the reason a defect cannot simply be patched.; Immutability is a property of the bytecode at an address, not of a system. A deployment behind an upgrade proxy is mutable by whoever holds the admin key, and describing that system as immutable is a material misstatement to its users, whatever the individual implementation contracts do.; See
Impediment: Anything that slows or stops the team from making progress towards its goal: a missing decision, an unavailable environment, a dependency, a skills gap, a policy. Impediments are raised in order to be removed, which means each needs an owner, an age and a route upward when it lies outside the team's control.; The impediments that matter most are usually organisational and chronic, so they are the ones teams stop raising. An impediment log with only trivial entries is evidence that the escalation route does not work.; See
Increment: A concrete, usable step towards the Product Goal that meets the Definition of Done and works with all prior increments. Multiple increments may be created within a Sprint and may be delivered before the Sprint ends; the Sprint Review is not a release gate. Work that does not meet the Definition of Done is not part of an increment and cannot be presented as progress.; An increment that requires a later hardening phase to become usable is not an increment. It is inventory with an optimistic label.; See
Indexer: A service that reads chain data and events and builds a queryable off-chain view for applications, because chains are not designed for the aggregate and historical queries interfaces need. It is a read-path dependency with its own availability, lag and correctness characteristics.; Indexers must handle reorganisations by unwinding and replaying, or they serve state that the chain no longer agrees with. Surface indexer lag in the interface: a user comparing your screen to a block explorer will notice before you do.; See
Inference: Running a trained model to produce an output for a given input. It is the operation that costs money in production, is measured in latency and tokens, and scales with traffic, in contrast to training, which is a one-off or periodic cost.; Inference cost and latency both grow with the amount of context supplied, so a design that stuffs everything available into every request is paying continuously for material the task did not need.; See
Information radiator: Alistair Cockburn's term for a display placed where people already are, showing current, meaningful information without anyone having to ask for it: a board, a build monitor, a burn-up, an impediment list. The contrast is an information refrigerator, where the data is available but only to those who go and open it.; A radiator that is out of date is worse than none, because it teaches people to distrust the wall. In distributed teams the same function must be served by a live artefact everyone actually opens, not by a dashboard nobody visits.; See
Integration: Bringing the work of several people or teams together into a single working whole, and demonstrating that it works. At scale, integration is where optimistic plans meet reality, and the longer it is deferred the more expensive and less predictable it becomes.; A separate integration phase, team or environment converts a continuous activity into a queue with an owner. If integration is only proven at the end of a programme increment, the programme has no idea where it stands until then.; See
Inter-rater agreement: The extent to which independent graders assign the same score to the same output, measured with a statistic that corrects for chance agreement. It sets the ceiling on how good any evaluation can be: a system cannot be measured more precisely than its graders agree.; Low agreement means the criteria are ambiguous, not that the graders are careless. Fix the rubric before blaming the model, and never compare model scores across a period in which the grading guidance changed.; See
Interaction modes: The three ways Team Topologies says two teams may interact. Collaboration means working closely together for a defined period to discover something, accepting high communication cost and blurred boundaries. X-as-a-service means one team consumes something the other provides with minimal interaction, which is efficient and requires a stable interface. Facilitating means one team helps the other learn, for a bounded time.; The mode should be chosen deliberately and reviewed: collaboration is for discovery and should end, and a pair of teams stuck in permanent collaboration is really one team with a reporting line between them.; See
Invariant: A property that must hold across every reachable state of a system regardless of what sequence of calls produced it: total supply equals the sum of balances, collateral never falls below the value it backs, no path allows a user to withdraw more than they deposited. Invariants are the specification that matters for contract security, because exploits are sequences that violate one.; Example-based tests check the paths you imagined; invariants are what let a fuzzer or a prover check the ones you did not. Write them before the implementation, in the language of value and authority rather than of functions.; See
Inverse Conway manoeuvre: Deliberately changing team structure and communication paths so that the system architecture you want becomes the one the organisation naturally produces. In practice this means drawing the target architecture, aligning team boundaries to its modules, and giving each team ownership of a module end to end.; It is slow and politically expensive, and it fails where teams are reorganised on paper while the code, the on-call rota and the release process stay shared.; See
Iterative vs incremental: Incremental means delivering a product in usable pieces, each adding to the last. Iterative means revisiting and reworking what was already delivered as understanding improves. They are independent: you can build incrementally with no iteration (each piece is final once shipped) or iterate on a prototype that is never released. Agile approaches deliberately combine both, so that feedback on an increment can change the increments that follow and the ones already built.; Teams that are purely incremental have no mechanism for being wrong. A plan divided into thirty fortnightly deliveries is still a plan, not empiricism.; See

J

Jailbreak: An input crafted to make a model produce output its training and system instructions were intended to prevent, typically through role-play framings, obfuscation or incremental escalation. It targets the model's own behavioural constraints rather than the surrounding application.; Jailbreaking and prompt injection are often conflated. A jailbreak is the user subverting the model's policy; an injection is a third party subverting the application through content the model reads. The first is a content-safety problem, the second a systems-security one.; See
Jobs to be done: A way of framing demand around the progress a customer is trying to make in a particular circumstance, rather than around the customer's demographic attributes. The associated research method looks for the situation, the motivation and the alternatives considered, which together explain why a product was hired or fired.; It is a lens, not a methodology, and there are competing schools with incompatible notation. Its main practical benefit is widening the competitive set to include the spreadsheet and doing nothing.; See

K

Kaizen: Continuous, incremental improvement carried out by the people doing the work, as an ordinary part of the work rather than a separate initiative. Its power comes from frequency and ownership: many small changes made by those closest to the problem, each observed for effect.; Improvement that is only permitted in a quarterly workshop run by a central team is not kaizen. Improvement that is never given capacity is a wish.; See
Kanban: A method for improving a service by managing the flow of work through it, drawn from lean manufacturing and adapted for knowledge work by David J. Anderson. Its practices are to visualise the work, limit work in progress, manage flow, make policies explicit, implement feedback loops, and improve collaboratively. It starts with what you do now and changes the system incrementally rather than imposing a new structure.; Kanban is not "Scrum without sprints" and a board with columns is not Kanban. Without explicit WIP limits and a policy for pulling work, you have a visualisation and no method.; See
Kanban board: A visual model of a service’s workflow in which columns represent the states work passes through and cards represent work items. Done well, the board shows the actual policy of the system: what each state means, when an item may be pulled, how many items each state may hold, and which items are blocked.; Boards drift into fiction fastest at the right-hand end, where items sit in "ready for release" for weeks. A column that nothing ever leaves is a queue you have stopped measuring.; See
Keeper: An off-chain actor that submits transactions to trigger on-chain actions which nothing on the chain can initiate by itself — liquidations, rebalances, settlements, expiries — usually in return for an incentive. Chains have no scheduler, so anything that must happen at a time requires someone to be paid to make it happen.; A protocol that depends on keepers must remain solvent when none appears, because the incentive can become uneconomic exactly when volatility makes the action most urgent. Model the case where nobody calls for an hour.; See
Key management: The generation, storage, use, rotation and recovery of the private keys that control deployment, upgrade, treasury and operational authority. In a system without an administrator who can reverse a transaction, key compromise is loss and key loss is loss, so the procedures around keys are as load-bearing as the contract code.; Rehearse the recovery, the rotation and the compromise response before they are needed, because an untested procedure is a plan rather than a control. A key held by one person on one device is a bus factor of one with a monetary value attached.; See
Kill switch: A remotely controlled flag that disables a feature, a code path or an entire screen in an installed application. It exists because rolling back a mobile release does not recall the binaries already installed, so the fastest available remediation is to turn the offending behaviour off from the server.; A kill switch that has never been exercised is a hypothesis. Test it in production on a real feature, confirm the fallback path is one users can actually live with, and define the behaviour when the configuration fetch itself fails.; See
Kingman's formula: An approximation for the average waiting time in a single-server queue, expressing it as the product of three factors: a utilisation term, a variability term and the service time itself. The utilisation term grows without bound as utilisation approaches one hundred per cent, so the last increments of busyness buy enormous amounts of delay. Reducing variability lowers wait time at any level of utilisation.; This is the formal answer to "why can we not run the team at full capacity?" Planning people to a hundred per cent allocation does not maximise output; it maximises queue time.; See
Knowledge cutoff: The point beyond which a model's training data does not extend, so anything later is unknown to it unless supplied in the request. It bounds what the model can know unaided, and it applies to library versions, APIs, prices, personnel and events alike.; Models often answer confidently about the period after their cutoff rather than declining, and they are unreliable narrators of their own cutoff. Anything time-sensitive must be retrieved and supplied, never asked for from memory.; See
KPI: A measure selected to indicate how well an ongoing activity is performing against expectation. KPIs monitor a steady state and are typically bounded by a threshold; objectives and key results describe a change to be achieved in a period. The two answer different questions and should not be merged.; A KPI that nobody would act on if it moved is a report line, not an indicator. Every KPI should have a named owner and a stated response to it going the wrong way.; See

L

Large language model: A model trained on very large quantities of text to predict continuations, and adapted afterwards to follow instructions and hold conversations. It produces a probability distribution over next tokens and samples from it, so the same input can yield different outputs and no output carries an inherent guarantee of correctness. Treat it as a component with a statistical failure mode, not as a lookup that occasionally errs.; The determinism engineers expect from a function is absent. Any design that assumes a fixed input produces a fixed output needs either a fixed sampling configuration or, more honestly, a verification step downstream.; See
Last responsible moment: The point beyond which delaying a decision eliminates an important option or makes it materially more expensive. The principle is to defer commitment until that moment, so the decision is taken with the most information available, and then to decide firmly. It requires knowing when the moment arrives, which means tracking the option being protected.; This is not a licence to procrastinate. A decision deferred past its last responsible moment is simply a decision taken badly, by default, and usually by whoever shouts loudest.; See
Layer 2 and rollup: A layer 2 is a system that executes transactions off the main chain while deriving its security from it. A rollup is the dominant form: it batches transactions, executes them elsewhere and posts the data and a correctness argument back to the base layer, either a fraud proof contested during a challenge window (optimistic) or a validity proof verified immediately (zero-knowledge).; The proof mechanism determines how long withdrawals take and what must be trusted in the meantime, which is an architectural constraint on your product, not a detail. Sequencer centralisation and its failure modes are a separate question that the security inheritance does not answer.; See
Lead time: The elapsed time from a customer request being made to it being satisfied. It includes all the time an item waits in the backlog before work begins, which cycle time excludes, so lead time is what the requester experiences and cycle time is what the team experiences.; Teams that report only cycle time can look excellent while requests age for months in the queue in front of them. Always report both, and say where each clock starts.; See
Lead time for changes: The time from code being committed to that code running successfully in production. It measures the delivery pipeline specifically, excluding the discovery, design and queueing that happen before a commit exists, and it is dominated in most organisations by waiting for approvals, environments and release windows rather than by build duration.; Do not confuse it with customer lead time. A four-hour change lead time is compatible with a nine-month wait from request to delivery, and executives who hear only the first number will draw the wrong conclusion.; See
LeSS: A scaling approach by Craig Larman and Bas Vodde that applies Scrum to multiple teams working on one product with a single Product Owner, one Product Backlog, one Definition of Done and one shared Sprint. It adds very little to Scrum and instead concentrates on removing organisational structures — separate component teams, project managers, handover functions — that make coordination necessary.; LeSS demands more organisational change than SAFe and provides fewer places to hide, which is why it is chosen less often and, where genuinely adopted, changes more.; See
Little's Law: A result from queueing theory stating that, for a stable system over a long enough interval, average work in progress equals average throughput multiplied by average cycle time. Rearranged, average cycle time equals work in progress divided by throughput: halve the work in progress at constant throughput and the average item finishes in half the time.; The law holds only under its assumptions, including a stable system where arrivals and departures balance and nothing is abandoned. Teams that dump work in and delete it later cannot use it as a forecast, only as an argument for lowering WIP.; See
LLM-as-judge: Using a model to score another model's output against a rubric, so that evaluation can cover open-ended responses where no exact match exists. It scales grading to volumes no human team could read, at the cost of introducing a second probabilistic component into the measurement itself.; Judges carry known biases — towards longer answers, towards their own style, towards the first option presented — and must themselves be validated against human labels before their scores are trusted. An unvalidated judge measures agreement with a model, not quality.; See

M

MEV and front-running: Maximal extractable value is the profit obtainable by choosing which transactions to include in a block and in what order. Front-running is the concrete practice of observing a pending transaction and placing one's own before it to profit from the effect, with the sandwich variant placing transactions both before and after.; The public mempool means user intent is visible before it executes, so this is an ordinary operating condition rather than an exotic attack. Slippage limits, deadlines, private submission and commit-reveal are design responses; assuming your users will not be targeted is not.; See
Microservices: An architectural style in which a system is composed of small services that are independently deployable, own their own data, and communicate over the network. Its principal benefit is deployment and team independence; its costs are distributed-systems complexity, operational overhead and eventual consistency.; Microservices are an organisational solution with a technical implementation, and they punish teams that lack mature automated delivery and observability. Splitting a system you do not understand produces a distributed version of the same confusion, with added latency.; See
Minimum marketable product: The smallest release that a customer would actually pay for or adopt, and that the organisation is willing to put its name to. A minimum marketable feature is the same idea at feature granularity: the smallest coherent slice that delivers value on its own. Unlike an MVP, the purpose is revenue or adoption rather than learning.; Distinguishing this from an MVP resolves most of the arguments about whether an MVP is allowed to be rough. They are different objects with different success criteria.; See
Mob programming: The whole team working on the same thing, at the same time, in the same space, with one person typing and the others directing. It maximises knowledge transfer and removes handovers and review queues entirely, at the cost of everyone's attention on one item. It is especially effective for the hardest or least understood work, and for onboarding.; Judge it by cycle time on the item and by how quickly the team stops depending on one expert, not by lines of code per person. The name "ensemble" is now widely preferred, since "mob" carries unfortunate connotations.; See
Model cascade: A routing arrangement in which a cheaper model attempts the request first and escalates to a more capable one only when a confidence signal, a validation check or a verifier says the first answer is inadequate. It reduces average cost while preserving quality on the hard tail, provided the escalation signal is trustworthy.; The cascade is only as good as its escalation trigger. If the cheap model is confidently wrong in the same cases where it is wrong at all, the cascade never escalates and you have bought a cheaper error.; See
Model routing: Directing each request to a model chosen by the characteristics of the request — difficulty, sensitivity, latency budget, language, required tools — rather than sending everything to one model. It lets a system buy capability only where a request needs it, and it keeps the application decoupled from any single supplier.; Routing requires the classifier's decisions to be evaluated like anything else, because a router that misclassifies hard requests as easy degrades quality invisibly. Log the routing decision with every request or you will not be able to explain a regression.; See
Money for nothing, change for free: A contract pattern associated with Jeff Sutherland, designed to align incentives in a fixed-price engagement. "Change for free" allows the client to swap items of equivalent size into the remaining backlog at no charge, provided the total size is unchanged; "money for nothing" allows the client to terminate early when enough value has been delivered, paying the supplier a share of the remaining contract value.; It only works where both parties trust the sizing and where the supplier genuinely benefits from early termination. Without the termination clause, change-for-free simply gives the client free flexibility and the supplier no reason to agree.; See
Monolith and modular monolith: A monolith is a system deployed as a single unit. A modular monolith keeps that single deployment while enforcing strict internal module boundaries with explicit interfaces and no shared internal state, so that modules could later be extracted if there is a reason to. The deployment shape and the internal structure are separate decisions, and it is the second that determines whether a system is maintainable.; The pejorative sense of monolith describes a system with no internal boundaries, not one with a single deployment. For most organisations a well-modularised monolith is the correct starting point, and services should be extracted only where a specific scaling or independence need justifies the operational cost.; See
Monte Carlo forecasting: Forecasting by simulation: sample repeatedly from the team's historical throughput or cycle time, run thousands of trials, and read the results as a distribution of completion dates with associated probabilities. The output is a statement such as "eighty-five per cent of simulations finish by 14 March", which is honest about uncertainty in a way a single date never is.; It requires only a count of completed items per period and assumes the near future resembles the recent past. If the team, the domain or the item sizes have just changed, the history is not a sample of the system you now have.; See
MoSCoW: A prioritisation technique from DSDM sorting requirements into must have, should have, could have and won't have this time. Its discipline comes from the rule that the musts should account for a minority of the effort in a timebox, leaving the shoulds and coulds as the contingency that protects the delivery date.; Without an effort cap on the must category, everything becomes a must and the technique becomes a list. It also gives no guidance on sequencing within a category, which is where most of the value in prioritisation actually lies.; See
Muda, muri, mura: The three categories of loss in the Toyota Production System. Muda is waste, work that consumes resources without adding value; muri is overburden, loading people or systems beyond sustainable capacity; mura is unevenness, variation in demand or flow that causes both of the others. They are causally linked: unevenness produces overburden, which produces waste.; Most organisations attack muda alone, hunting visible waste while leaving the unevenness that creates it untouched. Levelling demand usually removes more waste than any waste-elimination exercise.; See
Multisig and timelock: A multisig requires a threshold of independent keys to authorise a privileged action, so no single compromised key is sufficient. A timelock imposes a mandatory delay between an action being queued and being executable, so the action is publicly visible before it takes effect. Together they are the standard control over upgrade and treasury authority.; A multisig whose signers share a device, a custodian or an office defeats its own purpose, and a timelock is only a control if someone is watching the queue and can act within the window. The delay length should reflect how long it would actually take to organise a response.; See
MVP: In Eric Ries's formulation, the smallest thing you can build that generates validated learning about a business hypothesis with the least effort. An MVP is an experiment: it has a hypothesis, a metric and a decision attached to it, and it may not be a product at all.; The term is now routinely used to mean "version one with the features we ran out of time for", which is the opposite of the original meaning. If nobody can state what would be learned and what decision the result would change, it is not an MVP.; See

N

Nexus: Scrum.org's framework for three to nine Scrum Teams working from one Product Backlog on one product. It adds a Nexus Integration Team accountable for a usable integrated increment each Sprint, plus cross-team refinement, planning, a Nexus Daily Scrum and a Nexus Sprint Review, all aimed squarely at dependencies and integration.; The Nexus Integration Team is meant to coach teams into resolving integration problems themselves. Staffed as a permanent integration squad, it becomes the downstream queue it was designed to eliminate.; See
North star metric: A single measure that best captures the value customers receive from a product, chosen to align teams on an outcome rather than on their local outputs. It is normally paired with a small set of counter-metrics or input metrics so that improving it in a harmful way is visible.; Any single number can be pushed in isolation, and will be. The counter-metrics are not optional decoration; they are the thing that stops the north star becoming a target in Goodhart's sense.; See

O

Observability for LLM systems: Capturing enough per-request detail to reconstruct and explain any individual interaction: the resolved prompt, the retrieved context and its scores, the model and version, the sampling parameters, each tool call and result, the tokens consumed and the final output. Without the full trace, a production failure cannot be reproduced, because the input is not just the user's message.; Logging the request and response alone is insufficient, since the retrieved context is usually where the defect lives. Set the retention policy and the redaction rules deliberately, because these traces contain whatever the user typed.; See
Offline-first: Designing an application to work from local state by default, treating the network as an enhancement that synchronises rather than a precondition for use. It removes the spinner as the default experience on poor connections and makes the application usable on transport, in buildings and abroad.; The cost is conflict resolution, and it is a product decision rather than a technical one: someone must decide what happens when two devices changed the same thing and which side wins. Teams that adopt the pattern without answering that question ship silent data loss.; See
OKR: A goal-setting structure pairing a qualitative objective with a small number of measurable key results that indicate it has been achieved. Key results describe outcomes, not activities, and the structure is intended to give teams a clear direction while leaving the method of achieving it to them.; OKRs decay into a task list when key results describe deliverables ("launch the portal") rather than changes in the world, and they decay into theatre when they are tied to compensation, at which point every target will be set safely low.; See
On-chain and off-chain: On-chain means data or logic that lives in the ledger and is replicated, verifiable and expensive. Off-chain means everything else — indexers, relayers, front ends, oracles, storage — which is cheap, fast, private and unverifiable. The central design decision in most systems is which state must be on-chain to be trustworthy and which merely needs to be available.; Public chains have no confidentiality: anything written on-chain is visible to everyone, permanently, and encrypting it only defers the problem to key management. Personal data almost never belongs on-chain, and a hash that can be brute-forced from a small domain is not anonymisation.; See
Open-weight model: A model whose trained parameters are published and may be downloaded and run by others, typically under a licence with conditions. It permits self-hosting, offline operation, deep customisation and full control over where data goes, at the cost of carrying the serving, scaling and security burden yourself.; Open weights are not the same as open source: the training data, code and process are usually not published, and some licences restrict field of use. Read the licence before treating it as unrestricted.; See
Opportunity solution tree: A visual structure, created by Teresa Torres, that connects a desired outcome at the root to the customer opportunities that could produce it, the candidate solutions for each opportunity, and the experiments that would test each solution. It makes the reasoning from outcome to build decision explicit and comparable.; Its value is in forcing several opportunities to be considered before solutions are chosen. A tree with one opportunity and a list of pre-decided features is a roadmap drawn sideways.; See
Options thinking: Treating a plan as a portfolio of choices rather than a single committed path, and valuing arrangements that keep choices open where uncertainty is high. Small batches, modular architecture, feature flags and short contracts all buy optionality; large integrated commitments spend it. The discipline is to be explicit about what an option costs and what it is worth.; Options are not free. Keeping two implementations alive, or a flag in the codebase, carries a real carrying cost that must be paid down once the uncertainty resolves.; See
Oracle: A mechanism for bringing external data — a price, a rate, an event outcome, a random value — onto a chain, since a deterministic execution environment cannot reach out to fetch anything itself. The oracle is therefore a trusted component in an otherwise trust-minimised system, and its design determines what the system as a whole can be trusted for.; The oracle is usually the weakest link in a protocol that handles value, and its failure modes are staleness, a thin source, and a single reporter, not just outright compromise. Treat its data as adversarial input and design what happens when it is wrong or absent.; See
Oracle manipulation: An attack that moves the input a protocol reads rather than breaking the protocol's own logic — distorting a thin market that is used as a price source, or exploiting a source that can be moved within a single transaction. The contract then behaves exactly as designed on a value that is briefly false.; Reading a spot price from a single venue is the recurring mistake. Time-weighted values, multiple independent sources, sanity bounds and a circuit breaker on implausible moves are the standard mitigations, and the first design question is always how deep the market behind the number is.; See
Outcome vs output: An output is something the team produced: a feature, a release, a document. An outcome is a change in customer or organisational behaviour that results from it, such as a task completed more often or a support cost avoided. Outputs are easy to count and easy to commit to; outcomes are what the organisation is actually buying.; Roadmaps made of outputs are commitments to build regardless of evidence. The test is whether the team is allowed to hit the outcome by building less than was planned.; See

P

Pair programming: Two people working together at one workstation on the same problem, continuously reviewing, discussing and swapping roles. It substitutes continuous review for asynchronous code review, spreads knowledge of the codebase as it goes, and shortens the feedback loop on design decisions to seconds.; It is not two people doing one person's job: the relevant comparison is against the full cost of separate review, rework, defects and knowledge silos. It is also tiring, and works badly if imposed for a full working day without breaks or choice of partner.; See
Parameter-efficient fine-tuning: Fine-tuning that trains a small number of additional or modified parameters while leaving the base weights frozen, most commonly through low-rank adapters. It cuts the compute and storage required dramatically and allows many task-specific adapters to share one served base model.; The economics improve; the data problem does not. A cheap tuning run on a poorly curated dataset produces a cheap, confidently wrong model, and the adapter still has to be re-validated against every base model update.; See
Phased release: A platform-provided rollout that releases an update automatically to a growing share of users over a fixed number of days, with the developer able to pause it or release to everyone immediately. It is the store's managed variant of a staged rollout, with the schedule set by the platform rather than by the team.; The mechanism is vendor-operated and the specifics — the daily percentages, what a pause does, whether users can update manually anyway — are governed by each platform's current policy. Do not assume the two major platforms behave the same way, and re-check before relying on the detail.; See
PI planning: A recurring two-day event in SAFe where all the teams of an agile release train plan the next programme increment of roughly ten weeks together, negotiating objectives, surfacing dependencies on a programme board, and voting on confidence in the plan. Its real product is alignment and the visible map of cross-team dependencies.; The event is expensive — hundreds of people for two days each quarter — and worth it only while the dependency board is dense. If the same dependencies appear quarter after quarter, the money would be better spent changing the architecture that creates them.; See
Planning poker: A consensus estimation technique in which each participant privately selects a card from a roughly exponential scale, all cards are revealed simultaneously, and the outliers explain their reasoning before a re-estimate. The simultaneous reveal exists to prevent anchoring on the first or the loudest voice; the conversation between the reveals is the actual product.; The number is a by-product. A team that rushes to an average without hearing why the high and low estimates differed has discarded the only valuable part of the exercise.; See
Platform team: A team that provides internal services — deployment, data, identity, infrastructure — as a self-service product, so that stream-aligned teams can deliver without raising tickets or waiting. Its users are internal engineers, and its success measure is adoption and the delivery speed of its consumers.; If teams must open a request and wait, it is a shared services function wearing a platform badge. A platform that is mandated rather than chosen also loses the only reliable signal of whether it is any good.; See
Poka-yoke: Designing a process or device so that a particular error cannot be made, or is detected the instant it is made. In software this means type systems, schema validation, deployment pipelines that refuse untested artefacts, and irreversible actions that require an explicit, differently shaped confirmation.; Mistake-proofing is nearly always cheaper than training or vigilance. A checklist that relies on human attention is the weakest form and should be the last resort.; See
Product backlog: The single ordered list of everything known to be needed in the product, and the sole source of work for the Scrum Team. It is emergent: items are added, removed and reordered continuously as understanding changes, and only the near-term items need to be small and well understood. The Product Owner is accountable for its ordering.; A backlog that only grows is a landfill. If nothing has been deleted from it in six months, it is no longer a decision-making instrument and no one is reading past the first screen.; See
Product discovery: The work of deciding what to build: understanding the problem, the customer and the constraints well enough to identify a solution worth delivering. Marty Cagan frames it around four risks that must be addressed before committing to build — value, usability, feasibility and business viability.; Discovery is not a phase that precedes delivery, and it is not the Product Owner's private activity. Engineers and designers who join only at delivery will produce a feasible solution to a problem nobody validated.; See
Product operating model: The way an organisation is arranged to fund, staff, decide and measure product work: durable teams organised around customer problems, funded by outcome rather than by project, with decision rights held close to the evidence. It is the structural counterpart to product practice — without it, discovery and empowerment have nowhere to live.; Most failed agile transformations changed team process and left the operating model alone, so annual project funding kept dictating fixed scope to teams that had been asked to be empowered.; See
Product owner: The accountability for maximising the value of the product resulting from the work of the Scrum Team. It covers developing and communicating the Product Goal, creating and ordering Product Backlog items, and ensuring the backlog is transparent and understood. One person holds it, and the organisation must respect their decisions for the accountability to mean anything.; A Product Owner who cannot reorder the backlog without a steering committee is a backlog administrator. Splitting the role into a "business PO" and a "technical PO" reliably produces two queues and no owner.; See
Project vs product funding: Project funding allocates money to a defined scope for a defined period, forms a team around it and disbands the team at the end. Product funding allocates money to a durable team that owns an area and is steered by outcomes, with investment reviewed periodically rather than fixed in advance. The first optimises for predictability of spend against a plan; the second for the ability to change the plan.; This is the single most consequential structural choice in an agile operating model, and the one most often left untouched. Annual project funding with fixed scope makes empowered teams impossible no matter what the team process is called.; See
Prompt: The complete input supplied to a model for one inference: instructions, retrieved context, examples, conversation history and the immediate request. It is the entire interface to the model, which makes it a versioned artefact of the system rather than a piece of copy.; Prompts held in a spreadsheet, a wiki page or a product manager's notes are unversioned production code. Put them in the repository, review changes to them, and run the evaluation harness before shipping an edit.; See
Prompt engineering: The empirical practice of shaping inputs — instructions, worked examples, output format, decomposition into steps — to raise the reliability of a model on a given task. It is engineering only when changes are measured: a variant is proposed, run against a held-out set, and kept or discarded on the evidence.; Most of what circulates as prompt technique is folklore validated on a handful of anecdotes. Without a harness you cannot distinguish a genuine improvement from a change that happened to please you on three examples.; See
Prompt injection: An attack in which instructions are planted in content the model will process — a web page, a document, an email, a tool result — and are followed as though they came from the application or the user. It is the defining security problem of systems that combine untrusted input with privileged tools, because the model has no reliable way to separate data from instruction.; This is not solved by telling the model to ignore instructions in documents. Contain it architecturally: least-privilege tool access, human confirmation for consequential actions, and treating every model output derived from untrusted input as untrusted itself.; See
Property-based testing for contracts: Generating large numbers of randomised call sequences against a contract and asserting that stated invariants hold after every one, with the tooling shrinking any failing sequence to a minimal reproduction. It explores the state space that hand-written unit tests cannot, and it is the cheapest technique with a real chance of finding a novel exploit path.; It finds only the violations of the properties you wrote, so the investment goes into the invariants rather than the harness. Run campaigns long enough to matter, keep every shrunken counterexample as a permanent test, and record coverage of the state space rather than of the lines.; See
Prototype: A deliberately incomplete artefact built to answer a question: a sketch, a clickable flow, a fake back end or a throwaway implementation. Fidelity should be chosen to match the question, and everything not needed to answer it should be left out.; The commercial risk is the prototype that works well enough to be shipped. Build it in a way that makes promotion to production obviously unacceptable, or budget for rebuilding it.; See
Provenance of generated code: The recorded answer to how a change came to exist: which prompt or task produced it, which model and version, what context it was given, who reviewed it and against what evidence. Kept as pipeline metadata it supports incident analysis, licence and policy questions, and any later decision to regenerate rather than patch.; "The AI wrote it" transfers no accountability whatsoever. The person who merged the change owns the defect exactly as they would own a typo of their own, and provenance exists to explain a failure, never to allocate blame away from the team.; See
Proxy pattern: A deployment in which users interact with a stable proxy address that delegates execution to a separate implementation contract, allowing the implementation to be replaced while state and address persist. It converts an unfixable defect into a fixable one, and in doing so introduces an administrator who can change the rules.; The upgrade key is now the system's largest risk, and storage-layout collisions and uninitialised implementations are the classic failure modes of the pattern itself. Whoever holds upgrade rights, and under what delay and quorum, belongs in the user-facing documentation, not only in the code.; See
Psychological safety: Amy Edmondson's term for a shared belief that the team is safe for interpersonal risk-taking: that speaking up with a question, a concern, a mistake or a dissenting view will not lead to humiliation or punishment. It is a property of a group at a point in time, and it is what makes error reporting, honest estimation and genuine retrospectives possible.; It is not comfort, niceness or the absence of challenge; Edmondson pairs it explicitly with high standards. Teams that confuse the two become pleasant places where nothing difficult is said.; See
Pull system: A system in which new work enters only when the downstream capacity to take it becomes available, signalled by the completion of other work. The contrast is a push system, in which work is released according to a schedule or a forecast regardless of downstream state, so queues accumulate wherever capacity is tightest. Pull caps queues by construction; push merely hides them.; Assigning work to named individuals in advance is push, whatever the board looks like. The signal to start must come from free capacity, not from a plan or a manager.; See

Q

Quantisation: Representing model weights, and sometimes activations, at lower numeric precision to reduce memory footprint and increase serving speed. It is the standard technique for fitting a self-hosted model onto smaller hardware, and the quality loss is usually modest and task-dependent rather than uniform.; Degradation concentrates in long reasoning chains, precise arithmetic and strict format adherence, which are exactly the behaviours an aggregate benchmark averages away. Test a quantised model against your own structured-output and tool-calling cases before deploying it.; See
Queueing theory: The mathematics of waiting lines, describing how arrival rates, service rates and variability interact to produce delay. Its central lesson for delivery is that queue length, not working speed, dominates end-to-end time, and that delay rises non-linearly as utilisation approaches capacity. It explains why a team can be fully occupied and still slow.; Most improvement effort is spent making the work items faster to process. The queues in front of them usually account for the larger share of elapsed time and cost nothing to shorten except the willingness to start less.; See

R

RACI: A responsibility matrix assigning, for each activity, who is responsible for doing it, who is accountable for the outcome, who must be consulted before it happens and who is informed afterwards. Exactly one party should be accountable for any given item.; It clarifies existing responsibilities and cannot create clarity where the organisation genuinely has not decided. Long consulted lists are the usual failure: each name is a queue, and the matrix quietly becomes a delay schedule.; See
RAPID: A decision-rights framework from Bain assigning five roles for a decision: recommend, agree, perform, input and decide. Unlike a responsibility matrix, it is explicitly about who decides and who can block, which makes it useful where decisions stall rather than where tasks are unassigned.; Its value is separating the people with a veto from the people with an opinion. Naming the decider in advance is what prevents a decision being relitigated by whoever was unhappy with it.; See
Real options: The application of financial option theory to non-financial decisions: an option has a price, a value, and an expiry, and it should be exercised when the information gained from waiting no longer exceeds the cost of waiting. In delivery this reframes "decide later" as an explicit trade between the cost of holding the option open and the value of the information that arrives before expiry. Chris Matts and Olav Maassen popularised its use in software under the summary that options have value, options expire, and one should never commit early unless one knows why.; The framing only helps if the expiry date is real and known. Most teams can name the decision and not the date, which turns real options back into vague deferral.; See
Reentrancy: A vulnerability class in which an external call made partway through a function allows the callee to call back into the contract before the first invocation has finished updating its state, so the contract acts on stale values. The standard defences are to complete all state changes before making external calls, and to apply an explicit reentrancy guard.; It is not limited to a direct call back into the same function: cross-function and cross-contract variants act on shared state through a different entry point, and token standards with transfer callbacks reintroduce the hazard in ordinary-looking code.; See
Refactoring: Changing the internal structure of code without changing its external behaviour, in small verified steps supported by tests. It is a continuous activity performed as part of delivering features, exploiting the fact that a well-structured codebase is cheaper to change than a badly structured one.; A "refactoring sprint" is a rewrite with better public relations. If behaviour changes, it is not refactoring, and if there are no tests, it is editing and hoping.; See
Relayer: A service that submits a user's signed intent to the chain on their behalf and pays the transaction fee, so the user need not hold the native asset. It changes the product's onboarding substantially and inserts a party that can delay, reorder or decline to submit.; A relayer is a censorship and availability dependency, so there must be a documented path for a user to submit directly when it is unavailable. Replay protection on the signed intent is not optional.; See
Release train: A fixed-cadence release schedule in which a build is cut from the mainline on a set date and ships with whatever is complete, while unfinished work waits for the next departure. It converts an unpredictable external approval step into a regular, plannable event and removes the negotiation over whether a given feature can hold the release.; This is the client-release sense of the term and is unrelated to the agile release train of SAFe, which is a grouping of teams. The discipline that makes it work is that the train never waits: a feature that misses it must be flag-protected or absent, not rushed in.; See
Remote config: Server-controlled values fetched by an installed application to change its behaviour without shipping a new binary. It is the mobile answer to the store gate: because a code change takes a review cycle to reach users and older versions persist indefinitely, configuration is the only fast control surface an engineer has over an app already on a device.; Each key is a liability with a lifecycle, not a free option: it must have an owner, a removal date and a defined behaviour for clients that cannot fetch it. Mobile makes this worse than on the server, because a flag can only be removed once the versions that read it have fallen out of use, which can take a very long time.; See
Reranking: A second retrieval stage in which a more expensive model scores each candidate against the query directly and reorders the shortlist. Because it examines query and document together rather than comparing independent vectors, it is markedly more accurate than first-stage retrieval, and it is affordable only because the shortlist is short.; Reranking improves ordering and cannot recover a document the first stage never returned. Diagnose recall before precision: if the right answer is absent from the top hundred, no reranker will find it.; See
Retrieval-augmented generation: An architectural pattern in which relevant material is retrieved from a corpus at request time and placed in the prompt, so the model answers from supplied evidence rather than from parameters alone. It separates the knowledge, which can be updated cheaply, from the model, which cannot, and it makes answers attributable to a source.; RAG is a pattern, not a product category and not a feature you buy. Its quality is almost entirely the quality of the retrieval step — chunking, indexing, ranking, filtering — and teams that treat it as a component to install spend their time tuning prompts while the real defect is that the right document is never in the top results.; See
Review capacity: The volume of change a team can read, understand and take responsibility for in a period, without degrading the quality of the reading. It is bounded by human attention rather than by tooling, and it degrades sharply as the size and unfamiliarity of each diff increases. In an assisted workflow it is usually the real capacity figure for the team.; Review capacity is finite and largely fixed in the short term, so it should be managed like any other constrained resource: cap the work in progress feeding it, keep batches small, and refuse to measure the team on a generation rate it cannot absorb.; See
Review-to-merge ratio: The proportion of candidate changes that survive review and reach the mainline, together with the effort spent on the ones that do not. It exposes the waste in a high-generation workflow: a low ratio means the team is paying full review cost for work that is discarded, which is a specification problem rather than a reviewer problem.; Optimising the ratio upward by reviewing less carefully is the obvious degenerate solution, so read it alongside change failure rate. A rising merge rate with a rising failure rate means the gate has been loosened, not that the generation improved.; See
RFC: A written proposal circulated for comment before a significant change, describing the problem, the proposed approach, the alternatives and the trade-offs, with a stated period for responses and a named decider. It is a mechanism for gathering expertise asynchronously without making every stakeholder an approver.; An RFC process without a deadline and a decider becomes a consensus requirement, at which point proposals die of silence. Comment rights and veto rights must be distinguished explicitly.; See
Right-sizing: Splitting work so that each item is small enough to flow through the system within the team’s service level expectation, rather than estimating how long each item will take. The question changes from "how big is this?" to "is this small enough?", which is faster to answer and more reliably acted upon.; Right-sizing plus throughput forecasting makes story-point estimation redundant for most planning purposes, which is usually the real reason it meets resistance.; See
Rubric grading: Scoring an output against explicit, separately assessed criteria — factual accuracy, completeness, format, tone, safety — rather than as a single overall judgement. Decomposition makes disagreement locatable and tells you which dimension a change actually moved.; A rubric that two competent people apply to the same output and score differently is not yet a rubric. Calibrate it on a sample and rewrite the criteria until the scores converge, before using it at scale or handing it to a model.; See

S

SAFe: The most widely adopted scaling framework, created by Dean Leffingwell, combining Scrum, XP practices, lean product development and portfolio management into a prescriptive structure of teams, agile release trains, solution trains and portfolio governance. It supplies a large body of defined roles, events and artefacts, and a corresponding training and certification programme.; Its prescriptiveness is both the reason large organisations adopt it and the reason it so often lands as a renaming exercise: existing hierarchy maps neatly onto the new role names, quarterly planning replaces annual planning, and nothing about batch size, dependencies or engineering practice changes. Describing SAFe as agile, or its adoption as an agile transformation, is a claim that needs evidence in delivery data rather than in an implementation roadmap.; See
Sampling and temperature: Sampling is the procedure for choosing the next token from the model's output distribution; temperature and top-p are the parameters that control how much of that distribution is in play. Lower settings concentrate on the most likely continuations and produce more repeatable output; higher settings widen the range and produce more variation.; Temperature zero is not determinism. Batching, hardware, model versions and tie-breaking all introduce variation, so a system that requires identical output for identical input needs caching or a verification step, not a parameter setting.; See
Scrum: A lightweight framework for delivering product in complex domains, defined by Ken Schwaber and Jeff Sutherland in the Scrum Guide. It fixes one timebox (the Sprint), three accountabilities, five events and three artefacts, each artefact carrying a commitment, and leaves every technical and managerial practice to the team. The framework is deliberately incomplete: it makes dysfunction visible on a short cycle and supplies no cure for what it reveals.; Scrum is a container, not a delivery method. Adopting it without engineering practice produces the same output on a shorter reporting cycle, which teams experience as pressure rather than improvement.; See
Scrum master: The accountability for the effectiveness of the Scrum Team: establishing the framework as defined, coaching the team in self-management and cross-functionality, helping the Product Owner with backlog technique, removing impediments, and working with the wider organisation on the obstacles it creates. The Scrum Guide describes it as a true leadership accountability serving the team and the organisation.; A Scrum Master who assigns tasks, chases status, maintains the plan and reports to a steering group is a project manager with a different business card. The test is whether the team would still function if they were away for a fortnight.; See
Scrum of scrums: A coordination event in which representatives of several teams meet regularly to surface cross-team impediments, dependencies and integration risks, and to agree what to do about them. It works when the representatives are people doing the work and when the meeting produces decisions rather than reports.; Staffed by managers and run as a status round, it becomes a weekly reporting layer that adds delay to every cross-team decision it touches.; See
Scrum team: One Product Owner, one Scrum Master and the Developers: a single unit of typically ten or fewer people, with no sub-teams and no hierarchy, focused on one Product Goal at a time. It is cross-functional, holding every skill needed to create value each Sprint, and self-managing, deciding internally who does what, when and how.; If the team must raise a ticket to another team to release, test or provision, it is not cross-functional in the sense the framework assumes, and its Sprint boundary will not hold.; See
Scrum@Scale: Jeff Sutherland's scaling framework, built by extending the Scrum Team pattern recursively into two interlocking cycles: a Scrum of Scrums network for delivery and a Product Owner network for the what, joined at an executive action team and an executive meta-scrum. It is modular, letting an organisation scale only the components it needs.; The executive action team is the load-bearing part: it exists to remove organisational impediments. Without real authority in that group, the rest of the structure is a coordination layer with no ability to fix what it surfaces.; See
Segregation of duties: A control requiring that no single person can both initiate and authorise a sensitive action, so that error or fraud requires collusion. In software delivery it most often appears as a rule that the author of a change may not be the person who approves its release to production.; The requirement is for two pairs of eyes and an auditable record, not for a separate department. Peer-reviewed commits with an enforced automated pipeline satisfy it while preserving flow, provided the controls cannot be bypassed by the author.; See
Self-managing team: A team that decides internally who does what, when and how, within boundaries set by the organisation: the goal, the constraints, the standards and the resources. Self-management concerns the method of the work, not its direction or its funding.; Autonomy without clear boundaries is abandonment, and produces the anxious paralysis often mistaken for resistance. State explicitly what the team decides, what it is consulted on, and what is decided elsewhere.; See
Servant leadership: A leadership stance, named by Robert K. Greenleaf, in which the leader's first concern is the growth, capability and effectiveness of the people they serve, and authority is used primarily to remove obstacles and develop others. In delivery it looks like clearing impediments, building capability, protecting focus and holding the boundary around the team.; It is not the absence of leadership and does not mean doing whatever the team asks. A leader who will not hold a standard or give hard feedback is not serving the team, only avoiding discomfort.; See
Service level expectation: A forecast of how long an item of a given class will take, stated as a cycle time and a probability drawn from the team’s own historical distribution — for example, eighty-five per cent of standard items finish within nine days. It is an expectation set by measurement, not a target set by negotiation.; An SLE turned into a performance target will be met by splitting items differently rather than by flowing faster. Report it as a distribution, not as an average with a pass mark.; See
Set-based concurrent engineering: Developing several candidate solutions in parallel and narrowing the set as evidence arrives, rather than selecting one design early and refining it. Constraints eliminate candidates until one remains, which means the eventual choice is made with far more information and rarely has to be reversed. It originated in Toyota’s product development practice.; It looks wasteful on a spreadsheet because several options are funded at once. It is usually cheaper than the rework caused by committing early to the wrong architecture, but that comparison is never on the spreadsheet.; See
Shu-ha-ri: A model of skill acquisition borrowed from Japanese martial arts, describing three stages: shu, follow the form exactly; ha, break the form deliberately once you understand why it exists; ri, transcend the form and work from principle. It is used in agile coaching to argue that early prescriptive adherence to a framework is a teaching device rather than an end state.; It is frequently used to dismiss legitimate criticism ("you are only at shu"). Beginners can be right, and a team held at shu for three years has been trained in obedience, not in practice.; See
Slack: Deliberately unallocated capacity: time that is not committed to planned delivery. Slack absorbs variability, which shortens queues, and it is the only place where improvement work, learning, refactoring and responses to the unexpected can actually happen.; Slack is the first thing cut under pressure and the reason the pressure never ends. A plan with no slack has no capacity to absorb the surprise that is statistically certain to arrive.; See
Smart contract: A program deployed to a blockchain that executes deterministically as part of transaction processing, with its code and state visible to all participants. It is better understood as a public, adversarially exposed state machine holding value than as a contract: it runs exactly as written, for anyone who calls it, permanently.; There is no staging period in which a defect is merely embarrassing. A deployed contract is production from the first block, open to every participant simultaneously, which is why the discipline around changing one has more in common with firmware than with a web service.; See
SPACE framework: A framework by Nicole Forsgren and colleagues for measuring developer productivity across five dimensions: satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. Its central argument is that productivity is multidimensional and that any single metric will be gamed, so a measurement system should combine at least three dimensions and include at least one perceptual measure.; SPACE is a design guide for a measurement system, not a set of metrics to copy. An organisation that picks only activity counts from it has reproduced exactly the error the framework was written to prevent.; See
Specification-first development: Writing the executable specification — acceptance tests, properties, contracts, schemas — before generating an implementation, so that generated code is evaluated against an artefact the team authored rather than against a reviewer's impression. The specification becomes the durable asset and the implementation becomes comparatively disposable, which is the inversion that makes regeneration a cheap option.; This is the pre-existing discipline of acceptance test-driven development with the economics changed, not a new method. Where the specification is written after the generated code, to match it, the team has documented a guess rather than constrained one.; See
Spike: A timeboxed investigation whose output is knowledge rather than a shippable change: a prototype, a measurement, a proof of concept or an answer to a specific question. It exists to reduce uncertainty enough to make the next decision, and the timebox is what stops it becoming an open-ended research project.; Write down the question before starting and throw the code away afterwards. A spike whose output is quietly promoted to production is how unreviewed experiments become load-bearing.; See
Sprint: A fixed timebox of one month or less within which a usable increment is created, and the container for all other Scrum events. Its length is constant so that forecasting and inspection have a stable cadence; its goal is fixed once agreed, while the scope of the Sprint Backlog may be renegotiated with the Product Owner as work is understood. A new Sprint starts immediately after the previous one ends.; Changing Sprint length to fit a particular piece of work destroys comparability and is nearly always a sign that the work is not being sliced small enough.; See
Sprint backlog: The Sprint Goal, the Product Backlog items selected for the Sprint, and the plan for delivering them. It belongs to the Developers, who update it throughout the Sprint as they learn, and it is a real-time picture of the work they intend to do to meet the Goal. It is a plan, not a contract.; Managers who treat the Sprint Backlog as a fixed commitment convert a planning tool into a compliance instrument, after which teams pad it and it stops telling anyone the truth.; See
Sprint goal: The single objective a Sprint is intended to achieve, agreed during Sprint Planning and unchanged for the duration of the Sprint. It is the commitment attached to the Sprint Backlog, and it gives the Developers the discretion to alter scope in service of the objective. A good Sprint Goal states an outcome that a stakeholder would recognise as valuable, not a list of items.; "Finish the fourteen tickets we pulled in" is not a Sprint Goal. If the goal cannot survive the removal of any single backlog item, it is a scope summary wearing a goal’s clothes.; See
Sprint planning: The event that opens the Sprint, timeboxed to eight hours for a one-month Sprint and proportionally less for shorter ones. It answers three questions: why this Sprint is valuable (producing the Sprint Goal), what can be done, and how the chosen work will be done. The whole Scrum Team attends, and the Developers alone decide how much work to select.; Planning that consists of dividing a velocity number by an estimate is arithmetic, not planning. The output that matters is a goal the team believes in and a plan for the first day or two.; See
Sprint retrospective: The event closing the Sprint, in which the Scrum Team inspects how it worked — people, interactions, process, tools and Definition of Done — and identifies improvements. It is timeboxed to three hours for a one-month Sprint. At least one actionable improvement is normally taken into the next Sprint Backlog so that it competes for real capacity.; Retrospectives die when improvements are recorded but never scheduled, or when the only impediments raised are outside the team’s control and nobody carries them upward.; See
Sprint review: A working session at the end of the Sprint where the Scrum Team and stakeholders inspect the increment, discuss what changed in the environment, and adapt the Product Backlog together. It is timeboxed to four hours for a one-month Sprint. Its output is a revised backlog, not an approval.; A demonstration with a slide deck and a sign-off is not a Sprint Review. If the Product Backlog is unchanged when everyone leaves, the inspection produced no adaptation and the event was theatre.; See
Squad and tribe: In the same Spotify description, a squad is a small, cross-functional, self-organising team with end-to-end responsibility for an area of the product, and a tribe is a collection of related squads, deliberately capped at around one hundred people to limit coordination overhead. The arrangement was designed to maximise team autonomy while keeping alignment through shared mission and architecture.; The so-called Spotify model was a description, not a framework, and its authors have said repeatedly that it should not be copied. Adopting the names while keeping project funding, shared component teams and central release approval changes nothing but the vocabulary.; See
Staged rollout: Releasing a new build to a controlled and increasing fraction of the user base, monitoring stability and business signals at each stage, and halting or reverting the rollout before it reaches everyone if the signals degrade. It is the mobile form of progressive delivery and the principal defence against a bad build, given that the update itself cannot be withdrawn from devices that already have it.; Halting a rollout stops new installs and leaves the users who already updated on the broken version, so a halt is containment rather than a fix. Decide the halt thresholds before starting, and make sure someone is watching during the hours the rollout advances.; See
Statement of work: The contractual document defining what a supplier will deliver: scope, deliverables, acceptance, timelines, responsibilities and commercial terms. In an agile engagement it is best written to fix the cadence, the collaboration obligations, the definition of done and the acceptance mechanism, while allowing scope within a budget envelope to be reordered.; A statement of work that itemises fixed features by date converts every piece of learning into a change request. The more precisely the scope is specified up front, the more expensive being right later becomes.; See
Story point: A unit-free relative measure of the size of a backlog item, combining volume, complexity and uncertainty, and calibrated only against other items in the same team's backlog. Points are useful because relative comparison is cognitively easier and faster than absolute estimation in hours.; A point is not an hour, not a day and not a currency. The moment points are converted to time, compared across teams or used in a contract, they become a worse version of hours with extra ceremony, and most teams would do better to right-size and count items instead.; See
Stream-aligned team: In Team Topologies, a team aligned to a single valuable stream of work — a product, a service, a customer segment — and able to deliver changes to it without depending on other teams. It is the default and most common team type; the other three exist to reduce its cognitive load.; The stream must be narrow enough to fit in the team's heads. A team aligned to "everything the customer touches" is not stream-aligned, only overloaded.; See
Structured output: Requiring a model's response to conform to a schema, either by instruction or by constraining decoding so that only schema-valid tokens can be emitted. Constrained decoding guarantees the shape of the output, which removes an entire class of parsing failure from the integration.; Valid JSON is not correct JSON. Schema conformance says nothing about whether the field values are right, so the usual validation, range checks and business rules still apply to every field.; See
Swarming: Several people working together on a single item to finish it, rather than each starting something new. It is the natural consequence of a WIP limit being reached, and it trades a little individual efficiency for a large reduction in cycle time and handover cost.; Swarming is hard where work is personally assigned and where skills are narrow, which are exactly the conditions it is most needed to fix. Resistance to it is usually a symptom of specialisation, not of laziness.; See
System prompt: The instruction block supplied by the application rather than the end user, setting the role, constraints, tone, tool policy and refusal behaviour for the interaction. Models are trained to weight it more heavily than user turns, which makes it the primary place to express application policy.; Higher weighting is not a security boundary. Treat the system prompt as a strong default that a determined user or a poisoned document may still subvert, and enforce anything that genuinely matters outside the model.; See

T

T-shaped: A description of an individual with deep expertise in one discipline and enough working breadth across neighbouring ones to help outside their specialism. A team of T-shaped people can rebalance around whatever is currently blocking flow rather than waiting for the right specialist to be free.; Breadth grows through pairing and rotation, not through a training catalogue. It is also actively discouraged by any performance system that rewards only depth in a named discipline.; See
Takt time: The rate at which units must be completed to meet demand, calculated as available time divided by units of demand in that time. It originates in manufacturing, where demand is countable and units are identical, and is used to pace a line and size its stations.; It transfers badly to software, where work items are not interchangeable and demand is not a count. Where it is used sensibly in knowledge work, it is as a cadence for a repeating, standardised service, not as a target for feature delivery.; See
Team API: The explicit, published interface a team offers the rest of the organisation: what it owns, how to ask for something, how it prefers to be contacted, its service expectations, its roadmap and its current state. Making it explicit removes the ambient cost of everyone discovering the same things by asking.; Most interruption load is caused by an undocumented team API. Publishing it is cheap and usually reduces ad-hoc traffic within a fortnight.; See
Team topologies: Matthew Skelton and Manuel Pais's model for organisation design in technology, built on four team types — stream-aligned, platform, enabling and complicated-subsystem — and three interaction modes, with team cognitive load as the constraint that determines how responsibilities should be divided. Team structure is treated as a deliberately evolving design, not a fixed hierarchy.; The value is in limiting cognitive load and making interactions explicit. Relabelling existing teams with the four names, while leaving their responsibilities and dependencies untouched, achieves nothing.; See
Technical debt: Ward Cunningham's metaphor for the future cost incurred by shipping a design that is not quite right for the problem as currently understood. Like financial debt it carries interest, paid as slower change and higher defect rates, and like financial debt it can be a sound decision when taken deliberately and repaid promptly. The metaphor is about the gap between a design and current understanding, not about bad code.; Most of what is labelled technical debt is simply mess, taken on accidentally and never repaid. Calling it debt is useful only if someone can name what was borrowed, why, and when it will be repaid.; See
Test-driven development: A development cycle in which a failing test is written first, the simplest code that passes it is written next, and the design is then improved while the tests stay green. The tests are a design tool as much as a verification tool: code that is hard to test is usually code with poor dependencies, and the cycle surfaces that immediately.; TDD is a design discipline, not a testing policy, and the coverage it produces is a side effect. Writing the tests afterwards to satisfy a coverage gate gives you neither the design feedback nor much of the confidence.; See
Testnet and mainnet fork: A testnet is a separate network with valueless assets, used for integration testing and rehearsal. A mainnet fork is a local copy of live chain state at a chosen block, against which changes can be executed with real balances, real liquidity and real third-party contracts, without touching the live network.; Testnets diverge from production in liquidity, adversaries and the behaviour of external protocols, so they prove the plumbing and not the economics. Rehearse anything that touches value against a mainnet fork, and rehearse the rollback as well as the deployment.; See
Theme: A grouping of related work under a common purpose, used to communicate direction and to see how effort is distributed across areas of the product. A theme is a label applied across items rather than a container they must live inside, and it usually spans several epics.; Themes are for communication and portfolio visibility. Treating them as another layer of the backlog hierarchy adds administration without adding decisions.; See
Theory of constraints: A management approach developed by Eliyahu Goldratt holding that every system is limited by a small number of constraints, and that throughput improves only when the constraint improves. Its five focusing steps are to identify the constraint, exploit it, subordinate everything else to it, elevate it, and then repeat because the constraint will have moved.; Improvement anywhere other than the constraint is an illusion that shows up as extra inventory. Most local efficiency programmes are precisely this.; See
Throughput: The number of work items completed per unit of time, for example items per week. It is a count, not an estimate, which makes it the most tamper-resistant delivery measure a team has, and combined with right-sized items it is sufficient for probabilistic forecasting.; Throughput only forecasts well when items are of broadly similar size. If the team ships one epic and forty trivial fixes in a quarter, the count is arithmetically true and practically useless.; See
Throughput re-baselining: Deliberately discarding historical delivery data and rebuilding a forecast base after a change in the way work is produced. Probabilistic forecasting assumes the recent past is a sample of the present system; introducing assisted or agentic generation breaks that assumption, so the old history describes a system that no longer exists.; Re-baseline by collecting new history, not by multiplying the old figures by an expected uplift. An assumed productivity factor applied to last quarter's throughput is a wish with a decimal point.; See
Timebox: A fixed maximum duration for an activity, set in advance and not extended. The purpose is to convert an open-ended question into a bounded economic decision: when the box closes, you inspect what you have and decide what to do next rather than continuing by default. Scope, not the box, absorbs the variation.; A timebox that is routinely extended is a deadline being missed, and it teaches the team that the box means nothing. A timebox that ends early is finished, not failed.; See
Token: The unit a model actually reads and emits: a fragment of text, typically a common word or a piece of one, produced by a tokeniser specific to that model family. Cost, latency and context limits are all denominated in tokens, and the mapping from characters to tokens varies by language and by content type, with code and non-Latin scripts generally consuming more per character.; Estimating tokens from a word count is a rough heuristic that breaks on exactly the inputs that matter — logs, JSON, minified code, and languages other than English. Count with the tokeniser before building a budget on the number.; See
Token budget: An explicit allocation of the context window across the parts competing for it — system prompt, examples, conversation history, retrieved documents, tool definitions and room for the response — together with the policy for what is dropped when the allocation is exceeded. Making the budget explicit turns silent truncation into a designed trade-off.; The commonest production failure in retrieval systems is quiet eviction: history or retrieved context is trimmed to fit, the answer degrades, and nothing in the logs says why. Emit the budget breakdown with every trace.; See
Tool use and function calling: Supplying the model with declared operations it may request — a search, a calculation, a write to a system — so that it emits a structured call which the application executes and returns the result of. The model chooses and parameterises; the application decides whether to perform the action and with what authority.; The model is proposing, not acting, and the trust boundary sits in your code. Grant each tool the narrowest permissions the task needs, validate every argument as hostile input, and require explicit confirmation for anything irreversible.; See
Traceability and audit evidence: Traceability is the ability to link a change in production back through its release, its tests, its review and its approval to the requirement and the decision that authorised it. Audit evidence is the artefact that demonstrates a control operated as intended — not that a policy existed, but that it was applied to this change, on this date, by this person or system.; Evidence produced by the delivery pipeline as a by-product of doing the work is stronger, cheaper and more complete than evidence assembled retrospectively for an audit. The documents written specifically for auditors are the ones least likely to reflect what actually happened.; See
Transaction cost and holding cost: The two costs that determine optimal batch size. Transaction cost is the fixed overhead of processing a batch at all — regression testing, a release window, a change approval, a planning event — and falls per unit as batches grow. Holding cost is the cost of work sitting unfinished or unreleased, including delayed value, obsolescence and integration risk, and rises with batch size. Where the two curves cross is the economic batch size, and lowering transaction cost moves that point smaller.; Organisations respond to painful releases by releasing less often, which raises holding cost and makes each release riskier still. The only durable answer is to attack the transaction cost through automation.; See
Transaction cost collapse: The sharp fall in the fixed cost of producing a candidate change when generation is largely automated, which moves the economic batch size downward. Because optimal batch size sits where transaction cost and holding cost cross, cutting the cost of attempting a change makes smaller, more frequent, more speculative attempts rational where they previously were not. The lever only operates if the rest of the pipeline — review, test, release — falls in cost with it.; Cheap generation with unchanged review, approval and release costs does not collapse the transaction cost; it relocates it. The queue simply forms in front of whatever step still costs what it always did.; See
Trunk-based development: A branching model in which developers integrate small, frequent commits directly into a single mainline, using short-lived branches measured in hours where branches are used at all. It is a prerequisite for genuine continuous integration and is consistently associated in the DORA research with higher delivery performance.; The usual objection is code review. Short-lived branches with fast review, or pairing with direct commits, satisfy both; long-lived branches with a review queue satisfy neither.; See
Trusted test suite: A test suite whose green result is accepted as sufficient evidence to merge, because it is fast, deterministic, meaningfully covering, and has a known history of catching real regressions. Trust is an empirical property earned by the suite, not a policy declared about it, and it is the asset that makes high-volume machine-generated change safe to accept.; A flaky suite is worse than none: it trains everyone to re-run until green, which is precisely the behaviour that lets a generated defect through. Measure the suite's own false-positive and false-negative history before relying on it as a gate.; See

U

Ubiquitous language: A shared vocabulary for a bounded context, used identically by domain experts, developers, tests, documentation and the code itself. When the code uses the same words as the business, translation errors between requirement and implementation largely disappear.; Its enemy is the term that means two things in one system. When you find one, the usual fix is a context boundary rather than a longer definition.; See
Unit cost per request: The fully loaded cost of serving one user-facing interaction, including retries, escalations in a cascade, every step of an agent loop, retrieval, reranking and any evaluation run in line. It is the figure that determines whether a feature is viable at the volume it will actually receive.; Per-token pricing makes the cost look linear when agentic and retrieval-heavy designs make it anything but: one interaction can be many inferences. Measure cost per completed task, per user and per day, and set hard caps before launch rather than after the first surprising invoice.; See
Usability testing: Observing representative users attempting real tasks with a product or prototype, to find where the design fails them. It is a qualitative method: a handful of participants surfaces most serious usability problems, and the output is a list of specific failures rather than a statistic.; Asking people whether they like it is not usability testing. Give them a task, stay quiet, and record where they hesitate.; See
User story: A short placeholder for a conversation about a change, conventionally written from the perspective of the person who wants it: as a role, I want a capability, so that an outcome. Ron Jeffries described its three elements as card, conversation and confirmation — the written note, the discussion it provokes, and the agreed acceptance criteria that confirm it is done.; The template is not the point and is not compulsory. A backlog of rigidly formatted stories written by one person and handed to another is a requirements document with a costume on.; See

V

Value stream: The complete sequence of activities an organisation performs to take a customer request from idea to realised value, including every wait, handover and approval. Value stream mapping is the practice of drawing that sequence with process time and wait time recorded at each step, so that total lead time and flow efficiency become visible and the largest queues can be attacked first.; Map the stream that exists, not the one in the process documentation. The gap between the two is usually where the delay lives.; See
Vector search: Retrieval by embedding the query and returning the corpus items whose vectors are nearest to it. It finds material that is topically related without sharing vocabulary, which is its principal advantage over keyword matching, and at scale it uses approximate methods that trade a little recall for a great deal of speed.; It is weak exactly where keyword search is strong: product codes, error strings, names, acronyms and rare terms. Systems that use it alone fail on the precise, literal queries users type when they already know what they are looking for.; See
Velocity: The amount of work, usually measured in story points, that a particular team completes in a particular sprint. Its only legitimate use is as an input to that team's own short-range capacity forecast, and even then only as a range across several sprints. It is not mentioned in the current Scrum Guide.; Velocity is not productivity and cannot be compared between teams, because the unit is locally defined. Setting velocity targets, rewarding increases or reporting it upwards guarantees inflation: points per item drift upward, the chart rises, and nothing ships faster.; See
Verification bottleneck: The condition in which the constraint on delivery has moved from writing a change to establishing that the change is correct, safe and wanted. When generation becomes abundant, throughput is set by the rate at which candidate changes can be verified, so investment in tests, static analysis, staged rollout and observability buys more than investment in generation does.; Applying the theory of constraints honestly here is uncomfortable: improving generation speed once verification is the constraint produces only a larger queue of unmerged work and the sensation of being busier without shipping more.; See
Version adoption curve: The distribution of active users across released client versions over time, which shows how quickly a release reaches the installed base and how long an old version persists. Its shape is the single most important planning input in mobile: it determines when a server change can safely stop supporting an old client and when a configuration key can finally be deleted.; The tail is long and never reaches zero on its own, so every client release should be treated as something you will be supporting for a long time. Plan back-end compatibility against the curve you observe, not against the release you just shipped.; See

W

Westrum typology: Ron Westrum's classification of organisational cultures by how they handle information: pathological, where information is hoarded and messengers are shot; bureaucratic, where information follows the rules of the department; and generative, where information is actively sought and failure leads to enquiry. The DORA research found generative culture to be strongly associated with delivery performance.; Culture here is measured by how bad news travels, which is observable. Ask what happened to the last person who reported a serious problem early and you will have the classification.; See
WIP limit: An explicit cap on the number of items allowed in a state, a lane or a whole system at one time. Reaching the limit forbids starting new work, which forces the team to finish, swarm or surface the impediment that is holding items up. The limit is a tool for provoking conversations, not a target to be optimised.; A limit that is never reached is not doing anything, and a limit that is routinely overridden teaches the team that policies are decorative. Lower it until it hurts, then fix what hurts.; See
Work in progress: The number of work items that have been started and not yet finished. It is the inventory of a knowledge-work system, and because it appears directly in Little’s Law it is the single most powerful lever on cycle time that a team controls without changing anything else.; High WIP feels like productivity because everyone is busy. It is the main cause of long cycle times, stale context, merge pain and the sensation that nothing ever finishes.; See
Working agreement: The explicit agreements a team makes about how it will work together: core hours, how decisions are made, what pulling work means, response expectations, how disagreement is handled. A team charter is the broader companion document, usually adding purpose, stakeholders, boundaries and success measures. Both are written by the team, kept short, and revised when they stop matching reality.; Agreements written once at inception and never revisited become wall decoration. Review them when the team changes shape, and delete any clause nobody has referred to in three months.; See
WSJF: A sequencing heuristic that scores each item by its cost of delay divided by its job size, taking the highest score first. In SAFe, cost of delay is approximated by summing three relative scores — user and business value, time criticality, and risk reduction or opportunity enablement — and job size is a relative estimate.; The scale is usually applied without calibration, so it becomes a ritual that launders opinion into a number. It is only better than a conversation if everyone understands what the components mean and the numbers are revisited when reality moves.; See