# DeliverySheet

> DeliverySheet takes a vague work request from intake to a clear delivery
> decision — making the shape, owner, capacity, dependencies and open questions
> visible before anyone commits people, budget or a date. It is a delivery
> governance product for engineering and delivery managers, not a task tracker.
> Built for product and engineering organisations of roughly 50–1,000 people
> where requests arrive from many directions and one person has to decide what
> gets promised.

Built and supported by Tan Gravam (Amsterdam). Contact: tan.gravam@gravam.com

Last updated: 2026-10-11. The full quotable corpus — every essay's direct
answer, every glossary definition and the topic pillar syntheses, each with the
URL that carries it — is one fetch:
[llms-full.txt](https://www.deliverysheet.com/llms-full.txt)

## What it does

The product owns one line of seven stages: **Capture → Shape → Decide → Plan →
Commit → Deliver → Learn**. A demand only walks the stages it needs — a small
request takes a short path, a real initiative takes the long one.

- **Capture** — paste a Slack message, an email or a request; AI drafts a
  structured demand. Entering the lifecycle requires a stated need plus either an
  impact or a trigger, so genuinely empty requests do not become work items.
- **Shape** — the decision brief: the problem, the outcome, why it matters and
  a likely owner, drafted by AI for a person to confirm; what is known, assumed
  and still unknown is written by the person, with an AI suggestion per field
  on request.
- **Decide** — what happens next: plan it, run a time-boxed discovery, park
  it, or decline it.
- **Plan** — dependencies, decisions, capacity per craft, and risks. Each
  dimension can honestly be marked "none known", which is different from "not
  assessed".
- **Commit** — a recorded commitment. Committing a demand that is not ready
  requires an exception naming why it is early, what is missing, who accepts the
  risk, and what condition would change the decision.
- **Deliver** — delivery check-ins and an explicit outcome. Each check-in says
  where the work stands: what is happening now and who has it, what it is
  waiting on, and the next step with its owner and date (plus the next
  checkpoint); a next step past its date or with no owner is raised in Needs
  attention. The outcome records what shipped, and what differed from the
  promise when it is not a clean delivery. Open risks
  and blocked dependencies can be closed from the delivery view. An optional
  work-item table (exportable to CSV) makes overdue work visible without
  replacing the team's board.
- **Learn** — a short retrospective. A verdict alone does not close a demand; a
  written lesson is required.
- **Reports** — portfolio health, commitment ledger, risk register, committed
  effort, early commitments, and completed & learned, plus a one-click weekly
  status update to paste into Slack or a leadership deck.
- **One-pager** — a print-ready summary of any demand (problem, the outcome or
  committed outcome, scope in and out, owner, stakeholders, why now), copyable
  as text for people outside the workspace.
- **Weekly summary email (optional)** — off unless the workspace owner turns it
  on; sent only to the owner, only in weeks where something aged (a decision
  came due, a commitment went without a check-in, work stalled).
- **An example demand** — every new workspace starts with one clearly-labelled
  example, fully shaped, so the lifecycle can be seen before the first real
  request is pasted.

## What it deliberately does not do

These are design constraints, not missing features:

- No time tracking, timesheets or billable hours.
- No per-person performance metrics — no completion rates, velocity or delivery
  scores.
- No story points, sprints or burndown charts.
- No actual-cost or salary tracking, and today no cost figure of any kind: a
  commitment carries effort in FTE-months per team and no money figure is
  recorded or shown. A cost forecast (estimated cost x committed FTE-months) is
  the intended direction and is not built.
- No custom fields or configurable stages per organisation.
- No hard delete of work records — demands, people, teams and companies are
  deactivated or archived, never destroyed. (A workspace owner can permanently
  delete the whole workspace.)
- It does not yet replace Jira or Linear for day-to-day execution. It owns the
  decision, not the ticket queue.

## Key concepts

- **Demand** — a work request that has entered the lifecycle. The unit the
  product governs.
- **FTE-month** — one full-time person working for one month. The capacity unit,
  recorded per craft with a confidence level, comparable across teams.
- **Vertical work** — a delivery stream owned by one team producing end-to-end
  value in its lane (frontend, backend, data, mobile, platform). Consumes
  capacity continuously.
- **Horizontal work** — a cross-cutting concern that pulses into several
  verticals at gates (security, legal, compliance, design, accessibility,
  privacy). Consumes capacity in bursts and gates other people's progress.
- **Allocation vs consumption** — the product shows what people are committed to,
  never what they spent.
- **Commitment exception** — the recorded, four-field justification required to
  commit a demand that is not ready.

## Pricing

$189 per workspace per month, billed monthly via Stripe, tax-inclusive.
Unlimited members and unlimited demands — there is no per-seat pricing. A 7-day
free trial requires a card; no charge if cancelled before it ends. The trial is
available once per account and once per payment card. If a subscription lapses
the workspace becomes read-only — data is never deleted.

Sign-in is with a Google account (Workspace or personal) — currently the only method.

## Data and AI

Intake text is sent to the Anthropic API to draft structured fields. Anthropic
does not use API inputs and outputs to train its models by default. Under
Anthropic's standard API retention policy, inputs and outputs are automatically
deleted from its backend within 30 days, subject to Anthropic's stated
exceptions. All AI processing is server-side. Providers used: Supabase
(database and authentication, AWS us-east-1, Northern Virginia),
Hetzner Online (application hosting, Germany),
Google (OAuth sign-in and
analytics), Anthropic (AI processing), Resend (email we send you: the trial-ending
notice and the optional weekly summary), Stripe
(billing).

## Pages

- [Home](https://www.deliverysheet.com/): what the product does and who it is for
- [Pricing](https://www.deliverysheet.com/pricing): plan, FAQ, trial terms
- [Free templates](https://www.deliverysheet.com/templates): four CSV templates
  for engineering intake and delivery planning — a project request form, an
  FTE-month capacity plan, a decision log and a RAID log — each linked to the
  essay that explains how to use it; plus links to the scripts and checklists
  that live inside essays: seven emails for answering a request, a four-section
  status report, a change request checklist, a three-sentence lessons learned
  template and five emails for a project that is running late
- [Request or topic? A one-page guide to print](https://www.deliverysheet.com/request-or-topic):
  the three things a work request must say before anyone sizes it (the need,
  the impact, why now), the rule (the need plus one of the other two), the
  question to send back for each missing part, and two stamped examples
- [Desk cartoons for engineering managers](https://www.deliverysheet.com/cartoons):
  single-panel cartoons (a one-word request, an estimate carved in stone, a
  date before the plan, five first priorities, "later" since March, ten
  projects started, a green status beside a fire), each linked to the essay
  that argues the point; three have a blank a visitor can fill with their own
  word, and each can be downloaded as an image
- [Request or topic? (a two-minute game)](https://www.deliverysheet.com/spot-the-request):
  eight example work requests; the visitor decides which could be decided on as
  written and which should go back with a question. Fixed examples, no AI, nothing
  stored. Teaches the capture rule: the need, plus an impact or a reason for now
- [Free request check](https://www.deliverysheet.com/request-check): paste a
  work request, see whether it states the need, the impact and why now, and the
  questions to send back for what is missing — no account, nothing stored
- [Writing](https://www.deliverysheet.com/blog): essays on delivery governance
- [Comparisons](https://www.deliverysheet.com/vs): how DeliverySheet relates to the
  tools around it, layer differences stated honestly
- [vs Jira and Linear](https://www.deliverysheet.com/vs/jira-and-linear): where the
  layers differ, and a plain statement that it does not replace them today
- [vs product roadmap tools](https://www.deliverysheet.com/vs/product-roadmap-tools):
  roadmap tools decide what to build next; DeliverySheet governs whether a specific
  demand is ready to be promised
- [vs Monday and Asana](https://www.deliverysheet.com/vs/monday-and-asana): they
  coordinate work already taken on; DeliverySheet governs whether to take it on at
  all
- [vs a spreadsheet](https://www.deliverysheet.com/vs/spreadsheets): where the
  intake sheet genuinely works, where it quietly fails, and the honest trigger for
  outgrowing it
- [vs Jira Product Discovery](https://www.deliverysheet.com/vs/jira-product-discovery):
  JPD collects and ranks product ideas inside Atlassian; DeliverySheet governs
  whether a specific demand is ready to be promised — the step the idea-to-epic
  handoff skips
- [vs Airtable and Notion](https://www.deliverysheet.com/vs/airtable-and-notion):
  the spreadsheet's natural second home — the structure genuinely improves, and
  the missing part (enforced commitment states) migrates intact
- [vs enterprise PPM](https://www.deliverysheet.com/vs/enterprise-ppm):
  ServiceNow SPM and Planview do demand governance at portfolio scale; this is
  the same idea for one engineering organisation — if you have a PMO, buy a PPM
- [vs Productboard](https://www.deliverysheet.com/vs/productboard): Productboard
  gathers customer feedback, prioritizes features and publishes roadmaps for
  product teams; DeliverySheet governs whether a specific engineering demand is
  ready to be promised — no integration, the handoff is manual
- [vs Smartsheet](https://www.deliverysheet.com/vs/smartsheet): the common
  incumbent for intake forms and project tracking — far more flexible;
  DeliverySheet trades that for fixed, enforced commitment states, a readiness
  verdict and an honest close
- [vs Jira Service Management](https://www.deliverysheet.com/vs/jira-service-management):
  a service desk resolves requests against an SLA and is the better home for
  small, repeatable requests; DeliverySheet is for the project-sized ask that
  needs a decision and a recorded commitment — no portal, no SLAs, no sync
- [Project one-pager example](https://www.deliverysheet.com/examples/one-pager):
  a filled-in one-pager for a fictional demand — problem, committed outcome,
  scope in and out, owner, stakeholders, why now
- [About](https://www.deliverysheet.com/about): who builds DeliverySheet and why it
  exists — one person, Tan Gravam, in Amsterdam
- [Glossary](https://www.deliverysheet.com/glossary): plain definitions of the delivery-governance vocabulary
- [Feed](https://www.deliverysheet.com/blog/rss.xml): RSS for new articles

## Topics

- [Turning a request into something you can decide on](https://www.deliverysheet.com/topics/intake):
  the one-sentence bar for entering the process, why a subject word is not a
  request, and how to keep a wait from decaying into silence.
- [How to decide what to commit to](https://www.deliverysheet.com/topics/commit):
  six things to settle before a team commits to work (problem, outcome, owner,
  capacity, dependencies, unknowns), the four-field exception when the date
  will not wait, and why a silent no costs more than a clear one.
- [Capacity and what to measure](https://www.deliverysheet.com/topics/capacity):
  FTE-months as a unit that travels to budget altitude, and why allocation data
  survives being looked at while consumption data does not.
- [After the commitment](https://www.deliverysheet.com/topics/deliver): status that
  carries its reasoning, an outcome that is a comparison rather than a checkbox, and
  a retrospective that produces one written lesson.
- [Planning that stays honest](https://www.deliverysheet.com/topics/planning):
  facts vs assumptions vs open questions, vertical vs horizontal work, three-state
  readiness, and where AI belongs.

## Glossary terms

One URL per definition, stated exactly as the term page states it.

- [What is a demand?](https://www.deliverysheet.com/glossary/demand):
  A demand is a work request that has entered the delivery lifecycle — the
  unit a delivery governance system tracks from intake to decision.
- [What is an FTE-month?](https://www.deliverysheet.com/glossary/fte-month):
  An FTE-month is 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.
- [What is vertical work?](https://www.deliverysheet.com/glossary/vertical-work):
  Vertical work is 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.
- [What is horizontal work?](https://www.deliverysheet.com/glossary/horizontal-work):
  Horizontal work is a cross-cutting concern that pulses into several delivery
  streams at specific gates — security review, legal, compliance, design,
  accessibility, privacy.
- [What is a commitment exception?](https://www.deliverysheet.com/glossary/commitment-exception):
  A commitment exception is 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.
- [What is a delivery commitment?](https://www.deliverysheet.com/glossary/delivery-commitment):
  A delivery commitment is a recorded promise to deliver a stated outcome by a
  date, made by a named owner with the capacity the delivering teams agreed to
  give, and kept as a baseline that later results are compared against.
- [What is a re-baseline?](https://www.deliverysheet.com/glossary/re-baseline):
  A re-baseline is a deliberate, recorded change to a delivery commitment: a
  new outcome, date or capacity, with the reason for the change, kept beside
  the original baseline instead of overwriting it.
- [What is allocation vs consumption?](https://www.deliverysheet.com/glossary/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.
- [What is a clarification brief?](https://www.deliverysheet.com/glossary/clarification-brief):
  A clarification brief is 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.
- [What is three-state readiness?](https://www.deliverysheet.com/glossary/readiness-three-state):
  Three-state readiness means a planning dimension has three states, not two:
  not assessed, assessed and nothing found, and assessed with items.
- [What is a delivery outcome?](https://www.deliverysheet.com/glossary/delivery-outcome):
  A delivery outcome is the explicit close of a commitment: what actually
  shipped, and — when the result is not a clean delivery — what differed from
  the promise.
- [What is delivery governance?](https://www.deliverysheet.com/glossary/delivery-governance):
  Delivery governance is the practice of deciding what to commit to —
  establishing value, ownership, capacity, dependencies and open questions
  before people, budget or a date are promised.
- [What is a decision-ready demand?](https://www.deliverysheet.com/glossary/decision-ready-demand):
  A decision-ready demand is one 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.
- [What is a delivery path?](https://www.deliverysheet.com/glossary/delivery-path):
  A delivery path is 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.
- [What is a RAG status?](https://www.deliverysheet.com/glossary/rag-status):
  A RAG status is 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.
- [What is demand management?](https://www.deliverysheet.com/glossary/demand-management):
  Demand management is 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.
- [What is a time-boxed discovery?](https://www.deliverysheet.com/glossary/time-boxed-discovery):
  A time-boxed discovery is 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.
- [What is the demand lifecycle?](https://www.deliverysheet.com/glossary/demand-lifecycle):
  The demand lifecycle is 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.
- [What is work intake?](https://www.deliverysheet.com/glossary/intake):
  Work intake is the 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.
- [What is capacity planning?](https://www.deliverysheet.com/glossary/capacity-planning):
  Capacity planning establishes what each team can honestly promise for a
  period — gross FTE-months minus what is already spoken for — and commits
  demands against that line in priority order.
- [What is a capacity line?](https://www.deliverysheet.com/glossary/capacity-line):
  A capacity line is 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.
- [What is a definition of ready?](https://www.deliverysheet.com/glossary/definition-of-ready):
  A definition of ready is 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.
- [What is scope creep?](https://www.deliverysheet.com/glossary/scope-creep):
  Scope creep is the accumulation of unrecorded additions to a commitment's
  scope — each too small to renegotiate the promise, together large enough to
  break it.
- [What is request triage?](https://www.deliverysheet.com/glossary/triage):
  Request triage is 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.
- [What is a delivery roadmap?](https://www.deliverysheet.com/glossary/delivery-roadmap):
  A delivery roadmap is 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.
- [What is backlog bankruptcy?](https://www.deliverysheet.com/glossary/backlog-bankruptcy):
  Backlog bankruptcy is 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.
- [What is a RAID log?](https://www.deliverysheet.com/glossary/raid-log):
  A RAID log is 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.
- [What is a readiness bar?](https://www.deliverysheet.com/glossary/readiness-bar):
  A readiness bar is 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.
- [What is an honest close?](https://www.deliverysheet.com/glossary/honest-close):
  An honest close ends 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.
- [What is shaping?](https://www.deliverysheet.com/glossary/shaping):
  Shaping turns 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.
- [What is a slow maybe?](https://www.deliverysheet.com/glossary/slow-maybe):
  A slow maybe is 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.
- [What is RICE scoring?](https://www.deliverysheet.com/glossary/rice-scoring):
  RICE scoring is a prioritisation formula that scores each candidate piece of
  work as Reach × Impact × Confidence ÷ Effort, so that ideas of different
  sizes can be compared on expected value per unit of effort.
- [What is WSJF (weighted shortest job first)?](https://www.deliverysheet.com/glossary/wsjf):
  WSJF (weighted shortest job first) is a sequencing rule that divides each
  job's cost of delay by its size or duration and does the highest ratio
  first, so the work that is most expensive to keep waiting per unit of effort
  goes ahead.
- [What is MoSCoW prioritisation?](https://www.deliverysheet.com/glossary/moscow-prioritisation):
  MoSCoW prioritisation is a technique that sorts requirements for a fixed
  timebox into four categories — Must have, Should have, Could have and Won't
  have this time — so that everyone agrees in advance what is dropped first if
  time runs short.
- [What is a RACI matrix?](https://www.deliverysheet.com/glossary/raci-matrix):
  A RACI matrix is a grid of tasks or decisions against people or roles,
  marking for each who is Responsible for doing the work, who is Accountable
  for the result, who must be Consulted before it happens, and who is Informed
  afterwards.
- [What is resource allocation?](https://www.deliverysheet.com/glossary/resource-allocation):
  Resource allocation assigns a share of specific people's or teams' capacity
  to specific work for a defined period — the decision about who gets the
  capacity, as distinct from the calculation of how much capacity exists.
- [What does KTLO (keep the lights on) mean?](https://www.deliverysheet.com/glossary/ktlo):
  KTLO (keep the lights on) is the work a team must do to keep what already
  exists running — support, on-call, patches, upgrades, renewals and routine
  operations — as distinct from work that changes what exists.

## Articles

- [Not every request should enter the process](https://www.deliverysheet.com/blog/not-every-request-is-a-demand):
  the bar for entering a delivery process is one sentence — what needs to change,
  plus who is affected or why now — and why an override always gets used.
- ["SSO" is a topic, not a request](https://www.deliverysheet.com/blog/a-topic-is-not-a-request):
  half an intake queue is a subject area wearing the grammar of a request; the
  test is what will be true afterwards that is not true today.
- [Waiting on information is a state, not silence](https://www.deliverysheet.com/blog/waiting-on-information-is-a-state):
  most requests that die were never refused — they were asked a question nobody
  chased; a wait needs the question, who was asked, an owner and a date.
- [Why delivery commitments slip before a single line of code](https://www.deliverysheet.com/blog/why-delivery-commitments-slip-before-code):
  most missed dates are decided at intake, not in delivery — the six things a
  request lacks that a commitment needs.
- [Vertical and horizontal work: the distinction planning tools miss](https://www.deliverysheet.com/blog/vertical-and-horizontal-work):
  why delivery streams and cross-cutting concerns need different capacity models,
  and why treating both as "epics" produces predictable late-stage bottlenecks.
- [Allocation, not consumption: what an engineering manager should measure](https://www.deliverysheet.com/blog/allocation-not-consumption):
  allocation data survives being looked at; consumption data does not.
- [FTE-months: a capacity unit you can defend in a budget meeting](https://www.deliverysheet.com/blog/fte-months-capacity-unit):
  why story points do not travel to portfolio or budget altitude, and what to use
  instead.
- ["No known risks" has to be a valid answer](https://www.deliverysheet.com/blog/no-known-risks-is-an-answer):
  a planning dimension needs three states, not two — not assessed, assessed and
  nothing found, assessed with items — or people invent entries to look diligent.
- [You will commit before you are ready. Make it cost four fields.](https://www.deliverysheet.com/blog/early-commitment-exception):
  why banning early commitments hides them, and the four fields that make one
  countable: why now, what is missing, who accepts, what would change it.
- [Separate the facts from the assumptions before you plan anything](https://www.deliverysheet.com/blog/known-facts-assumptions-unknowns):
  requests arrive as a blend of fact, assumption and open question written in one
  voice; the assumptions list is also your risk register.
- [AI should draft and challenge. It should not decide.](https://www.deliverysheet.com/blog/ai-should-suggest-not-decide):
  the dividing line is accountability, not model capability — use AI where the
  output is verifiable in seconds and a wrong answer is one edit.
- [Saying no is a decision. Record it like one.](https://www.deliverysheet.com/blog/saying-no-is-a-recorded-decision):
  a request left to rot in a backlog is a no nobody communicated; park and
  decline should be first-class, recorded and reversible.
- [What a decision-ready demand actually contains](https://www.deliverysheet.com/blog/decision-ready-demand):
  the six things that must be established before a request can honestly become a
  commitment, and why "missing" blocks promising rather than discussing.
- [Estimating capacity when you don't know enough yet](https://www.deliverysheet.com/blog/estimating-capacity-you-dont-have-yet):
  attach confidence to the figure, protect the range's top end, and treat "I need
  to look first" as a time-boxed fork rather than a refusal.
- [The dependency you don't own](https://www.deliverysheet.com/blog/the-dependency-you-dont-own):
  logged is not asked and asked is not confirmed; "asked but not confirmed" is the
  state most dependencies live in and the one no tool names.
- [What goes in the quarter, and who decides](https://www.deliverysheet.com/blog/what-goes-in-the-quarter):
  plan against per-team capacity not an organisational total, commit to less than
  fits, and write down what you are NOT doing.
- [When a team is over-committed, say which thing slips](https://www.deliverysheet.com/blog/when-a-team-is-over-committed):
  remove something, move a date, or cut named scope — and tell the person who was
  promised it. Effort and re-estimating are not answers.
- [A decision without a record is a decision you will make again](https://www.deliverysheet.com/blog/decisions-need-a-record):
  record what was decided, what was rejected and why, who decided, and the
  condition that would make you revisit it.
- [Green is a judgement, not a colour](https://www.deliverysheet.com/blog/rag-status-is-a-judgement):
  a status colour is only worth reading if it carries what changed, what differs
  from the plan, and what decision is needed.
- ["Delivered" is not an outcome](https://www.deliverysheet.com/blog/delivered-is-not-an-outcome):
  three closes rather than one, and the difference from the promise recorded
  whenever the result was not clean.
- [A retrospective that isn't theatre](https://www.deliverysheet.com/blog/a-retrospective-that-isnt-theatre):
  one written lesson, attached to the work, required before completion.
- [What makes a request shapeable](https://www.deliverysheet.com/blog/what-makes-a-request-shapeable):
  a need plus either an impact or a trigger; a topic word is not a request, and the
  floor is deterministic rather than AI-dependent.
- [Forecast what work will cost. Do not track what it did.](https://www.deliverysheet.com/blog/cost-forecasting-not-cost-tracking):
  FTE-months times an estimated monthly cost answers the question finance asks,
  before the money is committed.
- [Scope is mostly what you're not doing](https://www.deliverysheet.com/blog/scope-is-what-youre-not-doing):
  the out-of-scope list is the half that holds when someone asks for one more thing
  in week six.
- [An owner is a person, not a team](https://www.deliverysheet.com/blog/an-owner-is-a-person):
  a team name is a blank that looks answered; only a person can make the judgement
  or refuse the demand.
- [What "complete" should mean](https://www.deliverysheet.com/blog/what-complete-should-mean):
  complete when the outcome is recorded and a lesson is written — not when the work
  stops.
- [Declining a request by email: seven scripts to copy](https://www.deliverysheet.com/blog/declining-a-request-email-templates):
  copy-paste emails for decline, park until a review date, ask what is missing,
  a smaller yes, redirect to the right owner, the reply when sales already
  promised a date, and declining a customer's request
- [How to say no to a stakeholder](https://www.deliverysheet.com/blog/how-to-say-no-to-a-stakeholder):
  the slow maybe costs more relationship than a fast no; what a good refusal
  contains, and how to refuse upward.
- [Quarter planning without the theatre](https://www.deliverysheet.com/blog/quarter-planning-without-the-theatre):
  a plan is a set of commitments teams agreed to, not a ranked wishlist; walk the
  list to the capacity line, then stop.
- [Moving delivery governance out of the spreadsheet](https://www.deliverysheet.com/blog/moving-out-of-the-spreadsheet):
  the trigger is not row count; very little data moves — states move.
- [An intake form is a door, not a net](https://www.deliverysheet.com/blog/the-intake-form-is-a-door):
  ask the two questions that make a request decidable, be allowed to say "not
  yet", and make cleared requests visibly move.
- [Your first 90 days: aim for one honest close](https://www.deliverysheet.com/blog/first-90-days-one-honest-close):
  one commitment made with evidence and closed honestly teaches leadership more
  than a quarter of green dashboards.
- [Demand management is deciding, not collecting](https://www.deliverysheet.com/blog/what-is-demand-management):
  an intake queue records wishes; demand management shapes them, refuses some on
  the record, and commits the rest against capacity.
- [A discovery is a decision with a deadline](https://www.deliverysheet.com/blog/discovery-is-a-decision-with-a-deadline):
  a spike that never ends is a parking lot; what separates discovery from
  research is a time-box, a target date, and a conclusion someone must record.
- [Reporting delivery to leadership: promises, not activity](https://www.deliverysheet.com/blog/reporting-delivery-to-leadership):
  activity lists answer no question leadership has; report promises against
  outcomes — what was committed, what closed honestly, what slipped and why.
- [A definition of ready for commitments, not tickets](https://www.deliverysheet.com/blog/definition-of-ready-for-commitments):
  A sprint definition of ready checks tickets. The one that matters checks
  promises — the bar a demand clears before people and a date are committed.
- [An estimate is not a commitment](https://www.deliverysheet.com/blog/an-estimate-is-not-a-commitment):
  A range with low confidence leaves the team and arrives upstairs as a date.
  What stops the hardening is making the promise a separate, recorded act.
- [The mid-quarter ask is an edit, not an addition](https://www.deliverysheet.com/blog/the-mid-quarter-ask):
  Capacity did not grow when the urgent ask arrived. A mid-quarter request is an
  edit to a named commitment — the honest record names what it displaces.
- [You don't need a scoring framework](https://www.deliverysheet.com/blog/you-dont-need-a-scoring-framework):
  RICE and WSJF rank unshaped demands to two decimal places. A readiness bar
  plus a visible capacity line does the work the score pretends to do.
- [Backlog bankruptcy: 400 unrecorded nos](https://www.deliverysheet.com/blog/backlog-bankruptcy):
  A 400-item backlog is 400 decisions nobody recorded. Closing it is a batch of
  recorded declines and parks with reasons — not a purge.
- [Close the quarter by counting the exceptions](https://www.deliverysheet.com/blog/quarter-end-count-the-exceptions):
  Three counts close a quarter: honest closes, slips with named differences, and
  early-commitment exceptions. Each changes next quarter's line.
- [Capacity planning for engineering teams](https://www.deliverysheet.com/blog/capacity-planning-for-engineering-teams):
  How to plan engineering capacity for a quarter in four steps: each team's real
  capacity in FTE-months, sizing work, and what to do with what does not fit.
- [The engineering intake process, end to end](https://www.deliverysheet.com/blog/engineering-intake-process):
  The work intake process for an engineering team: one door, two questions,
  four recorded exits, and visible movement. No triage committee, no
  twelve-field form.
- [An intake form template with two required fields](https://www.deliverysheet.com/blog/intake-form-template):
  The copy-paste template: what needs to change, who is affected or what
  happens if nothing changes, and an optional date. Every further field is paid
  for by the requester.
- [A capacity planning template that fits on one sheet](https://www.deliverysheet.com/blog/capacity-planning-template):
  Five columns per team — gross, committed elsewhere, interruption reserve, the
  honest line, the walk — and the two failures no spreadsheet fixes.
- [When everything is a priority, run the capacity line](https://www.deliverysheet.com/blog/when-everything-is-a-priority):
  "It's all P1" is a missing constraint, not a stakeholder failure — an
  ordering costs nothing until it has to fit under a per-team capacity line.
- [Triage is deciding what happens next, not sorting by size](https://www.deliverysheet.com/blog/triaging-engineering-requests):
  four recorded exits, refusal authority in the room, and why deciding is
  faster than sorting — a sorted item always comes back; a decided one never
  does.
- [Sprint commitment vs forecast: the argument is at the wrong level](https://www.deliverysheet.com/blog/sprint-commitment-vs-forecast):
  Scrum was right to rename the sprint commitment a forecast — and the
  organisation still makes real commitments one level up, where they need a
  ledger.
- [The RAID log, minus the theatre](https://www.deliverysheet.com/blog/raid-log-without-the-theatre):
  keep the four categories, attach them to the demand instead of a document,
  and make "assessed, nothing found" recordable — the log was never the
  point; the looking was.
- [OKRs point. Commitments deliver.](https://www.deliverysheet.com/blog/okrs-and-commitments):
  an OKR is a direction with a measurement; a commitment is a promise with an
  owner, capacity and a date — each fails when asked to do the other's job.
- [The status report that answers questions](https://www.deliverysheet.com/blog/engineering-status-report):
  four sections on one page — committed, closed honestly, at risk with
  reasons, committed early — and no activity lists.
- [Ten projects in flight is a queue pretending to be progress](https://www.deliverysheet.com/blog/too-many-projects-in-flight):
  attention is the scarce unit; pay for parallelism at commitment time with a
  per-team capacity line, and the WIP limit finally holds.
- [The date sales already promised](https://www.deliverysheet.com/blog/the-date-sales-already-promised):
  book the pre-promised date as what it is — an early commitment with a
  recorded exception naming who accepted the risk — and count the cost by
  quarter three.
- [The side channel is rational](https://www.deliverysheet.com/blog/the-side-channel):
  requests bypass intake because bypassing works better; make the door the
  fastest path to an answer and walk the DMs to it.
- [Five honest alternatives to the intake spreadsheet](https://www.deliverysheet.com/blog/spreadsheet-intake-alternatives):
  keep the sheet, Airtable/Notion, a Jira intake project, JPD, or enforced
  states — the case for each stated first, and the failure that moves you on.
- [Delivery roadmap: how to build one that survives the quarter](https://www.deliverysheet.com/blog/how-to-build-a-delivery-roadmap):
  How to build a delivery roadmap from commitments: the five columns, a worked example, the update rhythm, and the three ways a roadmap rots.
- [How to prioritise tech debt against features](https://www.deliverysheet.com/blog/prioritising-tech-debt-against-features):
  Tech debt loses planning because it arrives with no problem, outcome or cost of delay. Shape it like any demand, and know what evidence makes it win.
- [How much capacity to reserve for unplanned work](https://www.deliverysheet.com/blog/unplanned-work-capacity-reserve):
  Measure each team's interrupt rate over the last two quarters, hold the reserve as a named line, and decide now what happens when it runs out.
- [A change request process that fits on one page](https://www.deliverysheet.com/blog/change-request-process):
  A lightweight change request process: what a request must state, who decides, and when to re-baseline with a reason. With a copyable checklist.
- [When to stop a project you already committed to](https://www.deliverysheet.com/blog/when-to-stop-a-committed-project):
  Sunk cost, the three signals that justify cancelling, kill criteria set at commitment time, and how to close a stopped project honestly.
- [Lessons learned: a template and examples](https://www.deliverysheet.com/blog/lessons-learned-template):
  A three-sentence lessons learned template, six examples in weak and strong form, and how a lesson differs from a sprint retrospective and a post-mortem.
- [How to write a one-page project brief](https://www.deliverysheet.com/blog/one-page-project-brief):
  The six questions a one-page project brief answers, a weak and a strong line for each, what to leave out, and a plain-text template to copy.
- [AI project requests: what to ask first](https://www.deliverysheet.com/blog/ai-project-requests):
  treat it like any other request, then ask four more questions before
  committing a team: which task changes, whose data, how good is good enough,
  and what happens when it is wrong.
- [How to tell stakeholders a project is late](https://www.deliverysheet.com/blog/telling-stakeholders-a-project-is-late):
  tell them the day you would bet against the date, in four parts; five
  copy-paste emails for a new date, a scope-or-date choice, a late dependency,
  a wrong estimate and a stop; then re-baseline with a reason, never overwrite.
- [Capacity planning when one team serves several product lines](https://www.deliverysheet.com/blog/capacity-planning-across-product-lines):
  plan the teams, not the lines; rank requests from every product line once
  per shared team; walk the list down the team's FTE-months and give the first
  request past the line a written answer. With a worked three-line example
  and why a percentage split per line is a budget, not a plan.
- [How much process does a request need? Four paths, chosen in a minute](https://www.deliverysheet.com/blog/how-much-process-a-request-needs):
  as much as a wrong commitment would cost: three questions (how many teams,
  how long until you would know, can it be undone) and four paths — a light
  confirmation, a standard plan, a strategic initiative, and an urgent
  exception with four recorded fields.
- [Putting a project on hold: a review date, or it is a no](https://www.deliverysheet.com/blog/putting-a-project-on-hold):
  a hold needs a review date or an explicit indefinite hold with the reason;
  what to write down, the three outcomes on the review date, and why a third
  park should be a decline.
- [A risk register that gets read: mitigate it, accept it, or it blocks](https://www.deliverysheet.com/blog/risk-register-that-gets-read):
  five columns per risk, three ways out (mitigated, accepted, closed), and the
  rule that gets it read: an unresolved serious risk blocks the commitment.
- [Pushing back on an unrealistic deadline: three offers, not one no](https://www.deliverysheet.com/blog/pushing-back-on-an-unrealistic-deadline):
  ask what happens the day after, get a figure the delivering team owns, and
  offer three trades (scope, date, or a displaced commitment); if everything
  still stands, commit early with a recorded exception.
- [The say/do ratio: measuring delivery predictability without scoring people](https://www.deliverysheet.com/blog/say-do-ratio-delivery-predictability):
  commitments kept over commitments made, counted from the baseline, in three
  outcomes, at organisation level only; split the misses by early commitment.
- [Fixed scope or fixed date: pick one before you commit](https://www.deliverysheet.com/blog/fixed-scope-or-fixed-date):
  a commitment holds two of scope, date and capacity; how to choose which one
  flexes, write it into the commitment, and record it when it moves.
- [How to justify engineering headcount: show what was turned away](https://www.deliverysheet.com/blog/justifying-engineering-headcount):
  four numbers for one team (honest capacity, what was committed and
  delivered, what was declined for capacity, what that cost), and what a hire
  would not fix.
- [How a platform team should take requests from other teams](https://www.deliverysheet.com/blog/platform-team-intake):
  two doors (support rotation, change requests), three questions at the door,
  a weekly decision in writing, and a published list of committed, parked and
  declined work.
- [How to run a pre-mortem: forty-five minutes before you commit](https://www.deliverysheet.com/blog/how-to-run-a-pre-mortem):
  imagine the failure, write reasons alone, keep the plausible and fatal ones,
  and turn each into a risk, a dependency, an open question or a cut.
- [A project status meeting agenda that makes decisions](https://www.deliverysheet.com/blog/project-status-meeting-agenda):
  written updates first; thirty minutes on what changed colour, decisions
  needed, changes to what was promised and who sent nothing; how often to
  meet.

## Legal

- [Privacy Policy](https://www.deliverysheet.com/legal/privacy)
- [Terms](https://www.deliverysheet.com/legal/terms)