Research Retrospective & Learning Capture Template

A practical, team-friendly retrospective template to capture what went well, what failed, root causes, and concrete actions so learning is archived, assigned, and measured for follow-up.

Purpose

This lightweight retrospective template helps research teams capture outcomes, surface root causes, and convert lessons into concrete, owned actions and archival knowledge. Use it after experiments, sprints, protocol updates, or project milestones to ensure failures accelerate future discovery rather than repeat.

When to use

  • After completing an experiment, pilot, or project phase
  • When key results diverge from expectations
  • After near-miss incidents or reproducibility failures
  • At regular cadence (monthly or quarterly) as part of continuous improvement

Who should attend

Include the experiment owner(s), primary contributors (wet lab, data, analysis), a representative of quality or reproducibility if available, and a knowledge steward or librarian. Timebox to 45–90 minutes depending on scope.

Template — Fillable Sections

1. Project / Experiment Snapshot

Title: _______________________

Lead / PI: _______________________

Project ID / Experiment code: _______________________

Dates (start → end): _______________________

Objective / Hypothesis (one sentence): _______________________

Key outcome(s): _______________________

2. What went well

List concrete successes, improvements, or surprises that should be preserved or scaled.

  • Success #1 — why it mattered and evidence: _______________________
  • Success #2 — why it mattered and evidence: _______________________

3. What failed or under-delivered

Describe failures, unexpected outcomes, or gaps in reproducibility. Be specific about observed results vs. expectations.

  • Issue #1 — observed vs expected: _______________________
  • Issue #2 — observed vs expected: _______________________

4. Root cause analysis (5-whys / other)

Use the 5-whys to trace plausible causes from symptom to underlying system issues. Capture evidence and uncertainty at each step.

  1. Symptom: _______________________
  2. Why? _______________________
  3. Why? _______________________
  4. Why? _______________________
  5. Why? _______________________
  6. Why? _______________________

Most likely root cause(s): _______________________

Tip: Distinguish human, process, materials/equipment, data/analysis, and environment causes.

5. Concrete action items

Define small, testable actions that address root causes, with clear owners, due dates, and verification criteria.

Action Owner Due date Success criteria / How to verify Status
_______________________ _______________________ _______________________ _______________________ Open / In progress / Done

6. Who owns follow-up & check-ins

Follow-up owner (learning steward): _______________________

Check-in cadence: weekly / biweekly / monthly — next check-in date: _______________________

7. Knowledge artifacts to archive

List documents, protocols, data files, code, notebooks, run logs, versions, and where they will be stored.

  • Protocol / SOP location (link): _______________________
  • Raw data (path/repository): _______________________
  • Analysis code / notebook (link & commit/tag): _______________________
  • Final reports / slides (link): _______________________
  • Other artifacts (calibrations, equipment logs): _______________________

8. Tags & metadata for archival

Suggested tags to help discovery later: project-name, technique (e.g., RNAseq), instrument-id, reagent-lot, protocol-version, reproducibility-rating, hazard-level, institution/team.

9. Lessons for guidelines / playbooks

What should be added to team playbooks, checklists, or training? Be brief and actionable.

  • Playbook item #1: _______________________
  • Playbook item #2: _______________________

10. Reflection & open questions

Notes for future investigations, uncertainties to test, or decisions that need escalation.

Open question #1: _______________________

Example (short)

Snapshot: Cell line treatment pilot; objective: test compound X at 4 concentrations.

What failed: Dose–response inconsistent across runs; CV > 40%.

Root cause (summary): Variation traced to incubation temperature drift → calibration schedule missing → incubator setpoint not verified after maintenance.

Action: Add post-maintenance calibration check and a run-start checklist item; owner: lab manager; due: 2 weeks; verify: 3 consecutive runs CV < 20%.

Artifacts: run logs archived to /labdata/compoundX/pilot1, protocol v1.2 uploaded to repository, tag: compoundX, incubator-123

How to make this stick

  1. Assign a learning steward to file the retrospective and link artifacts into the shared knowledge hub.
  2. Review action items at the team huddle until verified done; close actions only after verification evidence saved.
  3. Convert recurring lessons into playbook checklist items and training for relevant roles.
  4. Use tags and metadata consistently so future teams can search by technique, instrument, reagent lot, or reproducibility rating.

Archivist checklist (before closing retrospective)

  • Upload protocol and protocol version to repository with link in this record.
  • Archive raw data and analysis code; include commit hash or version tag.
  • Tag records with agreed metadata and link to related projects.
  • Assign follow-up owner and verify first check-in scheduled.

Suggested minimum metadata to capture with this record

  • Project/Experiment name, PI, team
  • Dates and versioned protocol identifier
  • Instrument IDs and reagent lot numbers
  • Data repository paths and code references
  • Reproducibility rating (e.g., reproducible / partial / not reproducible)
  • Tags (technique, instrument, hazard, priority)

Further improvements (capability opportunities)

Consider converting this template into an interactive form so teams can save retrospectives, track action-item status over time, and generate dashboards of recurring root causes and open actions. Storing structured fields (owner, due date, tags, reproducibility rating) enables aggregation across projects and helps reduce repeated mistakes.


Discussion

Comments and conversation will live here.