Skip to content

Fixed-Inventory Configuration Sprint

Timeboxed process — instantiates Inventory-Bounded Resource Recomposition

A timeboxed, cross-functional loop that generates, assembles, tests, and revises candidate configurations using only the declared inventory — nothing may be ordered in.

A specification and a pile of mismatched resources do not combine themselves. Fixed-Inventory Configuration Sprint is the engine that drives the combining: a bounded, timeboxed working session in which a cross-functional group generates candidate configurations, assembles them, tests each against the sufficiency bar, and revises — all under a hard rule that only the declared inventory may be used. Its two defining constraints are the ones in its name: a fixed clock and a fixed stock. The timebox forces convergence before analysis-paralysis sets in; the inventory boundary forbids the escape hatch of "let's just order the right part," which is what keeps the team actually recomposing rather than quietly procuring. The sprint is not any single artifact — it is the cadence that turns a target and a stock into a tested configuration and a record of what worked.

Example

A small hardware team must field a battery-powered river-level sensor for a pilot in three days. The proper radio module is weeks out. They call a 48-hour Fixed-Inventory Configuration Sprint and open the bin: an assortment of dev boards, a short-range mesh radio meant for a different product, a solar panel from a cancelled project, some ultrasonic rangefinders. The rule is stated at the top — whatever ships uses only what is on this table.

Round one bolts a rangefinder to a dev board and the mesh radio, and the sufficiency test — does it report level to ±2 cm and survive a night on the panel? — fails on power. Round two swaps to lower-duty-cycle firmware and a bigger capacitor from the bin; it passes range but the radio drops packets past ~40 m. Round three relays through a second board as a repeater. By hour 40 a configuration clears the bar, and just as valuable, the team leaves with a short learning record: the mesh radio is viable only with a repeater, the solar budget is the real constraint, and the ±2 cm threshold is the one that drove every redesign.

How it works

  • Declare the stock and start the clock. Freeze the inventory that may be used and the deadline; both are fixed for the duration and neither may be renegotiated mid-sprint.
  • Generate, then build the most promising candidate. Diverge on possible configurations quickly, then commit to assembling one rather than debating on paper.
  • Test against the sufficiency bar each cycle. Run a fast go/no-go check against the performance thresholds — not a full validation, just enough to decide keep, revise, or discard.
  • Revise and repeat until it clears or time runs out. Each loop feeds a running record of what failed and why, so the sprint converges instead of circling.

Tuning parameters

  • Timebox length — the fixed duration. A tighter box forces faster convergence and cheaper failures but risks a brittle, under-tested result; a longer one buys robustness at the cost of momentum and drift.
  • Inventory strictness — how absolute the "declared stock only" rule is. Zero-exception keeps the exercise honest; a small, explicitly-listed consumables allowance can unblock a sprint without reopening the procurement escape hatch.
  • Test rigour per cycle — how hard each in-loop sufficiency check bites. Lighter checks let you iterate faster; heavier ones catch failures sooner but slow the loop.
  • Team breadth — how cross-functional the room is. More disciplines surface more affordances and catch more incompatibilities, but a crowded sprint coordinates slower.

When it helps, and when it misleads

Its strength is momentum under constraint: the fixed clock defeats the tendency of a fit-from-stock problem to expand indefinitely, and the fixed stock keeps the team solving the actual problem instead of wishing for parts. Because it aims at sufficient rather than optimal, it is a working instance of satisficing — stopping at the first configuration that clears the bar rather than searching for the best one — which is the right stance when the deadline is real.[1]

Its failure modes come from the same constraints. A timebox can manufacture a configuration that merely passed the quick check and is brittle in the field, because the in-loop sufficiency test is fast, not rigorous — the sprint should hand its winner to a heavier validation, not treat the go/no-go as proof. And a sprint can be run backwards as theatre: a foregone configuration walked through the motions to look justified. The discipline that guards against both is to keep the sufficiency bar honest and external to the room, and to carry the learning record forward so the next sprint starts smarter rather than rediscovering the same dead ends.

How it implements the components

Fixed-Inventory Configuration Sprint realises the bounded-iteration side of the archetype — the components that govern working within the stock over time:

  • fixed_inventory_boundary — the sprint's central rule: only the declared inventory may be used, enforced for the whole timebox.
  • sufficiency_test — the fast per-cycle go/no-go against the performance thresholds that decides keep, revise, or discard.
  • learning_record — the running capture of what failed and why across cycles, so iteration converges and later sprints inherit the lessons.

It runs the fast in-loop check, not the heavyweight validation — rigorous sufficiency_testing belongs to Controlled Pilot and Integration Test Plan. It also does not engineer the bridges between mismatched parts: interface_contract and adapter_and_conversion_plan belong to Technical Bypass or Adapter Design.

Notes

The inventory boundary is the load-bearing constraint. Relax it quietly — "we'll just grab one part" — and the sprint stops being recomposition and becomes ordinary procurement with extra steps; the whole point is to discover what the existing stock can be made to do.

References

[1] Satisficing, Herbert Simon's term, is choosing the first option that meets an acceptability threshold rather than searching for the optimum. A timeboxed sprint against a sufficiency bar is satisficing by construction — appropriate when the cost of continued search exceeds the value of a better configuration. ↩