Micro‑Experiment Sprint Kit

Welcome — run faster, learn safer

This kit helps a small team run short, tightly scoped experiment sprints that produce clear validated learning and an accountable next step. Use it when you need to test a riskiest assumption, reduce uncertainty quickly, or convert an idea into a measurable insight without long pilots.

When to use a micro‑experiment sprint

• You're unsure which hypothesis matters most and want the fastest way to know.
• You need a lightweight, repeatable cadence for discovery with minimal operational disruption.
• You want a clear go/no‑go decision and an evidence record that scales.

Pre‑Sprint Readiness Checklist

Run this checklist 1–3 days before the sprint start.

• Clear hypothesis: One sentence: "If we do X, then Y will change by Z because of W." (No more than one primary hypothesis.)
• Success metric: One primary measurable outcome and 1–2 safety/operational constraints.
• Scope defined: what will and will not change during the sprint (channels, feature subset, customer cohort, timeframe).
• Minimum viable prototype plan: materials, mockups, scripts, data access required.
• Data plan: how you will capture baseline and experiment data, who owns it, and where it will be stored.
• Decider named: who will make the post‑sprint decision (continue, iterate, stop, scale).
• Stakeholders invited: brief notice and agenda sent to any required approvers, operations, or compliance reviewers.

Roles & responsibilities

• Facilitator: runs the agenda, enforces timeboxes, captures decisions.
• Experiment Owner: owns the hypothesis, metrics, and the post‑sprint recommendation.
• Prototype Lead: builds the rapid prototype or orchestrates vendors/tools to create it.
• Validator / Customer Voice: runs quick interviews, user tests, or validation scripts.
• Data Steward: ensures necessary telemetry is captured and produces the outcome numbers.

Suggested 5‑day sprint agenda (compact)

Adapt timing to fit 3–5 working days. Each day includes facilitator prompts.

1. Day 0 — Prep (half day)
   • Confirm hypothesis & success metric. Facilitator prompt: "What specific number or behaviour will convince us?"
   • Finalize minimal prototype and validation plan. Make sure data hooks exist.
2. Day 1 — Build the smallest testable thing
   • Create a prototype that exercises the hypothesis end‑to‑end (not pretty—functional).
   • Facilitator prompt: "What can we show or measure by tomorrow that would change our plans?"
3. Day 2 — Run quick validations
   • Execute validation scripts: user interviews, A/B tests, funnel smoke tests, or small pilot with a constrained cohort.
   • Data Steward captures early metrics. Facilitator prompt: "What early signal will let us stop or continue?"
4. Day 3 — Iterate and broaden evidence
   • Tweak prototype and validation based on early findings. Increase sample size where safe.
   • Facilitator prompt: "Which assumption failed and what change would most change the result?"
5. Day 4 — Analyze and prepare decision
   • Data Steward presents outcome vs. success metric. Owner prepares a concise recommendation.
   • Facilitator prompt: "What does the evidence support—stop, iterate, or scale?"

Rapid Prototype Template (one‑page)

• Hypothesis: ____________________
• Primary success metric: ____________________ (include baseline)
• Prototype description: what will be shown/used and to whom
• Validation method: interview script / A/B plan / observational checklist
• Data captured: fields, storage location, responsible person
• Risks & constraints: operational, compliance, safety

Quick Validation Script (user interview / observational)

1. Intro: 30s—"We’re testing X, not you. I want 3 minutes of your feedback."
2. Task: ask participant to complete the core task; observe friction.
3. Key quantitative check: did they complete task? How long? Any errors?
4. One open question: "What did you expect to happen?"
5. Close with one prioritized suggestion from the participant.

Measurement primitives

Prefer simple, high‑signal measures you can collect quickly:

• Conversion rate for the target cohort (baseline vs experiment)
• Time to complete a critical task
• Qualitative NPS / task ease score from 5 quick users
• Observed failure rate or error counts

Retrospective & decision template

Keep it short and action‑focused.

1. What did we think would happen? (hypothesis)
2. What actually happened? (data summary)
3. What did we learn about the core assumption?
4. Decision (choose one): Stop / Iterate with changes / Scale
5. If Iterate or Scale: next experiment or scaling plan, owner, and timeline.

Common pitfalls and quick tips

• Avoid multi‑heading hypotheses—test one core assumption at a time.
• Don’t equate activity with learning—capture the data that answers the hypothesis.
• Timebox decisions—short sprints need fast closures; name the decider ahead of time.
• Use cohorts or feature flags to contain risk when testing in production.

Next steps: scale the practice

After a few successful sprints, standardize templates, and create an experiment backlog. Consider converting the prototype plan and retrospective into interactive forms so each run feeds a searchable experiment registry.

Image search phrase: sprint planning kit