Choosing a small test is not about picking the most exciting automation. It is about picking the narrowest question you can answer with evidence in a short cycle. The Lean Enterprise Institute defines cycle time as the time required to complete a process, as timed by actual measurement, and distinguishes it from processing time, which is "typically a small fraction" of the time a product moves through a value stream.1 That gap between work and elapsed time is your first clue about where a test belongs.

Everything on this page, including any numbers in examples, is hypothetical. Nothing here is measured from a real client or a real tool run. Use the descriptions as patterns to copy into your own measurement, not as benchmarks.

Start from the largest waiting interval, not the largest task

If you have mapped your workflow in the Handoff mapper at /map/, you already have per-stage work minutes and wait minutes. The mapper flags the largest wait, with ties reported honestly rather than broken arbitrarily. That flag is the natural starting candidate for a small test, because waiting is usually where automation can change elapsed time without touching the judgment a person is doing.

The Lean lexicon frames non-value-creating time as time spent on activities that add cost but no value from the customer's perspective, such as storage, inspection, and rework.1 A queued item sitting in an inbox is the office equivalent. A test aimed at that queue is cheap to observe: did the item move sooner, or did it not?

Keep the distinction between work and wait explicit in your test note. Shortening a five-minute drafting task proves something different from emptying a two-day queue, and only one of those is likely to matter to the person waiting.

Write the test as one stage, one change

A small test changes exactly one stage of the map. Everything upstream and downstream stays as it is. This is deliberate: if the result is surprising, you want to know which change caused it.

  • Stage under test: name the stage and its owner role.
  • Current behaviour: what happens today, stated as an observation, not a guess.
  • Changed behaviour: what the automation will do instead, in one sentence.
  • Unchanged: list the adjacent stages you are deliberately leaving alone.

If you cannot describe the change in one sentence, the test is too big. Split it.

Define pass and fail before you run

The most common failure in small tests is deciding afterwards whether it worked. Set the criterion first, in the same note where you recorded your baseline numbers. A usable criterion names the measure, the comparison, and the period.

Here is a hypothetical example: a stage labelled "intake triage" has an owner role of "first reviewer", with a recorded wait of 480 minutes and work of 12 minutes. The test changes only how the queued item is surfaced to that reviewer. The pass rule might be: median wait for the stage falls below 240 minutes across the next twenty items, with the reviewer's work minutes unchanged or lower. Fail is anything else, including a fall in wait paired with a rise in rework.

That example is invented to show the shape of a criterion. Your numbers will differ, and they should come from your own measurements.

Keep a human in the loop where consequences are serious

Not every stage should be automated end to end. NIST's AI Risk Management Framework appendix on human-AI interaction notes that human roles and responsibilities in decision making and oversight need to be clearly defined and differentiated, and that human-AI configurations span from fully autonomous to fully manual.2 It also observes that systems vary in whether human oversight is required at all.

The same appendix states that the govern function is where organisations clarify and define the roles and responsibilities of the humans in these configurations, and the map function is where they document processes.2 In practical terms: for each stage you test, write down who approves, who can override, and what the override looks like.

NIST also warns that human-AI interaction results vary, and that in some conditions the AI part of the interaction can amplify human biases rather than correct them.2 A small test is a good place to notice this early, before the pattern is baked into a process.

Match the measure to the thing you changed

The NIST framework's section on AI risks and trustworthiness lists characteristics including valid and reliable, accountable and transparent, explainable and interpretable, and safe.3 It notes that tradeoffs are usually involved and that trustworthiness is only as strong as its weakest characteristic.3 A test that reports only elapsed time is incomplete if your change also affects accuracy or the ability of a reviewer to explain a decision.

A practical compromise for a small test: one primary measure tied to the stage you changed, and one guard measure chosen to catch the most plausible side effect. Keep the pair fixed for the duration of the test.

Run it, then decide what the numbers mean

When the test period ends, compare against the baseline you recorded. If you changed your inputs during the run, say so in the note; the earlier numbers and the later ones are not directly comparable. Record the outcome even when it is a fail, since a failed small test that you can explain is more useful than an unclear success.

Then choose the next step from the result:

  1. Passed and the measure is stable. Consider extending to a longer period before widening scope.
  2. Passed but a guard measure moved. Investigate the side effect before extending.
  3. Failed. Either the stage was the wrong choice, or the change was the wrong change. Return to the map and pick again.
  4. Inconclusive. Usually the criterion was vague or the volume too low. Tighten the criterion first.

A short checklist

  • One stage, one change, adjacent stages named as unchanged.
  • Baseline wait and work recorded before the change, from actual observation.
  • Pass and fail rules written before the run, with a period.
  • A named human owner, an approval point, and an override path.
  • One primary measure and one guard measure, both fixed.
  • All numbers marked hypothetical until measured.

If you have not mapped the workflow yet, start at the workflow mapper and read reading the wait before you write the test note.