Glossary
The vocabulary this product uses, defined plainly. Opinionated where the distinction matters — several of these terms are only useful because of what they exclude.
- Demand
A work request that has entered the delivery lifecycle — the unit a delivery governance system tracks from intake to decision.
A demand is distinct from a task: a task is work to do, a demand is a request that has not yet earned a commitment. It carries the problem, the intended outcome, an owner, and the open questions that would change the answer.
The argument for this → Topic: Turning a request into a decision →
- FTE-month
One full-time person working for one month — a capacity unit that is comparable across teams and, where cost is recorded, is the multiplier a cost forecast would use.
Unlike story points, which are deliberately team-local and have no monetary meaning, FTE-months can be summed across teams and multiplied by a monthly cost. They are coarse on purpose: the granularity broadcasts its own error bar.
The argument for this → Topic: Capacity and what to measure →
- Vertical work
A delivery stream owned by a single team or discipline that produces end-to-end value within its own lane — frontend, backend, data, mobile, platform.
Verticals run in parallel with each other and consume capacity continuously, as a rate: this team, this fraction, these months.
- Horizontal work
A cross-cutting concern that pulses into several delivery streams at specific gates — security review, legal, compliance, design, accessibility, privacy.
A horizontal is rarely a standalone deliverable; its function is to gate other teams’ progress. Its load is driven by other people’s schedules, which is why several streams reaching the same gate in the same fortnight is the most predictable "surprise" bottleneck in delivery.
- Commitment exception
A recorded justification required to commit to work that is not yet decision-ready, naming why it is early, what is still unknown, who accepts the risk, and what condition would change the decision.
The point is not to prevent early commitments — real deadlines exist — but to make them countable. At quarter end you can then ask whether the misses came from early commitments or from a readiness bar that is set wrong.
- Allocation vs consumption
Allocation is what people are committed to; consumption is what they spent. Delivery governance measures allocation and deliberately does not measure consumption.
Allocation answers the questions a manager is accountable for and stays accurate when watched. Consumption — hours logged, per-person completion rates, velocity — stops being accurate the moment people know it is being read.
The argument for this → Topic: Capacity and what to measure →
- Clarification brief
A short artifact that separates what is known from what is assumed from what is still an open question, produced when a raw request is shaped into a demand.
The split matters because a request written in one confident voice makes an assumption indistinguishable from a fact, and every downstream estimate then inherits it. The assumptions list is also a risk register before you have one.
The argument for this → Topic: Turning a request into a decision →
- Readiness (three-state)
A planning dimension has three states, not two: not assessed, assessed and nothing found, and assessed with items.
Collapsing "assessed, nothing found" into "empty" makes an honest blank indistinguishable from a skipped step, so people invent dependencies and risks to look diligent. Invented entries are worse than blanks: they consume review attention and make the register look trustworthy when it is not.
- Delivery outcome
The explicit close of a commitment: what actually shipped, and — when the result is not a clean delivery — what differed from the promise.
Tracking means delivery is happening; the outcome means it is closed. A demand is only complete once the outcome is recorded and a lesson has been written.
- Delivery governance
The practice of deciding what to commit to — establishing value, ownership, capacity, dependencies and open questions before people, budget or a date are promised.
It is distinct from project management, which runs work already committed to, and from task tracking, which records work already planned. Most missed dates are decided at this layer, not during delivery.
- Decision-ready demand
A demand that can responsibly be committed to: the problem stated apart from the proposed solution, an intended outcome, a named owner, a first capacity figure, the dependencies, and the open questions written down as unknowns.
The point of the bar is where it sits — before the promise, not after. Most missed dates are decided at commitment time, when a request that had none of these became a promise anyway; readiness is checkable, optimism is not.
- Delivery path
The level of rigor a demand takes to commitment — fast-track, standard plan, strategic initiative, or urgent exception — chosen at the decision step, so a small contained demand is not forced through the ceremony a strategic one needs.
The path changes what commitment requires: a fast-track demand takes a light confirmation (owner, expected outcome, target); standard and strategic paths require an agreed capacity figure or a recorded exception; an urgent demand that is not ready ALWAYS requires the exception. One-size rigor fails in both directions — theatre for the small work, rubber-stamping for the large.
- RAG status
A traffic-light health signal on delivery — on track, at risk, off track — that is a judgement by the person accountable, not a computation, and is only worth reading when the reasoning comes with it.
Computed status invites gaming and hides the interesting part: what changed, and what decision or help is needed. A RAG check-in that carries those two sentences is a governance signal; a bare green light is decoration.
- Demand management
The practice of deciding what happens to requested work — shaping raw requests into decidable demands, refusing or parking some on the record, and committing the rest against real capacity.
It is distinct from intake, which collects requests, and from project management, which runs work already committed to. The test is exits: every request reaches a recorded outcome — planned, sent to a time-boxed discovery, parked with a review date, or declined with a reason — and none can simply be ignored in a queue.
The argument for this → Topic: Turning a request into a decision →
- Time-boxed discovery
A deliberate learning step taken instead of a decision: a goal, optionally the questions to answer, a time-box, and a target date on which it must conclude with recorded findings and an explicit decision.
The ending is what separates discovery from research. On the target date the demand is planned, re-decided with what was learned, parked, or declined — a reason is required to park or decline, and the findings stay on the record. A spike with no end date is not a smaller commitment; it is an unbounded one.
- Demand lifecycle
The path a work request takes from arrival to a closed outcome: Capture, Shape, Decide, Plan, Commit, Deliver, Learn — where a demand only walks the stages it needs.
The stages exist to place the expensive questions early: shaping before deciding, readiness before committing, an honest close before the lesson. A small demand can skip planning ceremony entirely; what no demand skips is the decision and the close.
- Intake
The arrival point where work requests enter an organisation, and the bar a request must clear there to become decidable: what needs to change, plus who is affected or why it matters now.
Intake collects; it does not decide — deciding is demand management. The common failure is over-building the door: category pickers, priority fields and sizing questions ask the requester to answer things that belong to a later stage, at the exact moment their patience is shortest. Two required questions and visible movement afterwards beat a twelve-field form.
The argument for this → Topic: Turning a request into a decision →
- Capacity planning
Establishing what each team can honestly promise for a period — gross FTE-months minus what is already spoken for — and committing demands against that line in priority order.
The two failures are planning against a gross number (holidays, support rotations and interruptions are not available capacity) and planning against an organisational total (capacity is per team; a spare month of mobile capacity does not build a backend service). The plan holds when each team's line is real and the demands walked down it stop at the line.
The argument for this → Topic: Capacity and what to measure →
- Capacity line
A team's honestly available capacity for a period, stated in FTE-months — the constraint that commitments are walked down against, in priority order, until it is spent.
The line is what converts a priority ordering into decisions. An ordering costs nothing — any number of items can be "P1" — but a line forces the next commitment to name what it displaces. Committing past the line is possible; what keeps the line real is that the overrun is made explicit and owned in the room, never absorbed silently.
The argument for this → Topic: Capacity and what to measure →
- Definition of ready
The bar a piece of work must clear before it is accepted — applied at ticket level in Scrum, and far more consequentially at commitment level, before people and a date are promised.
At commitment level the bar is six things: the problem stated apart from the proposed solution, an intended outcome, a named owner, a capacity figure from the delivering team, the dependencies, and the open questions written down as unknowns. Readiness is checkable; optimism is not — and a demand that cannot clear the bar can still be committed, but only with a recorded exception.
- Scope creep
The accumulation of unrecorded additions to a commitment's scope — each too small to renegotiate the promise, together large enough to break it.
The working defence is not vigilance; it is a dated out-of-scope list. An in-scope list describes an intention, but the explicit record of what you are NOT doing is what holds when someone asks for one more thing in week six — because the answer changes from "no" to "that was decided, and here is the reason".
- Triage
The decision about what happens next to each incoming request, with four recorded exits: plan it, run a time-boxed discovery, park it with a review date, or decline it with a reason.
The test for real triage is that a request cannot leave the step still undecided. What most teams run instead is sorting — a weekly meeting that re-orders the queue, assigns labels and decides nothing, so the same items return every week. Deciding is faster than sorting: a recorded park or decline never comes back next week; a sorted item always does.
The argument for this → Topic: Turning a request into a decision →
- Delivery roadmap
A time-ordered statement of what an organisation intends to deliver — a communication artifact that sequences intentions, distinct from the commitment record that says what was actually promised, by whom, against what capacity.
The two get conflated, and the conflation is expensive: a roadmap entry reads as a promise to whoever wants it to be one, while carrying none of a commitment's substance — no owner, no agreed capacity, no recorded unknowns. A roadmap is a useful summary OF commitments; it fails as a substitute for them, because when a date on it slips, nobody can reconstruct what was actually agreed.
- Backlog bankruptcy
The deliberate closure of an oversized backlog by finally making the decisions it contains — each item leaving as a recorded decline with a reason, a park with a review date, or a survivor someone will still argue for out loud.
It is not a purge. A mass delete teaches requesters nothing and the requests come back. A 400-item backlog is 400 unrecorded nos — requests refused in practice without anyone saying so — and bankruptcy converts them into decisions that exist on the record and stay made.
The argument for this → Topic: Turning a request into a decision →
- RAID log
A register of the four places delivery surprises come from — risks, assumptions, issues and dependencies — kept so each has demonstrably been looked at, not merely listed.
The categories are right; the usual ritual kills them. A standalone sheet filled at kickoff and reviewed monthly cannot distinguish "assessed, nothing found" from "nobody looked", so entries get invented to signal diligence. The working version attaches the four categories to the specific demand they belong to and makes assessed-and-empty a recordable answer.
- Readiness bar
The set of things a demand must have before it may be promised: the problem stated apart from the solution, an intended outcome, a named owner, a capacity figure from the delivering team, the dependencies, and the open questions written down.
The bar's power is its position — before the commitment, not after — and its honesty valve: it can be crossed early, but only with a recorded exception naming what is missing and who accepts the risk. A bar that cannot be crossed gets routed around; one that can be crossed silently is decoration.
- Honest close
Ending a commitment by comparison rather than checkbox: delivered as committed, delivered with named differences, or not delivered — the difference recorded in words whenever the result was not clean.
The close is what makes every earlier claim auditable: whether estimates run light, whether early commitments miss more often, what "high confidence" meant in practice. A "done" checkbox destroys exactly that data at the moment it is freshest.
- Shaping
Turning a raw request into something decidable: the problem stated apart from the proposed solution, the intended outcome, what is known versus assumed versus unknown, and a likely owner.
Shaping is not specification — it produces a decision input, not a build plan. A shaped demand can still be declined, and that is the point: the work of understanding happens while the requester still has the context, and before anyone's time is promised.
The argument for this → Topic: Turning a request into a decision →
- Slow maybe
A request that is never refused and never advanced — kept alive by silence, costing the requester repeated follow-ups and the team repeated re-reading, until it dies unrecorded.
The slow maybe feels kinder than a no and costs more relationship than one: the requester spends months on hope, learns the process cannot be trusted, and escalates next time. A recorded decline with a readable reason — or a park with a review date — is the respectful version.
The argument for this → Topic: Turning a request into a decision →
These definitions come from building DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.