Experiment failure & learning retrospective template

Purpose

This structured retrospective helps teams turn failed or inconclusive experiments into usable learning. It guides a short facilitated conversation that clarifies what happened, identifies root causes, captures improvements to protocol or data practices, and assigns concrete next actions so the same mistakes aren’t repeated.

When to use

• After an experiment that didn’t support the hypothesis, produced unclear results, or encountered major deviations.
• When an experiment had unexpected safety, quality, or reproducibility issues.
• As a lightweight post-mortem for near-miss runs that exposed process gaps.

Who attends

• Experiment owner (required)
• Primary experimenter(s) and data analyst(s)
• Lab manager or process owner (if relevant)
• A facilitator (rotating role) to keep the session productive and neutral

Timing & agenda (recommended 30–60 minutes)

1. Welcome & context (5 min)
2. Brief recap of experiment (5–10 min)
3. What happened: data & deviations (10–15 min)
4. Root cause analysis (10–15 min)
5. Learning capture & protocol updates (5–10 min)
6. Action plan & owners (5–10 min)

Facilitator script (short lines you can read)

1. "Thanks — we’ll use ~45 minutes. Our purpose is to learn, not to blame. We’ll record decisions and owners."
2. Recap: "Who can briefly state the hypothesis, key design choices, and expected outcome?" (refer to experiment record)
3. What happened: "Show the key results and any deviations from plan. What surprised us? Which data points changed our view?"
4. Root cause: "Let’s explore causes, starting with observed deviations. We’ll aim for facts and evidence, then test causal explanations."
5. Learning capture: "What should we change in the protocol, data collection, or assumptions? What new hypotheses or controls should we add?"
6. Action plan: "For each improvement, who will own it and when will it be done? We'll also decide whether to re-run, redesign, or archive."

Template questions & prompts (use during the session)

1. Brief recap
   • Experiment ID / title:
   • Hypothesis (one sentence):
   • Primary outcome metric(s):
   • Design summary and critical parameters (brief):
   • Expected outcome and pass/fail criteria:
2. What happened — evidence & deviations
   • Show key data and plots (attach links to raw data and notebooks).
   • What deviated from the plan? (measurements, timing, materials, environment, instrumentation)
   • Were there missing or unreliable data points? Describe any data-quality issues.
   • Immediate effects on conclusions (did data invalidate assumptions, reduce power, or introduce bias?):
3. Root cause analysis

   Use 5 Whys or a quick fishbone. Focus on evidence-based causes rather than speculation. Example prompts:

   • Why did the deviation occur? (repeat up to five times where useful.)
   • Was a procedure unclear or inconsistently followed?
   • Were instruments calibrated and functioning as expected?
   • Were environmental or supply issues involved?
   • Was the experiment underpowered or designed with unrealistic assumptions?
4. Learning log — capture what we learned and how to codify it
   • New knowledge (facts, patterns, limits):
   • Confirmed or refuted assumptions:
   • Protocol changes to make (exact text or pointer to protocol section):
   • Data collection improvements (fields to add, units to standardize, QC steps):
   • Documentation to update (experiment registry, SOPs, lab notebook templates):
5. Action plan

   Record discrete actions with owners and due dates. Prefer small, testable actions (3–10 tasks max).

   1. Action: [clear task statement]
      Owner: [name]
      Due: [date]
      Acceptance criteria: [how we'll know it's done]
   2. Action: ...

   Decision outcome (choose one):

   • Re-run with modifications (list required changes)
   • Redesign (new experimental approach needed)
   • Archive as a valid negative/inconclusive result (record where and why)
   • Escalate to program/PI for resource or priority decision

Example concise output (what to record in the experiment registry)

Title: [Experiment ID] — short summary of outcome and next step

Key learning: [one or two sentences]

Protocol change: [short pointer or new sentence to paste into SOP]

Next action: [task, owner, due date]

Practical tips to avoid repeated failures

• Always link retros to the experiment's raw data and notebooks to avoid reconstructing context later.
• Tag retros with common taxonomy: failure-type, root-cause-category, system/component, reagent/batch, instrumentation.
• Prefer one owner per action and clear acceptance criteria; follow up in the experiment registry or weekly huddle.
• Celebrate useful negative knowledge: share a short note in the team's knowledge feed to normalize learning from failure.

Storage & reuse guidance

Store the retrospective record in the experiment registry and link to protocol/SOP pages. Add tags and a short summary so others can find relevant learnings. Consider adding repeatable problem patterns to a team "watchlist" for broader process improvements.

Optional: quick checklist (for a 15-minute micro-retro)

1. Recap hypothesis & expected outcome (1 min)
2. State what actually happened (3 min)
3. Identify 1–2 root causes (5 min)
4. Agree on 1 immediate action + owner (3–5 min)

Why this template helps

Without a short, structured retrospective, useful lessons are lost and the same mistakes recur. This template makes it fast to extract evidence-based learning, improve protocols, and create accountable follow-through so experiments—successful or not—build organizational knowledge.