Skip to content

Value Declaration

Estimating the worth of the intended change in writing, before the cycle runs. Range, most-likely, assumptions. Forms the VRI numerator — the denominator is what the team actually delivered.

Owners: PO, Leadership Phase it lives in: Before We Build → After We Build (Volume V) The corpus principle this enacts: A prediction not checked is indistinguishable from a guess — including the value prediction.

Where it lives in the chain

How to do this

The value declaration has four lines:

  1. What changes"Gal's grading session drops from 47 minutes to under 15."
  2. Per-person value"32 minutes saved per session. 3 sessions per week. 96 min/week per grader."
  3. Reach"50 graders in pilot schools. 500 graders if full rollout succeeds."
  4. Range"Low estimate: 800 hours saved per quarter (pilot only, modest adoption). Most-likely: 4,000 hours (pilot + first expansion). High: 25,000 hours (full rollout)."
  5. Assumptions"Assumes shortcut adoption ≥60%. Assumes sessions per week don't decrease in response." The assumptions are what would have to be true for the declared value to hold.

What good practice looks like

The PO writes value declaration before any code begins. "We predict this is worth approximately 4,000 hours per quarter. If it comes in below 1,500 hours, we will reconsider the initiative." That is a falsifiable claim with a kill threshold.

After the signal reading, the VRI is computed: "Predicted 4,000 hours. Measured pilot saved 2,300 hours, projected to full rollout 18,000 hours. VRI for pilot: 0.58. VRI for trajectory: 4.5 (we underestimated)." Both outcomes are valuable — they update the next initiative's declaration.

A team that never declares value in writing also never gets to honestly compute VRI — they describe outcomes post-hoc to match what they delivered. That is not a model that's correcting; that is rationalisation. The declaration's discipline is the willingness to be wrong on the record.

200apps · How We Work · NWIRE