Glossary

The words we use, defined once. If a page in this Playbook uses a term differently, the page is wrong.

After action review. A review of what happened after a milestone, release or incident, with actions and owners. Learning, not blame.

Architectural decision record. A decision record for a choice that shapes a system's structure or technical direction.

Backlog item. An independently deployable, testable piece of work that delivers part of a feature. Usually touches one repository. Specified as scenarios.

Bug. A defect found in a production system, linked to the feature whose behaviour it breaks.

Candidate. A validated proposal awaiting prioritisation onto the roadmap.

Canonical objective document. The single source of truth for an objective: summary, problem statement, scope and out of scope, key results, stakeholders and outcomes. Owned by the Product Owner and maintained throughout delivery.

Decision record. A written record of a decision with lasting consequence: context, options, choice and who decided. See Decision records.

Decision-makers. The senior stakeholders who take viability decisions, prioritise the roadmap and approve significant changes of scope.

Delivery team. A cross-functional team that owns an objective from discovery to support.

Deployment. Any change to a production system, whether or not it affects users.

Deployment log. The record of every production change: what, when, who, and ideally why.

Design (work item). A tracked item for low-level design activity on a feature.

Discovery, Design, Implementation, Operation. The four phases of how we work. See Overview.

Engineering Owner. The person accountable for the technical design and implementation of an objective.

Feature. A tangible unit of value within an outcome that a non-technical stakeholder can understand. Has a definition of ready and of done.

Department leadership. The management team of the Technology department, which sponsors hackathons and hit squads and holds departmental decision authority.

Feature flag. Configuration that controls whether users can see a deployed capability. The usual way a deployment becomes a release.

First line. Customer Support, who receive, triage and resolve issues and own communication with whoever raised them.

Guardrail. A signal that prompts a conversation rather than a rule that blocks, such as the size of a change. See Autonomy and guardrails.

Hackathon, minihack. Two or three days, or one day, set aside to experiment and build something valuable together. See Hackathons.

Hit squad. A short-lived cross-team group formed to solve a well-defined ways-of-working problem.

Key result. A measurable indicator that an objective has succeeded.

Known error. An issue that is understood and has consciously been left unresolved for now, recorded with its impact, workaround and the reason.

Now, Next, Later. The three columns of the roadmap. Now is in active delivery; Next is ready to start; Later is agreed priority after that.

Objective. A validated, prioritised and committed piece of work on the roadmap, scoped to about three months or less.

Outcome. A measurable result an objective must deliver. Tracked on the outcome dashboard with a state of Design, Implementation, Operation or On hold.

Outcome specification. A versioned description of system behaviour from the user's perspective. The to-be version is the requirement during design; the as-is version is the user guide after release.

P1 to P4. Issue priority, from critical to low, derived from impact and urgency. A P1 stops other work until contained.

Product Owner. The person accountable for the product side of an objective, including its canonical document, requirements and user guides. Usually a product manager.

Proposal. A short, structured case for a piece of work, written before any commitment. Anyone can write one.

Roadmap. The Now, Next and Later view of objectives, about nine months ahead, with its companion outcome and release dashboards.

Root cause category. A tag applied to every resolved support issue saying why it happened, so that trends are visible.

Release. A change to a production system that affects one or more groups of users.

Release dashboard. The list of speculative, planned and completed releases that staff can subscribe to.

ROM (rough order of magnitude). An early indication of scale given before design, with its assumptions stated. Not an estimate, and never a commitment.

Security and reliability impact assessment. The assessment every architectural, design and scope decision record carries of its effect on security (threats, data, dependencies, access) and reliability (load, failure, recovery, observability).

Second line, third line. The engineering tiers of support: a rotating engineer with shadow support, then the delivery teams. First line is Customer Support.

Service desk. The three-line support model through which issues are raised, prioritised and resolved. See Operation and support.

Shadow engineer. The lead software engineer or test engineer on a weekly rota supporting the second line engineer.

Spike. A time-boxed technical investigation that answers a specific question and produces a written summary, sometimes a proof of concept.

Stretch outcome. An explicitly optional outcome delivered only if the core objective lands comfortably. Never extends the timeline.

Task. A discrete piece of work towards a backlog item. Effort is recorded against tasks.

Technology leadership. The head of engineering, the principal engineer and the department's senior technology leaders, who own architecture and standards.

Test plan. The output of designing a feature that says how each behaviour and quality attribute will be proved. Derived from the solution design and iterated with it, never written in hindsight.

User guide. The as-is version of an outcome specification.

Validation. The two time-boxed decisions, viability then feasibility, that turn a proposal into a candidate.