Glossary

How to read this. Terms are grouped by stage rather than alphabetically: a word usually breaks where it does its work. The English form comes first because it is the canonical one — the form worth writing in documents unless the team has agreed otherwise.

01 — Requirements

Definition of Ready

The conditions a task meets before it can be taken into work. The list is shared across all of the team’s tasks and written down before anyone needs it.

No Russian rendering has taken hold: people say «дор» or «критерии готовности». The common substitution is to treat readiness as a matter of how much has been written. Readiness is about something else — whether the answers exist to the questions that would otherwise surface halfway through development.

Definition of Done

The conditions under which work counts as finished: code merged, tests passing, documentation updated — which of these applies is the team’s decision.

What separates it from acceptance criteria is scope of application. There is one DoD for every task; acceptance criteria belong to each task individually. When the DoD exists only in the team lead’s head, arguments about whether something is done are settled by seniority rather than by evidence.

Acceptance criteria

Checkable conditions for one specific task. They answer the question of how anyone will know the thing was built right.

A bad criterion gives itself away: it cannot be checked without asking its author. “Works correctly”, “convenient”, “fast” are intentions, not criteria. Fast means a number of milliseconds, on a stated volume of data.

Scope

What is inside the work. Russian documents say «объём», but speech declines the English word instead — «скоуп», «в скоупе», «выходит за скоуп».

Scope creep is expansion along the way without revisiting the estimate or the date. The sign of trouble is visible from the start: the boundary is described only from the inside. What is included is stated; what is excluded is not.

Stakeholder

Anyone whose interests the system touches. Russian borrows the word outright — «стейкхолдер» — and here the borrowing is more precise than a translation would be.

Substituting “client” is where it goes wrong: there is one client and several stakeholders, and their interests diverge. The standard example is a time-tracking system. The employee needs flexibility and as few mandatory fields as possible; the finance director needs every hour tied to a project and no edits after the fact. A requirement written from one of them surfaces at acceptance from the other.

User story

A requirement in the form “as a role, I want action, so that goal”.

By design it is a reminder of a conversation, not a specification. The part that gets dropped is the last one, the goal — and that is the part explaining why, and the part that lets someone propose a different solution.

02 — Analysis

Functional / non-functional requirement

A functional requirement says what the system does. A non-functional one says what property it has while doing it: response time, availability, load it withstands, how long data is kept.

The Russian calque «нефункциональные» misleads — it reads as “optional”. In practice these are simply missing from the spec and arrive as an incident a month after release.

Traceability

A followable link between a requirement, its implementation and its check.

Two questions test it. For any line of the spec: where is the code and where is the test. For any defect: which requirement it violates. Without this a change to a requirement does not become a change to a test, and the divergence is discovered in production.

Assumption

Something taken as true without checking, because checking is expensive, slow, or there is nobody to ask.

The danger is not the assumption but the unrecorded one. A recorded assumption is distinguishable from a fact and can be challenged; an unrecorded one reads as an established requirement a week later, including to the person who made it.

Business rule

A constraint of the domain that does not depend on the interface or on the system: a discount never exceeds half the amount, an unsigned contract has no force.

Rules outlive screens and migrate from system to system. The usual mistake is to describe a rule inside a scenario. It gets rewritten for the second scenario, and the two wordings drift apart.

Edge case

Behaviour at the boundary of a range: zero, empty, maximum, simultaneity, repetition, a negative value where nobody expected one.

Often conflated with a corner case, which is several boundaries meeting at once. The distinction is practical: edge cases can be enumerated in a list, combinations cannot, and have to be chosen by risk.

03 — Development

Refinement

Working through backlog items before they reach planning. Russian speech uses the transliteration «рефайнмент»; the older word was grooming.

The meeting exists almost everywhere; the work does not always happen in it. The sign of decay is that no new questions about the spec come up — only estimates. That means items are being taken as given rather than tested for readiness.

Technical debt

A decision taken knowingly for speed, with the intention of redoing it later.

“Knowingly” is the load-bearing word. Where there was no intention and the result is merely bad, that is a defect, not debt. The distinction is not terminological: debt is scheduled and repaid, a defect is fixed.

Blocker

A reason work cannot continue. Russian almost always uses the plural — «есть блокеры?» at the stand-up.

An analyst’s typical blocker is neither a developer nor code, but an answer not received from a party they have no direct access to: an adjacent team, an external vendor, the security office. That kind of blocker is invisible on the board and therefore does not get counted.

04 — Testing

Defect / bug / incident

English practice keeps three words apart. A bug is an error in code. A defect is behaviour diverging from a requirement. An incident is an event in production that reached users.

Russian has collapsed all three into «баг», and the collapse is expensive. When a divergence from a requirement is called a bug, nobody asks what the spec actually said — the item goes to development as a coding error, though the error was in the description.

Regression

The failure of something that used to work. Regression testing is the re-checking of previously working behaviour after a change.

A practical sign: if every release is followed by fixing something that was not in the release, either there is no regression suite or it does not cover the neighbouring areas.

UAT

User acceptance testing — checking, from the side of the client or the future users, whether the system solves their problem.

It almost always degenerates into a second round of functional testing, for one recurring reason: acceptance criteria were never written, so there is nothing to check except that everything is clickable.

05 — Deployment

Release / deploy

Not synonyms, though Russian speech treats them as one word. Deploy means the code has reached the server. Release means the functionality has reached the user.

A feature flag is what separates them: the code ships and stays silent, and is switched on by a separate decision. While the two words are merged, no conversation about staged rollout is possible — it is unclear which of the two events is being discussed.

Rollback

Returning the previous version.

It does not always work, and that is a question for the analyst rather than for deployment. A data migration applied during the deploy is not undone by rolling back code: the code returns, the data stays transformed. “Is this migration reversible” is a question asked at spec time and remembered on release night.

Feature flag

A switch that turns functionality on without a new deploy. It buys rollout to a share of users, and switching off without a rollback.

The price is branching behaviour. The system has as many states as there are combinations of live flags, and the spec has to describe behaviour with the flag off as well. A flag left on is a genre of incident in its own right.

Hotfix

A change made outside the usual cycle, because waiting is not an option.

The sign of a healthy process is that the hotfix makes it back into the spec after the fact. Where it does not, the next planned version overwrites it and the defect returns with the same cast.