**An estimate quietly converted into a commitment or deadline, then held against the team.**
An estimate is a guess made with the least information you'll ever have about a piece of work. A commitment is a promise. Estimate laundering is the trick of treating the first as if it were the second: the guess goes into the planning meeting, a deadline comes out, and when the deadline slips it's recorded as the developer's failure to hit "their" number. The tell is the missing conversation: nobody ever said the words "we are now committing to this date," so the team is bound by a promise it never actually made.
*Failure mode:* [Power](/guides/agile-theatre/power-agile-theatre/). *Go deeper:* [story points vs hours](/guides/agile-estimation-guide/story-points-vs-hours/) and Mike Cohn on separating estimating from committing.
Feedback banking
**Honest retrospective input stored up and withdrawn against you at review time.**
The retrospective is sold as a safe place to be candid. Feedback banking is the discovery that candor has a settlement date: a frustration you named in a retro can resurface months later in a performance review, a bonus calibration, or a quiet conversation about "fit." It doesn't require a villain; the mere presence of someone who signs off on promotions is enough to teach a team that the safe move is to perform contentment. A retro where honesty is a career risk isn't a safe retro, and it's why anonymity, manager-exclusion and the Vegas rule exist at all.
*Failure mode:* [Power](/guides/agile-theatre/power-agile-theatre/). *Go deeper:* [how to build a psychologically safe space](/guides/scrum-masters-retrospective-guide/how-to-build-a-psychologically-safe-space/).
Velocity ratchet
**Velocity treated as an ever-rising productivity target, so teams inflate to keep up.**
Velocity is meant to be a team's private forecasting input: the rolling average of points completed, used to project how long a backlog will take. The velocity ratchet is what happens when it escapes the room as a performance metric: last sprint's number becomes this sprint's floor, and the only permitted direction is up. Teams respond the only way the incentive allows (a story that was a 3 becomes a 5), so the number climbs while nothing ships faster. Even the pro-points authorities warn that any hint of cross-team comparison produces exactly this inflation.
*Failure mode:* [Power](/guides/agile-theatre/power-agile-theatre/). *Go deeper:* [velocity](/guides/agile-estimation-guide/velocity/) and the [DORA metrics](/guides/agile-metrics/dora-metrics/) on why velocity isn't a delivery measure.
Pressure valve (retro-as-)
**A retro that lets people vent so leadership feels heard, with no power to change the causes.**
When the problems that actually matter (budget, headcount, dependencies, decisions made two levels up) are outside the team's authority, the retrospective can name them but not fix them. It becomes a pressure valve: the team gets to speak precisely so that nothing has to change, releasing just enough steam to give leadership an excuse not to act. The antidote is a *radiator*, not a valve: triage each issue by who owns it, escalate the red ones upward by name and date, and keep them visible until someone with the power to fix them does.
*Failure mode:* [Void](/guides/agile-theatre/the-follow-through-void/). *Go deeper:* the follow-through void, [why retrospectives fail](/guides/scrum-masters-retrospective-guide/why-retrospectives-fail/), and *Agile Retrospectives* (2nd ed) on Circles & Soup and Retrospective Radiators.
## Frequently asked questions
### Are these official agile terms?
No. We coined them in this field guide. They aren't in the Scrum Guide or the standard texts. We named them because the failure modes are common enough to deserve nouns and nobody had named them cleanly. The underlying failures are thoroughly documented; the labels are ours, and you're welcome to use and cite them.
### What's the difference between velocity ratchet and estimate laundering?
Both are Power-mode distortions of estimation, but they act on different numbers. The velocity ratchet turns a team's private pace metric into an ever-rising target, so teams inflate points to keep up. Estimate laundering converts a single up-front guess into a commitment and then holds the team to it. One weaponises the trend; the other weaponises the individual estimate.
## Related reading
- [Agile Theatre: the field guide](/guides/agile-theatre/). The four failure modes in full.
- [Power: when authority captures the ceremony](/guides/agile-theatre/power-agile-theatre/). Where estimate laundering, feedback banking and the velocity ratchet live.
- [Void: when the ceremony changes nothing](/guides/agile-theatre/the-follow-through-void/). The retro-as-pressure-valve, and the radiator that replaces it.
---
# Agile Theatre: a field guide to how ceremonies fail
URL: https://www.teamretro.com/guides/agile-theatre/
Agile theatre is what an agile ceremony becomes when it's run for appearance instead of function: the standup, the planning session or the retrospective happens on schedule and looks the part, while the thing the meeting exists to produce quietly doesn't. The reliable tell is that the ceremony's real audience has stopped being the team.
It usually isn't a failure of effort, and a fresh format won't fix it. It sets in for structural reasons: a manager the standup is really performed for, a velocity figure graded from above, a retrospective whose actions never survive into the next sprint. That is why it shows up in four recognizable modes rather than as one vague sense that agile isn't working.
## Telling the real thing from the performance
| A ceremony is doing its job when… | It's theatre when… |
|---|---|
| The team talks to each other and to the board | Everyone reports to the most senior person in the room |
| Estimates stay forecasts the team owns | Estimates harden into commitments held against the team |
| Dropping the meeting would be missed | Dropping it would cost nothing but calendar time |
| Last retro's action actually happened | Nothing changes after the retro |
Each mode below is that gap at its sharpest: the ceremony it captures, and how to run that ceremony for real instead. If you want the meetings explained straight first, start with what the [agile ceremonies](/guides/agile-ceremonies-guide/) are actually for; if the right-hand column already looks familiar, read on.
---
# Agile Verdicts: straight answers to the arguments teams keep having
URL: https://www.teamretro.com/guides/agile-verdicts/
Ruling-first answers to the arguments agile teams keep having — are standups micromanagement, story points vs #NoEstimates, whether retros are worth it, and if velocity is a useful metric. We steelman both sides, then rule.
---
# AI agents joined your team. Your improvement loop hasn't noticed.
URL: https://www.teamretro.com/guides/ai-agent-retrospectives/
*This guide is about applying something teams already know, the continuous-improvement cycle, to something new: the work your team now does with AI agents. We build retrospective software, so this lens is the one we know best; the loop it describes works in whatever tools and ceremonies you already have.*
*Want the 10-minute version first? Start with the quick-start post, [gather feedback from AI agents](/blog/gather-feedback-from-ai-agents/), then come back here for the full picture.*
## The oldest trick in teamwork
Every method your team uses to get better is a version of one loop: **do the work, look at how it went, change something, check that the change helped.** Deming taught it to manufacturing as Plan–Do–Check–Act; Toyota made it a culture and called it kaizen; software made it a ceremony. Norm Kerth's *Project Retrospectives* (2001) popularized the retrospective for software teams, and the Agile Manifesto pinned it as a principle: *"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly"* ([principle 12](https://agilemanifesto.org/principles.html)). Blameless postmortems run the same loop for incidents; a media team's campaign wash-up and a support team's triage review run it without ever using the word "agile."
The loop works because of one premise: **work generates evidence about how work should change.** Teams that harvest that evidence compound: each cycle makes the next one better. Teams that don't, repeat themselves.
For seventy years, the evidence came from people. People noticed the friction, complained at lunch, raised it in [the retro](/retrospectives/). The loop's sensors were human.
## A new kind of worker
Sometime in the last two years, your team started delegating real work to a new kind of worker. AI agents now write and review code, audit ad accounts, draft support replies, build reports, migrate content. And this worker has a strange profile: tireless, fast, capable, and context-starved. Rahul Garg's framing has become the field's shorthand: *"AI assistants are like junior developers with infinite energy but zero context,"* which is why *"the time saved by AI-generated code is often consumed by the effort required to correct it"* ([Patterns for Reducing Friction in AI-Assisted Development](https://martinfowler.com/articles/reduce-friction-ai/)).
That correction cost is **friction**, and agent work generates it constantly: the ambiguous brief that forced a guess, the doc that didn't exist, the account structure that fights every session, the tool that timed out, the requirement that changed mid-task. Nothing about this is new. Human work generates the same list. Two things about it are new.
**The new worker doesn't complain at lunch.** An agent hits a wall, works around it, and moves on. It doesn't get frustrated enough to raise the problem in Friday's retro. The signal your improvement loop has always relied on (a person minding the friction until a ceremony collects it) doesn't fire.
**And the evidence evaporates.** When the session ends, the friction's context dies with it. Next session (next person, same agent) hits the same wall fresh. You can't improve on evidence you never captured; the loop starves quietly while the work looks fine.
So here's the situation, stated plainly: **a growing share of your team's work now produces improvement evidence that your improvement loop was never wired to collect.**
## The field noticed, and rebuilt the loop solo
The people closest to agent work saw this early, and by mid-2026 "capture agent friction and feed it back" is consensus practice under at least half a dozen names: Garg's [Feedback Flywheel](https://martinfowler.com/articles/reduce-friction-ai/feedback-flywheel.html), Every's [Compound Engineering](https://every.to/source-code/compound-engineering-the-definitive-guide), Osmani's [Loop Engineering](https://addyosmani.com/blog/loop-engineering/), Thoughtworks' [sensor-instrumented harness engineering](https://www.thoughtworks.com/en-us/insights/blog/generative-ai/harness-engineering-agent-feedback-exploring-ai-coding-sensors), the platform vendors' fleet-scale memory loops ([OpenAI's "dreaming"](https://openai.com/index/chatgpt-memory-dreaming/), [Factory Signals](https://factory.ai/news/factory-signals)), and GitHub's [`gh-aw`](https://github.com/github/gh-aw), whose session-insights workflows already generate automated session-analysis reports. Even the vendors reach for the retro word: OpenAI's Codex guidance reads *"when Codex makes the same mistake twice, ask it for a retrospective and update AGENTS.md"* ([best practices](https://learn.chatgpt.com/guides/best-practices)).
These loops are good. If your team runs any of them, keep it; everything in this guide builds on them rather than replacing them. But notice two gaps.
First, the practice gap: watching isn't improving. Around 90% of teams instrument their agent traces; only about 37–52% systematically evaluate what they capture ([LangChain, Jun 2026](https://www.langchain.com/state-of-agent-engineering)). Most teams have the dashboard. Far fewer have the loop.
Second, the shape gap: **nearly every loop in the field is solo.** One practitioner tuning their personal playbook, one platform curating its fleet's memory, one observability stack clustering its own traces. Seventy years of continuous improvement says the compounding happens at the *team*: where the aggregate view lives, where priorities get reweighted, where process and docs and budgets have owners. That layer is exactly the piece nobody has rebuilt. The reports exist; the room hasn't been booked.
Solo, each friction note is too small to be worth fixing. Aggregated on the team's board, the same notes stack into one of its largest costs: the reweighting only the team layer can see.
## The anatomy of the loop
When your team decides to wire this up, the loop has more moving parts than it first appears. The journey a single piece of friction has to survive:
| Stage | The question |
|---|---|
| **Hosting** | Where does the agent run, and what does that make observable? |
| **Detection** | How is friction noticed? (Self-notice, a reviewing agent, telemetry, and human correction, which is still the dominant sensor: [~70% of silent failures are first caught by a person](https://arxiv.org/abs/2606.14589)) |
| **Instrumentation** | What *makes* the agent record it? (Nobody logs friction they weren't told to look for) |
| **Recording** | What does a useful record contain, and where does it live? |
| **Harvesting** | How do records from many sessions and many people come together? |
| **Synthesis** | Which patterns matter, and *at what level* does each fix belong? |
| **Close the loop** | Did the fix actually reduce the friction, or was it theatre? |
Three disciplines make the difference between a loop and a diary, and each gets its own chapter in this guide:
- **Records, not vibes.** A useful entry cites the moment, names one root cause from a small fixed vocabulary, and proposes a ticket-sized fix. Fixed labels are what let entries aggregate: "the docs were confusing" can't be counted; eight `missing-documentation` entries can. *(Chapter: [What a good friction record looks like](/guides/ai-agent-retrospectives/ai-friction-records/))*
- **The altitude question.** Every recurring pattern gets fixed at some level: a memory note, a prompt, config, the docs, the work material itself, the process, or upstream with a vendor. Route the fix too low and it recurs for everyone else; too high and you bloat an artifact nobody reads. *(Chapter: [Where should the fix land?](/guides/ai-agent-retrospectives/where-should-the-fix-land/))*
- **Judgment in a room.** Some friction is deliberate: the review gate someone chose as a control point ([a recap of Ronacher's AIE Europe talk](https://www.youtube.com/watch?v=_Zcw_sVF6hU): "friction is what's necessary… to steer"; Thoughtworks now warns of the [cognitive debt](https://www.thoughtworks.com/about-us/news/2026/combat-ai-cognitive-debt-radar-v34) of over-frictionless agent work). Keep-or-kill, priorities, and cross-owner fixes are negotiations, not computations. They need the fix-owners in one conversation. *(Chapter: [The report exists. The room doesn't.](/guides/ai-agent-retrospectives/the-report-exists/))*
## Where the story goes
Garg's cadence list for the flywheel includes a line that is almost a dare: *"an agenda item in the existing sprint retrospective: what worked with AI this sprint?"* ([martinfowler.com](https://martinfowler.com/articles/reduce-friction-ai/feedback-flywheel.html)). That's the thread this guide pulls. Not a new ceremony, not an AI-run one: the improvement loop your team already trusts, extended to cover the newest worker on it, with the agent as a *participant*: it brings the evidence, drafts the fixes, answers questions; the team keeps the judgment, because the fixes land in processes, documents, and budgets that people own and answer for.
And an honest floor to start from: if your team just adds the agenda item and talks (no log, no labels), that's already better than silence, and for light agent use it may be enough. The rest of this guide is what you add when that conversation keeps repeating itself.
## The chapters
1. **This page**: why AI-assisted work needs the loop your team already runs.
2. **[The map: agent feedback loops, tools, and approaches](/guides/ai-agent-retrospectives/agent-feedback-loops/)**: the reference framework covering the friction lifecycle, the named loops the field has built, and the classification schemes in use. Start here if you think top-down.
3. **[What a good friction record looks like](/guides/ai-agent-retrospectives/ai-friction-records/)**: capture in the moment, the root-cause labels, the never-log rules.
4. **[Where should the fix land?](/guides/ai-agent-retrospectives/where-should-the-fix-land/)** The altitude problem, and the routing table.
5. **[The report exists. The room doesn't.](/guides/ai-agent-retrospectives/the-report-exists/)** Why synthesis is a team ceremony, priced against its rivals.
6. **[Running the AI collaboration retro](/guides/ai-agent-retrospectives/running-the-ai-collaboration-retro/)**: the facilitator's guide, with the 15-minute agenda item, the template, and the prompt cards.
7. **[Get started in ten minutes](/guides/ai-agent-retrospectives/get-started/)**: [`ai-session-retro` and `ai-retro-brief`](https://github.com/TeamRetroHQ/teamretro-skills), the capture and synthesis ends of the loop, ready to install.
Prefer the short form? Two companion posts on the blog: the quick start, [gather feedback from AI agents](/blog/gather-feedback-from-ai-agents/), and the story of the first time we ran it ourselves, [our AI teammates joined our retro](/blog/our-ai-teammates-joined-our-retro/).
## Frequently asked questions
### Do AI agents need their own separate retrospective?
No. The approach in this guide extends the improvement loop your team already runs, often as a single agenda item in the existing retrospective, rather than adding a new ceremony. The agent participates by bringing evidence and drafting fixes; the team keeps the judgment.
### Why doesn't AI agent friction show up in normal retrospectives?
Two reasons. Agents don't complain: they hit a wall, work around it, and move on, so nobody carries the problem to the retro. And the evidence evaporates: when the session ends, the friction's context dies with it, so the next session hits the same wall fresh.
### We already log our agent traces. Isn't that enough?
Watching isn't improving. Around 90% of teams instrument their agent traces, but only about 37–52% systematically evaluate what they capture. The traces are raw material; the loop needs capture discipline, synthesis, and a team-level venue where fix-owners decide together.
### Should the AI run the retrospective itself?
No. The agent is a participant: it brings the evidence, drafts the fixes, and answers questions. The team keeps the judgment, because the fixes land in processes, documents, and budgets that people own and answer for.
### What's the minimum viable version of this practice?
Add one agenda item to your existing retrospective (what worked with AI this cycle?) and talk. No log, no labels. That's already better than silence, and for light agent use it may be enough. The rest of the guide is what you add when that conversation keeps repeating itself.
*We'd rather be argued with than agreed with politely. Every chapter ends with what would change our minds.*
---
# What a good friction record looks like
URL: https://www.teamretro.com/guides/ai-agent-retrospectives/ai-friction-records/
## Why records, not memories
One session's friction is noise. The same friction across eight sessions is a pattern your team can fix, but only if those eight sessions left behind records you can actually read together: consistent (same schema, so they're comparable) and honest (evidence-cited observations, not vibes).
Neither happens by default. The moment friction occurs is the moment of maximum information about it: the exact stale line in the runbook, the exact parameter the brief left open. That information decays fast. The agent normalizes its own workaround within a few turns, and at session end the signal is gone unless something wrote it down; whatever a subagent figures out *"vanishes the moment it returns"* ([Hindsight, May 2026](https://hindsight.vectorize.io/blog/2026/05/06/claude-code-subagents-shared-memory)). This chapter is about the writing-down.
## How friction gets noticed
Before anything can be recorded, it has to be noticed. Four channels, and they see different things:
**The agent notices itself struggling.** Retry loops, backtracking, re-reading the same file or re-querying the same analytics view, a guess forced by a gap in the brief. Production platforms have converged on essentially this behavioral-signal list ([Factory Signals, Jan 2026](https://factory.ai/news/factory-signals)). The cheapest channel, with two honest limits: it's blind to absent things (a retry loop is felt; a document that never existed produces no signal), and self-observation outruns self-diagnosis: models localize their own agentic errors poorly even on curated traces (~11%, [TRAIL](https://arxiv.org/abs/2505.08638)). So the in-session job is to observe symptoms and cite evidence, holding the diagnosis loosely.
**A second agent reviews the transcript.** A fresh reviewer catches what the working agent normalized. More objective; costs a second pass and carries its own judgment errors.
**A human corrects the agent.** Still the dominant sensor: an 8-week production study found ~70% of silent agent failures were first caught by a person noticing something felt off, not by unit tests, health checks, or governance audits ([arXiv 2606.14589](https://arxiv.org/abs/2606.14589)). Every correction (a reviewer's "no, I meant…", a stakeholder re-explaining the brief mid-audit) marks exactly where context diverged from intent, and the agent can capture it in the moment at zero extra process cost.
**Telemetry.** Tool-error rates, permission denials, loop counts, long durations. Automatic and unbiased, but shallow: it knows *that* something happened, not *why*.
The strongest setups triangulate: telemetry flags *where* to look, a review pass explains *why*, and human correction fills in the class of problem no self-signal can reach. Whatever mix you run, what survives should be the same thing: a record.
## What makes the agent record it
An agent won't record friction nobody told it to look for. Most friction goes unrecorded not because it wasn't noticed but because nothing made capture happen. Four mechanisms, differing mainly in what guarantees firing:
- **A skill**: a versioned, written procedure the agent executes at session end. Carries the schema and the honesty rules, so what fires is consistent: the same procedure works on a refactor and an ads-account review. Weakness: invocation is probabilistic; it can silently never fire.
- **A hook**: the harness itself triggers or reminds (a session-start injection, a session-end trigger). Deterministic (the only option that depends on nobody remembering anything), but blunt (it fires on the two-minute session too) and platform-bound.
- **A convention line**: one standing instruction in the scope's context file, or its non-code twin, a step in the team SOP: "end every substantial AI-assisted session by logging friction." Zero infrastructure, but it leans entirely on the model honoring one line among many, and it decays as the file grows; the named failure mode is the memory file that has *"stopped being read"* ([anti-patterns field note](https://www.digitalapplied.com/blog/claude-code-anti-patterns-team-adoption-failure-modes-2026)).
- **A command**: a human-typed `/retro` at the end of a feature branch or a triage shift. Deliberate and precisely timed; the weak link is human memory.
These compose; layer them. A deterministic trigger (hook, or an end-of-shift SOP step), a procedural payload (the skill), and a convention line that names the practice as a norm. Pick at least one trigger; two is better. Even vendors have landed on the instinct: OpenAI's Codex guidance reads *"when Codex makes the same mistake twice, ask it for a retrospective and update AGENTS.md"* ([best practices](https://learn.chatgpt.com/guides/best-practices)).
## The anatomy of a good entry
A record is the contract between the session that noticed the friction and everything downstream. Synthesis quality is capped by record quality. Four load-bearing parts:
One entry, four parts: the evidence-cited moment with its cost, exactly one root-cause label, a ticket-sized fix, and permission to say nothing.
**1. An evidence-cited moment, with its cost.** What happened, when, and the observable consequence, specific enough that someone who wasn't in the session could act on it. Cost means redone work, wasted time, wrong output; a record without cost can't be ranked later. Agent-estimated cost is soft: mark it `(est.)` rather than faking precision.
**2. Exactly one root-cause label** from a fixed ten-label vocabulary. Fixed vocabularies can be labeled reliably (MAST reached κ = 0.88 on 14 failure modes; see [arXiv 2503.13657](https://arxiv.org/abs/2503.13657)); free-form categories drift per person and stop aggregating. The ten:
- `ambiguous-instruction`: the ask left a key parameter open (audience, scope, definition, time window) and forced a guess
- `missing-context`: a standing fact the team knows but didn't share
- `incorrect-context`: information provided was wrong
- `missing-documentation`: a doc that should exist doesn't (no README, spec, runbook, or SOP)
- `incorrect-documentation`: a doc exists but is stale or wrong, and was relied on
- `work-material-friction`: the material being worked on made the work slow or error-prone: tech debt or confusing structure in code; a tangled account, board, spreadsheet, or template outside it (always name the concrete material)
- `missing-access-or-tool`: a needed connector, permission, or tool wasn't available
- `agent-error`: the agent's own mistake (wrong assumption, stale knowledge, a bug it introduced)
- `changed-requirements`: the ask changed mid-session and work was redone
- `environment-friction`: tooling failures, timeouts, sandbox or platform issues
One label per finding keeps the distributions honest: pick the closest fit, note the strain in the evidence, never invent a label mid-entry. Three boundary rules do most of the disambiguating work. The *agent-knowable test*: was the fact findable anywhere the agent could reasonably look? Found nowhere it should have been → `missing-documentation`; supplied only later, by a person → `missing-context`. *Agent-error is the residual*: use it only when the inputs were adequate and the agent still erred; if the error traces to a bad input, label the input. And *ambiguity versus movement*: if clarifying revealed what was always meant, it was `ambiguous-instruction`; if the goal genuinely moved, it's `changed-requirements`.
**3. A ticket-sized fix, naming its altitude.** The altitude is the level the fix targets: memory, skill, environment, docs, the material itself, process, or upstream. A friction record with no fix attached is a complaint.
Here's a complete entry from a non-code session, a monthly ads-account review:
```markdown
- **[missing-context]** The brief didn't say the French campaigns were deliberately
paused for Q3; ~40 min (est.) auditing a "broken" campaign that was fine.
→ Fix (altitude: process): add campaign-status flags to the monthly brief template
```
A moment, a cost with an `(est.)` marker, one label, a fix somebody could pick up next week. Compare the unusable version of the same observation, "the brief was confusing": no moment, no cost, no next step. Vagueness is itself a failure mode.
**4. Permission to say nothing.** "Nothing notable" is a valid and useful answer; a log padded with manufactured findings drowns the real ones.
One more design point: recording should be **ungated**: an agent that needs permission to record friction under-reports. Let it file freely, and let human feedback land as correction after the fact: additive signal from the person who was in the session too, not a checkpoint the loop waits on.
## The never-log rules
Records outlive their sessions: they get committed, shared, and aggregated. Some things never go in:
- **Secrets, credentials, tokens, or API keys**, in any form, even partial.
- **Customer data or personal information.**
- **Unreleased business numbers or confidential figures**: describe the effect, not the data.
- **Above all, people.** Never a name, a role, or anything that identifies who caused a gap. Describe the gap and what it cost: "the brief left the audience open," not "X's brief." Entries critique inputs and systems, not people. That is the same discipline a good [retrospective](/retrospectives/) runs on, and what makes the log safe to read together.
Critiquing the *inputs* is expected: unclear briefs, missing context, and late requirements are usually where the actionable material lives. The agent should critique itself with the same honesty. If a scope's friction can't be described without sensitive context, keep that scope's entries private and share only the aggregated brief.
## Where the log lives
One log per **review scope**: the boundary where fixes land. For most dev work that's the repo: its docs, config, and conventions are repo-homed, so its friction log is too. Outside code, the scope is the ads account, the support inbox, the client engagement; keep the log in that workspace's document home. A record filed outside its scope is one the eventual fix-owner never finds; an entry written to a scratch directory dies with the session.
What must stay identical everywhere is not the storage but the shape: **the schema, not the storage, is what makes entries aggregate later.** That's the whole team angle of this chapter: comparable records, across people, agents, sessions, and tools, are what make team-level aggregation possible at all. Adapt the storage freely; guard the schema.
## What comes next
A pile of good records is raw material, not insight. The next chapters take it from here: choosing the [**altitude** of each fix](/guides/ai-agent-retrospectives/where-should-the-fix-land/) (the difference between a memory note and the refactor the friction keeps pointing at); [synthesizing entries into a one-page brief](/guides/ai-agent-retrospectives/the-report-exists/) the team can read together; and [the ceremony where humans and the log meet](/guides/ai-agent-retrospectives/running-the-ai-collaboration-retro/) (the retrospective, with the agent's records as a participant's input). The loop is one instance of the Feedback Flywheel: harvest learnings back into the artifacts that supply context ([martinfowler.com](https://martinfowler.com/articles/reduce-friction-ai/feedback-flywheel.html)). And the entry discipline is error analysis, *"the most important activity in evals"* ([Husain & Shankar, evals FAQ](https://hamel.dev/blog/posts/evals-faq/)), moved to the cheapest possible moment: while the session that hit the friction is still open.
Everything above works with a text file and any capable agent. If you'd rather not build the template yourself, the free [`ai-session-retro` skill](https://github.com/TeamRetroHQ/teamretro-skills) implements this entry shape end to end; the [quick-start post](/blog/gather-feedback-from-ai-agents/) walks through installing it in about ten minutes.
**Next chapter:** [Where should the fix land?](/guides/ai-agent-retrospectives/where-should-the-fix-land/) covers the altitude problem and the routing table.
---
# Are retrospectives worth it? Our verdict
URL: https://www.teamretro.com/guides/agile-verdicts/are-retrospectives-worth-it/
**Yes, but not for the reason most teams defend them. A retro earns its hour through learning and team cohesion, not through a tidy list of action items.** If yours only produces words, the ritual isn't the problem. The follow-through is, and so is the team's power to act.
"Retros are a waste of time" isn't a lazy complaint. It's the most serious critique anyone makes of agile ceremonies, and the honest defense has to go through it, not around it.
## The case that retros are pointless
The skeptics' evidence is specific and it's everywhere. Concerns get aired and nothing happens; the same sticky note comes back sprint after sprint with the quiet resignation that it won't be addressed this time either. By one commonly-cited survey, only about [a third of teams](https://www.easyagile.com/blog/improve-sprint-retrospective-action-items) consistently finish their retro action items, and even that framing misses the deeper failure. (For what it's worth, the folklore is too gloomy: our own data on whether [teams actually do what they decide in retrospectives](/guides/follow-through-index/) puts action completion closer to three in four.)
The deepest version of the critique is powerlessness. The meaningful problems (budget, headcount, cross-team dependencies, infrastructure, decisions made two levels up) are genuinely outside the team's authority. So the retro becomes the place those problems get named and nothing more: the team is handed a voice but no lever to pull. Worse, it gives leadership an excuse. There's a channel for gripes now, so if nothing improves, that's the team's outlet not functioning, not the org's problem to fix.
Then there's the career risk, which almost no vendor page will name. When honest feedback gets stored up and quoted back in a performance review, flagged as complaining too much, people learn the lesson fast: candor is a liability. And there's a real cost even to the venting itself. Sitting through an hour of other people's frustrations, sprint after sprint, is its own quiet drain.
That is a formidable case. A retro that behaves like this is worse than no retro, because it teaches learned helplessness on a two-week cycle.
A retro that only surfaces team-controllable items is comfortable but dishonest. When the real blocker is out of the team's hands and the meeting quietly buries it, the retro has become a [pressure valve](/guides/agile-theatre/agile-theatre-glossary/#pressure-valve), and [feedback banking](/guides/agile-theatre/agile-theatre-glossary/#feedback-banking), where candor is punished later, is what teaches people to stop raising the things that matter.
## Why they are still worth it
The defenders' strongest line isn't "action items get done." It's cohesion. Even an imperfect retro, held as a regular, un-skippable ceremony, does more for a team's ability to work together than its absence. Teams that never stop to talk suffer internal strife far more often than teams that do. The most telling redemption story in the discourse is the engineer who went from dreading retros to looking forward to them, and realized the difference was that they had simply never seen one run properly.
The current canon backs this. The second edition of *[Agile Retrospectives](https://pragprog.com/titles/dlret2/agile-retrospectives-second-edition/)* (2024, with David Horowitz added as a third author) makes the shift explicit: the success criterion is *learning*, not a checklist of actions. A retro where the team genuinely understood something isn't a failure because it produced no ticket. That single reframe answers the number-one complaint, because "nothing changed" stops being the only measure of a retro's worth.
## Where we would change our mind
We would tell a team to stop running retros in one specific situation: when the real problems are overwhelmingly outside its control, leadership won't act on escalations, and the meeting has no power and no follow-through. At that point the retro is theatre, and we would rather you fix the escalation path, or shrink the cadence to something honest, than keep performing reflection every fortnight. A powerless retro isn't a neutral waste of an hour; it actively erodes trust.
We would also cut the cadence, not the ceremony, when a team has genuinely run out of new things to say. A weekly retro on a team where nothing has changed decays into a tick-box ritual. That's a frequency problem, not proof retros are worthless.
## The practical take
- Redefine success as learning, not action items. Aim for one real change or one shared insight per retro, and review last time's at the top of this one. A long list is how retros become [box-ticking theatre](/blog/avoid-these-retrospective-anti-patterns/).
- Triage issues by who owns them, and escalate the ones outside the team's control by name and date. Do not tell people to "stay in their circle of influence" if that means burying the real blocker. Radiate it outward instead.
- Protect safety, because feedback banking is real. Exclude the authority figure whose presence quiets the room, keep what is said in the room, and offer anonymity as an option per idea. Psychological safety isn't a soft nicety: Google's Project Aristotle found it the single biggest factor in team effectiveness, building on Amy Edmondson's research.
- Right-size the cadence. If there is nothing new to reflect on weekly, run it fortnightly. Forced reflection is its own anti-pattern.
The [Scrum Guide](https://scrumguides.org/) says the retrospective is the team inspecting itself to improve. So the moment it's being run *at* the team rather than *by* it, you've lost the thing that made it worth an hour. That's the [Void failure mode](/guides/agile-theatre/the-follow-through-void/), reflection with nothing downstream of it, and it's the most fixable one on this list.
## Frequently asked questions
### Are retrospectives a waste of time?
They are when they only produce words, when the same concerns get aired every sprint and nothing changes. But the fault is usually the follow-through and the team's power to act, not the ceremony itself. A retro that leads to learning and small, owned change earns its hour; one that functions as a pressure valve does not.
### Does a retrospective need an action item to be worthwhile?
No. The second edition of Agile Retrospectives reframes success as learning, not a to-do list. A retro where the team genuinely understood something is not a failure just because it produced no ticket. Chasing action items for their own sake is how retros become box-ticking. Aim for one real change or one shared insight, not a long list that half-vanishes into the backlog.
### When is a retrospective genuinely not worth running?
In one specific situation: when the real problems are overwhelmingly outside the team's control, leadership won't act on what gets escalated, and the meeting has no power and no follow-through. A powerless retro isn't a neutral waste of an hour. It actively erodes trust by teaching the team that speaking up changes nothing. Fix the escalation path or shrink the cadence to something honest rather than performing reflection every fortnight. And if the team has simply run out of new things to say, cut the frequency, not the ceremony.
## Related reading
- [Why retrospectives fail (and how to make yours matter)](/guides/scrum-masters-retrospective-guide/why-retrospectives-fail/): the deep dive on powerlessness, weaponised feedback and the follow-through void.
- [Why retrospectives are a useful agile tool](/guides/scrum-masters-retrospective-guide/why-retrospectives-a-useful-agile-tool/): the case for the ceremony, made plainly.
- [How to build a psychologically safe space](/guides/scrum-masters-retrospective-guide/how-to-build-a-psychologically-safe-space/): the antidote to feedback banking.
- [Agile Theatre: the Void failure mode](/guides/agile-theatre/the-follow-through-void/): reflection with nothing downstream, and how to escalate what the team cannot fix alone.
- [Agile and retrospective statistics](/guides/agile-statistics/#sprint-retrospectives-and-continuous-improvement): the measured case for retrospectives, each figure quoted with its conditions and linked to its source.
- [Retrospectives in TeamRetro](/retrospectives/): run one that leads to learning, not just words.
---
# Are standups micromanagement? Our verdict
URL: https://www.teamretro.com/guides/agile-verdicts/are-standups-micromanagement/
**A standup isn't micromanagement by design, but it becomes micromanagement the moment it's run *for* a manager instead of *by* the team.** The dividing line isn't the meeting. It's the direction the updates point.
This is one of the most repeated complaints in developer forums: the daily standup is the daily confession, fifteen minutes of proving you earned yesterday's pay. Take it seriously: when it's true it's corrosive, and it's true more often than the ceremony's defenders like to admit.
## The case that it is micromanagement
Take the strongest version of the argument, because it's a good one.
The status already exists. Modern teams have ticket boards, pull requests, commit history and Slack. Forcing everyone into a synchronous recital of information that's already in the system of record is redundant; the deadpan version is *we have Slack now*. When the recital points at the front of the room, it stops being coordination and becomes a reporting layer: the clearest tell is a team lead taking notes during the standup to forward to managers who don't even attend.
Then there's the human cost, which vendor content almost never names honestly. Standup anxiety is real. People rehearse their thirty seconds, hold a little work back on good days so they have something to show on bad ones, and describe keeping up appearances as most of the job. That's not coordination. That's performance, and performance is exhausting.
The interruption is the second-order tax. A mid-morning standup doesn't cost fifteen minutes; it costs the context switch on either side of it: the ramp-down before and the ramp-up after. And the enforcement tell is the sharpest of all: a team trims a bloated standup down to a tight fifteen minutes, it works, and a returning manager restores the full hour within two days. If the meeting truly exists for the team, why does shortening it threaten someone above the team?
That's a strong case. A standup that behaves this way *is* micromanagement, and the people sitting through it are right to resent it.
## Why it is not, when it is run right
The [Scrum Guide](https://scrumguides.org/) is unusually blunt here: the Daily Scrum is an event *for the developers*, who run it to inspect their own progress and plan the next day of work. It's explicitly not a status meeting, and the manager isn't meant to be the one asking the questions. There's a satisfying jiu-jitsu here: the guide teams invoke to justify the ceremony is the same guide that says it isn't the manager's meeting. Quote it back.
Run that way, a standup does something no dashboard does. It surfaces the blocker nobody filed a ticket for, and it creates the small serendipity where one person names what they're about to start and another says *I wrote a script for that last month*. That payoff only lands when the work is genuinely interdependent, but when it is, the standup earns its slot.
The test for micromanagement isn't whether a manager is in the room. It's whether the meeting is theirs. If updates are aimed at the front to prove effort, it's an audit. If they're aimed sideways to coordinate work, it's a standup. Same fifteen minutes, opposite meetings.
## Where we would change our mind
We would concede the "it's micromanagement" verdict without argument in three cases: a manager runs the meeting and interrogates the updates; attendance is enforced as a check on presence rather than a coordination need; or what someone says gets stored up and quoted back at review time as evidence they complain too much. Any of those, and the honest word for the meeting is micromanagement.
We would also drop the daily cadence rather than defend it when the team's work isn't interdependent day to day. For people working parallel, non-overlapping tickets, a daily verbal sync is a solution to a problem they don't have. Two or three a week, or a written async update, coordinates just as well. [Async and remote standups](/guides/daily-standup-guide/async-and-remote-standups/) is a real option, not a downgrade. But it has its own failure mode worth naming plainly: the honest admission from teams that switched is that not everyone reads the thread, and a blocker can sit longer than it would on a call. Async is a trade, not a free win.
When tickets genuinely overlap, the daily earns its slot; when everyone's in a separate lane, two or three syncs a week (or an async thread) covers it without the daily interruption.
## The practical take
- Point the updates sideways. Organize the meeting around the work on the board, not a lap of the room. [Walk the board](/guides/daily-standup-guide/daily-standup-agenda/) instead of walking the people.
- Make it explicitly the team's meeting. If a manager attends, their role is to listen and clear the blockers only they can clear. Redirect updates that drift toward the front: tell the team, not me. The [manager-report anti-pattern](/guides/daily-standup-guide/standup-anti-patterns/) is the one to watch for.
- Give status-hungry managers the board or an async digest, not a seat that quiets the room. Sharing the *information* costs nothing; requiring the *ritual* costs the team its candor.
- Timebox hard and parking-lot the problem-solving. The fastest way to make a standup feel like surveillance is to let it run long enough that people start performing for it.
The honest answer to "are standups micromanagement?" is: not necessarily, but the burden of proof sits with the meeting. When authority quietly distorts a ceremony this way, it's a [Power failure mode](/guides/agile-theatre/power-agile-theatre/), and the standup is the easiest one to tip.
## Frequently asked questions
### Are daily standups micromanagement?
Not by design. A standup is coordination when the team runs it to plan its own day, and micromanagement when it is run for a manager auditing activity. The tell is the direction the updates point: sideways to teammates, or forward to the front of the room. Same fifteen minutes, opposite meetings.
### Should my manager attend the daily standup?
They can attend, but they should not run it. The Scrum Guide makes the Daily Scrum an event for the developers, who use it to plan their next day of work, not a status report for a manager. If a manager attends, the job is to listen and clear blockers only they can clear, not to question. If their presence quiets the room, share the board or an async digest instead of taking a seat.
### Are daily standups even part of agile?
The Agile Manifesto never mentions them; the daily is Scrum's invention. That cuts both ways: you can't defend a broken standup as "what agile requires," and you can't skip coordination and call it agility. The Manifesto asks for conversations; the standup is one way to have them.
## Related reading
- [Why your standup is broken: the common anti-patterns](/guides/daily-standup-guide/standup-anti-patterns/). Diagnose the specific failure mode before you change anything.
- [What is a standup meeting?](/guides/daily-standup-guide/what-is-a-standup-meeting/). What the ceremony is actually for.
- [Daily scrum vs daily standup](/guides/daily-standup-guide/daily-scrum-vs-daily-standup/). Where the Scrum Guide rules apply and where they do not.
- [Agile Theatre: the Power failure mode](/guides/agile-theatre/power-agile-theatre/). How authority in the room distorts honesty across every ceremony.
- [Standups in TeamRetro](/standups/). Run a coordination-first standup, sync or async.
---
# Async and remote standups
URL: https://www.teamretro.com/guides/daily-standup-guide/async-and-remote-standups/
An async standup replaces the live daily meeting with short written updates that each person posts by a set deadline: no shared clock, no everyone-in-a-room. It trades real-time coordination for schedule flexibility, and for the right team that's a good trade. For the wrong team it's a channel full of updates nobody reads.
The question is never "async or live?" in the abstract. It's "what does *this* team's work actually need each morning". The answer changes with distribution, coupling, and trust.
## When async wins
Reach for async when the cost of synchronizing everyone is high and the work doesn't demand a real-time huddle:
- **Timezone spread.** If the team spans more than a few hours, a single live slot is somebody's lunch and somebody else's late evening. Async stops the meeting from taxing the people furthest from headquarters.
- **Deep-focus work.** For teams whose value is uninterrupted maker time, a fixed morning meeting is a daily context-switch. Async lets people fold the update into a natural break.
- **A standup that had already decayed.** If the live meeting had become a status recital, moving it async at least stops it eating a synchronous fifteen minutes, though that's treating a symptom; see [the anti-patterns](/guides/daily-standup-guide/standup-anti-patterns/) for the underlying fix.
## When to stay live
Async is not a free upgrade. Keep the meeting live when:
- **The work is tightly coupled.** If people are constantly stepping on each other's changes, real-time coordination prevents collisions that a once-a-day written post won't.
- **The team is new or low-trust.** A live standup is partly a workaround for a team that can't yet read itself. Written updates assume a habit of surfacing problems that a young team may not have. See [the three questions](/guides/daily-standup-guide/daily-standup-questions/) for why blockers get under-reported.
- **Blockers need resolving now.** Some blockers can't wait for a thread reply three hours later. If your blockers are typically urgent, the latency of async is a real cost.
## How to run an async standup
Async trades a shared clock for a shared deadline. Updates flow in through the morning; the team reads and responds when they log on, which only works if someone actually responds.
The mechanics are simple; the discipline is in the follow-up.
1. **One channel, one deadline.** Pick a dedicated channel and a posting deadline in each person's local morning. A rolling local deadline beats a single global time; nobody's standup should be their midnight.
2. **The same short prompt every day.** Focus, blockers, anything the team needs from you. Use a consistent [async template](/guides/daily-standup-guide/daily-standup-templates/) so updates are scannable and comparable.
3. **Thread the back-and-forth.** Keep the channel to one post per person; every follow-up goes in a thread, or the channel is unreadable by mid-morning.
4. **Answer the blockers.** This is the step that separates a working async standup from a wall of ignored text. A blocker posted and un-answered is worse than a blocker raised live and forgotten, because now there's a written record of the team not helping.
5. **Escalate what's stuck.** Any blocker that isn't moving after a round of thread replies gets a fifteen-minute live call with the two people it concerns. Async is the default, not a religion.
**Pro tip:** a standup tool earns its place here. TeamRetro's [Slack](/integrations/slack/) and [Microsoft Teams](/integrations/microsoft-teams/) integrations remind the team when it's time to post, and when the standup closes they post a single digest of everyone's updates back to the channel, so the update lands where the team already works and nobody has to reconstruct a scattered thread. For choosing between options, see [standup tools and software](/guides/daily-standup-guide/best-standup-tools/).
## The tradeoff you're actually making
Live and async optimize for different things, and pretending otherwise is how teams end up unhappy with both.
| | Live standup | Async standup |
|---|---|---|
| Coordination | Real-time; blockers resolved on the spot | Delayed; blockers resolved in threads |
| Schedule cost | Everyone stops at once | Fold into your own morning |
| Timezones | Punishes the outliers | Neutral |
| Best for | Coupled work, new teams | Distributed, focus-heavy teams |
| Failure mode | The forty-minute status meeting | The channel nobody reads |
Most distributed teams land on a blend: async by default, with a small live overlap window for the conversations that genuinely need it. What matters is choosing on purpose rather than defaulting to a daily video call because that's what "standup" sounds like. An [async standup tool](/standups/) that collects everyone's written update against the same prompts and posts a single digest is what makes that blend workable across time zones.
For where the standup sits in the sprint, see the [agile ceremonies guide](/guides/agile-ceremonies-guide/); for making any format stick, start with [how to run an effective standup](/guides/daily-standup-guide/how-to-run-a-daily-standup/); or return to [the daily standup guide](/guides/daily-standup-guide/) for the full set of chapters.
## Frequently asked questions
### What is an async standup?
An async standup replaces the live daily meeting with short written updates each person posts by a set deadline, usually in a channel, thread, or standup tool. Everyone answers the same brief prompts on their own time, and the team reads and responds when they log on. It trades the real-time back-and-forth of a live sync for schedule flexibility, which is why it suits distributed and timezone-split teams.
### When should a team run async instead of a live standup?
When the cost of getting everyone in a room at once is high and the work doesn't need real-time coordination. Distributed teams across timezones, teams with heavy maker-focus time to protect, and teams where the daily meeting had already decayed into status are all good candidates. Run live when the work is tightly coupled, the team is new or low-trust, or blockers need to be resolved in the moment.
### How do you run a standup across time zones?
Go async by default and set a rolling deadline in each person's local morning rather than a single global time. Collect the updates into one digest so nobody has to piece together a scattered thread, keep a shared board as the source of truth, and reserve a small overlap window for the handful of conversations that genuinely need to be live. Don't force someone's midnight to be someone else's standup.
### Do async standups actually work?
They work when the team treats them as coordination, not compliance. The failure mode is a channel of updates nobody reads: status theatre with extra steps. Async works when blockers get answered in threads, stalled items get escalated to a quick call, and the updates are short enough to actually scan. If people are posting into a void, the format isn't the problem; the follow-up is.
---
# Backlog refinement (grooming): cadence, ownership, and what "ready" means
URL: https://www.teamretro.com/guides/agile-ceremonies-guide/backlog-refinement/
Backlog refinement, still widely called grooming, is the ongoing work of getting product backlog items ready before the sprint they'll be built in: clarifying what each item means, splitting the ones that are too big, adding acceptance criteria, sizing them, and keeping them ordered by priority. It isn't a single meeting so much as a habit. And it's the quiet difference between sprint planning that's calm and sprint planning that's a two-hour argument.
## Is it a ceremony or not?
Technically, no. The Scrum Guide doesn't list backlog refinement as one of the events. It describes it as an ongoing activity that should consume no more than about 10% of the developers' capacity. So the purists are right: it isn't a ceremony.
And yet Asana's guide to agile ceremonies is titled "4 events + backlog refinement," and most working teams give refinement a standing session on the calendar and run it like any other ceremony. Both camps are pointing at the same truth from different sides: refinement is not a formal event, but treating it like one is usually the right call. Skip it and the cost doesn't disappear. It just moves into [sprint planning](/guides/agile-ceremonies-guide/sprint-planning/), where it's more expensive and worse-timed.
**Pro tip:** grooming and refinement are the same activity. The community moved from "grooming" to "refinement" for the obvious reason; the work didn't change. Say whichever your team says.
## What refinement actually does
Refinement takes raw backlog items (often a title and a vague hope) and makes them workable. In practice that's four moves, running continuously:
- **Clarify.** Turn "improve onboarding" into something with a clear intent and [acceptance criteria](/guides/agile-estimation-guide/acceptance-criteria/) the team can test against.
- **Split.** Break items too big to finish in one sprint into thin, independently valuable slices. This is a craft of its own: see [splitting user stories](/guides/agile-estimation-guide/splitting-user-stories/).
- **Size.** Reach a shared [story-point estimate](/guides/agile-estimation-guide/what-are-story-points/), usually via [planning poker](/free-planning-poker-for-agile-teams/), so relative effort is understood before commitment.
- **Order.** Keep the backlog sorted so the most valuable, most ready work sits at the top where planning will reach for it.
The output isn't a document. It's a rolling buffer of items that are ready to be pulled, typically a sprint or two ahead of where the team is now.
## Cadence: how often, how long
There's no rule, but there is a sensible default: one short recurring session as the anchor, plus continuous small touches in between.
For a two-week sprint, most teams run a single refinement session mid-sprint, timeboxed to about an hour, and top it up ad hoc as questions come up. Weekly works just as well. What matters is less the exact slot than the *buffer*: you're aiming to always have roughly a sprint's worth of ready work queued, so planning never opens the backlog to find nothing it can commit to.
Two failure modes bracket the right amount. Too little, and planning becomes refinement-under-time-pressure: the team clarifies and splits on the clock, and commits to work it barely understands. Too much, and refinement swells into a second planning meeting, litigating detail on items that may never reach a sprint. That's the refinement face of [ceremony overload](/guides/agile-theatre/ceremony-overload/), meeting time that buys nothing back. Keep it inside the Scrum Guide's ~10%-of-capacity guideline and it stays useful.
## Who runs it
The product owner owns the backlog: priority, intent, and the *why* of each item are theirs. But refinement is a team sport. The developers are the ones who ask the awkward questions, surface the complexity nobody costed, and do the actual sizing. A product owner refining alone produces items that are crystal clear to exactly one person and full of surprises for everyone else the moment planning starts.
The scrum master keeps the session timeboxed and stops it drifting into design-by-committee. Beyond that, the fewer spectators the better.
## What "ready" means: the Definition of Ready
The point of refinement is to make items *ready*, and "ready" deserves a definition, the same way "done" does. A lightweight [Definition of Ready](/guides/agile-estimation-guide/definition-of-ready/) is the checklist an item must pass before the team will commit to it in planning: it's understood, it's small enough to finish in a sprint, it has acceptance criteria, dependencies are known, and it's estimated.
**A caution:** don't turn the Definition of Ready into a bureaucratic gate. Its job is to catch items that will blow up mid-sprint, not to demand a perfect spec before anyone's allowed to start. A too-strict DoR quietly reintroduces the up-front analysis phase agile was meant to shrink.
Refinement and planning are a relay, not a rivalry. Refinement gets items ready, planning commits to them. If the line between them feels blurry on your team, [sprint planning vs backlog refinement](/guides/sprint-planning-guide/sprint-planning-vs-backlog-refinement/) draws it clearly. For where refinement sits relative to the formal events, see [scrum events vs ceremonies](/guides/agile-ceremonies-guide/scrum-events-vs-ceremonies/).
## Frequently asked questions
### What is backlog refinement?
The ongoing activity of getting product backlog items ready to be worked on: clarifying what each item means, splitting the big ones, adding acceptance criteria, sizing them, and re-ordering by priority. It happens continuously through the sprint so that by the time an item reaches planning, the team can commit to it without a fight.
### Is backlog refinement a Scrum ceremony?
No. The Scrum Guide doesn't list it as an event. It's an ongoing activity, not a fixed meeting, and the Scrum Guide says it should take no more than about 10% of the developers' capacity. But most teams give it a recurring session and treat it like a ceremony, because skipping it is what turns sprint planning into chaos.
### What is the difference between backlog grooming and backlog refinement?
None. They're the same activity. "Grooming" is the original term; the Scrum community shifted to "refinement" because grooming picked up unfortunate connotations. Plenty of teams still say grooming. The work is identical either way.
### How often should you refine the backlog?
Continuously, with one short recurring session as the anchor: commonly once a week, or once mid-sprint for a two-week cadence, timeboxed to roughly an hour. The goal is a rolling buffer of ready items, usually a sprint or two ahead, so planning always has good material to pull from.
### Who runs backlog refinement?
The product owner owns the backlog and drives priority and intent, but refinement is a team activity. The developers ask the questions, surface the hidden complexity, and do the sizing. A product owner refining alone produces items that make sense to one person and surprise everyone else in planning.
---
# Standup tools and software (Slack, Teams, TeamRetro)
URL: https://www.teamretro.com/guides/daily-standup-guide/best-standup-tools/
Before you evaluate a single standup app, answer the prior question: do you need one at all? A co-located team standing at a physical board needs no software: the board and fifteen minutes do the whole job. Tools earn their place when the team is distributed, split across timezones, or running [async](/guides/daily-standup-guide/async-and-remote-standups/), where "everyone online at 9:30" stops being realistic.
And one warning up front: **no tool fixes a standup that's broken for facilitation reasons.** If yours has decayed into status theatre or a manager report, software won't rescue it. It'll just make the theatre more efficient. Fix the meeting first (see [the anti-patterns](/guides/daily-standup-guide/standup-anti-patterns/)), then decide whether a tool would help the version that actually works.
## The four categories of standup tool
Almost every option falls into one of four buckets. Pick the category that matches how your team already works before you compare products within it.
**Chat-native bots.** Tools that live inside Slack or Microsoft Teams and prompt each person for a written update on a schedule, then post a digest. Best for teams that already run their day in chat and want async without leaving it. The risk is the update becoming a box-ticking ritual nobody reads. The tool makes posting easy but can't make anyone respond.
**Project-management boards.** Running the standup straight off your Jira, Linear, or Azure board. The appeal is honesty: you're looking at the real work, which makes "walk the board" the natural format and keeps status out of the meeting. Jira in particular has seen sharp growth as the home for sprint coordination. The risk is that the board reflects reality only as well as the team keeps it updated.
**Dedicated async tools.** Purpose-built async standup products with structured prompts, digests, and follow-up tracking. Best for fully distributed teams for whom async is the primary mode, not a fallback. The risk is adding another destination the team has to check.
**Retro-connected platforms.** Tools where the standup is one part of a wider team-health loop that also covers retrospectives and health checks. Best for teams that want the daily coordination to feed the same continuous-improvement cycle as their [retrospectives](/retrospectives/), so a blocker that keeps recurring in standup becomes a talking point in the retro instead of vanishing.
## What to look for
Whichever category fits, the features that actually matter are few:
- **Async prompts on each person's schedule**: a rolling local deadline, not one global time that's someone's midnight.
- **A single readable digest**, not a thread you have to reconstruct.
- **It lives where the team already works**, whether Slack, Teams, or your board, rather than adding a place to check.
- **A clean path from blocker to follow-up**, so raised blockers get owners instead of scrolling away.
- **No manager-dashboard framing.** The moment the tool's headline view is "who did what," it's optimizing for the reporting anti-pattern that kills standups.
**Pro tip:** the best test of a standup tool is whether it makes *blockers* more visible and more likely to get cleared, not whether it produces a tidy activity report for a manager. If the demo leads with the manager view, keep looking.
## Where TeamRetro fits
TeamRetro sits in the retro-connected category. Everyone posts their update in TeamRetro, and its [Slack](/integrations/slack/) and [Microsoft Teams](/integrations/microsoft-teams/) integrations send the reminder and post the closing digest to the channel, so async standups still land where the team already works. If you run everything through a board, the [Jira integration](/integrations/jira/) publishes a blocker's action straight to it.
The reason to run standups here rather than in a standalone bot is the loop. TeamRetro connects the daily sync to the team's [retrospectives](/retrospectives/) and [health checks](/health-checks/): a blocker that surfaces every morning becomes a pattern the retro can actually fix, instead of a line in a channel nobody scrolls back to. For the full product view, see the [standups page](/standups/).
That's the honest pitch: if you just want an async prompt in Slack and nothing else, a lightweight bot will do it. If you want the standup to be part of how the team inspects and improves itself over time, a connected platform is the better home.
## Choosing, in one line
Co-located and small: use a board and fifteen minutes. In Slack or Teams all day: a chat-native bot, or TeamRetro with its reminders and digests in the channel. Everything already in Jira: run it off the board. Distributed and improvement-minded: a retro-connected platform. Match the tool to the team you have, and to a standup you've already made worth attending.
For the meeting itself, start with [how to run an effective standup](/guides/daily-standup-guide/how-to-run-a-daily-standup/); for the daily prompts, grab the [copy-paste templates](/guides/daily-standup-guide/daily-standup-templates/); or start from the top of [the daily standup guide](/guides/daily-standup-guide/).
## Frequently asked questions
### Do you need a tool for daily standups?
No, a co-located team with a physical board needs nothing but the board and fifteen minutes. You need a tool when the team is distributed, split across timezones, or running async, at which point a shared board plus a way to collect written updates stops the meeting depending on everyone being online at once. Buy a tool to solve a specific coordination problem, not to fix a standup that's broken for facilitation reasons.
### What is the best tool for daily standups?
There's no single best. It depends on how your team works. Chat-native bots suit teams that live in Slack or Teams and want async prompts; project-management boards suit teams that already run everything in Jira and want the standup on the board; dedicated async tools suit fully distributed teams; and retro-connected platforms like TeamRetro suit teams that want the standup feeding the same loop as their retros and health checks.
### What should you look for in standup software?
Async prompts on each person's schedule, a single readable digest instead of a scattered thread, integration with where the team already works (Slack, Teams, or your board), and a clean link from blockers to follow-up. Avoid anything that turns updates into a manager dashboard. The value is team coordination, and software that optimizes for reporting recreates the exact anti-pattern that kills standups.
### Can you run standups in Slack or Microsoft Teams?
Yes, and for distributed teams it's often the best home for them. A dedicated channel with a set posting deadline works on its own; a standup bot adds automatic prompts and rolls everyone's replies into one digest so nobody has to scroll. The TeamRetro Slack and Teams integrations send the reminder and the closing digest, while people post their update in TeamRetro. Keep the channel to one post per person and thread the follow-ups, or it becomes unreadable fast.
---
# How to build trust on a team (and make it safe to speak up)
URL: https://www.teamretro.com/guides/team-dynamics/building-trust-and-psychological-safety/
Trust and psychological safety are related but distinct. Trust is one-to-one: your read on whether a specific person will come through. Psychological safety is a group-level belief that the team is safe for taking interpersonal risks, like admitting a mistake. You build both through repeated leader behaviors, not a one-off pep talk.
Most guidance here stops at "create a safe space," which is not an instruction anyone can follow. Safety is an outcome, produced by what people repeatedly do in small moments: how a manager reacts the first time someone admits a mistake, whether the quiet person on the call ever gets asked directly. This chapter is about those moments, and the trust they add up to.
## Trust and psychological safety are not the same thing
Trust is dyadic. It runs between two people and points outward: will they do what they said, are they good at their part. Psychological safety is a property of the group, and it points inward: if I ask this question or admit I am lost, how will these people judge me. You can trust a colleague privately and still not feel safe raising a concern in the full team meeting.
Patrick Lencioni, whose model of [team trust](/guides/team-dynamics/five-dysfunctions-of-a-team/) puts its absence at the base of the dysfunctions pyramid, draws a distinction worth stealing: *predictive trust* (I have worked with you long enough to anticipate what you will do) versus *vulnerability-based trust* (I can say "I was wrong" or "I need help" without it being stored up and used against me later). Predictive trust arrives with time. Vulnerability-based trust has to be built on purpose, and it is the kind teams run on.
## Why building trust and safety matters
The case rests on two well-known bodies of research, and it pays to be precise about what each shows.
The first is Amy Edmondson's. Her [1999 study of 51 work teams](https://www.hbs.edu/faculty/Pages/item.aspx?num=2959) defined psychological safety as "a shared belief held by members of a team that the team is safe for interpersonal risk taking." In that study, safety was *associated with* more of what she calls learning behavior (teams that asked questions and talked openly about their errors), which was in turn associated with better performance. This is correlational work, so the honest verb is "associated with," not "causes." Edmondson later brought the idea to a wide audience in [The Fearless Organization](https://www.wiley.com/en-us/The+Fearless+Organization-p-9781119477266) and a 2014 TEDx talk, where she made the human mechanism plain:
> "Don't want to look ignorant? Don't ask questions. Don't want to look incompetent? Don't admit weakness or mistake." — Amy Edmondson, [TEDxHGSE, 2014](https://www.youtube.com/watch?v=LhoLuui9gX8)
The safe move is to stay quiet, which is exactly what costs teams the information they need.
The second is Google's [Project Aristotle](https://rework.withgoogle.com/intl/en/guides/understand-team-effectiveness), its internal study of why some teams outperformed others. Google found psychological safety to be the most important of the five dynamics it identified, and the foundation the other four rest on. This is observational research on Google's own teams, so "Google found" is the right frame, not a law of physics. We cover all five keys in [what is team dynamics](/guides/team-dynamics/what-is-team-dynamics/). Two independent lines of evidence pointing the same way is a strong enough signal to act on.
## How to build trust: the behavior list
Edmondson frames the leader's job as a toolkit with three parts: set the stage, invite participation, and respond productively. Each part maps to a specific moment where trust is built or broken. None of it requires a personality transplant, only a handful of unglamorous things done consistently.
### Set the stage
Framing does more work than most managers expect, and two moves matter most.
- **Name the work as a learning problem, not just an execution problem.** When you say out loud that the work is uncertain and interdependent, that no one has done exactly this before and the parts depend on each other, you make questions and course-corrections read as the job rather than as incompetence.
- **Say that you need everyone's input, and say why.** "I do not have the full picture, and I will make worse calls if you sit on what you see" is a sentence that hands people explicit permission to speak. Say it, then behave as though you meant it.
### Invite participation
Setting the stage is talk. Inviting participation is what you do once people are in the room.
- **Model fallibility first.** A leader who says "I may miss things here, so tell me when I do" resets the odds for everyone else. Edmondson calls this situational humility, and it opens a room faster than any amount of encouragement.
- **Ask real questions, then be quiet.** Proactive inquiry means asking specific questions you do not already know the answer to, and leaving enough silence that someone can fill it. "What are we missing?" dropped into a two-second pause is theater. The same question with a real ten-second pause is an invitation.
- **Build structures so speaking up is routine rather than heroic.** Do not rely on courage; design the meeting so input is the default: round-robins where everyone speaks once, write-first prompts that capture views before the loudest voice sets the tone, anonymous retrospective entries, and pre-mortems. Structure carries the people who will never be first to raise a hand.
A short check-in question at the top of a meeting is a low-stakes version of the same idea: it gets every voice into the room once, before the stakes are high. Our list of [check-in questions](/icebreakers/check-in-questions/) is built for that. To practice small disclosures as a group, you can run something like [Two Truths and a Lie](https://games.teamretro.com/games/two-truths-and-a-lie/) live with your team.
### Respond productively
This is the part that decides everything, because people learn what is safe from what happens after they take a risk, not from what you announced you wanted.
- **Treat bad news as the most consequential moment you get.** When someone brings you a problem early, your first visible reaction trains the whole team. Thank the person who flagged it before you react to the problem itself. The engineer who says "I think I shipped the bug" is doing exactly what you need more of.
- **Replace blame with curiosity.** "Whose fault was this?" ends the flow of information. "What happened, and what can we learn?" keeps it open. [Laura Delizonna, writing in Harvard Business Review](https://hbr.org/2017/08/high-performing-teams-need-psychological-safety-heres-how-to-create-it), frames this as approaching conflict as a collaborator rather than an adversary, and suggests asking your team for feedback on how you deliver hard messages.
- **Destigmatize honest mistakes without dropping standards.** Safety is not immunity from accountability. Edmondson is explicit that a preventable, blameworthy act still gets sanctioned; what you destigmatize is the intelligent failure, the well-reasoned attempt that did not work, and the honest "I do not know." The goal is a team that is high on safety and high on standards at once, not a comfortable one that has quietly stopped pushing.
Responding productively includes closing the loop. If people surface problems and nothing visibly changes, they learn that speaking up is pointless, and the safety you built leaks away. Follow-through is where this shows: a team that keeps agreeing to changes that never ship is quietly teaching itself that candor is pointless. For a facilitator-focused version aimed at retrospectives, see [how to build a psychologically safe retrospective](/guides/scrum-masters-retrospective-guide/how-to-build-a-psychologically-safe-space/).
## How to measure whether your team feels safe
Safety is easy to assume and hard to see. Edmondson's original study measured it with a seven-item survey answered on a scale, and it still holds up as a starting point. The reverse-scored items are marked, since a "yes" there is a bad sign.
1. If you make a mistake on this team, it is often held against you. *(reverse-scored)*
2. Members of this team are able to bring up problems and tough issues.
3. People on this team sometimes reject others for being different. *(reverse-scored)*
4. It is safe to take a risk on this team.
5. It is difficult to ask other members of this team for help. *(reverse-scored)*
6. No one on this team would deliberately act in a way that undermines my efforts.
7. Working with members of this team, my unique skills and talents are valued and utilized.
Two practical notes. First, run it anonymously: a person who feels unsafe is the least likely to admit it out loud, so a show-of-hands reading will flatter you. Second, watch the trend rather than a single number, since what matters is whether safety is climbing or sliding as you change your behavior. A recurring [team health check](/health-checks/) does both. To read the signals off behavior instead, our guide to [telling whether your team feels psychologically safe](/blog/how-to-tell-if-your-team-feels-psychologically-safe/) covers what to watch for. Written [team agreements](/guides/team-dynamics/team-norms-and-working-agreements/) help too: making expectations explicit removes much of the guesswork that keeps people quiet.
## Building trust when the team is remote
Everything above gets harder when the team is distributed, because the micro-moments that build trust in an office do not happen on their own. The hallway "quick question," the read on someone's face when a plan lands badly: remote, you have to engineer them.
- **Default to written and async, with explicit triggers for going live.** Write-first input levels the field for quieter people and non-native English speakers who lose out in fast verbal meetings. Decide together which decisions are worth a synchronous call.
- **Keep camera-on optional.** Mandating cameras reads as surveillance and taxes the people already most drained by video. Invite it and model it, and let people opt out without owing anyone a reason.
- **Over-communicate context.** Co-located teams absorb the why behind a decision by proximity; distributed teams do not, so write the reasons down or people fill the vacuum with worst-case guesses.
- **Protect low-stakes human connection on purpose.** The chat that happens for free in a kitchen has to be scheduled online: a standing check-in, a few minutes of non-work talk at the top of a call. It feels inefficient, and it is where a lot of trust is quietly made. Running something like [This or That](https://games.teamretro.com/games/this-or-that/) live gives a distributed team that moment.
The deeper version of this sits in [remote and distributed team dynamics](/guides/team-dynamics/remote-and-distributed-team-dynamics/). The short form: distributed trust is built on cadence, not on a single offsite.
None of this is fast. Trust and safety are made in small, repeated moments and lost in one bad reaction to bad news, which is why the behavior list matters more than any workshop. Start with the moment you control most: what you do the next time someone tells you something you did not want to hear.
## Frequently asked questions
### What is the difference between trust and psychological safety?
Trust is dyadic: your read on whether a specific person will come through. Psychological safety is a group-level belief that the team is safe for taking interpersonal risks, like admitting a mistake or asking a naive question. You can trust a colleague one-to-one and still not feel safe speaking up in the full group. They reinforce each other, but they are different things.
### How do you build trust in a team?
Through repeated behaviors, not a slogan. Amy Edmondson's toolkit is a useful spine: set the stage by framing the work as a learning problem and saying you need everyone's input; invite participation by modeling fallibility, asking real questions, and building structures like round-robins and anonymous input; and respond productively by thanking people who flag problems and replacing blame with curiosity.
### How do you measure psychological safety on a team?
Amy Edmondson's original seven-item survey is the standard starting point, asking whether mistakes are held against people, whether it is safe to take risks, and whether it is hard to ask for help. Run it anonymously, since people who feel unsafe are the least likely to say so out loud, and watch the trend over time rather than any single score. A recurring team health check does both.
### Does psychological safety mean lowering standards?
No, and that is the most common misread. Safety is not immunity from accountability, and it is not about being nice. Edmondson's point is that you destigmatize honest mistakes and the words "I do not know," while still holding a high bar and sanctioning careless work. The strongest teams are high on safety and high on standards at once.
### How do you build trust in a remote team?
You engineer the micro-moments that happen for free in an office. Default to written, async input so quieter and non-native English voices count equally; keep cameras optional rather than mandated; over-communicate the context behind decisions; and protect low-stakes human connection with a standing check-in question. Remote trust is built on cadence, not on a one-off offsite.
---
# What is a burndown chart? Sprint & release burndown
URL: https://www.teamretro.com/guides/agile-metrics/burndown-chart/
**A burndown chart is a simple line graph that answers one question at a glance: how much work is left, and are we on track to finish it?** The vertical axis shows **work remaining** (usually [story points](/guides/agile-estimation-guide/what-are-story-points/) or tasks) and the horizontal axis shows **time**, typically the days of a sprint. As the team completes work, the line falls, or "burns down," toward zero. This chapter of the [agile metrics guide](/guides/agile-metrics/) covers how to read one, sprint and release burndowns, and how it compares with a burnup.
## How to read a burndown chart
A burndown chart usually shows two lines:
- **The ideal line** runs straight from the total committed work on day one down to zero on the last day. It represents a perfectly even pace and is a reference, not a plan the team must hit exactly.
- **The actual line** plots the real work remaining at the end of each day.
Reading the gap between them tells you most of what you need:
- **Actual above ideal**: the team is behind the even pace.
- **Actual below ideal**: the team is ahead.
- **A flat actual line**: nothing is being completed; work may be stuck, or [items are too big to close](/guides/agile-estimation-guide/splitting-user-stories/). [Work item age](/guides/agile-metrics/lead-time-vs-cycle-time/) shows which items are stuck.
- **A sudden jump upward**: scope was added to the sprint mid-flight.
The shape matters more than any single day. A line that only drops sharply on the last two days, for example, often means work is being held "almost done" rather than finished, which is a useful thing to notice.
## Sprint burndown vs release burndown
A **sprint burndown** tracks the work remaining inside one sprint, day by day. It is the team's own tool for steering the current sprint. A **release (or product) burndown** tracks work remaining across many sprints toward a larger goal, usually measured per sprint rather than per day, and helps forecast *when* a whole body of work will be done. One is about this sprint; the other is about the roadmap.
## Burndown vs burnup
A burndown chart shows work *remaining*, falling toward zero. A **burnup chart** shows work *completed*, rising toward a separate line that represents total scope. The burnup's advantage is that scope is its own line: when work is added, the scope line moves and you can clearly distinguish "the team is behind" from "more work was added." A plain burndown hides that: added scope just makes the line look stalled. Many teams use a [burnup chart](/guides/agile-metrics/scrum-metrics/#burnup-the-forecast-stakeholders-can-read) precisely to make scope creep visible.
## What a burndown chart will not tell you
A burndown chart is a conversation starter, not a verdict. It shows *that* the team is off the ideal pace, never *why*. A bumpy line can mean blockers, oversized items, mid-sprint scope changes, or simply that real work is rarely evenly paced. Treating the ideal line as a target to be hit exactly, or using the chart to judge individuals, reliably backfires. Its value is in prompting the right questions.
## The burndown chart in the retrospective
That is why the burndown chart is a frequent and productive topic in the [sprint retrospective](/guides/agile-ceremonies-guide/sprint-retrospective/). Looking back at the sprint's curve, the team can ask why work bunched up at the end, whether items were sliced small enough, or whether scope kept shifting, then turn those observations into concrete improvements for the next sprint. [From numbers to actions](/guides/agile-metrics/from-metrics-to-action/) covers how to bring a chart like this into the retro.
## Frequently asked questions
### What is a burndown chart?
A burndown chart is a simple line graph that shows how much work is left in a sprint or project over time. The vertical axis is work remaining, usually in story points or tasks, and the horizontal axis is time, typically the days of a sprint. As the team completes work, the line "burns down" toward zero. It gives the team an at-a-glance sense of whether they are on track to finish what they committed to.
### How do you read a burndown chart?
A burndown chart has two lines. The ideal line runs straight from the total work at the start down to zero at the end of the sprint, at a steady, even pace. The actual line plots the real work remaining each day. When the actual line sits above the ideal line, work is behind; when it is below, the team is ahead. A flat actual line means nothing is being completed, and a sudden jump up means scope was added mid-sprint.
### What is the difference between a burndown and a burnup chart?
A burndown chart tracks work remaining, falling toward zero, while a burnup chart tracks work completed, rising toward a total-scope line. The key advantage of a burnup chart is that it shows scope changes as a separate moving line, so you can tell the difference between "the team is behind" and "more work was added." A burndown chart is simpler and more common but can hide scope creep, because added work just makes the line look like the team has stalled.
### What is the difference between a sprint burndown and a release burndown?
A sprint burndown tracks the work remaining within a single sprint, day by day, and is mainly a tool for the team to manage the current sprint. A release (or product) burndown tracks work remaining across many sprints toward a larger goal, usually measured per sprint rather than per day. The sprint burndown answers "are we on track this sprint?"; the release burndown answers "when will this whole body of work be done?"
## Related reading
- [Agile and engineering metrics](/guides/agile-metrics/): the hub, with the burndown beside the other team metrics.
- [Scrum and sprint metrics](/guides/agile-metrics/scrum-metrics/): the burnup, sprint goal success and the other sprint measures worth keeping.
- [What are story points?](/guides/agile-estimation-guide/what-are-story-points/): the units most often plotted on a burndown chart.
- [The four Scrum ceremonies explained](/guides/scrum-masters-retrospective-guide/scrum-ceremonies/): where the chart is inspected during the sprint.
- [What is a sprint retrospective?](/guides/scrum-masters-retrospective-guide/what-is-a-sprint-retrospective/): where the team acts on what the chart reveals.
---
# Overload: when there's too much ceremony
URL: https://www.teamretro.com/guides/agile-theatre/ceremony-overload/
The cost of a ceremony isn't the fifteen minutes on the calendar. It's the fifteen minutes, plus the twenty you spend winding down before it and the twenty you spend ramping back up after, multiplied by everyone in the room.
Overload is the failure mode that hides in plain sight, because each individual ceremony looks cheap. A quarter-hour standup, an hour of planning, an hour of retro. Who could object? The problem is that they don't come one at a time. They come stacked, on a cadence, on top of a working day that has to fit real deep work into the gaps. Unlike the other three modes, Overload isn't about a captured or hollowed-out ceremony; a perfectly good ceremony can still be one too many. It's the only mode you diagnose with arithmetic.
## The meeting tax, counted honestly
So count it: the whole stack, not just the daily. A two-week sprint typically runs two to four hours of sprint planning, an hour or two of review, an hour or two of retro, a refinement session or two, and a fifteen-minute daily standup that adds up to another two-and-a-half hours across ten days. Tally it and you're at the better part of a working day per developer, every sprint, before a single line of code. Practitioners do this sum in person-hours, because that's the unit management feels: fifteen minutes of standup across a team of twelve isn't fifteen minutes, it's three person-hours, every day, gone. Then add the part the calendar never shows (the wind-down before each of those interruptions and the ramp-up after) and a fifth of the working week is a conservative figure, which is exactly the overhead practitioners keep reporting.
Count the whole stack honestly (planning, review, retro, refinement and the daily) and a conservative tally is a fifth of the week, one day in five, gone before any focused work.
That's not automatically wrong. Coordination has real value, and three person-hours well spent can save far more downstream. But it's a *tax*, and the honest question about any tax is what you're getting for it. A team that can't point to a decision made, a collision avoided, or a blocker cleared as a result of a ceremony is paying the tax for nothing. The overhead is only defensible when the return is nameable.
## The context switch is the real bill
The calendar undercounts the cost, though, because the meeting itself is the cheap part. The expensive part is the context switch on either side. A developer deep in a problem doesn't teleport into the standup and back. They surface, they lose the mental model they'd built, and they spend the first stretch afterward rebuilding it. Practitioners describe the morning standup as a device for detonating the start of the day: work doesn't really begin until it's over, so the whole pre-standup hour gets written off. The fifteen minutes is the sticker price; the context switch is the bill.
The fifteen-minute time-box is the part everyone sees. The overrun, plus the ramp-down and ramp-up on either side of it, is the part that actually costs the day.
This is why *when* a ceremony sits matters as much as how long it runs. A standup mid-morning fragments a maker's block twice; the same standup at a natural boundary costs a fraction. And it's the strongest case for moving status off the synchronous clock entirely: if the daily's real job is a status readout the tools already hold, an [async standup](/guides/daily-standup-guide/async-and-remote-standups/) removes the interruption without losing the information, and a short live sync a few times a week keeps the human coordination the async thread can't. Our [how to run a daily standup](/guides/daily-standup-guide/how-to-run-a-daily-standup/) chapter covers protecting the maker's day around whatever cadence you land on.
## Cadence burden: the short-sprint trap
Then there's the multiplier nobody plans for: sprint length. Every ceremony that fires "once per sprint" fires twice as often on a one-week sprint as on a two-week one. Halve the sprint and you double the planning sessions, the reviews, and the retros, but you don't halve the work between them, so the ceremony-to-work ratio balloons. Teams on one-week sprints describe it bluntly as bad: planning and retro every single week, with the reflection often coming up dry because a week isn't long enough to have learned anything new.
The fix is to stop treating cadence as a single dial. Sprint length, standup frequency, and retro frequency don't have to move together. A team that finds weekly retros hollow can run the retrospective every two or three sprints and lose nothing. Reflection has its own natural rhythm, and forcing it faster than the team accumulates lessons just manufactures the box-ticking retro from the [Performance](/guides/agile-theatre/performance-agile-theatre/) chapter. Right-size each ceremony to the interval at which it actually produces something.
## When Overload compounds the other modes
**If your ceremony overhead is 20% of the week and the team can't name what changed because of it, you're not doing agile — you're paying a tax to look like you are.** The tell of Overload isn't that the meetings are long; it's that removing one would cost the team nothing but calendar time. Audit every recurring ceremony against a single question: what decision or coordination does this produce? Delete the ones with no answer.
Overload rarely arrives alone. Martin Fowler's ["Flaccid Scrum"](https://martinfowler.com/bliki/FlaccidScrum.html) names the version where a team performs every ceremony but skips the engineering discipline underneath, so it pays the full meeting tax and gets none of the delivery benefit, because the bottleneck was never coordination. And "water-scrum-fall," the pattern Forrester's Dave West named, is Overload compounding [Power](/guides/agile-theatre/power-agile-theatre/): a plan that's fixed in scope, time and cost up front, then wrapped in sprints, so the team carries both the ceremony overhead of agile and the rigidity of waterfall, with the worst of each.
It's worth taking the counter-argument seriously, too, because it's popular and it's half right. Practitioners love to point out that a lot of elite engineering orgs barely run the ceremony stack: engineers lead projects, teams choose their own method, and continuous delivery gives faster feedback than any weekly meeting. Handle that observation carefully: "rules don't apply to us" is not a strategy, and a large distributed team genuinely needs more synchronizing than a small co-located one. The real lesson isn't *skip the ceremonies*; it's *match the ceremony to the coordination the work actually requires*, which for some teams is far less than the standard playbook assumes, and for others is exactly the standard amount. Overload is what you get when you copy the playbook instead of sizing the need. The last mode, the [follow-through void](/guides/agile-theatre/the-follow-through-void/), is what you get when even the right-sized ceremonies change nothing.
## Frequently asked questions
### How many meetings is too many in scrum?
There's no fixed number. The test is the ratio and the return. Add up the recurring ceremony time as a percentage of the team's week; if it's north of 20% and the team can't name what changed because of it, you're overloaded. A ceremony earns its slot by producing a decision or a coordination the work genuinely needs, not by being on the standard list.
### Are one-week sprints too short for all the ceremonies?
Often, yes. Planning and a retro every single week means the ceremony-to-work ratio balloons, and mature teams frequently find nothing new to reflect on that fast. Right-size the cadence: run the retrospective every two or three sprints if weekly reflection is dry, and move status to async so the daily doesn't eat the morning.
### Why does big tech seem to skip scrum ceremonies?
Many elite teams do run lighter: engineers lead projects, teams pick their own method, and CI/CD plus feature flags give faster feedback than a weekly ceremony could. But the lesson isn't rules don't apply to us; it's match ceremony to real coordination need. A tiny co-located team needs less synchronizing than a large distributed one, and copying either extreme blindly is its own mistake.
### How do I reduce agile meeting overhead without losing coordination?
Audit every recurring ceremony against one question: what decision or coordination does this produce? Kill or merge the ones with no answer, move status reporting to the tools that already hold it, and size the remaining meetings to the smallest group that actually needs to be there. The goal is less time performing coordination and more time doing the work.
## Related reading
- [Performance: the ceremony you run for the audience](/guides/agile-theatre/performance-agile-theatre/). The ceremony that's cheap to keep because no one expects anything from it.
- [The follow-through void](/guides/agile-theatre/the-follow-through-void/). When even a right-sized ceremony changes nothing.
- [Async and remote standups](/guides/daily-standup-guide/async-and-remote-standups/). Moving status off the synchronous clock.
- [Sprint planning meeting](/guides/sprint-planning-guide/sprint-planning-meeting/). Running planning tight enough to earn its hour.
- [Agile ceremonies: the complete guide](/guides/agile-ceremonies-guide/). What each ceremony is for, so you can tell which ones the work actually needs.
- [Agile Theatre glossary](/guides/agile-theatre/agile-theatre-glossary/). The four coined failure modes, defined.
---
# The cone of uncertainty in agile estimation
URL: https://www.teamretro.com/guides/agile-estimation-guide/cone-of-uncertainty/
Your earliest estimate is your worst one, and that's a property of the work, not a flaw in the team. The cone of uncertainty is the reason to stop demanding a single number for something nobody has started.
The cone is a simple observation with sharp consequences: at the start of a piece of work, the spread between your estimate and reality is enormous, and it narrows as you learn. Barry Boehm spotted the shape in software-cost data; Steve McConnell named it. Plotted over time it looks like a cone: wide on the left, where you know least, collapsing toward a point on the right, where the work is nearly done and there's nothing left to be wrong about.
The spread is widest before you start and collapses as you learn. The estimate isn't wrong, just early.
## Why it matters for estimation
Most estimation pain comes from demanding a point estimate at the widest part of the cone. Someone asks "how long will the new billing system take?" before a line is written, gets "about three months," and treats it as a commitment. The cone says that number is honestly somewhere between six weeks and nine months, and pretending otherwise just relocates the disappointment to later.
This is the whole reason agile estimates relative size instead of committing to dates. [Story points](/guides/agile-estimation-guide/what-are-story-points/) and [planning poker](/guides/agile-estimation-guide/what-is-planning-poker/) don't fight the cone; they accept it. A quick [relative read](/guides/agile-estimation-guide/relative-vs-absolute-estimation/) ("this is bigger than the thing we shipped last sprint") is the honest amount of precision available early, and [velocity](/guides/agile-estimation-guide/velocity/) turns that into a forecast with a range rather than a false promise.
## How to narrow the cone
The cone narrows when you remove unknowns, not when you add buffer. In order of leverage:
- **Spike the riskiest unknown.** A time-boxed [spike](/guides/agile-estimation-guide/splitting-user-stories/) buys information, which is the only thing that actually shrinks the range.
- **Refine until the questions stop.** A story the team keeps asking questions about is sitting at the wide end of the cone; sharp [acceptance criteria](/guides/agile-estimation-guide/acceptance-criteria/) drag it rightward.
- **Split it.** Smaller stories sit further down the cone: each piece is understood, so each estimate is tighter than one estimate for the whole.
- **Re-estimate when you've learned something.** [Re-estimating](/guides/agile-estimation-guide/velocity/) as the cone narrows is honest; doing it to chase a target is not.
## The cone is not an excuse to pad
The wrong lesson is "everything's uncertain, so double every estimate." Padding moves the whole cone up without narrowing it; you're still guessing, just pessimistically. The right response to a wide cone is either to resolve the uncertainty (spike, refine, split) or to communicate the range honestly and commit to re-estimating.
**Uncertainty is information.** A padded point estimate throws it away; a range keeps it. When a question deserves a range, don't hand it a single number to feel safe.
## Frequently asked questions
### What is the cone of uncertainty?
The cone of uncertainty describes how the range of an estimate is widest at the start of a piece of work and narrows as the work progresses and unknowns get resolved. Early on, an estimate can be off by a large factor in either direction; by the time the work is well understood, the range collapses toward the actual result.
### Who came up with the cone of uncertainty?
The shape was first observed by Barry Boehm in the early 1980s as a software-cost relationship, and Steve McConnell later named it the "cone of uncertainty" and popularized it in agile and software estimation.
### How does the cone of uncertainty apply to agile estimation?
It's the reason agile estimates relative size rather than committing to dates up front. Story points and planning poker accept that early estimates are wide, trade false precision for a quick relative read, and re-estimate as the cone narrows through refinement, spikes and shipped work.
### How do you reduce the cone of uncertainty?
You don't pad it; you resolve the unknowns that make it wide. Run a spike on the riskiest part, refine the story until the questions stop, split it so each piece is understood, and re-estimate once you've learned something. The cone narrows when uncertainty is removed, not when the number is inflated.
## Related reading
- [Relative vs absolute estimation](/guides/agile-estimation-guide/relative-vs-absolute-estimation/): why relative sizing survives the cone.
- [Splitting user stories](/guides/agile-estimation-guide/splitting-user-stories/): spikes and splits, the moves that buy the information that shrinks the range.
- [Velocity](/guides/agile-estimation-guide/velocity/): turning an early, wide estimate into a forecast with a range.
- [Agile estimation guide](/guides/agile-estimation-guide/): the full estimation cluster.
- [Free planning poker for agile teams](/free-planning-poker-for-agile-teams/): get the quick relative read the cone calls for.
---
# Daily scrum vs daily standup: are they the same?
URL: https://www.teamretro.com/guides/daily-standup-guide/daily-scrum-vs-daily-standup/
Daily scrum and daily standup are the same meeting. Same fifteen minutes, same purpose, same three-ish beats. The two names come from two different lineages, and the only reason the question keeps getting asked is that people assume two words must mean two things. Here they don't.
The distinction worth keeping is narrow: **"daily scrum" is the term defined in the [Scrum Guide](https://scrumguides.org/); "daily standup" is the generic name any team can use.** Every daily scrum is a standup. Not every standup is a daily scrum, because not every team runs Scrum.
## Where each name comes from
"Standup" is the older word. It comes from [Extreme Programming](https://en.wikipedia.org/wiki/Stand-up_meeting), where the daily standup was one of the original practices, and it describes the format literally: you stand, so it stays short.
"Daily scrum" is Scrum's term for the same meeting, and Scrum gives it a job description. In the Scrum Guide the daily scrum is one of five events, owned by the developers, held at the same time and place each working day, timeboxed to fifteen minutes. Its stated purpose is to inspect progress toward the sprint goal and adapt the plan for the next day's work.
So the vocabulary maps cleanly:
| | Daily standup | Daily scrum |
|---|---|---|
| Origin | Extreme Programming | Scrum |
| Where it's defined | Convention, not a spec | The Scrum Guide |
| Requires a framework | No | Yes, it's a Scrum event |
| Owner | The team | The developers |
| Timebox | ~15 minutes | 15 minutes |
| Purpose | Coordinate the day | Inspect and adapt toward the sprint goal |
Read down the two columns and the rows that differ are all *context*: who defines it, what framework it sits in. The rows that matter for actually running it, timebox and purpose, are the same. That's why treating them as one meeting is not sloppiness; it's accurate.
## The distinctions that actually matter
If you run Scrum, there are two things the "daily scrum" framing adds that a loose standup sometimes loses:
**It's anchored to the sprint goal.** The daily scrum isn't "what did everyone do yesterday." It's "are we still on track to meet the sprint goal, and what do we change today if we're not." That anchor is what stops the meeting drifting into unstructured status. A standup with no goal to steer toward is the one that decays into a task-list read-aloud. If you want that anchor built into the prompts, the Goal-focused standup template in [TeamRetro's standup tool](/standups/) asks every update to tie back to the sprint goal.
**It's the developers' meeting.** The Scrum Guide is explicit that the daily scrum belongs to the people doing the work. That framing is a defense against the most common way standups go wrong: a manager quietly turning it into a reporting line. The daily scrum is harder to hijack precisely because the spec says whose meeting it is.
Neither of those is unique to Scrum, though. A good Kanban standup "walks the board" against the same idea of flow and blockers over individual narration. The framework supplies the discipline; it doesn't own it.
## What to call yours
Use whichever word your team already uses, and don't correct people who use the other one. If you're running Scrum, "daily scrum" is technically the right term and it usefully reminds everyone the meeting is anchored to the sprint goal. If you're not running Scrum, "standup" is the honest name and nobody will misunderstand you.
The trap isn't the vocabulary. It's assuming that because you've named the meeting correctly, you're running it correctly. You can hold a textbook "daily scrum" every morning and still be running a status meeting. See the [three questions and their failure mode](/guides/daily-standup-guide/daily-standup-questions/) and the [common anti-patterns](/guides/daily-standup-guide/standup-anti-patterns/) for why. The name is the easy part.
For how the daily scrum sits alongside the sprint's other events, see the [agile ceremonies guide](/guides/agile-ceremonies-guide/) and the retro guide's breakdown of [the four Scrum ceremonies](/guides/scrum-masters-retrospective-guide/scrum-ceremonies/). To go the other way (into running the meeting well), start with [what a standup is for](/guides/daily-standup-guide/what-is-a-standup-meeting/), or return to [the complete daily standup guide](/guides/daily-standup-guide/) for the full set of chapters.
## Frequently asked questions
### What is the difference between a daily scrum and a daily standup?
In practice, none worth arguing over. They are the same fifteen-minute daily meeting. The names come from different places: "daily scrum" is the term in the Scrum Guide, where the meeting has a specific owner and purpose within Scrum; "daily standup" comes from Extreme Programming and is the generic name any team can use, Scrum or not. Every daily scrum is a standup; not every standup is a daily scrum.
### Is a daily standup the same as a daily scrum?
Effectively yes. If you run Scrum, your daily standup is the daily scrum, and the Scrum Guide simply gives it a defined role: the developers inspect progress toward the sprint goal and adapt the plan for the next day. Teams outside Scrum run the identical meeting and call it a standup. The mechanics are the same; only the framework and the vocabulary differ.
### What is the 3-5-3 rule in Scrum?
It's a shorthand for the shape of Scrum: 3 roles (product owner, Scrum Master, developers), 5 events (the sprint, sprint planning, the daily scrum, the sprint review, and the sprint retrospective), and 3 artifacts (product backlog, sprint backlog, and the increment). The daily scrum is one of those five events, the only one that happens every day.
### Do you have to use Scrum to run a standup?
No. The standup came from Extreme Programming and works for any team that needs to coordinate daily: Kanban teams, support teams, even non-software teams. Scrum gives the meeting a formal name and a defined purpose, but the practice stands on its own. What matters is the habit of a short, daily, blocker-focused sync, not which framework you file it under.
---
# Daily standup agenda and format
URL: https://www.teamretro.com/guides/daily-standup-guide/daily-standup-agenda/
A daily standup agenda is deliberately thin: orient on the goal, work through what's in progress, assign owners to any blockers, and stop. The whole thing fits in fifteen minutes because the meeting is a *sync*, not a working session. The moment it tries to be more, the timebox breaks.
Here is a standup agenda that actually holds to fifteen minutes.
## The fifteen-minute run of show
**Orient on the sprint goal (0:00 – 1:00).** One sentence from the facilitator: what are we trying to finish this sprint, and are we on track. This is the anchor every update points back to. Skip it and the meeting drifts into disconnected status.
**The main body (1:00 – 12:00).** This is where most of the time goes, and you have two ways to run it:
- **Walk the board** (recommended for any team past its first few sprints). Move across the items in progress and talk about the work.
- **The three questions**, person by person: yesterday, today, blockers. Fine for a new team; prone to becoming a status recital. See [the three questions and their alternatives](/guides/daily-standup-guide/daily-standup-questions/).
**Blockers and owners (12:00 – 14:00).** Sweep the blockers that came up. Each one gets a name attached and a "we'll sort it right after." No solving, just ownership.
**Parking lot (14:00 – 15:00).** Confirm the deeper conversations that got parked, and who's staying for each. Then close.
Those times are a shape, not a stopwatch. A team of five often lands the whole thing in eight minutes. The point isn't precision. It's that every block has a purpose, and none of them is "problem-solving."
## Walk the board, don't walk the room
Walking the board moves right to left across items in progress, so the work talks, not the people. The card stuck in review for three days can't hide when the whole team is looking at the column.
The single highest-leverage change to a standup agenda is to organize it around the *board* rather than the *people*. Start at the column closest to done and move backward toward the newest work. For each item: who's on it, what's it waiting on, what does it need to move.
Why right to left? Because it biases the team toward *finishing* over *starting*: you spend your attention on the work closest to shipping, not the shiny new thing someone picked up this morning. It also makes stalled work impossible to miss. A person can narrate a busy day; a card sitting in the same column for three days cannot.
## The parking lot is what makes the timebox real
Every standup contains the seed of its own overrun: two people find a genuinely interesting problem and start solving it while eight others watch. The parking lot is the fix, and it's a facilitation habit more than a place.
When a conversation goes deep, the facilitator says some version of: *"Good one. Let's park it. Priya, Sam, can you two grab five minutes right after?"* Name the topic, name who's needed, move on. The discussion still happens. It happens with the two people it concerns, immediately, instead of with the whole team, never.
A standup that regularly runs to thirty or forty minutes is not a discipline problem. It's a design problem. The team is using a coordination meeting to do work that belongs in a parking lot or a separate session. The forty-minute standup is the clearest symptom in the [standup anti-patterns](/guides/daily-standup-guide/standup-anti-patterns/); fix the parking-lot habit before you blame the people.
## Who owns the agenda
Someone has to hold the shape, or it doesn't hold. On a Scrum team that's often the Scrum Master, at least early on, but the goal is a team that runs its own standup without a designated timekeeper. The facilitator's job is small and specific: open on the goal, keep the board moving, park the deep dives, end on time, which is easier in a [timeboxed standup tool](/standups/) that shows how long is left. It is not to receive updates. For the facilitation moves in detail (handling the rambler, the dominator, the silent day), see [how to run an effective standup](/guides/daily-standup-guide/how-to-run-a-daily-standup/).
Once the agenda is working, the fastest way to make it stick is to give people a consistent format to fill in. [Copy-paste standup templates](/guides/daily-standup-guide/daily-standup-templates/) provide exactly that for both live and async teams. And if the daily agenda feels stale, the [standup format catalog](/guides/daily-standup-guide/standup-meeting-ideas/) has ways to vary it without losing the fifteen-minute discipline.
For how the standup's agenda fits alongside the other sprint meetings, see the [agile ceremonies guide](/guides/agile-ceremonies-guide/); for the rest of the daily-standup chapters, head back to [the guide hub](/guides/daily-standup-guide/).
## Frequently asked questions
### What is the agenda for a daily standup?
A minute or two to settle and orient on the sprint goal, then the main body (either the three questions or, better, walking the board), then a quick sweep to assign owners to any blockers and hand off deeper discussions to a parking lot. Total: fifteen minutes or less. The agenda is deliberately thin because the meeting is a sync, not a working session.
### How do you structure a fifteen-minute standup?
Front-load what matters. Open on the sprint goal so every update has something to point at, spend the bulk of the time on the work in progress, and reserve the last minute to confirm who owns each blocker. Keep problem-solving out of the meeting entirely. The timebox holds only because deeper conversations are pushed to a parking lot the moment they start.
### What is a parking lot in a standup?
The parking lot is where any topic that needs more than a sentence goes to wait. When two people start problem-solving, the facilitator names the topic, notes who needs to be in it, and moves on. The discussion happens right after the standup with only the people it concerns. It's the single mechanism that keeps a fifteen-minute meeting from becoming a forty-minute one.
### How do you keep a daily standup to fifteen minutes?
Hold a hard timebox and end on time even mid-sentence, use the parking lot for anything that needs debate, and consider walking the board instead of going person by person so the focus stays on the work. The overrun is a signal, not a failure: a standup that regularly runs long is telling you the team is trying to solve problems in a meeting built only to surface them.
---
# The complete guide to daily standups
URL: https://www.teamretro.com/guides/daily-standup-guide/
A daily standup is fifteen minutes that should leave the whole team knowing what's moving and what's stuck. This guide covers what the meeting is for, the three classic questions and better ones, a fifteen-minute agenda, copy-paste templates, and the async and remote versions for teams split across time zones. When you're ready to run it with your team, [run your standups in TeamRetro](/standups/): written updates against the same questions, an optional live walk-through, and a summary posted to Slack or Microsoft Teams.
---
# The three standup questions (and smarter alternatives)
URL: https://www.teamretro.com/guides/daily-standup-guide/daily-standup-questions/
The three daily standup questions are: **what did I do yesterday, what will I do today, and is anything blocking me.** Almost every team starts here, and for a new team it's a reasonable floor: a shared structure so nobody freezes when it's their turn.
But the three questions have a well-known failure mode, and it's worth understanding before you adopt them uncritically. Answered literally, they turn the meeting into a status report: each person recites a task diary to the room, nobody responds, and the meeting produces coordination in name only. Teams feel this as the standup that's "just list out all your accomplishments of yesterday." That's not a facilitation slip. It's what the three questions do by default.
Yesterday, today, blockers: a check-in the team runs for itself. The instant the answers are aimed at a manager instead of the team, the same three questions become a status report.
## What each question is really asking
The questions are fine. The trick is answering the *intent* behind them, not the literal words.
**"What did I do yesterday?"** is not "prove you were busy." It's "did anything I finish change what someone else should pick up today." If your progress unblocks a teammate or completes a hand-off, say it; in [TeamRetro's standups](/standups/), an @mention in your update notifies them directly. If it's just tasks you closed that touch nobody else, it belongs in the ticket, not the meeting.
**"What will I do today?"** is not "read your to-do list." It's "where are you heading, so the team can spot a collision or a dependency before it happens." Two people about to touch the same module should discover that here, not in a merge conflict this afternoon.
**"Is anything blocking me?"** is the whole reason the meeting exists, and it's the one people skip. Blockers get under-reported because naming one can feel like admitting you're stuck. Lead with it anyway, and be specific: not "I'm a bit blocked on the API," but "I need the staging credentials from Priya before I can test. Can we sort that straight after this."
## Why "blockers first" beats "yesterday first"
The conventional order (yesterday, today, blockers) buries the most useful item last, by which point attention has drained. Flip it. Ask for blockers first, while the room is fresh, and the meeting immediately earns its place: the first thing said is something the team can act on.
**Pro tip:** a blocker raised in the standup needs an owner before the standup ends: a name and a "we'll sort it right after." A blocker that gets *aired* every morning but never *followed up* is worse than not raising it, because the team learns the meeting is where problems go to be acknowledged and then ignored.
## The stronger alternative: walk the board
Once a team has the habit, the sharpest upgrade is to stop asking the three questions person by person and instead **walk the board.**
Rather than going around the room, the facilitator moves across the work in progress (typically right to left, from nearly-done back toward just-started) and the conversation is about *items*, not *people*. Who's on this? What's it waiting on? What's stalled? Anyone able to help push it over the line?
The shift is subtle and it changes everything. Person-by-person invites everyone to justify their day. Walking the board invites the team to get items to done. It naturally spotlights the work that's stuck (the card that's been in review for three days is impossible to hide when you're staring at the column), and it stops the meeting rewarding the person with the longest task list. For the mechanics of running it, see the [daily standup agenda](/guides/daily-standup-guide/daily-standup-agenda/); for more ways to vary the format, see [standup formats to keep it fresh](/guides/daily-standup-guide/standup-meeting-ideas/).
## When to keep the three questions
Don't throw them out reflexively. The three questions are the right tool for a young team, a newly-formed team, or one that's genuinely low on the habit of talking to each other. They give structure where there's none yet. The [LinkedIn field wisdom](https://en.wikipedia.org/wiki/Stand-up_meeting) here is real: a standup is partly a workaround for a team that can't yet see itself clearly. Use the scaffolding while you need it, and let the team walk the board when it's ready to talk about work instead of about itself.
Whatever structure you use, the questions only work inside a meeting that's actually facilitated, the subject of much of [the daily standup guide](/guides/daily-standup-guide/). See [how to run an effective standup](/guides/daily-standup-guide/how-to-run-a-daily-standup/) for the moves that keep it fifteen minutes, and [copy-paste standup templates](/guides/daily-standup-guide/daily-standup-templates/) for prompts you can drop into Slack or Teams.
## Frequently asked questions
### What are the three daily standup questions?
What did I do yesterday, what will I do today, and is anything blocking me. The three questions come from early agile practice and give a team a shared structure for the daily sync. They work as a floor for a new team, but experienced teams often outgrow them. Answered literally, they produce a status report rather than a coordination conversation.
### What should you say in a daily standup?
Say the things that change what a teammate does today. Name any blocker first and be specific about what you need and from whom. Share progress in terms of the goal ("checkout is code-complete, starting on the error states"), not a task diary. Skip anything that doesn't affect the team's plan for the day; that belongs in the tool, not the meeting.
### What makes a good standup update?
It's short, it's aimed at the team rather than a manager, and it leads with what's stuck. A good update tells the room something they can act on: a blocker to clear, a dependency to plan around, a hand-off to arrange. A weak update recites completed tasks that nobody needs to respond to. If your update wouldn't change anyone else's day, most of it belongs in the ticket.
### What is a better alternative to the three questions?
Walk the board instead of the people. Rather than going person by person, move right to left across the items in progress and talk about the work: what's blocked, what's close, what's stalled. It keeps the focus on getting items to done rather than on justifying individual effort, and it naturally surfaces the items that are stuck, which is what the meeting is for.
---
# Daily standup templates (copy-paste, Slack and Teams)
URL: https://www.teamretro.com/guides/daily-standup-guide/daily-standup-templates/
A daily standup template is a short, fixed set of prompts everyone answers the same way, so the meeting has a shape and nobody has to improvise what to say. The templates below are copy-paste ready for a live standup, a Slack or Teams channel, or an async thread. Pick one, use it unchanged for a fortnight, then adapt. Further down are the seven templates built into TeamRetro, each with a live demo.
One rule before you copy anything: **keep it to three prompts, and put blockers first.** A longer template feels thorough and quietly trains people to write status reports. The shorter the template, the more likely each line says something the team can act on.
## The classic three-question template
The default. Best for a new team that needs structure before it needs nuance.
```text
Yesterday: what I moved forward
Today: what I'm focused on
Blockers: anything slowing me down (and what I need)
```
It works, with one caveat covered at length in [the three standup questions](/guides/daily-standup-guide/daily-standup-questions/): answered literally it produces a task diary. The "and what I need" on the blockers line is the small edit that keeps it honest.
## The blockers-first template
The same three prompts, reordered so the useful part comes while the room is still awake.
```text
🚧 Blocked on: what's stuck + who can help
🎯 Today: my one main focus
✅ Since yesterday: anything that changes your plan
```
Reordering looks trivial and isn't. Leading with blockers signals what the meeting is *for*, and it gets the most actionable item said first instead of last.
## The walk-the-board script (facilitator)
For teams past their first few sprints, run the board instead of the people. This is the facilitator's script, not a per-person template:
```text
1. "Sprint goal: . On track?"
2. Move right → left across in-progress items:
- "What's this waiting on?"
- "What does it need to move?"
- "Anyone able to help push it over the line?"
3. Blockers → assign an owner to each.
4. Parking lot → confirm who stays for what.
```
The [daily standup agenda](/guides/daily-standup-guide/daily-standup-agenda/) covers why this beats the per-person format, and how to facilitate it.
## Async templates for Slack and Teams
For distributed or timezone-split teams, the standup moves into a channel. Same brevity, one post per person, posted by a set deadline:
```text
*Standup — [date]*
🎯 Focus today:
🚧 Blockers / need help with:
🙌 Anything the team should know:
```
Keep the main channel to one post each and push every follow-up into a thread, or the channel becomes unreadable by 11am. For the full tradeoffs (timezones, when async wins, how to stop it becoming a wall of ignored updates), see [async and remote standups](/guides/daily-standup-guide/async-and-remote-standups/).
**Pro tip:** you don't have to run async by hand. TeamRetro's [Slack integration](/integrations/slack/) and [Microsoft Teams integration](/integrations/microsoft-teams/) remind the team at a set time, everyone posts their update in TeamRetro, and a single digest goes back to the channel when the standup closes, so the update lands where the team already works and nobody has to scroll the channel to see who's blocked. For choosing a tool, see [standup tools and software](/guides/daily-standup-guide/best-standup-tools/).
## The seven standup templates built into TeamRetro
TeamRetro ships seven ready-made standup templates. Each one below has its exact questions, a sample answer, a plain-text version you can paste into Slack or Teams, and a link to a live demo you can open without signing up. If none of them fits, you can build your own template with up to 10 questions and flag each one as blocked, doing or done, so the standup still counts blockers and progress.
### Daily Standup
**Use it when:** your team wants the classic three questions with no surprises.
1. What did you do yesterday?
2. What will you do today?
3. What is blocking you?
*Example from a backend developer:* "Merged the rate-limit fix for the public API. Today I'm writing the retry logic for failed webhooks. Blocked: I need a test account on the payment provider's sandbox."
```text
Daily Standup
1. What did you do yesterday?
2. What will you do today?
3. What is blocking you?
```
[Try the Daily Standup demo](https://secure.teamretro.com/demo/standups/yesterday-today-blockers) (no signup).
### Async check-in
**Use it when:** your team is spread across time zones and everyone writes their update on their own time. It skips the icebreaker.
1. What did you get done since your last check-in?
2. What's your focus today?
3. Anything blocking you?
*Example from a product manager:* "Finished the interview notes for the onboarding research and shared them in the doc. Today I'm turning them into three problem statements for Thursday's planning. Nothing blocking."
```text
Async check-in
1. What did you get done since your last check-in?
2. What's your focus today?
3. Anything blocking you?
```
[Try the Async check-in demo](https://secure.teamretro.com/demo/standups/async-check-in) (no signup).
### Weekly sync
**Use it when:** a daily meeting is too often, and a weekly check-in on wins, priorities and help needed is enough.
1. What were your wins this week?
2. What are your top priorities next week?
3. Where do you need help or unblocking?
*Example from a marketing lead:* "The pricing page test finished and the new layout won. Next week my priority is the webinar launch. I need help from design on the landing page by Wednesday."
```text
Weekly sync
1. What were your wins this week?
2. What are your top priorities next week?
3. Where do you need help or unblocking?
```
[Try the Weekly sync demo](https://secure.teamretro.com/demo/standups/weekly-sync) (no signup).
### Daily Standown
**Use it when:** you'd rather close the day than open it. The Daily Standown is an end-of-day check-in, so tomorrow starts with blockers already known.
1. What did you finish today?
2. What carries over to tomorrow?
3. Any blockers for tomorrow?
*Example from a site reliability engineer:* "Finished moving the staging database to the new cluster. The alert clean-up carries over to tomorrow. Blocker for tomorrow: I need sign-off from security before I change the firewall rules."
```text
Daily Standown
1. What did you finish today?
2. What carries over to tomorrow?
3. Any blockers for tomorrow?
```
[Try the Daily Standown demo](https://secure.teamretro.com/demo/standups/daily-stand-down) (no signup).
### Support team huddle
**Use it when:** you run a support team and the standup is about the queue, not a sprint.
1. How is the queue looking — anything unusual?
2. Which tickets need escalation or another pair of eyes?
3. Anything blocking you from resolving a ticket?
*Example from a support agent:* "Billing tickets doubled overnight, mostly about the new invoice email. Two enterprise tickets need someone from engineering to look at them. Blocked: I can't reproduce the SSO error without a test tenant."
```text
Support team huddle
1. How is the queue looking? Anything unusual?
2. Which tickets need escalation or another pair of eyes?
3. Anything blocking you from resolving a ticket?
```
[Try the Support team huddle demo](https://secure.teamretro.com/demo/standups/support-team-huddle) (no signup).
### Design crit check-in
**Use it when:** your designers need to share work in progress and line up the feedback they need.
1. What are you designing right now?
2. What feedback or review do you need today?
3. Anything blocking your design work?
*Example from a product designer:* "I'm on high-fidelity screens for the new checkout flow. I need a review of the error states from someone in engineering today. Blocked: I'm still waiting on final copy for the payment step."
```text
Design crit check-in
1. What are you designing right now?
2. What feedback or review do you need today?
3. Anything blocking your design work?
```
[Try the Design crit check-in demo](https://secure.teamretro.com/demo/standups/design-crit-check-in) (no signup).
### Goal-focused standup
**Use it when:** you run Scrum and want every update tied to the sprint goal.
1. What did you do to move the sprint goal forward?
2. What will you do today toward the goal?
3. What is blocking the goal?
*Example from a QA engineer:* "Tested the new sign-up flow end to end and logged two bugs against the goal. Today I'm retesting the fixes so the story can close. Blocking the goal: the test environment is two builds behind."
```text
Goal-focused standup
1. What did you do to move the sprint goal forward?
2. What will you do today toward the goal?
3. What is blocking the goal?
```
[Try the Goal-focused standup demo](https://secure.teamretro.com/demo/standups/goal-focused) (no signup).
## What "good" looks like, with examples
A template only helps if people fill it in with signal. The difference:
- **Strong:** "Blocked: I need the staging DB credentials from Sam before I can test the import." (A blocker, an owner, an action.)
- **Strong:** "Checkout is code-complete; starting on the failed-payment states today." (Progress framed against the work, plus a heads-up.)
- **Weak:** "Worked on some tickets yesterday, more of the same today." (Says nothing anyone can respond to.)
The test for any line is simple: *would this change what a teammate does today?* If not, it belongs in the ticket, not the standup.
## Make it a habit, then vary it
Use one template unchanged long enough for it to become automatic (a fortnight is about right), which is easier when the prompts are saved in [standup software](/standups/) rather than pasted in each morning. Then, if the daily rhythm starts to flatten, borrow a format from the [standup ideas catalog](/guides/daily-standup-guide/standup-meeting-ideas/) rather than letting the template quietly bloat back to a status report. And whichever template you land on, it only works inside a facilitated meeting: see [how to run an effective standup](/guides/daily-standup-guide/how-to-run-a-daily-standup/). The [daily standup guide](/guides/daily-standup-guide/) hub links the rest, from the agenda to the anti-patterns.
## Frequently asked questions
### What should a daily standup template include?
Three prompts at most: what's changed since yesterday, what you're focused on today, and what's blocking you, with blockers first if you want the meeting to earn its time. A good template is short enough that filling it in takes a minute and pointed enough that it can't be answered with a task diary. Anything longer trains people to write status reports.
### What is a good Slack standup format?
One short post per person, blockers at the top, at a set time each morning. Keep it to three lines (focus, blockers, anything the team needs from you) and thread the follow-ups so the channel stays scannable. Most teams either post manually to a dedicated channel, use a standup bot to prompt everyone and collect the replies in one place, or post in TeamRetro and let its Slack integration send the reminder and the closing digest.
### What should you say in a standup (with examples)?
Lead with anything that changes a teammate's day. Good: "Blocked: I need the staging DB credentials from Sam before I can test the import." Good: "Checkout is code-complete; starting on the failed-payment states today." Weak: "Worked on some tickets, more of the same today." The test is whether your update gives the team something to act on or respond to.
### How do you run an async standup in Slack or Teams?
Pick a channel, set a daily deadline (say 10am local), and have everyone post the same short template: focus, blockers, needs. A bot can prompt people and roll the replies into one digest so nobody has to scroll. Reserve threads for the back-and-forth, and escalate any blocker that isn't moving to a quick live call. See the async and remote standups chapter for the tradeoffs.
---
# Definition of done (DoD): checklist and examples
URL: https://www.teamretro.com/guides/agile-estimation-guide/definition-of-done/
The definition of done (DoD) is the short checklist a team agrees every story must meet before it counts as complete: reviewed, tested, merged, deployed, accepted. It is one standard for the whole team. [Acceptance criteria](/guides/agile-estimation-guide/acceptance-criteria/) are per story; the definition of done is global. Confusing the two is how "done" quietly comes to mean "works on my machine."
Every team has felt the gap between "the developer says it's done" and "it's actually shippable." The definition of done closes it. You agree it once and enforce it every sprint, regardless of what any individual story does. Without it, "done" is a per-person opinion, and the difference surfaces in the demo, or worse, in production.
## What the definition of done means in Scrum
The Scrum Guide calls it "a formal description of the state of the Increment when it meets the quality measures required for the product." In plain terms, the definition of done is the commitment attached to the Increment, one of the three Scrum artifacts. Work that meets it becomes part of the Increment. Work that doesn't can't be released or shown at the sprint review; it goes back to the product backlog.
If your organization already sets a definition of done, every team uses it as the minimum and can add to it. If it doesn't, the team writes its own. The idea isn't limited to Scrum: Kanban teams often write the same list as the policy for moving work into their final column.
## Definition of done examples
### Definition of done checklist example: a software team
A workable starting point for a team shipping to a web app:
- Acceptance criteria met and verified.
- Code reviewed and merged to the main branch.
- Automated tests written and passing; no new flaky tests.
- No known regressions or open critical bugs against the story.
- Documentation and changelog updated where the change is user-facing.
- Deployed to staging and smoke-tested.
- Product owner has accepted it.
Steal this, then cut it to what your team will actually enforce. A definition of done with a line nobody checks is worse than a short one. It trains the team to treat the whole list as decorative. Keep it on one screen, and keep every item falsifiable.
### Definition of done example: a team that doesn't ship code
The same idea works for a marketing, content, or design team. A content team's definition of done might read:
- The brief's acceptance criteria are met.
- Edited by someone other than the author.
- Facts, figures, and links checked.
- Accessibility basics done: alt text, heading order, readable contrast.
- Approved by whoever requested it.
- Published or handed off, and recorded where the team can see it.
### Story, sprint, and release levels
Scrum asks for one definition of done for the Increment. In practice, many teams group the checks by where they naturally happen:
| Level | Applies to | Typical items |
|---|---|---|
| **Story** | Every backlog item | Code reviewed, tests passing, acceptance criteria met, product owner accepted |
| **Sprint** | The Increment as a whole | Integrated on the main branch, regression suite green, deployed to staging |
| **Release** | What reaches customers | Release notes written, security and performance checks run, support briefed |
Keep the story level as the core list. If a check can only happen at release, write that on the list too, so nobody marks a story done while assuming someone else will catch the gap later.
## How to write a definition of done
1. **Start from what keeps escaping.** Look at the last few sprints: the bugs found after "done", the stories that bounced back, the carry-over. Each one points at a missing line.
2. **Write it with the whole team.** The people doing the work agree it in one session, with the scrum master facilitating and the product owner in the room. A list handed down from outside is one the team won't defend under deadline pressure.
3. **Make every line checkable.** "Tested" is a mood; "automated tests written and passing in CI" is a check. If two people could disagree about whether a line is met, rewrite it.
4. **Cut it to what you'll enforce now.** We'd start with five to eight lines. Add the aspirational ones when the team can actually meet them.
5. **Put it where the work happens.** A checklist in the ticket template or on the board's "done" column gets used. A page on the wiki gets forgotten.
6. **Review it in the retrospective.** When the same gap slips through twice, add a line. When a line gets ticked without anyone checking it, ask whether it still earns its place.
## Definition of done vs acceptance criteria
This is the distinction teams trip over most. The [acceptance criteria](/guides/agile-estimation-guide/acceptance-criteria/) for a login story are specific to login: correct credentials land you on the dashboard, three wrong attempts lock the account. The definition of done (reviewed, tested, deployed) is identical for the login story, the search story, and the billing story. Criteria are *local* and answer "did we build the right thing?" The definition of done is *global* and answers "is any of our work ever shippable?" A story isn't finished until it passes both gates.
## Definition of ready vs definition of done
They're bookends, not symmetric twins. The [definition of ready](/guides/agile-estimation-guide/definition-of-ready/) gates a story *into* the sprint: small enough, clear enough, estimated. The definition of done gates the finished work *out*. Ready is about the story; done is about the work. Teams that only have one usually have ready (because unready stories are loud) and quietly let "done" drift, which is how carry-over and "90% complete" stories accumulate.
The three checklists stop blurring together once you see what each one gates:
| | Definition of ready | Acceptance criteria | Definition of done |
|---|---|---|---|
| **Scope** | Global, every story | Local, this story | Global, every story |
| **Gates** | Entry into the sprint | The story's own outcome | Exit from the sprint |
| **Answers** | "Can we start this?" | "Did we build the right thing?" | "Is it shippable?" |
| **Owned by** | Team, with the product owner | Product owner, with the team | The team |
## Who owns the definition of done
The team writes it; the team enforces it. The scrum master facilitates, and the product owner weighs in on the acceptance bar, but the engineers decide what "done" technically requires, because a loosely defined "done" is a debt they pay, not management. Revisit it in a [retrospective](/guides/scrum-masters-retrospective-guide/) when the same gap keeps slipping through; that's the signal a line is missing.
## How the definition of done changes your estimates
Story points size the work all the way to done, not to "code complete." So the definition of done is baked into every estimate. Add a line like "performance tested" and every story gets a little bigger. When the list changes, re-check your reference stories in the next planning session, or velocity will dip for a reason nobody can name.
## What goes wrong
The definition of done becomes a poster. It's pinned to the team wiki, recited in onboarding, and ignored under deadline pressure: "we'll write the tests next sprint." Two sprints later the test debt is structural and the definition is a fiction. When "done" is soft, [velocity](/guides/agile-estimation-guide/velocity/) inflates: the team books points for work that isn't really shippable, and the forecast quietly stops meaning anything.
The fix isn't a longer list; it's a shorter one the team will hold the line on. A definition of done is only as real as the story you're willing to *not* mark done because it failed one.
Acceptance criteria gate the story. The definition of done gates the team. Keep it short enough that you'll actually enforce it. An unenforced gate is just paperwork.
## Frequently asked questions
### What is the definition of done in agile?
The definition of done (DoD) is a single checklist every story must satisfy before it counts as complete: typically tested, code-reviewed, merged, documented, and deployed to staging. It is one shared standard for the whole team, not a per-story list, and it exists so that "done" means the same thing every time someone says it.
### What is the difference between the definition of done and acceptance criteria?
The definition of done is global, the same gate for every story. Acceptance criteria are local, specific to one story. Acceptance criteria say what this feature must do; the definition of done says what "shippable" means for any work the team produces. A story needs to pass both.
### What is a definition of done checklist?
A short, explicit list of conditions applied to every story: code reviewed and merged, tests written and passing, no known regressions, docs updated, deployed to a test environment, and product-owner accepted. The exact items vary by team, but it should fit on one screen and every line should be checkable.
### What is the difference between the definition of ready and the definition of done?
The definition of ready gates entry into the sprint, the bar a story clears before the team commits to it. The definition of done gates exit, the bar the finished work clears before it ships. Ready is about the story being well-formed; done is about the work being releasable.
### How do you write a definition of done?
Start from what keeps escaping: the bugs, rework, and carry-over from the last few sprints. Agree the list as a whole team, write each line so it has a yes-or-no answer, cut it to what you will actually enforce, and put it where the work happens, such as the ticket template. Then revisit it in the retrospective whenever something slips through.
### Who creates the definition of done?
The development team owns it, usually with the scrum master facilitating. The product owner has input on the acceptance bar, but the people doing the work decide what "done" technically requires, because they are the ones who pay when it is defined loosely.
## Related reading
- [Agile estimation: the complete guide](/guides/agile-estimation-guide/): the hub for everything here.
- [Acceptance criteria](/guides/agile-estimation-guide/acceptance-criteria/): the per-story test the definition of done is often confused with.
- [Definition of ready](/guides/agile-estimation-guide/definition-of-ready/): the entry gate at the other end of the sprint.
- [Planning poker mistakes](/guides/agile-estimation-guide/planning-poker-mistakes/): how a soft "done" inflates velocity.
---
# Definition of ready
URL: https://www.teamretro.com/guides/agile-estimation-guide/definition-of-ready/
The definition of ready is the team's checklist for "we can sprint this": the bar a story clears before it enters [sprint planning](/guides/sprint-planning-guide/). Most teams write one in their first retro, paste it in the wiki, and never look at it again. The version that earns its keep is short, explicit, and *blocking*: a story that fails it doesn't get committed to.
## What a useful checklist covers
- The user-facing outcome is in one sentence: no "as a…" gymnastics, just what changes.
- [Acceptance criteria](/guides/agile-estimation-guide/acceptance-criteria/) fit in three to five bullets.
- The story is small enough to fit in a sprint with room left over.
- Dependencies on other teams are identified, and confirmed.
- If design is needed, it exists.
- The team has voted on it without spreading more than two card values.
The last item is the load-bearing one. A story that produced a 3-and-13 vote spread doesn't pass the readiness check. Either refinement explains the gap, or the story [splits](/guides/agile-estimation-guide/splitting-user-stories/).
## Definition of ready vs definition of done
The definition of ready gates entry into the sprint. The [definition of done](/guides/agile-estimation-guide/definition-of-done/) gates exit from it. They aren't symmetric: ready is about the story, done is about the work. Conflating them is how teams ship stories that pass their acceptance criteria but still don't solve the user's problem.
## What goes wrong
The definition of ready becomes a wishlist instead of a gate. Stories enter the sprint without meeting it because "we don't have anything else to work on." Two sprints later the team is missing its velocity targets, and the unready stories are the carry-over.
The fix is institutional, not motivational: if there are no ready stories, the team picks up a [refinement](/guides/agile-ceremonies-guide/backlog-refinement/) task, not an unready one. A gate you walk around isn't a gate. Enforce it once and the backlog starts arriving in better shape, because everyone learns what "ready" costs to skip.
## Frequently asked questions
### What is the definition of ready?
The definition of ready is the team's checklist for "we can sprint this": the bar a story clears before it enters sprint planning. A useful one is short, explicit, and blocking: a story that fails it doesn't get committed to, it goes back to refinement.
### What is the difference between the definition of ready and the definition of done?
The definition of ready gates entry into the sprint; the definition of done gates exit from it. They aren't symmetric: ready is about the story being well-formed, done is about the finished work being releasable.
### What should a definition of ready include?
The user-facing outcome in one sentence, acceptance criteria that fit in three to five bullets, a story small enough to fit a sprint with room to spare, dependencies identified and confirmed, any needed design in place, and a team vote that didn't spread more than two card values. The last item is the load-bearing one.
### Is the definition of ready part of Scrum?
No. The Scrum Guide doesn't define it, so it's optional. But most teams that ship predictably use one, because it stops unready stories from being dragged into a sprint and becoming next sprint's carry-over.
## Related reading
- [Agile estimation: the complete guide](/guides/agile-estimation-guide/): the hub for everything here.
- [Definition of done](/guides/agile-estimation-guide/definition-of-done/): the gate at the other end of the sprint.
- [Splitting user stories](/guides/agile-estimation-guide/splitting-user-stories/): what to do when a story can't pass the readiness check.
- [Backlog refinement](/guides/agile-ceremonies-guide/backlog-refinement/): where stories get made ready.
---
# Developer experience and productivity metrics: DevEx, DX Core 4, and what's measurable
URL: https://www.teamretro.com/guides/agile-metrics/developer-experience-metrics/
**There is no single developer productivity metric, and the ones that try to be one usually count effort or output.** The approach the research supports is to measure team outcomes alongside developer experience: how fast feedback arrives, how much mental load the work carries, and how often people get to focus, asking developers and reading system data side by side.
This chapter of the [agile metrics guide](/guides/agile-metrics/) covers the 2023 debate, DevEx, DX Core 4, and how to collect experience data without wasting anyone's time.
## The 2023 productivity debate
In August 2023, McKinsey published "[Yes, you can measure software developer productivity](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity)". It called software development "perennially undermeasured" next to sales or customer operations and proposed metrics at system, team and individual level. On top of DORA and SPACE, it added four measures:
- **Inner/outer loop time spent**: coding, building and unit testing versus integration, release and deployment. Top tech companies, it says, aim for up to 70 percent inner-loop time.
- **Developer Velocity Index benchmark**: a McKinsey survey of technology, working practices and organizational enablement, benchmarked against peers.
- **Contribution analysis**: individuals' contributions to a team's backlog, drawn from tools such as Jira and normalized with a proprietary algorithm.
- **Talent capability score**: the organization's knowledge, skills and abilities against capability maps.
The article reported use at nearly 20 companies, and itself warned against lines of code and commit counts.
Kent Beck and Gergely Orosz replied in The Pragmatic Engineer ([part 1](https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity), [part 2](https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity-part-2), August 2023). They model software work as a chain: effort, output, outcome, impact. Their critique is that "nearly every one of its custom metrics which differ from DORA and SPACE metrics, measure effort or output," and that "the act of measurement changes how developers work." The earlier in the chain you measure, the easier it is and the more likely you are to cause unintended consequences. Their advice: measure team outcomes and impact, and use effort and output to debug problems, not as the score.
The two pieces agree on more than the headlines suggest. McKinsey warns that a single metric, or too simple a set, invites gaming, and Beck and Orosz accept the executive need: CEOs and CFOs see sales and recruitment measured against targets and ask why engineering can't be. The real disagreement is over individual-level measurement and how much weight effort and output should carry.
Measure teams and systems, not individuals. Lead with outcomes and developer experience; keep activity counts as diagnostics, never as targets or rankings. The framework authors land here too. The [SPACE paper](https://queue.acm.org/detail.cfm?id=3454124) says activity metrics "should never be used in isolation either to reward or to penalize developers," and DX Core 4 marks its own throughput metric "not at individual level." When the critics and the framework authors converge on a line, that's the line to hold.
## Output, outcome and experience
Beck and Orosz's chain sorts any metric, with one row added for experience:
| Layer | What it tells you | Examples | Main risk |
|---|---|---|---|
| Effort and output | How much activity happened | Commits, pull requests, story points | Easy to inflate; says nothing about value |
| Outcome | Whether delivery works | Deployment frequency, change fail rate | Shows a slowdown, not its cause |
| Impact | Whether the work paid off | Revenue, cost reduction, share of time on new capabilities | Hard to attribute to one team |
| Experience | What gets in developers' way | Satisfaction with build times, ease of delivery, focus time | Needs careful question design |
Beck and Orosz place every DORA metric in outcome or impact; the [DORA metrics chapter](/guides/agile-metrics/dora-metrics/) covers them. [SPACE](/guides/agile-metrics/space-framework/) recommends metrics from at least three of its five dimensions, at least one of them perceptual. Experience is the row that's easiest to skip, and SPACE suggests it may move first: "it is possible that satisfaction could serve as a leading indicator for productivity."
## DevEx: three dimensions of developer experience
The DevEx framework comes from Abi Noda, Margaret-Anne Storey, Nicole Forsgren and Michaela Greiler, "[DevEx: What Actually Drives Productivity](https://queue.acm.org/detail.cfm?id=3595878)", ACM Queue 21(2), 2023. It defines developer experience as "how developers feel about, think about, and value their work," and distills more than 25 sociotechnical factors from the authors' earlier research into three dimensions.
DevEx has three dimensions: feedback loops, cognitive load and flow state. Each is measured twice, by asking developers and from workflow data, because either source alone misses part of the picture.
- **Feedback loops**: "the speed and quality of responses to actions performed." Waiting on a build, a test run or a code reviewer all count. The levers are faster build and test tooling and smoother hand-offs.
- **Cognitive load**: the mental processing a task requires. Poorly documented code and systems raise it; well-organized code, clear documentation and self-service tools lower it.
- **Flow state**: energized, uninterrupted focus. The paper suggests [clustering meetings](/guides/agile-theatre/ceremony-overload/), avoiding unplanned work and batching help requests.
The paper calls it a common misconception that developer experience is mostly about tools: "human factors such as having clear goals for projects and feeling psychologically safe on a team have a substantial impact on developers' performance." That's where developer experience meets [psychological safety](/guides/psychological-safety-at-work/), and why a program that only buys faster tooling can miss what slows a team down.
### Example measures from the paper
Each dimension gets perceptual measures (what developers report) and workflow measures (what systems record):
| Dimension | Perceptual measures | Workflow measures |
|---|---|---|
| Feedback loops | Satisfaction with automated test speed and output; with time to validate a local change; with time to deploy a change to production | Time to generate CI results; code review turnaround time; deployment lead time |
| Cognitive load | Perceived complexity of the codebase; ease of debugging production systems; ease of understanding documentation | Time to get answers to technical questions; manual steps required to deploy a change; frequency of documentation improvements |
| Flow state | Perceived ability to focus and avoid interruptions; satisfaction with clarity of task or project goals; perceived disruptiveness of being on call | Number of blocks of time without meetings or interruptions; frequency of unplanned tasks or requests; frequency of incidents requiring team attention |
Above these sit three KPIs, the paper's "North Star metrics": overall perceived ease of delivering software, employee engagement or satisfaction, and perceived productivity.
### Why you need both kinds of measure
The paper's example: code review turnaround can look fast in the data and still feel disruptive if reviews keep interrupting work, while developers can feel fine about builds that the data shows are slower than they need to be. Neither source alone gives the full picture.
### What the follow-up study found
"[DevEx in Action](https://queue.acm.org/detail.cfm?id=3639443)" (Forsgren, Kalliamvakou, Noda, Greiler, Houck and Storey, ACM Queue 21(6), 2024) surveyed 219 developers. Those with significant time for deep work felt 50 percent more productive than those without it; those with a high understanding of their code felt 42 percent more productive; those reporting fast code review turnaround felt 20 percent more innovative. The authors state the limits: the study was cross-sectional, and participants worked at companies already engaged with DX, a developer-experience vendor. The outcomes are also self-reported. Three of the four original DevEx authors (Noda, Greiler and Storey) held roles at DX when it was published.
## DX Core 4
DX Core 4 is DX's own framework, announced in December 2024 by Abi Noda, who developed it with Laura Tacho and input from authors of the DevEx and SPACE papers. DX's research page calls it "a unified framework for measuring developer productivity that encapsulates DORA, SPACE, and DevEx," in four dimensions:
| Dimension | Key metric | Secondary metrics |
|---|---|---|
| Speed | Diffs per engineer (PRs or MRs), not at individual level | Lead time; deployment frequency; perceived rate of delivery |
| Effectiveness | Developer Experience Index (DXI), developed by DX | Time to 10th PR; ease of delivery; regrettable attrition (organizational level only) |
| Quality | Change failure rate | Failed deployment recovery time; perceived software quality; operational health and security metrics |
| Impact | Percentage of time spent on new capabilities | Initiative progress and ROI; revenue per engineer and R&D as percentage of revenue (organizational level only) |
The dimensions counterbalance each other, since changes to speed "may negatively affect others (e.g., quality or effectiveness)." DX says diffs per engineer "requires caution" and sets three preconditions: counterbalance it with the DXI, tie no targets or rewards to it, and communicate how it's used. DX also recommends starting from self-reported baselines rather than waiting for full system instrumentation.
Two things to weigh. The effectiveness key metric is DX's own index, so a team not using DX needs its own experience measure; the three DevEx KPIs above are a workable substitute. And DX says Core 4 has been used at more than 300 companies and cites a 3 to 12 percent increase in engineering efficiency; both figures are vendor-reported. Core 4's most portable idea is its shape: one speed, one experience, one quality and one impact measure, read together.
## How to collect experience data from developers
The DevEx paper calls surveys "a crucial tool," quick to run and accurate when designed well. TeamRetro's [Developer Experience Survey (DevEx)](/health-check-templates/developer-experience/) is one built on the paper's three dimensions: 12 statements, rated privately and discussed as a team.
**Question design.** The paper says questions "should be based on well-defined constructs and be rigorously tested in interviews for consistent interpretation." In practice: one idea per question, the same wording every round so trends mean something, and questions about the respondent's own experience. SPACE explains the last point: asking whether the team is productive "is subject to blind spots," while asking whether the person felt productive "is a useful signal." Add one open question about what slowed people down most; that's where specific causes show up.
**Cadence.** The paper recommends quarterly or semi-annual for most organizations, plus short transactional surveys at specific touchpoints (its example: when a CLI tool fails to install). eBay and Pfizer, its two case studies, both survey quarterly.
**Anonymity.** Report only anonymized, aggregate results at team or group level, as SPACE advises. Tell people up front who sees what, and keep to it.
**Small teams.** The paper warns that company-wide averages hide problems in small groups, such as mobile developers. Small teams have the opposite problem. On a six-person team, one person moving from a 2 to a 5 shifts the average by half a point, so a single round says little. Set a minimum group size before showing any breakdown, read the spread and the comments rather than the mean, judge trends over several rounds, and don't rank small teams against each other.
**Acting on results.** The paper warns about survey fatigue and names its usual cause: "a lack of follow-up action." Share results with the team within a few weeks, let it pick one or two things to change, and show what happened by the next round. Pfizer gives teams dedicated time and resources for local improvements; eBay's DevEx team runs regular retrospectives with feature teams. The [health checks and maturity models chapter](/guides/agile-metrics/maturity-models-and-health-checks/) covers when perception data beats system data.
## Frequently asked questions
### What are developer experience metrics?
They measure the friction developers meet in everyday work. The DevEx framework groups them into feedback loops, cognitive load and flow state, each measured by asking developers and from system data, plus overall KPIs such as perceived ease of delivering software.
### How do you measure developer productivity?
With several measures at team level, never one number. Pair delivery outcomes such as the DORA metrics with developer experience data, and read them together. The SPACE authors recommend metrics from at least three dimensions, at least one of them perceptual.
### What is DX Core 4?
A framework the company DX announced in December 2024 that combines DORA, SPACE and DevEx into four dimensions: speed, effectiveness, quality and impact. Its key metrics are diffs per engineer (not at individual level), DX's Developer Experience Index, change failure rate, and percentage of time spent on new capabilities.
### Should you measure individual developer productivity?
No. Software is built by teams, and individual activity counts are easy to game and miss work such as reviews and pairing. The SPACE paper advises reporting only anonymized, aggregate results at team or group level.
### How often should you ask developers about their experience?
Quarterly or twice a year suits most organizations, according to the DevEx paper, with short transactional surveys at specific moments in between. Ask only as often as you can act on the answers.
## Related reading
- [Agile and engineering metrics](/guides/agile-metrics/): the hub, with every framework side by side.
- [DORA metrics](/guides/agile-metrics/dora-metrics/): the delivery outcomes to pair with experience data.
- [The SPACE framework](/guides/agile-metrics/space-framework/): five dimensions for choosing productivity metrics.
- [From numbers to actions](/guides/agile-metrics/from-metrics-to-action/): taking a metric into a retro and out as a change.
- [Is velocity a useful metric?](/guides/agile-verdicts/is-velocity-a-useful-metric/): why an output count fails as a productivity measure.
---
# What are DORA metrics? The five measures, explained
URL: https://www.teamretro.com/guides/agile-metrics/dora-metrics/
**DORA metrics are five measures of software delivery performance: change lead time, deployment frequency and failed deployment recovery time (throughput), plus change fail rate and deployment rework rate (instability).** They describe how fast and how safely one application or service gets changes into production. The widely quoted "four keys" became five in 2024.
They don't measure developer productivity, rank teams or explain why a number moved. Used well, they give a team a shared, low-argument starting point for a conversation about delivery.
## Who DORA is
DORA stands for DevOps Research and Assessment. Its [first study ran in 2014](https://dora.dev/insights/dora-metrics-history), [in partnership with Puppet](https://dora.dev/research/2014/) as an extension of Puppet's State of DevOps research. DORA's annual reports and the book *Accelerate* (Nicole Forsgren, Jez Humble and Gene Kim, [IT Revolution, 2018](https://itrevolution.com/product/accelerate/)) grew out of that work. Google acquired DORA in [December 2018](https://dora.dev/news/dora-joins-google-cloud/), and it now runs as a Google Cloud program. The metrics predate that, so "Google's metrics" is the wrong label: they are a research program's measures.
A detail often missed: DORA's own research gathers these numbers by survey, asking respondents about "the primary application or service they work on" ([2024 report](https://dora.dev/research/2024/dora-report/), p. 13). Pipeline data is one route to the numbers, not the only valid one.
## The five DORA metrics
DORA's [metrics guide](https://dora.dev/guides/dora-metrics/) splits the five into two factors. **Throughput** is "how many changes can move through the system over a period of time." **Instability** is "how well the software deployments go."
Three measures describe how fast changes move; two describe how often they go wrong. Recovery time sits with throughput because, in the 2024 report's words, that factor measures "the speed of making updates of any kind," including changes made in response to a failure. Deployment rework rate joined in DORA's 2024 report.
| Metric | Factor | DORA's definition |
|---|---|---|
| Change lead time | Throughput | Time for a change to go from committed to version control to deployed in production |
| Deployment frequency | Throughput | Number of deployments over a given period, or the time between deployments |
| Failed deployment recovery time | Throughput | Time to recover from a deployment that fails and requires immediate intervention |
| Change fail rate | Instability | Ratio of deployments that require immediate intervention, likely a rollback or hotfix |
| Deployment rework rate | Instability | Ratio of deployments that are unplanned but happen as a result of an incident in production |
### Change lead time
The clock starts at commit and stops at production. That makes it a measure of your delivery pipeline and review process, not of how long a ticket sat in the backlog. DORA's 2025 report still calls it **lead time for changes**; the guide's current name is change lead time.
- **Measure it:** for each change that reaches production, subtract the commit timestamp from the deploy timestamp. Report the median per week or month, because one long-lived branch will drag a mean upward for no useful reason.
- **Watch for:** starting the clock at ticket creation. That's a different, longer lead time, which the [lead time vs cycle time chapter](/guides/agile-metrics/lead-time-vs-cycle-time/) covers. Don't mix the two in one trend.
### Deployment frequency
How often you deploy to production, or the time between deployments.
- **Measure it:** count production deployments per service from your deployment tool's log.
- **Watch for:** counting deploys to staging, or adding up deploys across twenty services and reporting the total as one team's frequency.
### Failed deployment recovery time
This is the metric most people still search for as **mean time to recovery (MTTR)** or time to restore service. Same idea, narrower scope. In 2023 DORA [renamed and redefined it](https://dora.dev/insights/dora-metrics-history) because the older definitions "did not distinguish between a failure initiated by a software change and a failure caused by external factors, such as a data center outage." Today it counts only recovery from a deployment that failed.
- **Measure it:** for each failed deployment, time from the failure being detected to service being restored, whether by rollback, fix forward or patch. Use the median.
- **Watch for:** including incidents with no deployment behind them (a cloud provider outage, an expired certificate). Track those as reliability instead.
### Change fail rate
The share of deployments that need immediate intervention. Most pages, and parts of DORA's own 2024 report, call it **change failure rate**; the guide says change fail rate.
- **Measure it:** failed deployments divided by total deployments over the period. Agree in writing what "failed" means (rolled back, fixed with a hotfix, or degraded service needing remediation) before you count.
- **Watch for:** fix-forward changes no one labels as failures. The rate improves and nothing else does.
### Deployment rework rate
The share of deployments that were unplanned and happened because of an incident in production. This is the newest of the five. DORA's 2024 survey asked how many deployments "in the last six months were not planned but were performed to address a user-facing bug in the application."
- **Measure it:** tag each deployment as planned or unplanned when it happens, and divide unplanned by total.
- **Watch for:** confusing it with change fail rate. Change fail rate counts the deploy that broke something. Rework rate counts the extra deploys you shipped to deal with production problems.
## Four or five DORA metrics?
**Five, as of DORA's 2024 report and its current guide.** The "four keys" were deployment frequency, lead time for changes, change failure rate and time to restore service; by 2015 DORA had grouped them as throughput and stability. Two changes since then explain why sources disagree:
1. **2023:** time to restore service (MTTR) became failed deployment recovery time, with the narrower scope above.
2. **2024:** DORA had a "longstanding hypothesis that the change failure rate metric works as a proxy for the amount of rework a team is asked to do" ([2024 report](https://dora.dev/research/2024/dora-report/), p. 11). It added a rework question to test it, found the two metrics formed "a reliable factor of software delivery stability," and the fifth metric, deployment rework rate, joined the set.
Some pages list **reliability** as the fifth. That comes from the 2021 report, which DORA's [history of the metrics](https://dora.dev/insights/dora-metrics-history) now says "inaccurately called the 'reliability' metric the 'fifth metric'," since reliability measures operations, not delivery.
## Performance levels: read them by year
DORA doesn't set performance levels in advance. They emerge each year from a cluster analysis of survey answers, so thresholds and even the number of groups change. Three clusters appeared before 2018, four from 2018 to 2021, three in 2022, and four again in 2023 and 2024 (per [DORA's FAQ](https://dora.dev/faq/)).
The [2024 report](https://dora.dev/research/2024/dora-report/) (p. 13) clustered on the original four metrics, to stay comparable with earlier years:
| 2024 level | Change lead time | Deployment frequency | Change fail rate | Recovery time | Share of respondents |
|---|---|---|---|---|---|
| Elite | Less than one day | On demand (multiple deploys per day) | 5% | Less than one hour | 19% |
| High | One day to one week | Once per day to once per week | 20% | Less than one day | 22% |
| Medium | One week to one month | Once per week to once per month | 10% | Less than one day | 35% |
| Low | One to six months | Once per month to once every six months | 40% | One week to one month | 25% |
Look at the medium row: a lower change fail rate than high, but slower.
DORA says it chose to call the faster group "high" and the slower, more stable group "medium," and that "the best teams are those that achieve elite improvement, not necessarily elite performance." Treat the table as context for a conversation, not a grade.
The [2025 report](https://dora.dev/research/2025/dora-report/) took a different cut, combining throughput and instability with measures such as burnout and time spent on valuable work, and found seven team profiles. Delivery numbers alone can miss how the work feels to the people doing it, the side of a team that [team dynamics](/guides/team-dynamics/) covers.
## What DORA metrics can't tell you
The 2025 report says the five metrics "tell you what is happening, but they don't explain why." Its example is a low deployment frequency that could come from technical debt, bureaucratic processes or team burnout, with the metrics alone unable to say which.
In practice: your change lead time doubles over a quarter. The data can show where the time goes, perhaps changes waiting in review. It takes the team to say why: the test suite got flaky, so people batch changes to avoid rerunning it, and only one person feels safe approving the payments service. That conversation is what a [retrospective](/guides/running-effective-retrospectives/) or a [health check](/guides/agile-metrics/maturity-models-and-health-checks/) is for. The [from metrics to action chapter](/guides/agile-metrics/from-metrics-to-action/) covers how to run that loop.
Velocity is not one of the five. Story points measure a team's own pace at its own calibration, which is why [velocity works inside the team and breaks outside it](/guides/agile-verdicts/is-velocity-a-useful-metric/). DORA's metrics don't measure people's experience of the work either; that's the gap the [SPACE framework](/guides/agile-metrics/space-framework/) and [developer experience metrics](/guides/agile-metrics/developer-experience-metrics/) aim at.
## Using DORA metrics without breaking them
DORA's guide lists the pitfalls, and they are worth taking literally:
- **Don't set them as targets.** A mandate like "Every application must deploy multiple times per day by year's end" invites gaming, Goodhart's law in action.
- **Don't rely on one metric.** DORA advises several, "including some with a healthy amount of tension between them." Speed without the instability pair looks great right up to the incident.
- **Measure one application or service at a time.** DORA calls blending metrics across teams or whole organizations "problematic," and comparing a mobile app with a mainframe system misleading.
- **Share ownership, and compete with your own past.** Give development, operations and release the same five numbers, and compare a service with itself, not with other teams.
- **Don't let measurement crowd out improvement.** DORA suggests starting with conversations, its five-question [Quick Check](https://dora.dev/quickcheck/), or an existing tool before building custom integrations.
Teams without pipeline data can also start from TeamRetro's [DORA Metrics Self-Assessment for Teams](/health-check-templates/dora-metrics/), which gives a baseline to revisit.
### Improving the numbers
DORA's recommended loop: gather the cross-functional team that builds and runs the service, set a baseline, and talk about where delivery hurts. Commit to the single biggest constraint, with a leading indicator such as how long code reviews take. Do the work, check progress with "the DORA Quick Check, conversations, and team retrospectives," and repeat.
The lever DORA's guide singles out is **smaller batches**: smaller changes move through delivery faster and are easier to recover from, so they help throughput and instability at once. That fits the finding that speed and stability are not a trade-off: "top performers do well across all five metrics, and low performers do poorly." On the backlog side, smaller batches start with [slicing stories vertically](/guides/agile-estimation-guide/horizontal-vs-vertical-slicing/).
For where these five fit among the other frameworks, see the [agile metrics guide](/guides/agile-metrics/).
## Frequently asked questions
### What are the 4 key DORA metrics?
The original four keys were deployment frequency, lead time for changes, change failure rate and time to restore service (MTTR). DORA now uses five: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate, added in the 2024 report.
### Is MTTR a DORA metric?
Not under that name. Mean time to recovery (time to restore service) was one of the original four keys. In 2023 DORA renamed it failed deployment recovery time and limited it to failures caused by a change to production. It is the same idea with a narrower scope.
### What is the difference between change fail rate and deployment rework rate?
Change fail rate is the share of deployments that need immediate intervention, such as a rollback or hotfix. Deployment rework rate is the share of deployments that were unplanned and made because of an incident in production. The first counts the deploys that broke something; the second counts the extra deploys made to deal with production problems.
### Should DORA metrics be used to compare teams?
No. DORA says the metrics are best applied to one application or service at a time, and lists comparing very different applications and competing with other teams as pitfalls. Compare a service with its own past, not with a different team's service.
### How do you improve DORA metrics?
Fix the biggest constraint, not the worst-looking number. DORA's guide suggests the cross-functional team sets a baseline, discusses friction in delivery, commits to the most significant bottleneck, then checks progress and repeats. Reducing batch size is a common lever.
## Related reading
- [Agile and engineering metrics](/guides/agile-metrics/): the hub, with DORA beside the other frameworks.
- [The SPACE framework](/guides/agile-metrics/space-framework/): five dimensions of developer productivity, and how DORA fits inside them.
- [Lead time vs cycle time](/guides/agile-metrics/lead-time-vs-cycle-time/): the flow-metric definitions that DORA's lead time is often confused with.
- [From numbers to actions](/guides/agile-metrics/from-metrics-to-action/): turning a DORA trend into a retro action.
- [Is velocity a useful metric?](/guides/agile-verdicts/is-velocity-a-useful-metric/): why story points stay inside the team.
---
# Epic vs story vs task: the agile hierarchy explained
URL: https://www.teamretro.com/guides/agile-estimation-guide/epic-vs-story-vs-task/
Most agile tools (Jira, Azure DevOps, Linear) ship three tiers: epics, stories, tasks. The hierarchy is load-bearing only if each tier means something distinct. When teams point all three the same way, the tiers collapse and the planning signal goes with them.
Points live at the story tier. Estimate the epic and the tasks too and you count the same effort twice.
## Epic
A body of work bigger than a sprint, usually a feature or initiative the team delivers across several sprints. Epics are sized in [t-shirt sizes](/guides/agile-estimation-guide/t-shirt-sizing/), weeks, or story counts (how many stories you think it'll decompose into), *not* story points directly. A point number at the epic level is an aggregation of the underlying stories, not a direct estimate.
## Story
A [user-facing slice of work](/guides/agile-estimation-guide/what-is-a-user-story/) that fits in one sprint. Stories are what [planning poker](/guides/agile-estimation-guide/how-to-run-planning-poker/) estimates, and where [story points](/guides/agile-estimation-guide/what-are-story-points/) live. The story is the unit of [velocity](/guides/agile-estimation-guide/velocity/), and the unit of "what we'll commit to this sprint." If a story won't fit a sprint, it's really an epic: [split it](/guides/agile-estimation-guide/splitting-user-stories/) into stories that will. [Affinity estimation](/guides/agile-estimation-guide/affinity-estimation/) surfaces those oversized items early, weeks before sprint planning.
## Task
A child of a story: a checklist item, a piece of implementation. Tasks are typically sized in hours or not sized at all. Pointing tasks duplicates the story's points and makes velocity meaningless, because you end up counting the same effort twice, at two levels of abstraction.
## The trap: pointing every tier
Some Jira workflows encourage pointing tasks under stories; some tools push for pointing epics. Both habits produce velocity numbers that don't correspond to anything real, because effort is being counted at multiple levels. Pick one tier (the story) and only point there. Everything above it is an aggregation and everything below it is implementation detail; neither should feed the velocity number directly.
## Frequently asked questions
### What is the difference between an epic, a story and a task?
An epic is a large body of work that spans multiple sprints, a story is a user-facing slice that fits in one sprint, and a task is a technical step that helps complete a story. Roughly: an epic says what and why at scale, a story says what and why for the user, and a task says how to build it.
### When does a story become an epic?
When it won't fit in a single sprint. If the team can't deliver it end to end in one sprint, it's really an epic and should be split into several stories that each can. A story that keeps growing in refinement is usually an epic in disguise.
### Should you estimate epics in story points?
Not directly. Size epics in t-shirt sizes, rough story counts, or as the sum of their underlying stories once they're broken down. A point number on an epic is an aggregation, not an estimate. The real sizing happens at the story level.
### Do tasks get story points?
No. Tasks are sized in hours or left unsized. Pointing tasks under a story double-counts effort (you end up counting the same work at two levels), which makes velocity meaningless. Point the story, not its tasks.
## Related reading
- [What are story points?](/guides/agile-estimation-guide/what-are-story-points/): the unit that lives at the story tier.
- [Splitting user stories](/guides/agile-estimation-guide/splitting-user-stories/): what to do when a "story" is really an epic.
- [Velocity](/guides/agile-estimation-guide/velocity/): why counting effort at more than one tier breaks the forecast.
- [Agile estimation guide](/guides/agile-estimation-guide/): the full estimation cluster.
- [Free planning poker for agile teams](/free-planning-poker-for-agile-teams/): estimate stories with your team in real time.
---
# Estimating a bug with no repro
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-bug-with-no-repro/
**If you can't reproduce it, you can't estimate it. You can estimate looking for it.**
A bug with no repro is two unknowns wearing one ticket. The first unknown is the cause: there's a symptom in production but no reliable way to trigger it locally, no consistent stack trace, no line in the logs that always precedes it. The second unknown is the fix, which depends entirely on the first. Voting a number on the fix before the cause is known is voting on a story the team can't actually see.
The fix isn't always hard once you find the cause; it's often a one-line change. The expensive part is the finding. Estimating the search is honest; estimating the fix is wishful.
## What gets said in the room
> **Engineer A:** "I think it's the cache invalidation."
>
> **Engineer B:** "I think it's a race in the worker."
>
> **Lead:** "Has anyone been able to make it happen on demand?"
>
> **QA:** "We've tried twenty things. Nothing reliable."
>
> **Support:** "It's three users a week, always Tuesday afternoons."
## Questions worth asking before voting
- What's the symptom, and how often does it appear?
- Have we got logging on the suspected paths, or do we need to add it first?
- Is there a customer with a known-bad account we can reproduce against?
- What's the customer cost of the bug per week, and does it justify a deep dive?
- What's the time-box on the investigation before we revisit?
Two named theories and no repro isn't a number to settle; it's a search to fund. Give it a budget and a checkpoint, then re-estimate once the cause has a name.
**Vote a search budget. When the cause has a name, estimate the fix on its own.**
See [estimating a flaky test](/guides/agile-estimation-examples/estimating-a-flaky-test/) for the same shape, and [common planning-poker mistakes](/guides/agile-estimation-guide/planning-poker-mistakes/) on estimating bugs at feature precision. Browse the other [worked estimation examples](/guides/agile-estimation-examples/), or [open a free planning poker session](/free-planning-poker-for-agile-teams/) when the cause is known.
---
# Estimating a CI/CD overhaul
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-ci-cd-overhaul/
**Pipeline work has no demo. Slice by "which build can be deleted today" to keep it estimable.**
CI/CD overhauls are the worst-shaped stories on the backlog. There's no user-facing outcome, no demo, no screenshot anyone can put in the release notes. The work is structural: replace one pipeline with another, migrate a build system, consolidate three test runners into one, move from a hand-rolled shell script to a proper workflow file. The team knows the work needs to happen. The team also knows it'll take a quarter, and that quarter will be invisible from outside the engineering org.
The estimation failure mode is predictable. The team votes 13 because "it's a refactor, it's big." Three sprints in, the old pipeline is still running alongside the new one, two systems are partially configured, and every engineer has a different mental model of which one to use. The story isn't done because there's no definition of done: pipelines don't ship; they get adopted, and adoption is a separate question from "the new thing exists."
## What gets said in the room
> **SRE:** "We need to move off the old runner. Two sprints."
>
> **Lead:** "What's the definition of done?"
>
> **SRE:** "...the new one works."
>
> **Lead:** "The new one already works for half our jobs."
>
> **Backend:** "But the old one still runs for the other half."
>
> **Lead:** "Right. So we're done when we can delete the old one."
That's the move. The story isn't "build the new pipeline"; the team probably built that months ago in someone's spare-time spike. The story is "delete the old pipeline." Until the old build system is gone, the overhaul isn't done; it's parallel infrastructure with all the cost and none of the benefit. Sizing the story as *removal* instead of *creation* gives the team a definition of done it can vote against.
## How to slice it
Inventory the jobs still running on the old system. For each job: what would it take to delete the old version? That's a story. Some are trivial (the job was already mirrored to the new pipeline; just remove the old YAML). Some are real work (test suite has a hardcoded path; deploy step depends on an old env var). Each removal is a thin slice the team can ship and demo. "We deleted the Jenkinsfile for the auth service" is a demoable outcome.
Each removal is estimable in the usual way: spike the unknowns first (does this job have consumers we don't know about?), then estimate the removal against a reference removal you already shipped. Most slices land at 2 or 3 points. The story that was "13, refactor, big" was really fifteen 2s and a 3 in a trench coat.
## Questions worth asking before voting
- What gets deleted when this story is done?
- What jobs still depend on the old system?
- Is there a consumer of the old pipeline we don't know about, like an external team or a scheduled job?
- What's the rollback if the new pipeline regresses after we delete the old one?
- Who's authoritative on "the new pipeline is the source of truth"?
- Is anyone tracking which jobs run on the old versus new system, week to week?
If the answer to "what gets deleted" is "nothing this sprint," the team is still in the parallel-infra phase and the story [fails the readiness gate](/guides/agile-estimation-guide/definition-of-ready/).
**Pipeline work is done when the old thing is gone. Slice by deletion; estimate each removal on its own.**
See [horizontal vs vertical slicing](/guides/agile-estimation-guide/horizontal-vs-vertical-slicing/) for why "build the new system" is the wrong slice axis, and the other [worked estimation examples](/guides/agile-estimation-examples/). [Open a free planning poker session](/free-planning-poker-for-agile-teams/) once the team has a list of removals.
---
# Estimating a customer-reported bug
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-customer-reported-bug/
**The bug isn't the size. The customer is the size.**
A customer-reported bug carries scope the team can't see from the ticket alone. The technical fix might be a one-liner. But the surrounding work is often most of the story: reproducing on the customer's data, writing a postmortem, drafting the response, deciding whether to credit the account, communicating to other affected customers. None of it is on the ticket. All of it eats velocity.
Estimate two things: the fix, and the response. The fix is normal planning poker. The response is unfamiliar for engineering teams and gets systematically under-sized, which is why customer bugs feel like they bleed through the sprint even when the deck-vote was small.
## What gets said in the room
> **Backend:** "The fix is one line."
>
> **PM:** "Which account reported it?"
>
> **Support:** "Their CSM is asking for an RCA by Friday."
>
> **Lead:** "Are other accounts affected? Do we need to email them?"
>
> **QA:** "Can we repro on their data, or do we need a sanitised export?"
## Questions worth asking before voting
- Who reported it, and what's their ARR, SLA, or contract status?
- Is an RCA or postmortem owed externally?
- Are other accounts affected, and how do we find out?
- Do we need to credit, refund, or extend a trial?
- Who writes the customer-facing response, and is that on this ticket?
- Reproduction: customer's data, sanitized dump, or synthetic?
[Splitting](/guides/agile-estimation-guide/splitting-user-stories/) helps: the fix is one ticket, the response is another. Both go through planning poker; only one of them is engineering-shaped.
**Estimate the fix and the response separately. The account name is what makes the response big.**
See [common planning-poker mistakes](/guides/agile-estimation-guide/planning-poker-mistakes/) on the failure mode of voting on work the room doesn't own. Browse the other [worked estimation examples](/guides/agile-estimation-examples/), or [open a free planning poker session](/free-planning-poker-for-agile-teams/) with both stories ready.
---
# Estimating a dashboard
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-dashboard/
**The story that estimates the chart and forgets the data pipeline behind it.**
Dashboards are deceptive. The visible part (the chart, the date picker, the filters) looks like a couple of days of frontend work. The invisible part is the data layer: where the numbers come from, how often they're recomputed, what time zone they're in, what counts as a unique user, and what happens when finance says the number is wrong on Tuesday morning.
The estimate hinges on whether the data already exists in a queryable shape. If yes, the work is mostly rendering. If no, the work is a data pipeline with a chart on top, and that's a different number entirely.
## What gets said in the room
> **Frontend:** "Chart library can do the rendering. A day or two."
>
> **Backend:** "What's the source of truth for these numbers?"
>
> **Data:** "Real-time, or is end-of-day fine?"
>
> **PM:** "Whose time zone are we using for 'today'?"
>
> **Lead:** "What happens when finance says the chart is wrong?"
## Questions worth asking before voting
- Does the underlying data exist in a queryable form, or do we build the pipeline first?
- Refresh cadence: live, hourly, daily, on-demand?
- Time-zone handling: server time, user time, account time?
- Drill-down: links into raw rows, or just the aggregate?
- Export: CSV, share link, embedded image?
- Permissions: who sees which slice of the data?
- What's the response when the numbers disagree with another report?
If the data pipeline doesn't exist yet, the chart isn't the story. The pipeline is, and it's worth [splitting out](/guides/agile-estimation-guide/splitting-user-stories/) and sizing on its own.
**Estimate the data layer. If the numbers aren't queryable yet, the chart is the last five percent.**
Like [estimating a search feature](/guides/agile-estimation-examples/estimating-a-search-feature/), the visible UI is the easy part; the data layer is the work. See the other [worked estimation examples](/guides/agile-estimation-examples/), or [open a free planning poker session](/free-planning-poker-for-agile-teams/) when the data question has an answer.
---
# Estimating a data migration
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-data-migration/
**The migration itself is the easy part. The reconciliation step you forgot is where the points hide.**
A data migration (moving data from one system to another, or from one shape to another inside the same system) looks like a transform. Read from the source, transform, write to the destination, switch traffic over. The team votes on the transform. The transform is usually the smallest piece of work in the story. The points are in the things the transform doesn't see: records that look fine but reference data that didn't make it, records that look broken but are actually correct in a way the spec didn't capture, edge cases that survived only because the old system tolerated them and the new one doesn't.
This is a different problem from [a database migration](/guides/agile-estimation-examples/estimating-a-database-migration/). A schema migration changes the shape of one store with the data already in it. A data migration moves data across systems, and the question isn't "does the ALTER finish in time?" but "what do we do about the rows that don't match either side?" Most of the work is reconciliation, cutover strategy, and rollback. The transform code is the part you write fastest and finish last.
## What gets said in the room
> **Backend:** "It's a script. Read, map, write. Two days max."
>
> **Data eng:** "Have we looked at how dirty the source is?"
>
> **SRE:** "What's the cutover, big bang or dual-write?"
>
> **Lead:** "Who reconciles the rows that don't migrate cleanly?"
>
> **PM:** "When are we sunsetting the old system?"
The PM's question is the one that should drive the estimate. If the old system goes away in a month, you need a strategy that hits 100% correctness; if it stays alongside the new one for two quarters, you can afford to leave the long tail for later. The estimate isn't of the transform. It's of the strategy.
## Questions worth asking before voting
- What's the source data quality: clean, dirty, or unknown?
- Cutover strategy: big bang, dual-write, shadow read, gradual?
- How long do both systems coexist? Is there a sunset date?
- Who's reconciling the rows that don't migrate cleanly, and at what bar?
- What's the rollback if the new system gets bad data after cutover?
- Are there downstream consumers (reports, integrations) that must migrate in lockstep?
If the team votes a 5 and someone says "wait, what about the audit-log records?", you didn't have an estimation problem; you had [two stories pretending to be one](/guides/agile-estimation-guide/splitting-user-stories/). Split it: the transform is one ticket, the reconciliation and cutover plan is another.
**Vote on the strategy, not the transform. The transform is two days. The strategy is the quarter.**
See [estimating a database migration](/guides/agile-estimation-examples/estimating-a-database-migration/) for the single-system schema-change variant, and the other [worked estimation examples](/guides/agile-estimation-examples/). [Open a free planning poker session](/free-planning-poker-for-agile-teams/) once the cutover strategy is sketched.
---
# Estimating a database migration
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-database-migration/
**"Add a column" is a one-line migration. The estimate isn't about the column.**
Schema migrations run two clocks. One is the SQL: usually fast, usually mechanical. The other is the operational clock: how long does it lock the table, what does it do under concurrent writes, how do you back it out if it goes wrong, and what's the contingency if it runs longer than the deploy window. The team votes on the SQL because that's what's on the ticket. The work happens on the second clock.
On a small table, the two clocks are the same and the story is genuinely small. On any table that matters, they aren't. The estimate has to account for the backfill, the rollout strategy, and the rollback that someone needs to have rehearsed before the deploy goes anywhere near production.
## What gets said in the room
> **Backend:** "It's just an ALTER, the migration runs in a second."
>
> **SRE:** "On the orders table? With locks held? At 3pm?"
>
> **DBA:** "How are we backfilling existing rows?"
>
> **SRE:** "What's the rollback if the deploy fails halfway?"
>
> **Lead:** "Does the read path tolerate the column being null for an hour?"
## Questions worth asking before voting
- How big is the table: thousands, millions, hundreds of millions of rows?
- Online migration tool, or in-place ALTER?
- Backfill strategy: synchronous, batched job, dual-write?
- What does the read path do during the rollout window?
- Rollback: forward-only, or can we revert the schema?
- Has someone walked the on-call playbook for this migration?
If half the room is voting "the SQL" and the other half is voting "the rollout," you don't have a number problem; you have [two stories pretending to be one](/guides/agile-estimation-guide/splitting-user-stories/). Split it: the schema change is one ticket, the backfill and rollout plan is another.
**Estimate the rollout and the rollback, not the ALTER. The second clock is where the risk lives.**
See [estimating a data migration](/guides/agile-estimation-examples/estimating-a-data-migration/) for the cross-system variant, and the other [worked estimation examples](/guides/agile-estimation-examples/). [Open a free planning poker session](/free-planning-poker-for-agile-teams/) once the rollout is sketched.
---
# Estimating a dependency upgrade
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-dependency-upgrade/
**Patch and minor are noise. Major across N libraries is N spikes — estimate the worst one, not the average.**
Dependency upgrades come in two shapes that look identical in the package-manager output. The first: a stack of patch and minor bumps the team should batch, run the test suite against, and merge as one boring PR. That story is a 1, sometimes a 2, and the only reason to vote on it is to confirm the team agreed it's boring. The second shape: a major bump across one or more libraries, where the changelog has a "breaking changes" section and the team has to read it. That's the story that hides in plain sight. The team votes a 3 because "it's just an upgrade" and ships at a 13 three sprints later.
This isn't [a framework upgrade](/guides/agile-estimation-examples/estimating-a-framework-upgrade/). A framework upgrade is one library you've planned around for a quarter; the team knows it's a project. A dependency upgrade is the quiet maintenance ticket someone files because the security scan flagged six libraries, and nobody has read the changelogs. The trap is the distribution: of the six bumps, four are trivial, one is a renamed export, and one is a complete API redesign. The estimate that averages them is wrong in both directions.
## What gets said in the room
> **Engineer A:** "It's six bumps. Two each. 13 total."
>
> **Lead:** "Are they all minor?"
>
> **Engineer A:** "Three minor, three major."
>
> **Engineer B:** "Did anyone read the major changelogs?"
>
> **Engineer A:** "...let me look."
>
> **Lead:** "We don't have an estimate yet. We have three spikes."
The lead is right. There isn't one number for this story because there isn't one story. The minor bumps go together as their own small ticket; each major bump is [its own spike](/guides/agile-estimation-guide/splitting-user-stories/) until someone has read the changelog and knows what's breaking.
## Questions worth asking before voting
- How many bumps, and what's the major / minor / patch breakdown?
- Has anyone read the changelogs for the major bumps?
- Are any of these on libraries the team owns, versus vendors?
- Is there a transitive-dependency conflict that forces them to happen together?
- What's the rollback if one of the upgrades breaks production?
- Does the security team have a deadline, or is this tech debt?
If the answer to "has anyone read the changelogs" is no, the estimate isn't real. Vote a capped spike for each major bump, surface what's actually breaking, then re-estimate the implementation against what you found.
**Don't estimate dependency upgrades by counting bumps. Read the changelogs first, then estimate what you found.**
See [estimating a framework upgrade](/guides/agile-estimation-examples/estimating-a-framework-upgrade/) for the single-library major-version variant, and the other [worked estimation examples](/guides/agile-estimation-examples/). [Open a free planning poker session](/free-planning-poker-for-agile-teams/) after the spikes have answered what's actually changing.
---
# Estimating a design-system change
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-design-system-change/
**The story estimates the new component and forgets the 200 places that use the old one.**
A design-system change has two scopes. The first is the system itself: the new component, the new token, the updated documentation. The second is the call-sites: every product feature that consumed the old version and needs to be migrated to the new one. The first scope is small and known. The second is what makes the work actually take a quarter.
Teams that ship the system-side change without a deprecation path ship two systems: the new one, and every place that still uses the old one. The estimate has to include the rollout (codemod or hand-migration, deprecation timeline, visual-regression strategy) or the work simply pauses there for months while feature teams get to it whenever they get to it.
## What gets said in the room
> **Designer:** "The new token is a one-line change."
>
> **Frontend:** "How many components consume it today?"
>
> **Lead:** "Are we doing a codemod, or are feature teams migrating themselves?"
>
> **QA:** "Visual regression: Percy? Manual? Both?"
>
> **PM:** "What's the deprecation window for the old version?"
## Questions worth asking before voting
- How many call-sites are affected, measured rather than guessed?
- Codemod or manual migration? What's the codemod's coverage?
- Deprecation path (warn, error, remove) over what timeline?
- Visual-regression coverage on the affected screens?
- Cross-team comms: who do we tell, when, and how?
- Rollback if the new component has a bug only production reveals?
The upstream change is small and the downstream cleanup is the work, so [split them](/guides/agile-estimation-guide/splitting-user-stories/): the new component is one story, migrating the call-sites is another, and the second is sized on the measured count, not a guess.
**Estimate the downstream migration. The new token is a line; the 200 call-sites are the quarter.**
Like [estimating a framework upgrade](/guides/agile-estimation-examples/estimating-a-framework-upgrade/), the upstream change is small and the downstream cleanup is the work. See the other [worked estimation examples](/guides/agile-estimation-examples/), or [open a free planning poker session](/free-planning-poker-for-agile-teams/) when the downstream is sized.
---
# Estimating a feature-flag rollout
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-feature-flag-rollout/
**The story ships the flag and forgets the cleanup, and the metrics, and the kill-switch.**
A feature flag isn't a deploy mechanism; it's a small product. It needs a default, an override path, an audit trail, a kill-switch, and a removal plan. Most of those are missing from the original ticket, which usually reads "wrap it in a flag." That ticket is the gate, not the feature.
The estimate has to budget for the rollout phases (1% → 10% → 50% → 100%), the metrics that decide whether to ramp or roll back at each phase, and the cleanup ticket that removes the flag once the feature is permanent. Teams that don't schedule the cleanup ship a codebase full of dead flags within a year, which is its own operational debt.
## What gets said in the room
> **Backend:** "Wrapping the call in a flag, a few lines."
>
> **SRE:** "What metric tells us the rollout is going badly?"
>
> **PM:** "Which cohorts get the flag turned on first?"
>
> **Lead:** "Who removes the flag once we're at 100%, and when?"
>
> **Backend:** "Is there a kill-switch separate from the flag?"
## Questions worth asking before voting
- Rollout shape: linear ramp, cohort-based, or boolean cutover?
- Default value if the flag service is down: old behavior or new?
- Metrics that gate each phase: what counts as "going well"?
- Kill-switch path independent of the flag system?
- Removal ticket: created upfront, or "we'll do it later"?
- Audit trail: who flipped the flag, when, why?
The fix is the same as most rollout stories: [split](/guides/agile-estimation-guide/splitting-user-stories/) the implementation, the staged rollout, and the cleanup into separate stories, and create the removal ticket before you forget it exists.
**A flag is a small product. Estimate the ramp, the gating metrics, and the cleanup, not just the wrap.**
See [estimating a rate-limit rollout](/guides/agile-estimation-examples/estimating-a-rate-limit-rollout/) for the same rollout-eats-the-work pattern, and the other [worked estimation examples](/guides/agile-estimation-examples/). [Open a free planning poker session](/free-planning-poker-for-agile-teams/) when the phases are named.
---
# Estimating a file upload
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-file-upload/
**The drag-and-drop is the easy part. Everything underneath is the actual ticket.**
The browser side of file upload is a few hours' work. The rest of it is a feature. Size limits get hit by the first user with a 4K phone camera. Virus scanning is non-negotiable the moment you accept anything from the public. Resumable uploads matter as soon as someone tries a 2GB file on hotel wifi. Object-storage costs become real once retention is unbounded and someone starts uploading their backups.
The estimate depends on which of these the team is in scope for, and which are deliberately punted. "Upload a file" without that context is sizing the picker, not the system.
## What gets said in the room
> **Frontend:** "Drag-and-drop with a progress bar: half a day."
>
> **Backend:** "Where do the bytes go? S3? Disk?"
>
> **Security:** "Are we virus-scanning? What's the max size?"
>
> **SRE:** "Resumable uploads, or do they have to start over on a dropped connection?"
>
> **Finance:** "Storage costs? How long do we keep them?"
## Questions worth asking before voting
- Max file size, max files per user, max total per account?
- Allowed MIME types, and is the check authoritative or advisory?
- Storage backend: S3, local disk, bring-your-own bucket?
- Virus scanning: synchronous, async, or none?
- Retention: forever, time-limited, user-deletable?
- Resumable uploads, or single-shot only?
- Public URLs, signed URLs, or auth-gated download?
Each "yes" here is a slice of scope. If the answers pull in scanning, resumability, and retention all at once, that's not one number; it's a [story worth splitting](/guides/agile-estimation-guide/splitting-user-stories/).
**Size the storage, the scanning, and the retention. The picker is the cheapest part.**
Adjacent: [estimating a payment integration](/guides/agile-estimation-examples/estimating-a-payment-integration/) for the same operational-tail shape, and the other [worked estimation examples](/guides/agile-estimation-examples/). [Open a free planning poker session](/free-planning-poker-for-agile-teams/) when storage and retention have answers.
---
# Estimating a flaky test
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-flaky-test/
**A flaky test is two estimates. You don't know which yet.**
One version is a one-line fix: a timing assumption, a test-order dependency, a missing `await`. The other version is three days deep into a race condition in production code that the test happened to catch. When the cards spread from 2 to 13, the team isn't disagreeing about size. They're disagreeing about *which kind of bug it is*, which is the actual unknown.
Estimating to find out how big something is, instead of after, is how this story ends up at 5 in week one and 13 in week three. The fix isn't a sharper number; it's a different shape of work. Time-box the investigation, then estimate the actual fix once the shape is known.
## What gets said in the room
> **Engineer A:** "If it's flaky for the reason I think, this is a 2."
>
> **Engineer B:** "If it's flaky for the reason *I* think, it's a 13."
>
> **Lead:** "Has anyone actually run it locally with the seed pinned?"
>
> **QA:** "It only fails in CI. Never on a dev machine."
## Questions worth asking before voting
- Does it reproduce locally, or only in CI?
- How often does it fail: 1 in 50, 1 in 5, every other run?
- When did it start failing? Which commit?
- Is the test wrong, or is it catching something real?
- Is anyone disabling it in the meantime, and at what cost?
The gap between Engineer A and Engineer B isn't a [story-points](/guides/agile-estimation-guide/what-are-story-points/) disagreement to average away. It's an unknown to investigate. A short, capped spike closes it; a louder argument doesn't.
**Vote a time-box, not a fix. Half a day to investigate, then a real story for whatever you find.**
See [estimating a bug with no repro](/guides/agile-estimation-examples/estimating-a-bug-with-no-repro/) for the same shape, and [common planning-poker mistakes](/guides/agile-estimation-guide/planning-poker-mistakes/) for estimating bugs at feature precision. Browse the other [worked estimation examples](/guides/agile-estimation-examples/), or [open a free planning poker session](/free-planning-poker-for-agile-teams/) when the investigation has a result.
---
# Estimating a framework upgrade
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-framework-upgrade/
**Major version upgrades aren't tickets. They're projects.**
Patch versions are tickets. Minor versions are usually tickets. Major versions (the ones with breaking changes, deprecation cycles, peer-dependency cascades, and "we recommend migrating to..." in the changelog) are projects, and planning poker isn't the right tool for sizing them whole. The story that says "upgrade to React 19" or "Postgres 16" is not the work; it's the wrapper around the work.
Treating the upgrade as a single estimate produces a single failure mode: the team votes 13, runs out of time in week three, and ships a half-migrated codebase that has the new framework's bugs and the old framework's idioms. The honest move is to break the upgrade into a sequence of smaller stories, each independently estimable, with the upgrade itself as the umbrella project.
## What gets said in the room
> **Engineer:** "The codemod handles most of it."
>
> **Lead:** "Most of what? What does it not handle?"
>
> **SRE:** "Do all our deps support the new version yet?"
>
> **QA:** "What's our regression-testing strategy for the diff?"
>
> **PM:** "Are we shipping anything else this sprint, or is this the sprint?"
## Questions worth asking before voting
- How many breaking changes apply to our codebase (read the changelog and count)?
- Do peer dependencies support the target version, or do we cascade?
- Codemod or manual? What's the codemod's coverage?
- Test coverage on the changed surfaces: adequate, or do we add tests first?
- Rollback strategy if it goes badly mid-sprint?
- One PR or many? If many, what's the dependency order?
The right output of this conversation is often "this isn't a story, it's a project, so let's plan it that way," then [split](/guides/agile-estimation-guide/splitting-user-stories/) it into slices the team can each estimate against a reference story.
**Don't put a single number on a major upgrade. Break it into stories, then size those.**
See [estimation techniques](/guides/agile-estimation-guide/estimation-techniques/) for fuzzier or larger work, and [estimating a research spike](/guides/agile-estimation-examples/estimating-a-research-spike/) for the investigation that should precede the estimate. Browse the other [worked estimation examples](/guides/agile-estimation-examples/).
---
# Estimating a login feature
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-login-feature/
**Login stories are almost never a 3, but someone always votes 3.**
"Add login" reads small because everyone in the room has shipped login before, on a different product, with a different set of decisions already made. The scope you remember is the scope from last time, not the scope you're about to take on. The story sounds like a known quantity right up until someone asks one of the questions below, and then it isn't.
The trap isn't that login is hard. It's that the discussion ends before the trade-offs are visible. Backend engineers anchor on "we have a library for this." PMs anchor on the happy-path screenshot. Whoever has actually built the thing recently is the one who breaks the false consensus, usually with a question that wasn't on the ticket.
## What gets said in the room
> **Backend:** "It's just JWT, we have the library."
>
> **Security:** "Password reset isn't 'just JWT'."
>
> **PM:** "Do we need 2FA on day one, or is that a follow-up?"
>
> **Frontend:** "Are we federating to Google and Apple, or rolling our own?"
>
> **SRE:** "What's the rate limit on the login endpoint?"
## Questions worth asking before voting
- Is there a password-reset flow, and who owns the email template?
- Federated identity (Google, Apple, SSO), or username and password only?
- Session storage: JWT, server session, both, refresh tokens?
- Rate limiting and account lockout on the login endpoint?
- 2FA in scope now, or a deliberate "later"?
- Audit logging for failed attempts?
Most of these answers are either "trivial" or "that's its own ticket." Count the second kind. Two or more, and you don't have a story yet: you have a candidate for [splitting](/guides/agile-estimation-guide/splitting-user-stories/), and the [3 you were about to vote](/guides/agile-estimation-guide/what-are-story-points/) is measuring the wrong thing.
**If your team votes 3 on login, the conversation hasn't happened yet. Send it back.**
Adjacent: [common planning-poker mistakes](/guides/agile-estimation-guide/planning-poker-mistakes/) covers what goes wrong inside the session; [how to run a session](/guides/agile-estimation-guide/how-to-run-planning-poker/) has the four-phase loop. See the other [worked estimation examples](/guides/agile-estimation-examples/), or [open a free planning poker session](/free-planning-poker-for-agile-teams/) and walk this story through it.
---
# Estimating a notifications system
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-notifications-system/
**The story that starts as one email ends as the only thing the team builds for six weeks.**
The first notification is straightforward: pick an event, render a template, send it. The second is also straightforward. The tenth is when the team realizes they've been writing a notifications *system* for two months without admitting it. Preferences, digests, deduplication, do-not-disturb windows, per-channel overrides (none of which were in the original ticket) all become non-negotiable the moment a user gets paged at 3am.
Estimate the system, not the email. The team that votes on "send a Slack message when X happens" is underestimating by an order of magnitude, because they're sizing one row in a table that will eventually have thirty.
## What gets said in the room
> **Backend:** "Sending the email is a one-day ticket."
>
> **PM:** "Can users turn it off?"
>
> **Backend:** "Per-event or globally?"
>
> **Designer:** "What does the preferences page look like?"
>
> **SRE:** "What if the email service is down? Retry? Queue? Drop?"
>
> **Support:** "How do we tell a user why they didn't get the email?"
## Questions worth asking before voting
- One channel today, or do we wire in email + push + Slack from the start?
- User preferences: global toggle, per-event, or per-channel?
- Deduplication and digests: needed now, or "later"?
- Delivery guarantees: at-least-once, at-most-once, exactly-once?
- Audit trail: can support tell a user why a notification didn't arrive?
- Templating: who writes the copy, who localizes it, where does it live?
The honest number sizes "the table of thirty," not "the first row." If the room can only see the first row, the story isn't ready, so [split](/guides/agile-estimation-guide/splitting-user-stories/) the one channel you need now from the system you'll grow into.
**Size the system, not the email. The first notification is a day; the thirtieth is the project.**
Like [estimating a payment integration](/guides/agile-estimation-examples/estimating-a-payment-integration/), the public surface lies about the work. See the other [worked estimation examples](/guides/agile-estimation-examples/), or [open a free planning poker session](/free-planning-poker-for-agile-teams/) when the table is sketched.
---
# Estimating a payment integration
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-payment-integration/
**The ticket says "add Stripe." The work says half a quarter.**
Payments have a public API surface that fits on one page and a private decision surface that doesn't. Picking a provider is a one-day spike. Wiring up the happy-path checkout is a couple of days. Everything that comes after (the refund flow, the webhook retry policy, the idempotency keys, the reconciliation report finance is going to ask for in month two) is the actual feature, and none of it is on the ticket.
The story that says "integrate Stripe" is rarely the story being estimated. The story being estimated is "we can take money, refund it, prove we took it, and survive a disputed charge." Until the room is voting on that scope, the number is a guess about a different thing.
## What gets said in the room
> **Backend:** "Sandbox is straightforward. The library does most of it."
>
> **SRE:** "Webhooks need idempotency. What's our retry strategy if Stripe redelivers?"
>
> **Finance:** "How are refunds reconciled? Partial refunds?"
>
> **Compliance:** "Are we touching card numbers, or staying SAQ-A?"
>
> **PM:** "What does the failed-payment email say, and who writes it?"
## Questions worth asking before voting
- Sandbox-only first, or live keys in scope from day one?
- Refunds and partial refunds: UI, API, or admin-only?
- Webhook idempotency and retry handling: who owns the dedupe table?
- PCI scope: are we keeping SAQ-A by never touching the PAN?
- Reconciliation: who builds the report, and against which source of truth?
- Failure UX: are declined cards, expired cards and 3DS challenges all in scope?
The right move on a story like this is often to [split it](/guides/agile-estimation-guide/splitting-user-stories/). "Take money" is one story; "refund money" is another; "reconcile money" is a third. Estimating them as one is how the integration ships in week three and finance asks where the report is in week eight.
**Vote on "prove we took the money and survived the dispute," not "call the checkout API."**
Adjacent: [common planning-poker mistakes](/guides/agile-estimation-guide/planning-poker-mistakes/) on splitting stories too late; [estimation techniques](/guides/agile-estimation-guide/estimation-techniques/) for work this fuzzy. See the other [worked estimation examples](/guides/agile-estimation-examples/), or [open a free planning poker session](/free-planning-poker-for-agile-teams/) when refinement is ready.
---
# Estimating a performance regression
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-performance-regression/
**p95 doubled last week and the room is voting on the wrong thing.**
Performance regressions are diagnosis-heavy and fix-light, most of the time. The team that's already found the N+1 query knows the fix is small. The team that hasn't is voting on a story whose actual content is "spend three days reading flame graphs." Those are different stories.
Two questions decide the estimate. First: is the cause known? If yes, size the fix. If no, size the investigation. Second: what's the SLO the regression broke, and what's the deadline for restoring it? A regression that violates a customer-facing SLO has a different urgency profile from a 10% slowdown nobody noticed.
## What gets said in the room
> **SRE:** "p95 went from 200ms to 450ms last Wednesday."
>
> **Backend:** "Anything obvious in the deploys that day?"
>
> **Lead:** "Three deploys. None of them touched the slow endpoint."
>
> **Backend:** "Or didn't *look* like they touched the slow endpoint."
>
> **SRE:** "Are we within SLO? Do we have time to investigate properly?"
## Questions worth asking before voting
- Is the cause known, or are we sizing an investigation?
- What's the SLO, and is it currently breached?
- What changed between the last good window and the first bad window?
- Do we have flame graphs, traces, or just dashboards?
- Is rollback a viable mitigation while we investigate?
If the cause is still a guess, this is a [time-boxed spike](/guides/agile-estimation-guide/splitting-user-stories/), not a fix — and if an SLO is breached, rollback buys the time to run it without the clock against you.
**Size what you actually have, not what you wish you had. Unknown cause means you're sizing the search.**
Like [estimating a bug with no repro](/guides/agile-estimation-examples/estimating-a-bug-with-no-repro/), the work hides in the diagnosis. See the other [worked estimation examples](/guides/agile-estimation-examples/), or [open a free planning poker session](/free-planning-poker-for-agile-teams/) when the cause is named.
---
# Estimating a prototype
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-prototype/
**The story whose deliverable is "we know what to build now," not "we built it."**
A prototype is sized for learning, not for use. The point is to answer a question (does this interaction feel right, does this approach scale, will this API hold up) quickly enough that you can change direction before committing to it. Teams that estimate prototypes the same way they estimate features get a number that funds the wrong shape of work.
The other failure mode is the opposite: estimate a prototype small, ship something that "just works" enough, and then ship that thing to production because the schedule moved on. The prototype that becomes the product is the most expensive code in the codebase, because nobody planned for the parts that aren't there.
## What gets said in the room
> **Engineer:** "I can throw something together in a couple of days."
>
> **Lead:** "What's the question we're trying to answer?"
>
> **PM:** "Is this going in front of customers, or just internal?"
>
> **Lead:** "If the answer is yes, we throw it away and rebuild?"
>
> **Engineer:** "We never throw it away."
## Questions worth asking before voting
- What question is the prototype answering, and how will we know we have an answer?
- Internal-only, or in front of customers?
- Throwaway by default, and is the team committed to that?
- What's the time-box, and what happens at the end of it?
- If it works, what's the path from prototype to production code?
The engineer's "we never throw it away" is the real risk: budget the prototype for the answer, and size the production build as its own story so the throwaway doesn't get promoted by default.
**Size a prototype for the answer, not the artifact, and plan the rebuild before the schedule plans it for you.**
Like [estimating a research spike](/guides/agile-estimation-examples/estimating-a-research-spike/), the deliverable is knowledge; treat them the same way. See [common planning-poker mistakes](/guides/agile-estimation-guide/planning-poker-mistakes/) on investigation creeping into the story, and the other [worked estimation examples](/guides/agile-estimation-examples/).
---
# Estimating a rate-limit rollout
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-rate-limit-rollout/
**The code is half a day. The rollout is two months.**
Rate limits are easy to implement and hard to roll out. The middleware is a known pattern. The hard part is picking thresholds nobody complains about, and the only way to pick them is to measure existing usage, announce the limits in advance, watch a dry-run period for who *would* have been blocked, raise the noisy ones, and only then enforce. That sequence is the work, and it doesn't fit in a sprint.
Teams that estimate the middleware miss the rollout entirely. Teams that estimate the rollout get a much bigger number, ask whether it's actually urgent, and usually decide to phase it across multiple cycles, which is the right answer. Sizing the whole thing at once forces the team into a false binary.
## What gets said in the room
> **Backend:** "The middleware is a day. We have a library."
>
> **SRE:** "What thresholds? Have we looked at p99 of current usage?"
>
> **PM:** "Who do we need to email before this turns on?"
>
> **Support:** "What does the 429 response say? Is there a retry-after?"
>
> **Lead:** "Dry-run mode first, or straight to enforcement?"
## Questions worth asking before voting
- Have we measured current usage at p50, p95 and p99 per customer?
- What thresholds, and how were they chosen?
- Per-account, per-IP, per-API-key? Combinations?
- Dry-run period: how long, and what counts as "no surprises"?
- Customer comms: who do we email, and how far in advance?
- What does the 429 response look like: message, retry-after, docs link?
- What's the override path for a customer who needs a higher limit?
[Split it](/guides/agile-estimation-guide/splitting-user-stories/): enforcement is one story, dry-run plus comms is another, threshold tuning is a third. Each is sizeable on its own; the bundle is not.
**Size the rollout, not the middleware. Measuring, announcing, and dry-running is the story.**
See [estimating a feature-flag rollout](/guides/agile-estimation-examples/estimating-a-feature-flag-rollout/) for the same rollout-eats-the-work shape, and the other [worked estimation examples](/guides/agile-estimation-examples/). [Open a free planning poker session](/free-planning-poker-for-agile-teams/) when the phases are named.
---
# Estimating a research spike
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-research-spike/
**A spike isn't a story. Don't size it like one.**
Spikes are time-boxes with deliverables: "spend two days, come back with a recommendation." The number on the card is a budget, not a forecast. Estimating a spike with the feature deck is the wrong tool: you don't know what you'll find, the relative-effort question doesn't apply, and the team will end up arguing about a number that doesn't represent anything.
The other failure mode is letting the spike eat the work. The team votes a 3, the spike runs for two weeks, nothing ships, and the original story is still unestimated. A spike has a clock and a deliverable. If both aren't on the ticket, you're not estimating a spike. You're approving an open-ended investigation.
## What gets said in the room
> **Engineer:** "I genuinely don't know what this is until I look."
>
> **PM:** "What does 'done' look like? A doc? A demo?"
>
> **Lead:** "Two days, then we re-estimate the real story with what you've found."
>
> **QA:** "What happens if the spike says 'don't build it'?"
## Questions worth asking before voting
- What's the time-box: half a day, two days, a week?
- What's the deliverable: a doc, a prototype, a recommendation, a measurement?
- Who reviews the output, and against what criteria?
- What happens if the answer is "don't build this"?
- Is this on the team's velocity, or off-cycle?
Some teams keep spikes off the [velocity](/guides/agile-estimation-guide/velocity/) number entirely: they're investment, not delivery, and conflating the two distorts the planning signal. Either approach works; not picking one and applying it consistently doesn't.
**Vote a budget with a clock and a deliverable, then re-estimate the real story afterwards.**
Related: [estimation techniques](/guides/agile-estimation-guide/estimation-techniques/) for fuzzier work, and [common planning-poker mistakes](/guides/agile-estimation-guide/planning-poker-mistakes/) on letting investigation creep into the story. Browse the other [worked estimation examples](/guides/agile-estimation-examples/), or [open a free planning poker session](/free-planning-poker-for-agile-teams/) after the spike, not during.
---
# Estimating a search feature
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-search-feature/
**"Add a search bar" turns out to be "pick a search engine, build a relevance model, and own the index forever."**
Search has two surface areas the ticket never mentions. The first is relevance: what makes one result better than another, and who decides? The second is operational: where does the index live, how does it stay in sync with the source of truth, and what happens when it falls behind? "Add search" implies a UI control. The work is the ranking and the index.
A team that's shipped search before knows the answer is rarely the same twice. Postgres full-text is fine until someone wants typo tolerance. Elasticsearch is fast until you're paying for it on weekends. Algolia is easy until you need a custom ranking. The estimate depends on which trade-off the team is taking, and that decision usually hasn't been made when the ticket lands in refinement.
## What gets said in the room
> **Backend:** "Postgres can do this with `tsvector`."
>
> **PM:** "Should typos still match? Plurals?"
>
> **Frontend:** "Are we doing autocomplete, or just submit-then-results?"
>
> **SRE:** "How are we keeping the index in sync? Triggers? Job? Stream?"
>
> **Lead:** "Who owns relevance when someone complains the right answer is on page two?"
## Questions worth asking before voting
- What corpus: how many documents, how often do they change?
- Postgres FTS, a dedicated search service, or hosted (Algolia, Typesense)?
- Typo tolerance, stemming, synonyms, plurals: which are in scope?
- Faceting and filters, or just a single ranked list?
- How does the index stay in sync, and what's the staleness budget?
- Who owns relevance long-term, and how do they tune it?
If the infrastructure choice is still open, that decision is a [spike](/guides/agile-estimation-guide/splitting-user-stories/), not a story. Size the spike and re-estimate the build once relevance has an owner.
**The search box is a day. Relevance and the index are the feature, so estimate those.**
See [estimating a payment integration](/guides/agile-estimation-examples/estimating-a-payment-integration/) for the same shape, a small public surface hiding a long operational tail, and the other [worked estimation examples](/guides/agile-estimation-examples/). Or [open a free planning poker session](/free-planning-poker-for-agile-teams/) when the relevance question has an owner.
---
# Estimating a third-party API swap
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-a-third-party-api-swap/
**The new vendor's API looks identical until you start migrating the data.**
The pitch for swapping vendors is always the same: the new API is cleaner, faster, cheaper. The trap is that the old API's quirks are load-bearing. The codebase has two years of "this is a string but it's actually a date in their format," "this returns null when it means zero," "this rate-limits silently." A clean swap means reproducing every one of those quirks against the new vendor's behavior, which is different in ways nobody has documented.
The estimate has to budget for the dual-run: the old and new vendors running side by side, with output comparison, until the team has confidence the new one matches. That phase is often longer than the implementation. Stories that don't budget for it ship the new vendor and discover the gaps the next time a customer's data hits an edge case.
## What gets said in the room
> **Backend:** "The new SDK is nicer. The basic calls are a day each."
>
> **Lead:** "What about the historical data they're holding for us?"
>
> **SRE:** "Are we running both vendors at once, or cutting over?"
>
> **Backend:** "Their webhook format is different. So is the auth."
>
> **QA:** "How do we verify equivalence — diff the responses for a week?"
## Questions worth asking before voting
- Is there historical data at the old vendor that needs to come with us?
- Auth differences: API keys, OAuth, signed requests?
- Webhooks: do the events map cleanly, or do we translate?
- Dual-run period: how long, and what's "good enough" to cut over?
- Rate limits and pricing model on the new vendor: same shape, or different?
- Rollback: can we go back if the new vendor turns out to be worse?
The basic calls are easy; the equivalence proof is the work. If the dual-run and the data move are both real, that's more than one story: [split them](/guides/agile-estimation-guide/splitting-user-stories/) and size the verification separately from the implementation.
**Budget for the dual-run and the equivalence check. The clean-looking API is the cheap part.**
Like [estimating a database migration](/guides/agile-estimation-examples/estimating-a-database-migration/), the code is fast and the rollout is the work. See the other [worked estimation examples](/guides/agile-estimation-examples/), or [open a free planning poker session](/free-planning-poker-for-agile-teams/) when the dual-run plan is sketched.
---
# Estimating an accessibility fix
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-an-accessibility-fix/
**Accessibility fixes aren't bugs. They're features the team didn't ship the first time.**
Treating an a11y issue as a bug ("fix the modal so it traps focus") sizes the trap. It doesn't size what the trap depends on: the rest of the keyboard-navigation story, the screen-reader announcements, the color contrast that probably has the same problem on the next modal too. Most "small a11y fixes" are entry points into a class of issue that runs through the whole component.
The honest estimate is on the class, not the instance. Ship one fix and you'll be back next sprint for the sibling, and the sibling's sibling, until someone admits the work is "audit the modal interaction model" and sizes it that way.
## What gets said in the room
> **Frontend:** "Adding the focus trap is half a day."
>
> **QA:** "Does the close button announce on screen readers?"
>
> **Designer:** "Is the contrast on the secondary button passing?"
>
> **Lead:** "How many other modals have the same shape?"
>
> **PM:** "Are we doing all of them, or just the one customers complained about?"
## Questions worth asking before voting
- Is this an instance or a class? How many similar components exist?
- Audit scope: this component, this page, this product?
- WCAG target: A, AA, AAA?
- Testing: axe, manual screen-reader, keyboard-only walkthrough?
- Regression prevention: lint rule, story snapshot, CI check?
- What's the ongoing budget for a11y work after this lands?
If it's a class rather than an instance, [split](/guides/agile-estimation-guide/splitting-user-stories/) the one component customers hit from the audit of the rest, and size each against what you're actually committing to.
**Size the class, not the instance. One focus trap is half a day; the pattern behind it is the story.**
Like [estimating a design-system change](/guides/agile-estimation-examples/estimating-a-design-system-change/), the upstream fix is small and the downstream coverage is the actual work. See the other [worked estimation examples](/guides/agile-estimation-examples/), or [open a free planning poker session](/free-planning-poker-for-agile-teams/) once the scope is agreed.
---
# Estimating an ML experiment
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-an-ml-experiment/
**The model is the easy part. The data is the work.**
An ML experiment is research with engineering attached. The model architecture is usually an off-the-shelf choice, and training is a known pattern. The work is upstream: getting clean training data, defining the evaluation metric the team will live or die by, building the pipeline that takes the model from notebook to production. The first 80% of the experiment is data work; the last 20% is the model.
Estimating an ML experiment with the feature deck is the same trap as estimating a research spike: you don't know what you'll find. The estimate has to be a budget for the experiment, not a forecast of the result. If the result is "the model doesn't work," that's still a successful experiment that consumed the budget; the team can't pretend that outcome makes the points wrong.
## What gets said in the room
> **ML engineer:** "Training is a day. The model is standard."
>
> **Lead:** "Where's the training data coming from?"
>
> **Data:** "We need to label about 5,000 examples first."
>
> **PM:** "What metric tells us the experiment succeeded?"
>
> **SRE:** "If it works, what does shipping it look like? Inference latency? Cost?"
## Questions worth asking before voting
- Is the training data ready, or is labeling part of this story?
- What's the evaluation metric, and what's the baseline to beat?
- Notebook-only experiment, or end-to-end including a serving path?
- What's the time-box, and what's the deliverable at the end of it?
- If the model works, what's the path to production, and is that in scope?
- Cost of training and inference: does the team have the budget?
If labeling and a serving path are both in play, they're not one story: [split](/guides/agile-estimation-guide/splitting-user-stories/) the data work, the experiment, and the productionization, and size each on what it actually is.
**Budget the experiment, don't forecast the result. A model that fails is still a result the points paid for.**
Like [estimating a research spike](/guides/agile-estimation-examples/estimating-a-research-spike/) and [estimating a prototype](/guides/agile-estimation-examples/estimating-a-prototype/), the deliverable is knowledge first. See the other [worked estimation examples](/guides/agile-estimation-examples/), or [open a free planning poker session](/free-planning-poker-for-agile-teams/) when the experiment has shipped its result.
---
# Estimating an SSO integration
URL: https://www.teamretro.com/guides/agile-estimation-examples/estimating-an-sso-integration/
**SSO is mostly someone else's quirks: spike the identity provider first, and the rest is plumbing.**
"Add SSO" reads like one feature. It's two. The first is a small piece of OAuth or SAML or OIDC plumbing: well-documented, libraries exist, every modern auth library has a tutorial. The second is everything the identity provider does that isn't in the tutorial: the claim names that don't match the spec, the redirect-URI rules that are stricter than the spec, the session timeout that doesn't match yours, the off-by-one in how groups get serialized, the metadata endpoint that returns invalid XML on Tuesdays. The first part is the story everyone can vote on. The second part is the points.
Which means the estimate isn't really about SSO. It's about *this* identity provider, and whether anyone on the team has integrated against it before. Okta with a vanilla SAML config is a different story from Azure AD with a custom claims rule that nobody on either side fully understands. A team that ships an Okta integration in a sprint will spend three sprints on a federated AD FS deployment with a custom proxy in front of it, and the code they write looks almost identical at the end.
## What gets said in the room
> **Backend:** "It's an OAuth flow. Library handles it. 5 points."
>
> **Security:** "Which IdP? Okta? Azure AD? Custom SAML?"
>
> **Backend:** "...does it matter?"
>
> **Security:** "Yes. Their claims aren't the spec's claims."
>
> **Lead:** "Has anyone on this team integrated with their IdP before?"
>
> **SRE:** "What's the rollback if it breaks for half our users?"
The lead's question is the one that decides the estimate. If someone has shipped against this provider, the story is small and well-bounded. If nobody has, the story is two unknown-shaped pieces of work. The right move isn't to estimate harder; it's to time-box a spike against the provider's actual behavior and size the implementation after.
## Questions worth asking before voting
- Which identity provider, specifically? Okta, Azure AD, Google Workspace, Auth0, custom?
- Has anyone on the team integrated against this provider before?
- OAuth, SAML, or OIDC? And which version of each?
- What's the user-provisioning model: JIT, SCIM, manual?
- Group-to-role mapping: do we need it? Where does the mapping live?
- What happens to existing local accounts during cutover?
- Session timeout, idle timeout, MFA enforcement: whose policy wins?
- Can we test against the customer's actual provider, or only a sandbox?
If two or more of these come back as "that's its own ticket," [the story is too big](/guides/agile-estimation-guide/splitting-user-stories/): split out provisioning, role mapping, and migration as their own stories and size the auth flow on its own.
**Don't vote a number until you know whose identity provider you're integrating against. The provider is the story.**
See [estimating a third-party API swap](/guides/agile-estimation-examples/estimating-a-third-party-api-swap/) for the related "someone else's quirks" pattern, and the other [worked estimation examples](/guides/agile-estimation-examples/) for more. [Open a free planning poker session](/free-planning-poker-for-agile-teams/) once the spike has answered which provider and which quirks.
---
# Agile estimation techniques: which one to use and when
URL: https://www.teamretro.com/guides/agile-estimation-guide/estimation-techniques/
Most teams argue about which estimation technique is "right." That is the wrong question. Every technique trades something away: speed for precision, coverage for depth, a number for a conversation. The technique you pick is really the failure mode you have decided you can live with. So this page is a decision guide, not a ranking: what each technique is good at, how each one fails, and which to reach for in the situation in front of you.
## Why estimate at all
Estimation gets a bad name because teams treat the estimate as a promise. It isn't one. An estimate is a shared forecast: the team's best current read on relative effort, made together so everyone carries the same picture into the sprint. Held that way, it helps you plan and it surfaces disagreement early, while it is still cheap to resolve.
Held as a commitment to be measured against later, it does the opposite. Every retrospective becomes a defense of a number, people learn to pad, and the estimate stops telling you anything true. So before you choose a technique, agree on what the number is for: a forecast you refine, not a contract you enforce. Get that straight and the choice of technique becomes a practical question rather than a political one.
## Planning poker
Planning poker is the deliberate one. Each person privately picks a card, everyone reveals at once, and the spread starts the conversation. That [private-vote-then-reveal](/guides/agile-estimation-guide/how-to-run-planning-poker/) step is the whole point: it catches the disagreement other techniques smooth over, and it keeps the senior person's number from anchoring the room. The approach was popularized by Mike Cohn at Mountain Goat Software. Reach for it when you have a focused set of well-refined stories and you need shared understanding, not just a size.
Where it fails: speed. Planning poker is the slowest technique here, and unrefined stories turn that slowness into a refinement meeting wearing an estimation badge. If a story spreads from 3 to 13, you don't have an estimation problem, you have a story that needs [splitting](/guides/agile-estimation-guide/splitting-user-stories/).
Full walk-through: [how to run planning poker](/guides/agile-estimation-guide/how-to-run-planning-poker/). To run a session with your team right now, free, use [planning poker for agile teams](/free-planning-poker-for-agile-teams/).
## Story points
Story points are the unit most of these techniques produce, not a technique in themselves, and that distinction is worth holding onto. A point measures relative size: complexity, uncertainty, and effort rolled into one number, calibrated to the team's own reference story rather than to hours. Planning poker, buckets, affinity and magic estimation all output points. T-shirt sizing deliberately does not.
Where it fails: the moment points get read as hours or compared across teams. Two teams sizing the same backlog land on different point numbers because they calibrate against different reference stories, so comparing the two measures nothing except how differently they set their zero.
Full chapter: [what are story points](/guides/agile-estimation-guide/what-are-story-points/).
## T-shirt sizing
T-shirt sizing swaps numbers for categories: XS, S, M, L, XL. Dropping the granularity makes it fast, which is exactly what you want in early refinement, on roadmap work, and in conversations with product or leadership who do not need a decimal. It keeps a group moving at the stage where more precision would only be false precision.
Where it fails: t-shirts don't add up. The moment someone outside the team needs a velocity number and you build a wiki table to convert L into 8, you have reinvented story points with extra steps.
Full chapter: [t-shirt sizing](/guides/agile-estimation-guide/t-shirt-sizing/).
## Affinity estimation
Affinity estimation flips the usual order. The team sorts stories into bigger-and-smaller piles first, with no numbers, then labels the piles once everything is grouped. Committing to numbers last is the trick: by the time they arrive the relative order is already settled, so the per-story argument (is this a 3 or a 5?) never starts. It is fast, it scales to a large backlog, and it resists anchoring almost as well as planning poker. Magic estimation is its more decisive cousin: everyone places silently, and only the stories where placements diverged get a real discussion.
Where it fails: it hides disagreement. Silent agreement gets treated as real agreement, so a story that was quietly a mix of 3s and 8s can sail through as a unanimous 5, and nobody finds out until the sprint runs short. Run it remotely without a shared board and people anchor on whoever places first, which is the exact failure it was built to avoid.
Affinity estimation sizes a whole backlog in one session; see [affinity estimation](/guides/agile-estimation-guide/affinity-estimation/) for the step-by-step.
## Velocity-based forecasting
Velocity is not a way to size stories; it is what you do with the points once you have them. It is the average number of story points a team completes per sprint over its recent history, and it exists for one job: projecting how many sprints a backlog will take. Sum the points remaining, divide by velocity, and you have a forecast grounded in the team's actual rate rather than in wishful thinking.
Where it fails: the moment it becomes a target. Measure a team on velocity and it inflates, because the fastest way to raise the number is to size the same work bigger. That is Goodhart's law running on a two-week cycle.
Full hub, with a calculator you can run your own numbers through: [velocity](/guides/agile-estimation-guide/velocity/).
## Which technique when
Here is the short version. Match the situation to the technique that fits it, and go in already knowing how that technique fails, so the failure does not surprise you.
| Situation | Reach for | Why it fits | Watch out for |
|---|---|---|---|
| New team, still building a shared model | Planning poker | The discussion builds the shared reference the team doesn't have yet | Slow; budget the time and keep stories small |
| Huge backlog to size in one pass | Affinity or magic estimation | Relative sorting handles volume far faster than voting each item | Silent agreement can hide real disagreement |
| Roadmap or quarterly planning | T-shirt sizing | Coarse categories match coarse certainty | Sizes don't sum into a velocity number |
| A single tricky story | Planning poker | Private votes surface the hidden unknowns | A wide spread means split the story, not re-vote it |
| Committing to a sprint | Planning poker, then velocity | Shared sizing plus a forecast you can plan against | Don't treat the commitment as a promise, or velocity as a grade |
Match the situation to the technique, and go in knowing how it fails.
Mature teams don't pick one technique forever; they switch by the moment. T-shirts for the roadmap, affinity or magic estimation for the long refinement pass, planning poker at the top of the backlog when the next sprint's stories need real shared understanding before anyone commits. Pick the failure mode you are willing to wear this quarter, not the one that came in the agile coach's slide deck.
## Estimate in TeamRetro
TeamRetro's [Estimations](/estimations/) runs planning poker, t-shirt sizing, and the other techniques on this page in one place: private voting so nobody anchors on the loudest voice, a live reveal that starts the right conversation, and results that carry straight into your backlog. When you need the longer view, the same points feed [velocity](/guides/agile-estimation-guide/velocity/), so a season of estimates turns into a forecast you can actually plan against. Start a session with your team and see which technique fits the work in front of you.
## Frequently asked questions
### What are the main agile estimation techniques?
The ones most teams use are planning poker, t-shirt sizing, the bucket system, affinity estimation, and magic estimation. Most of them produce story points; t-shirt sizing produces categories (XS to XL) instead. Velocity sits alongside them as the forecasting step: it turns the points you estimated into a projection of how many sprints the backlog will take. Some teams also run #NoEstimates, forecasting by counting same-sized stories rather than pointing them, which works only once refinement is genuinely that sharp.
### Which agile estimation technique is best?
It depends, and that is the honest answer rather than a dodge. There is no single best technique, because each one fails differently: planning poker is slow but builds shared understanding, t-shirt sizing and buckets are fast but coarse, affinity and magic estimation move quickly through a big backlog but can hide disagreement. The decision rule is simple. Pick the technique whose failure mode you can afford for the work in front of you. Sizing the next sprint's stories, where a hidden disagreement is expensive, favors planning poker. Sizing a hundred-item backlog, where speed matters more than precision, favors affinity or magic estimation.
### When should you use t-shirt sizing or affinity estimation instead of planning poker?
Use them when speed matters more than per-story precision and you are not about to commit the work to a sprint. T-shirt sizing suits early refinement, roadmap work, and conversations with product or leadership, where coarse sizes (XS to XL) match how much you actually know at that stage. Affinity estimation suits sizing a large backlog in one pass, because sorting stories into relative piles is far faster than voting each one individually. Planning poker earns its slower pace when the stories are about to enter a sprint and the cost of an unspoken disagreement is high. In short: t-shirts and affinity for breadth and speed, planning poker for the depth you need right before you commit.
### Do all these techniques use story points?
No. Planning poker, the bucket system, affinity estimation, and magic estimation all output story points, numbers calibrated to the team's own reference story. T-shirt sizing deliberately does not: it uses categories (XS to XL) precisely because they are coarse and do not add up, which keeps early conversations from implying a precision you don't have yet. That is also its trade-off. Because t-shirt sizes don't sum, they can't feed a velocity number without a conversion table that quietly turns them back into points.
---
# The five dysfunctions of a team, explained honestly
URL: https://www.teamretro.com/guides/team-dynamics/five-dysfunctions-of-a-team/
The five dysfunctions of a team are absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results. Patrick Lencioni stacked them as a pyramid in a 2002 business fable, and the stacking is the whole idea: each layer is caused by the one beneath it. A team that will not admit mistakes cannot argue honestly. A team that cannot argue honestly never really commits. People who have not committed do not hold each other to account, and a team that avoids accountability drifts toward personal wins instead of shared ones.
That chain is the useful part of the model, and it is the part most teams skip. When a team keeps missing what it promised, the instinct is to tighten the promises. The pyramid says look further down.
This chapter covers what each layer looks like on a real team, how to work out which one is actually yours, what to run about it, and how much weight the model can carry.
Lencioni's pyramid, base to apex. Read it bottom-up: the layer you can see is rarely the one to fix.
## How the five dysfunctions pyramid works
The pyramid is a reading order, not a ranking of importance. Absence of trust sits at the base because every other layer rests on it, and inattention to results sits at the apex because that is where the damage finally shows. Each layer is a cause of the one above it and a symptom of the one below.
That gives you two directions to read it. Top-down is how problems surface: a team notices it is missing results long before it notices that nobody admits a mistake. Bottom-up is how you fix them: start at the lowest layer that is broken, because repairing a higher one while the base is still cracked rarely holds.
Lencioni also describes the pyramid in its healthy form, which is the more useful picture to aim for. A cohesive team trusts one another, argues openly about ideas, commits to decisions, holds each other to account for them, and puts collective results ahead of individual ones. Each dysfunction is the absence of one of those five behaviors.
## Where the model comes from, and what it is not
*The Five Dysfunctions of a Team* is a novel. Lencioni published it in 2002 as a leadership fable: most of the book follows a fictional CEO, Kathryn Petersen, taking over a struggling executive team at an invented company. The model arrives near the end, as the lesson of the story. It came out of his consulting practice at the Table Group, his own firm, which still sells the assessments and workshops built on it. The model is theirs, and so is the official instrument. Anyone else, us included, can only adapt it.
There is no study behind it. No sample, no control group, no peer review, no published data. That is not a scandal, because the book never claimed otherwise, but it is worth knowing before you use the pyramid to make a decision about real people. Compare it with Amy Edmondson's work on psychological safety, which came from studying 51 work teams and found that safety was associated with more learning behavior and better performance ([Edmondson, 1999](https://journals.sagepub.com/doi/10.2307/2666999)). Both are useful. Only one of them has evidence.
So read the five dysfunctions the way you would read a good checklist from an experienced practitioner: a well-organized way to name what you are seeing, not a finding. The [Wikipedia entry](https://en.wikipedia.org/wiki/The_Five_Dysfunctions_of_a_Team) is a fair summary if you want the book's structure without the fable.
## The five dysfunctions, layer by layer
Here is the working version. For each layer: what it looks like when it is happening to you, the signal most summaries leave out, and the thing worth running. The table is the map, and the detail sits underneath it.
| Dysfunction | What it looks like | What to run |
|---|---|---|
| Absence of trust | Nobody admits a mistake or asks for help | Personal histories, a check-in ritual, go first yourself |
| Fear of conflict | Meetings are polite and decisions get re-argued afterwards | Working agreements that say how you disagree |
| Lack of commitment | Everyone nods, then does something else | Decide out loud, write it down, set a review date |
| Avoidance of accountability | Slipped work goes unmentioned | Visible commitments, peer follow-up, a regular retro |
| Inattention to results | People defend their own patch | One shared measure the whole team owns |
### Absence of trust
**What it looks like.** People manage their image. Nobody says "I got that wrong" or "I do not understand this". Questions get asked privately after the meeting instead of in it. The team may be perfectly friendly, which is what makes this one hard to spot.
**The honest signal.** Lencioni means something narrower than the everyday word. He is not talking about believing your colleague will deliver on time, which is predictive trust and arrives with experience. He means vulnerability-based trust: the willingness to be seen not coping. Chapter 6 covers the distinction and how to build it in [trust and psychological safety](/guides/team-dynamics/building-trust-and-psychological-safety/). The quick test is whether anyone on your team has said "I need help" out loud in the last month.
**What to run.** Someone has to go first, and it should be whoever holds the most authority, because a manager admitting a mistake changes the cost of admitting one for everybody else. Beyond that, structure helps more than sentiment: a check-in question at the top of every meeting, and a [team charter](/guides/team-charter/) that makes the expectations explicit rather than assumed.
### Fear of conflict
**What it looks like.** Meetings are calm and slightly dull. Nobody pushes back hard. The real discussion happens afterwards in smaller groups, and decisions that seemed settled come back a week later.
**The honest signal.** Artificial harmony is not peace, it is deferred argument. A team with no visible disagreement is usually not aligned, it is unwilling. And the opposite failure exists too: conflict that is personal rather than about the work is not the healthy kind, and more of it will not help.
**What to run.** Give disagreement a shape so it does not feel like an attack. [Team norms and working agreements](/guides/team-dynamics/team-norms-and-working-agreements/) are the practical tool here, because they let the team decide in advance how it will handle a split rather than improvising under pressure. A regular [retrospective](/retrospectives/) then gives friction a scheduled outlet, which is usually easier than asking people to raise things in the moment.
### Lack of commitment
**What it looks like.** The meeting ends with apparent agreement and nothing much changes. Ask three people what was decided and you get three answers. Work restarts on questions everyone thought were closed.
**The honest signal.** This layer is where the causal chain earns its keep. People do not fail to commit because they are disengaged. They fail because they never got to say the thing they actually thought, so they never bought in. Lencioni's point is that consensus is not required, but being heard is. Someone who lost the argument will still back the decision if the argument was real.
**What to run.** Close every discussion out loud: what we decided, who is doing it, by when. Write it down where the team can see it, and put a date on when you will look at it again. Ambiguity is the thing you are fighting, not apathy.
### Avoidance of accountability
**What it looks like.** A commitment slips and nobody mentions it. Standards drift quietly. The manager becomes the only person who ever raises a problem, which turns every issue into an escalation.
**The honest signal.** This is peer-to-peer accountability, not management oversight, and it is the layer people most often try to fix first because it is the most visible. Adding a tracking tool to a team that has not committed to anything simply produces a well-maintained record of work not happening. If your accountability is weak, check the two layers below it before you buy anything.
**What to run.** Make commitments public inside the team so following up is normal rather than an accusation. Then keep a rhythm where noticing is expected: a [retrospective](/retrospectives/) that revisits the actions from last time does most of the work, because it makes "we said we would do this and we did not" a routine sentence instead of a confrontation.
### Inattention to results
**What it looks like.** People optimize for their own function, their own metric, or their own visibility. Individual reviews go well in a quarter the team collectively missed. Status is protected more carefully than the outcome.
**The honest signal.** This one is usually the symptom, not the disease. It is also the layer most often caused by something outside the team: if the organization rewards individual heroics, no amount of team-building will outvote the incentives. Be honest about whether you are looking at a team problem or a company one.
**What to run.** Name one measure the whole team shares and can actually influence, and review it together often enough that it feels real. The point is not the number. It is that the team has something it succeeds or fails at as a unit.
## Where this sits next to psychological safety
The bottom two layers of the pyramid describe much the same territory as psychological safety: whether it is safe to be wrong in front of these people. Edmondson's version has the research behind it and a more precise definition, so where the two overlap, hers is the one to lean on.
What Lencioni adds is the chain. Psychological safety tells you whether the conditions for honest work exist. The pyramid gives you an order of operations for what to fix when they do not, and it keeps going past the point where safety stops: commitment, accountability and shared results are not safety problems, they are follow-through problems. Read together, one explains the climate and the other explains the sequence. Chapter 6 on [building trust and psychological safety](/guides/team-dynamics/building-trust-and-psychological-safety/) and our guide to [psychological safety at work](/guides/psychological-safety-at-work/) go deeper on the first half.
## How to assess your team against the model
The official instrument is a 38-item questionnaire sold as a paper handout, with an online version of 42 questions priced per team member. It belongs to the Table Group, and teams reach for it because it looks rigorous. What actually makes an assessment useful is much simpler, and you can do it without buying anything.
Three things matter more than the instrument:
1. **Score the team, not the people.** Every statement should be about how *we* behave, not how Sam behaves. The moment a survey can be read as a performance review, the answers stop being honest and you have measured politeness instead.
2. **Do it together, and look at the spread.** The most useful part of any assessment like this is not the average, it is the disagreement. When half the team rates trust at 2 and the other half at 5, that gap is the conversation. A report that only shows you a mean has thrown away the interesting data.
3. **Treat a low score as a starting point.** The score is not a verdict on the team, it is a prompt for the discussion that follows it. Teams that improve are the ones that pick the lowest layer and do something specific about it, not the ones that measure most often.
TeamRetro's [Five Dysfunctions of a Team Assessment](/health-check-templates/team-dysfunction-radar/) is built to run exactly that. It is our adaptation of the five layers, not Lencioni's official assessment and not affiliated with the Table Group. Everyone rates the same five dimensions privately on a scale of 1 to 5, the team sees the combined radar and the spread together, and the discussion starts from where people actually disagree. It is free, it takes about ten minutes, and it is built to be re-run so you can see whether anything moved.
The Five Dysfunctions of a Team Assessment in TeamRetro. Everyone rates the same five dimensions privately, and the team reads the combined result together. It is our adaptation of the model, not the official assessment.
If you want the wider context on measuring a team, the [team health check guide](/guides/team-health-check/) covers how to run one well, and the [Psychological Safety Check](/health-check-templates/psychological-safety-check/) goes deeper on the bottom two layers.
## Where the model breaks down
Four failures are common enough to name.
1. **Using it to label people.** The pyramid describes team behavior. The moment it becomes vocabulary for describing a colleague, "he has a trust issue", it has stopped helping and started doing harm. Keep it pointed at the team.
2. **Diagnosing from the top down.** Almost every team that reads the book decides its problem is accountability, because that is the layer you can see. The model's own logic says the break is usually lower. Resist the diagnosis that requires the least uncomfortable change.
3. **Treating the layers as a curriculum.** The pyramid is not a five-week program to march through in order. Running a trust exercise on a team whose real problem is that nobody knows what the goal is will just annoy everyone. Find the break, then work on it.
4. **Assuming the answer is always trust.** Sometimes the team trusts each other completely and the strategy is incoherent, or the incentives are wrong, or there are simply too many people in the room to be a team at all. A model about interpersonal behavior will find interpersonal causes, whether or not they are the real ones. Chapter 1 on [what team dynamics are](/guides/team-dynamics/what-is-team-dynamics/) covers the other forces at work.
Held loosely, it remains one of the more useful things a manager can carry around, which is a fair result for a novel.
## Running it with your team
If you want to do something with this rather than just know it, the sequence is short.
Run the [Five Dysfunctions of a Team Assessment](/health-check-templates/team-dysfunction-radar/) with the whole team and look at the spread rather than the average. Take the lowest-scoring dimension, and only that one. Run a [retrospective](/retrospectives/) focused on it, ending with two or three specific actions and owners. Put the same health check back in the calendar for a few months' time so you find out whether it worked.
That loop, measure honestly, fix one layer, check again, is worth more than a complete understanding of the model. Which layer you start with matters far less than starting at all.
## Frequently asked questions
### What are the 5 dysfunctions of a team?
The five dysfunctions are absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results. Patrick Lencioni set them out as a pyramid in 2002, with absence of trust at the base. Each layer is caused by the one beneath it: people who cannot admit mistakes will not argue honestly, people who have not argued honestly do not commit, and so on up to a team that stops caring about shared results.
### What is the most common dysfunction of a team?
Absence of trust, because it is the base of the pyramid and everything above it depends on it. It is also the one teams are least likely to name, since a team can be friendly and still have no trust in Lencioni's sense. He means vulnerability-based trust, the willingness to say "I was wrong" or "I need help" in front of colleagues, rather than simply believing people will do their jobs.
### How do you overcome the five dysfunctions of a team?
Work from the bottom up and fix one layer at a time. Build trust by having whoever holds the most authority admit a mistake first, then make it routine with check-ins and a team charter. Make conflict safe with working agreements that say how the team handles disagreement. Close discussions out loud so commitments are unambiguous. Make commitments visible so peers can follow up without it feeling like an accusation. Finally, give the team one shared measure it owns together. The common mistake is starting at the top, with accountability, when the real break is lower down.
### What is the Five Dysfunctions of a Team questionnaire?
The official version, published by Lencioni's firm the Table Group, is a 38-item questionnaire, with a longer online edition of 42 questions sold per team member. Both ask the team to rate statements about how the group behaves rather than how individuals perform, and produce a score for each of the five dysfunctions. You do not need the paid version to get the value. What matters is that everyone rates the same dimensions privately, that the results are about the team rather than any one person, and that the team looks at where its answers disagree. TeamRetro's Five Dysfunctions of a Team Assessment is our own adaptation of the model rather than the official assessment, and it is free to run.
### Is the five dysfunctions model backed by research?
No. *The Five Dysfunctions of a Team* is a business fable, written as a novel with the model presented as the lesson of the story, and it came out of Lencioni's consulting practice rather than a study. There is no sample, control group or peer review behind it. That does not make it useless, but it does mean it should be treated as a well-organized practitioner's checklist rather than a finding. Amy Edmondson's research on psychological safety, which studied 51 work teams, covers similar ground in the bottom two layers and does have evidence behind it.
### What are the 5 C's of a team?
The 5 C's are a separate framework, usually listed as communication, camaraderie, commitment, confidence and coachability, though the exact list varies by source. It is unrelated to Lencioni's pyramid and there is no single authoritative version of it. The two get confused because both are memorable five-item lists about teamwork. If you want a sequence for diagnosing what is wrong with a team, the five dysfunctions is the more structured of the two, because its layers are ordered by cause.
---
# From numbers to actions: the limits of metrics, and how to use them in a retro
URL: https://www.teamretro.com/guides/agile-metrics/from-metrics-to-action/
**Metrics tell you what changed. They don't tell you why, and they stop meaning much once they become targets.** Use system metrics to pick the question, ask the team how it experiences the problem, find the cause together in a retrospective, agree one or two actions, then measure again. DORA metrics are still worth tracking, and DORA itself treats them as a starting point for that conversation, not the answer.
Earlier chapters of this [agile metrics guide](/guides/agile-metrics/) cover what to measure: [DORA](/guides/agile-metrics/dora-metrics/), [SPACE](/guides/agile-metrics/space-framework/), [developer experience](/guides/agile-metrics/developer-experience-metrics/), [flow](/guides/agile-metrics/lead-time-vs-cycle-time/), [scrum](/guides/agile-metrics/scrum-metrics/) and [health checks and maturity models](/guides/agile-metrics/maturity-models-and-health-checks/). This one covers what goes wrong when you use them, and what to do with the numbers instead.
## Where metrics run out
### They show what, not why
When DORA [announced its 2025 report on the Google Cloud blog](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report), its authors wrote: "Simple software delivery metrics alone aren't sufficient. They tell you what is happening but not why it's happening." That is the core limitation of any system metric. Change lead time rising from two days to five is a fact. Whether the cause is a growing review queue, a flaky test suite, or two senior engineers out on leave is something only the team knows. The number tells you where to look. The people doing the work tell you what you're looking at.
### Targets corrupt the number
Economist Charles Goodhart made the original observation, about monetary policy, in a paper for a [1975 Reserve Bank of Australia conference](https://www.rba.gov.au/publications/rdp/1990/9013/conference-volumes.html). The version usually quoted is anthropologist Marilyn Strathern's, from a 1997 article in the [*European Review*](https://www.cambridge.org/core/journals/european-review/article/improving-ratings-audit-in-the-british-university-system/FC2EE640C0C44E3DB87C29FB666E9AAB): "When a measure becomes a target, it ceases to be a good measure."
Donald T. Campbell put the social version more sharply in 1976, in [*Assessing the Impact of Planned Social Change*](https://doi.org/10.56645/jmde.v7i15.297): "The more any quantitative social indicator is used for social decisionmaking, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is intended to monitor." Campbell's point goes further than Goodhart's: the target doesn't only spoil the number, it changes the work.
DORA's [metrics guide](https://dora.dev/guides/dora-metrics/) lists this among its common pitfalls. Setting the metrics as goals, it says, "increases the likelihood that teams will try to game the metrics", and it gives the example of a mandate that every application deploy multiple times a day. A team under that mandate can split one release into five deploys, and the dashboard improves while nothing else does. The same thing happens to velocity, which the [velocity verdict](/guides/agile-verdicts/is-velocity-a-useful-metric/) covers in detail.
### Individual leaderboards
Delivery metrics describe a team's system. DORA's [guide to empowering delivery teams](https://dora.dev/guides/how-to-empower-software-delivery-teams/) says: "Software delivery performance is not an individual measure." Its example: "an individual's commit velocity could be constrained by slow code reviews, rather than a lack of skill." A leaderboard of commits, pull requests or story points per person ranks people on the parts of the system they don't control, and it teaches them to optimize their own number over the team's flow. DORA's advice is to "apply generous levels of curiosity to find the causes of performance differences within the system" before looking at individuals. The [SPACE framework](/guides/agile-metrics/space-framework/) shows how to keep individual, team and system levels apart.
### Vanity dashboards
A dashboard can be accurate and still useless. The common pattern: many metrics, blended across teams, refreshed daily, discussed by nobody. DORA warns against several parts of it. Its [metrics guide](https://dora.dev/guides/dora-metrics/) says the metrics "are best suited for measuring one application or service at a time." Its [guide to empowering delivery teams](https://dora.dev/guides/how-to-empower-software-delivery-teams/) says directors should "avoid reductive aggregation across teams or comparison across different contexts", and "The best use of the DORA metrics is to track the same application over time."
A test for any dashboard: name the last decision it changed. If nobody can, it's decoration.
### Survey fatigue
Perception data has its own failure mode. Ask people too often and they stop answering, or answer on autopilot. A 2004 study of college students by [Porter, Whitcomb and Weitzer](https://doi.org/10.1002/ir.101) found that "administering multiple surveys in one academic year can significantly suppress response rates in later surveys." Team surveys aren't student surveys, but the same risk plausibly applies. A survey that produces no visible change also gives people little reason to answer the next one. Keep surveys short, space them out, and show what changed since the last one before asking again.
## The loop: from a number to a change
The fix for all five problems is the same: treat metrics as the first step of a loop that ends in a change the team makes, then check whether the change worked.
System metrics show what changed, the team explains why, one or two actions follow, and the same metrics show whether the actions worked. Skip the middle and the dashboard never changes anything.
1. **Start with system metrics.** Pick the one trend that moved or matters most this period: change lead time, change fail rate, cycle time, carry-over. One, not twelve.
2. **Ask the team.** A short health check or a few targeted questions show how people experience the problem. Is review slow because reviewers are overloaded, or because changes are too large to review? Perception data narrows the search.
3. **Find the why.** A retrospective is where the team connects the number to what actually happened, using the techniques below.
4. **Agree one or two actions.** Each with an owner and a date, and each tied to the metric you started with. More than two, and they tend to compete for attention. The [Follow-Through Index](/guides/follow-through-index/) covers what makes retro actions actually get done.
5. **Re-measure.** Look at the same metric, with the same definition, after enough time for the change to show. If it didn't move, that's information too: the cause was elsewhere, or the action didn't happen.
## How to bring the numbers into the room
Numbers dropped into a retro without preparation can produce one of two reactions: defensiveness or glazed eyes. A little preparation avoids both.
- **One screen, not a dashboard tour.** Three to five metrics, each with its definition, its source and the date range. If you need to scroll, you've brought too much.
- **Trends, not snapshots.** Show six to twelve periods. A single number invites argument about whether it's good; a trend invites the useful question of what changed.
- **Pair speed with stability.** DORA advises choosing "multiple metrics, including some with a healthy amount of tension between them." Show deployment frequency next to change fail rate, so nobody reads a speed-up without its cost.
- **Let the team annotate.** Before any discussion, ask people to mark events on the timeline: the incident, the migration, the release freeze, the week half the team was out. The annotations are often the start of the explanation, and they put the team's knowledge on the same screen as the data.
- **Frame it as the system, not the people.** DORA's [culture guidance](https://dora.dev/capabilities/generative-organizational-culture/) is to "Hold blameless postmortems", because "By removing blame, you remove fear." The same applies to a metric review, which is what the [Retrospective Prime Directive](/guides/scrum-masters-retrospective-guide/what-is-the-retrospective-prime-directive/) asks of a retro. Our [team dynamics guide](/guides/team-dynamics/) covers why this matters for how a team works together.
In TeamRetro, a facilitator can paste the numbers, or a dashboard screenshot, into a retrospective's or health check's [Context](https://help.teamretro.com/article/275-adding-context) field (rich text and one image), which everyone sees on joining; the public API and MCP server can set it on an existing meeting.
## Root-cause techniques that turn a metric into a cause
A trend tells you where to look. These two techniques help a team get from the symptom to something it can change.
### 5 whys
Ask "why?" until you reach a cause you can act on. The Institute for Healthcare Improvement's [5 whys tool](https://www.ihi.org/library/tools/5-whys-finding-root-cause) describes it as: "When a problem presents itself, ask 'Why?' five times until you reach the root cause," and attributes it to Taiichi Ohno of the Toyota Production System.
A worked example, starting from a metric:
1. Why did change fail rate rise this quarter? Most failures were in the payments service.
2. Why there? Its deploys broke on configuration, not code.
3. Why configuration? Config changes skip the staging environment.
4. Why do they skip staging? Staging config drifted months ago, so people stopped trusting it.
5. Why did it drift? Nobody owns it.
The action is now concrete: assign an owner for staging config and resync it. Note the limit IHI names: a problem can have more than one root cause, and people who see different parts of the system may answer the whys differently. That's an argument for running it as a team, not for skipping it.
### Fishbone (Ishikawa) diagram
When a metric has several plausible causes, a fishbone diagram spreads them out before the team picks one. IHI describes the [cause and effect diagram](https://www.ihi.org/library/tools/cause-and-effect-diagram) as a tool "to explore and display the possible causes of a certain effect", also known as an Ishikawa or fishbone diagram. The classic categories in [IHI's toolkit](https://www.ihi.org/sites/default/files/QIToolkit_CauseandEffectDiagram.pdf) are Materials, Methods, Equipment, Environment and People. For a software team, swap in categories that fit: code, pipeline, process, environment, people, dependencies. Put the metric trend at the head, fill the bones, vote on the most likely cause, then use 5 whys on that one. The [Fishbone (Ishikawa) Retrospective](/retrospective-templates/fishbone-ishikawa-retrospective/) template sets this up as a retro format.
## Frequently asked questions
### Are DORA metrics still relevant?
Yes. DORA still publishes and refines them: its current guide lists five metrics in two groups, throughput and instability, and its 2025 report still analyzes both. What has changed is the framing. DORA says simple delivery metrics alone aren't sufficient, because they tell you what is happening but not why. Use them as a starting signal for a team conversation, not as a scorecard.
### What are the limitations of DORA metrics?
They describe outcomes of the delivery system, not causes, so they can't tell you why a number moved. They suit one application or service tracked over time, not comparisons across teams with different systems. They don't measure individuals, and DORA says delivery performance is not an individual measure. They don't capture product value or how the work feels to the team. And once they become targets, teams game them, which DORA itself warns about.
### What is Goodhart's law in software metrics?
Goodhart's law is usually quoted in Marilyn Strathern's 1997 wording: when a measure becomes a target, it ceases to be a good measure. In software, it means a metric like deployment frequency or velocity gets pushed up by changing behavior around the number, such as splitting deploys or inflating estimates, without the underlying delivery getting better.
### How do you use metrics in a retrospective?
Bring a one-screen summary of a few metrics as trends, not snapshots. Ask the team to mark what happened on the timeline, then pick the one trend that matters most and dig for the cause with 5 whys or a fishbone diagram. Agree one or two actions with an owner and a date, and look at the same metric again at a later retro to see whether it moved.
## Related reading
- [Agile and engineering metrics](/guides/agile-metrics/): the hub, with every framework in this guide on one map.
- [What are DORA metrics?](/guides/agile-metrics/dora-metrics/): the five measures, their definitions and how to collect them.
- [Health checks and maturity models](/guides/agile-metrics/maturity-models-and-health-checks/): the perception data that sits next to system metrics.
- [The Follow-Through Index](/guides/follow-through-index/): what makes retrospective actions actually get done.
- [Is velocity a useful metric?](/guides/agile-verdicts/is-velocity-a-useful-metric/): Goodhart's law on a two-week cycle.
---
# Get started in ten minutes
URL: https://www.teamretro.com/guides/ai-agent-retrospectives/get-started/
Everything before this chapter was the case, the schema, and the facilitation. This chapter is the doing. Ten minutes from now you can have the skills installed, a trigger that fires without anyone remembering, and a clear picture of what happens after the first five entries land.
## Install the two skills
The practice ships as two free skills in the [teamretro-skills repo](https://github.com/TeamRetroHQ/teamretro-skills), open source under an MIT license:
- **`ai-session-retro`** writes the end-of-session entry: the four-part, evidence-cited retro this guide has described, with one fixed root-cause label per friction item and a ticket-sized fix on every finding.
- **`ai-retro-brief`** reads the accumulated entries and synthesizes the one-page pre-retro brief: recurring friction ranked by frequency and cost, the root-cause distribution, whether past fixes were actually adopted, and three recommended actions.
Clone the repo and drop the skills into your Claude Code setup. Not on Claude Code? The repo's tool-agnostic prompt pack carries the same schema (same four-part entry, same fixed labels, same "no finding without a fix") to Cursor, GitHub Copilot, or any agent you can hand a system prompt.
## Make the trigger deterministic
Here is the one setup step teams skip and regret. Skill invocation is probabilistic: if nothing triggers the retro at session end, the log starves silently and your first brief never has enough to say. The fix is to layer a deterministic trigger on top. Pick at least one of these; two is better.
**A session-start hook.** Add a `SessionStart` hook to `.claude/settings.json` that injects one line of context: "at the natural end of a substantial session, run the ai-session-retro skill and commit the entry." Blunt (it fires on two-minute sessions too) but it's the only trigger that depends on nobody remembering anything.
**A `/retro` command.** Create `.claude/commands/retro.md` with a short instruction to run the skill on the current session, exactly as specified. Typing `/retro` at the end of a feature branch or a triage shift invokes it on demand. Deterministic once typed; the weak link is human memory, so pair it with one of the others.
**A convention line.** One sentence in the scope's context file (`CLAUDE.md` / `AGENTS.md`), or in the team SOP for non-code scopes: "End every substantial AI-assisted session by running ai-session-retro and committing the entry." Zero infrastructure; treat it as the norm layer, not the trigger.
Exact copy-paste snippets for all three live in the repo's `SETUP.md`.
The whole on-ramp: install the skills, let the agent write its first entry, and after about five, bring the one-page brief to your team.
## What your first entry will look like
Run one session with the skill on. At the end, the agent writes something like this: a real shape from a marketing scope, not a coding one, to make the point that the practice isn't dev-only:
```markdown
# 2026-07-16 — Monthly ads account review
**Session size:** ~25 turns, 1 deliverable
**Outcome:** shipped
## Friction
- **[missing-context]** The brief didn't say the French campaigns were
deliberately paused for Q3; ~40 min (est.) auditing a "broken"
campaign that was fine.
→ Fix (altitude: process): add campaign-status flags to the monthly
brief template
## Do this first
Campaign-status flags in the brief template — kills the largest single
time sink this month.
```
One label per finding, evidence with a cost, a fix sized to become a ticket. That first read is usually the moment the practice clicks: the agent names something about your work you half-knew and never wrote down.
## After five entries, run the brief
One entry is an anecdote; five is where patterns start to mean something. After a week or two of normal work, run `ai-retro-brief`. It reads every entry, ranks the recurring friction, states plainly which root-cause group dominates (briefing, documentation, the work material, tooling, or the agent itself), and checks whether the fixes past entries proposed were actually adopted. The output is one page, written for humans walking into a retro.
Then close the loop, and there are two ways to do it:
- **With any retro tool.** The brief is just a document. Read it before the meeting, add the top item or two to whatever board you run, sticky notes included. The whole practice works this way, end to end, without TeamRetro or any other specific product.
- **With TeamRetro, the agent posts for itself.** If your team runs its retros in TeamRetro, the agent can prepare its recommendations from the log and, with your confirmation on each item, file them through the [TeamRetro MCP server](/mcp/): parked items queued for your next retro, or actions when a fix already has an owner. Every posted item is prefixed `[AI retro]`, so the room can see which participant raised it: the agent's findings arrive on the board as its own contribution, instead of you relaying them second-hand.
## Where to go next
That's the whole loop: install, trigger, five entries, brief, retro. If you want to revisit the reasoning behind any step (the labels, the honesty rules, the facilitation), the [guide hub](/guides/ai-agent-retrospectives/) links every chapter. And if you're sending this to a teammate who won't read six chapters, send them [how to gather feedback from your AI agents](/blog/gather-feedback-from-ai-agents/), the 10-minute version of this whole guide.
---
# Group dynamics at work: the forces and the failure modes
URL: https://www.teamretro.com/guides/team-dynamics/group-dynamics/
Group dynamics is the study of the forces at work within and between groups of people, and how members influence one another's attitudes and behavior. The psychologist Kurt Lewin coined the term in the 1940s and founded a research center for it at MIT in 1945. It is the parent field that team dynamics draws from.
The definition is where most articles stop. It is also where they stop being useful. The forces Lewin described are the same ones that let a weak decision sail through a meeting unchallenged, or a quiet expert keep their doubts to themselves while the loudest voice sets the direction. This chapter stays with those forces and what a manager does when they turn against the work.
## Group dynamics vs team dynamics
Group dynamics and team dynamics get used as if they were interchangeable. They are not, and the gap matters for what you can borrow from the research.
Group dynamics is the wide field. It covers any set of people who influence each other, from a jury to a committee to a crowd. [Kurt Lewin](https://www.britannica.com/biography/Kurt-Lewin) treated the group as a system with its own forces rather than a sum of the individuals in it, so changing one part of that system makes the rest shift to compensate.
Team dynamics is the workplace subset: the same forces narrowed to a small group of interdependent people who share a goal and hold each other accountable for it. For the full definition and the five things that shape a working team, start with [what team dynamics are](/guides/team-dynamics/what-is-team-dynamics/). This chapter stays at the parent level, because the classic failure modes were named here first, in the group-dynamics research, long before anyone wrote a management post about them.
## The forces inside every group
Lewin's point was that these forces operate whether or not anyone names them. Four of them do most of the work.
- **Roles.** Who does what, and who the group expects to do what. Roles form quickly and often without discussion, then harden. Meredith [Belbin](https://www.belbin.com/about/belbin-team-roles) gave us a useful vocabulary for the informal roles people drift into, such as the plant who generates ideas or the finisher who chases loose ends, though his self-perception inventory has mixed psychometric support, so treat it as language rather than a test.
- **Norms.** The unwritten rules for how the group behaves, from expected reply times to whether it is safe to disagree in front of the boss. Norms are the most portable of the four, which is why writing them down as [team norms and working agreements](/guides/team-dynamics/team-norms-and-working-agreements/) pays off.
- **Cohesion.** How tightly members bond and want to stay in the group. Cohesion builds as a team moves through its [early stages](/guides/team-dynamics/stages-of-team-development/), and it is mostly an asset, up to the point where the wish to stay agreeable starts to outrank the work.
- **Conformity.** The pull to match the group's apparent position. Some conformity is sensible, since other people often know things you do not. The trouble starts when people conform against their own judgment because dissent feels expensive.
The first three are usually assets. The catch is that the same forces that make a group cohere can quietly degrade its judgment. That is the part the definitions leave out.
## The dark side: groupthink and social loafing
### Groupthink
Irving Janis studied a run of American foreign-policy disasters and asked how capable groups talked themselves into obviously bad decisions. His 1972 term was [groupthink](https://www.britannica.com/science/groupthink), which he defined as "a mode of thinking ... when members' strivings for unanimity override their motivation to realistically appraise alternative courses of action."
Janis named several warning signs. Three are worth memorizing:
- an illusion of invulnerability, where the group feels too capable to fail;
- self-censorship, where members swallow their doubts to keep the consensus intact;
- mindguards, self-appointed members who shield the group from information that would disturb the emerging agreement.
Notice that cohesion is the soil groupthink grows in. A tight, agreeable team is not automatically a safe one. It can be a team where disagreement has become socially expensive.
A cheap countermeasure is to make people's real positions visible before the group converges. You can run [Team Spectrum](https://games.teamretro.com/games/team-spectrum/) live with your team to surface where everyone stands on a question, instead of reading a show of hands that has already tilted toward whoever spoke first.
### Social loafing (the Ringelmann effect)
Around 1913, the French engineer Max Ringelmann had people pull on a rope, alone and in groups, and measured the force. Individuals pulled less hard as the group grew. The effect is now called [social loafing](https://www.simplypsychology.org/social-loafing.html): as a group gets bigger, the effort any one person contributes tends to drop.
At work this is the eight-person meeting where nobody owns the outcome, or the shared task everyone assumes someone else is carrying. The standard antidote is uncomfortable but effective: keep the accountable unit small, and put a named owner on every commitment. A shared task with no name against it is the one most likely to slip, so a named owner turns a group intention into one person's job.
### Conformity
Conformity is the quieter force under both of the above. People match the group for two reasons: they assume the group knows something they do not, and they would rather not pay the social cost of standing out. Both are reasonable in the moment and corrosive over time. A team that rewards agreement teaches its members to keep inconvenient information to themselves, which is the exact input groupthink needs.
## How group dynamics show up at work, and what to do
You cannot order a group to have good dynamics. The forces settle on their own. What a manager changes is the conditions, and then the forces resettle around them. Four moves cover most situations.
**Make dissent cheap.** Groupthink and conformity both feed on the sense that disagreeing is risky. Lower that cost on purpose: ask the most senior person to speak last, collect views in writing before the discussion, or assign someone to argue the opposing case so the objection is in the room by design. A regular retrospective gives dissent a scheduled, low-stakes channel instead of leaving it to erupt or fester.
**Keep the accountable unit small.** Social loafing scales with group size, so resist the urge to invite everyone. Fewer people in the room, and one named owner per action, does more for follow-through than any motivational speech.
**Name the roles and norms out loud.** Roles and norms form whether you manage them or not. Writing them into a [team charter](/guides/team-charter/) or a set of working agreements turns invisible defaults into choices the team can inspect and change.
**Build the kind of cohesion that tolerates disagreement.** The goal is a team safe enough to have the hard conversation, not one where nobody ever disagrees. Google's Project Aristotle found [psychological safety](/guides/team-dynamics/building-trust-and-psychological-safety/) to be the strongest predictor of team effectiveness in [its re:Work research](https://rework.withgoogle.com/intl/en/guides/understand-team-effectiveness), building on Amy [Edmondson's original work](https://journals.sagepub.com/doi/10.2307/2666999). Healthy cohesion comes from knowing each other as people, so a short shared activity like [This or That](https://games.teamretro.com/games/this-or-that/), run live, connects a group without forcing anyone to fake agreement.
You can take the temperature of these forces with a regular [health check](/health-checks/) rather than guessing at them.
## The honest limit
Group dynamics is a diagnostic lens, not a control panel. Naming a force does not disarm it, and every team drifts back toward its defaults the moment attention moves elsewhere. The work is ongoing: change the conditions, watch what the forces do, adjust again. That is slower than a slogan about teamwork, and it is the version that holds up. If you want the workplace application in full, read [what team dynamics are](/guides/team-dynamics/what-is-team-dynamics/); if you are ready to act, a [team charter](/guides/team-charter/) and a recurring [health check](/health-checks/) are the two most useful places to start.
## Frequently asked questions
### What is the difference between group dynamics and team dynamics?
Group dynamics is the broad field, founded by Kurt Lewin, that studies the forces inside any group of people who influence each other. Team dynamics is the workplace subset: those same forces in a small group of interdependent people who share a goal and hold each other accountable. Team dynamics is group dynamics applied to work.
### Who coined the term group dynamics?
The psychologist Kurt Lewin coined "group dynamics" in the 1940s and founded the Research Center for Group Dynamics at MIT in 1945. His central idea was that a group behaves as a system of interacting forces, not a simple sum of its members, so changing one part of a group shifts the whole.
### What is groupthink and what are its symptoms?
Groupthink, named by Irving Janis in 1972, is when a group's striving for unanimity overrides its members' motivation to appraise alternatives realistically. Warning signs include an illusion of invulnerability, self-censorship of private doubts, and "mindguards" who shield the group from inconvenient information. The result is a confident decision that no one has stress-tested.
### What is social loafing, or the Ringelmann effect?
Social loafing is the tendency for individual effort to fall as a group grows. Max Ringelmann measured it around 1913 when people pulled less hard on a rope in a team than they did alone. At work it shows up as diffused responsibility in large meetings. The fix is smaller groups and a named owner on every action.
### What are examples of group dynamics in the workplace?
Common examples are the informal roles people fall into, the unwritten norms about how meetings run, the cohesion that keeps a team together, and the conformity that can silence a dissenting view. The same forces help or harm depending on the conditions, which is why managers watch for groupthink and social loafing and invest in psychological safety.
---
# Horizontal vs vertical slicing
URL: https://www.teamretro.com/guides/agile-estimation-guide/horizontal-vs-vertical-slicing/
Vertical slicing splits a story along user outcomes; horizontal slicing splits it along technical layers. That single choice decides whether each slice ships something or nothing. Vertical slices ship value. Horizontal slices ship promises.
Horizontal slicing is splitting the way a knife splits dough: you get two halves of nothing.
## The difference
Horizontal slicing splits along architectural layers: frontend this sprint, backend the next, database the sprint after. The work fits into sprints, but no single sprint produces anything users can touch. The team's velocity numbers go up; the user-facing changelog stays empty.
Vertical slicing splits along user outcomes. A thin slice that touches every layer: a single button that actually works end to end, even if it only handles one input case. The team ships less per slice, but each slice is a real, shippable thing. The changelog fills up, users see progress, and the team can adjust course based on real usage rather than predicted usage.
Horizontal slices ship one layer at a time. Vertical slices ship a working column: a little of every layer, usable now.**"Behind a feature flag" still counts as shipped.** It's deployed, reversible, and observable in production, which is what makes a vertical slice a slice and not a promise. You don't need the feature switched on for everyone to have shipped it.
## When horizontal slicing seems necessary
It usually isn't. "We need the database schema before we can build the UI" is the classic justification, and it almost always gives way to "we can hard-code the response, ship the UI, and build the database in the next slice." The discomfort of shipping a fake backend is real, but it's smaller than the discomfort of shipping nothing for three sprints.
## The exception: foundational platform work
Some infrastructure has no user-facing slice short of completion: migrating to a new auth provider, swapping a queue backend, replacing the deployment pipeline. These are projects, not stories. Treat them as such: don't split them horizontally and pretend. Size them as a project, communicate the timeline, and accept that the team's velocity will reflect the investment. Dressing a three-sprint migration up as three "stories" fools only the burndown chart.
If a slice doesn't ship anything a user can use, it isn't a slice.
## Frequently asked questions
### What is vertical slicing in agile?
Vertical slicing splits a story along user outcomes, so each slice is a thin cut through every layer (UI, logic, and data) that delivers something a user can actually use, even if it only handles one case. Each slice is releasable on its own.
### What is the difference between horizontal and vertical slicing?
Horizontal slicing splits by technical layer, frontend one sprint and backend the next, so no single sprint produces anything a user can use. Vertical slicing splits by user outcome, so each slice ships a working end-to-end path. Vertical slices ship value; horizontal slices ship promises.
### Why is vertical slicing better?
Because each slice is a real, shippable thing. The changelog fills up, users see progress, and the team can adjust course based on real usage rather than predicted usage. Horizontal slicing raises the velocity numbers while the user-facing product stays unchanged for sprints at a time.
### When is horizontal slicing acceptable?
When the work is foundational platform work with no user-facing slice short of completion: migrating auth providers, swapping a queue backend, replacing the deploy pipeline. Those are projects, not stories: size them as such and communicate the timeline instead of pretending they split.
## Related reading
- [Splitting user stories](/guides/agile-estimation-guide/splitting-user-stories/): the full toolkit, and how to tell a real split from a fake one.
- [SPIDR story splitting](/guides/agile-estimation-guide/spidr-story-splitting/): five reliable vertical-slicing cuts.
- [Agile estimation: the complete guide](/guides/agile-estimation-guide/): the hub for everything here.
---
# Build a psychologically safe retrospective
URL: https://www.teamretro.com/guides/scrum-masters-retrospective-guide/how-to-build-a-psychologically-safe-space/
To build a psychologically safe retrospective, a Scrum Master models openness, supports team connectedness, sets team agreements, leans on the Prime Directive, and uses tools that allow anonymous input. The result is a space where people give honest feedback without fear of blame.
## What is psychological safety?
The term psychological safety is attributed to Professor Amy C. Edmondson of Harvard University. It is used to describe a workplace environment free from interpersonal fear.
This means people feel safe to take risks and experiment with different solutions. According to Edmondson, this is because there is a shared, unspoken belief among the team "that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes."
Edmondson noted that when people experienced low levels of psychological safety, they feared being perceived as:
- ignorant
- incompetent
- intrusive, and
- negative
## Why is psychological safety important?
Author Anthony Hood offers two reasons:
- Without psychological safety, people are afraid to speak up. The fear impacts thinking and decision making. When fear drives our behavior, our focus is self-preservation. This means they may not engage in the retrospective or not share an idea that could lead to positive changes in the team.
- A psychologically safe space supports the bottom line. It is related to a number of workplace outcomes, including innovation, knowledge sharing and divergent thinking, all of which deliver value to organizations and teams.
Google's Project Aristotle found psychological safety to be the most important component of high-performing teams. In fact, the project noted that it was the foundation for the other four components (dependability, structure and clarity, meaning of work and impact of work).
## How does psychological safety impact your team's retrospective?
Psychological safety can increase the effectiveness and productivity of retrospectives. How? When a team feels safe and is not distracted by fear of blame or shame, this can lead to:
- Improved engagement – people are more comfortable expressing their ideas
- Improved range of ideas offered
- Less energy trying to avoid or mitigate potential blame
- Reduced group think which can impact decision making
- Better evaluation of ideas
In short, when it comes to retrospectives, psychological safety gives team members the freedom to engage, explore and innovate.
## How can you tell if your team feels psychologically safe?
**Observe behaviors in the team.** Teams that feel psychologically safe behave very differently from those that don't. Teams that feel safe are engaged at meetings, can provide constructive feedback and challenge ideas in a positive way, and are able to share their lessons learned to help others avoid the same mistake. On the other hand, if people aren't attending the retrospective or engaging in the process, it's likely they aren't feeling comfortable enough to do so.
**Run a health check on psychological safety.** A team health check is an effective way of capturing how safe your team feels. The nature of psychological safety is such that the way people are questioned can affect their sense of safety and therefore, how they respond. This means, if they feel unsafe, they are unlikely to disclose it for fear of making the situation worse. Online health checks help address this in two ways. Firstly, people can respond anonymously. This removes fear of reprisal and increases the likelihood of people answering honestly. Secondly, they can be run asynchronously. This allows people to decide when they will respond and take as much time as they need to do so. There is also less time pressure and undue influence than if done face to face.
**Ask each person directly.** Under the right conditions, people will say whether or not they are feeling safe. This means it may be possible to simply ask a team how they feel. This could be done formally at an annual one-on-one, or more casually over a cup of coffee.
## How can a Scrum Master create a psychologically safe retrospective?
**Model and reinforce safe behavior.** It is important for a Scrum Master to model vulnerability during retrospectives. Examples include:
1. Sharing mistakes that have been made and what was learned from those mistakes
2. Asking for feedback
3. Being inclusive and intentional when making decisions
4. Acknowledging limits to expertise
5. Asking for help
6. Asking questions to confirm understanding
Such modeling reinforces acceptable language and behavior for the retrospective without having to state it outright. The behaviors themselves put people at ease and foster an environment of trust and understanding. Scrum Masters can also reinforce positive behavior when it is demonstrated by others. They can thank people for openly sharing their mishaps. They can praise those who ask questions. They can celebrate those who have offered help.
**Support team connectedness.** Given the direct link between team connectedness and high levels of psychological safety, supporting one will help the other. When Scrum Masters create opportunities and space for team connections to form and grow, they also foster the development of safety. While team building events are an effective go-to for building connections, the retrospective itself can also be used to increase safety. Including an icebreaker at the start of the meeting can help teams learn something fun and new about their team as well as bringing people's focus to the room. Checking out with a ROTI (return on time invested) exercise is a mechanism with which team members can provide feedback and feel heard.
**Remind the team about the Retrospective Prime Directive.** The Prime Directive helps to establish the culture needed for an agile retrospective. It calibrates the team to the mindset needed to ensure the meeting is both positive and result-oriented. Its purpose is to underpin the effectiveness of the meeting to ensure the team learns, finds solutions and improves. The statement uses a genuinely respectful tone. It includes reference to understanding and the true belief in the good intentions of others. It helps to align the space in which the retrospective will take place with trust and empathy. Such spaces are those in which people feel safe.
**Create team agreements.** Team agreements set ground rules. They are the behaviors a team promises to demonstrate when working with each other. They can cover a number of workplace contexts, from how the team will make decisions and how conflicts are to be addressed, through to how team members will support each other. They make expectations visible and articulate assumptions. They therefore deliver clarity and shared understanding to the team space, making it a psychologically safe place in which to participate.
**Use online retrospective tools that build safety.** Good [retrospective tools](/retrospective-tool/) include features designed to support psychological safety while delivering effective retrospectives. They help to create equitable, inclusive spaces in which a team can engage. They also help to support transparent processes that foster divergence and encourage openness. They can facilitate anonymous input, both synchronous and asynchronous meetings, and transparent decision making processes. They provide all team members opportunities for feedback. They can support accountability with the tracking of actions. They can be tailored to support diversity in teams.
**Run regular safety checks and track progress.** As mentioned above, running a team health check on a periodic basis allows you to do a quick check on the team's health, as well as any trends and progress. Sometimes, it's not just about any one point in time, but how things are changing over time. Discovering which dimensions are consistently low so that you can address them, or trending upwards so you can replicate success, is all part of having a regular cadence. A Scrum Master can use the data generated from the health check to inform actions that will support the team's psychological safety. It can also be used to monitor those levels over time.
As time passes and team members come and go, it is important to revisit the health check. After all, what makes people feel safe will change over time.
## Frequently asked questions
### What is psychological safety in a team?
Psychological safety is a shared belief that the team is a safe place to take interpersonal risks: to ask a question, admit a mistake, or raise a concern without fear of blame or embarrassment. The term is associated with Harvard professor Amy Edmondson, and it is the foundation that lets a retrospective produce honest feedback.
### Why does psychological safety matter in a retrospective?
A retrospective only works if people speak honestly, and people only speak honestly when they feel safe. Without psychological safety you get silence and "everything's fine"; with it you get the real problems on the table and genuine improvement. It is the single biggest factor in whether a retrospective creates value or just goes through the motions.
### How can a Scrum Master build psychological safety?
A Scrum Master builds safety by modeling openness (sharing their own mistakes and asking for feedback), supporting team connectedness, setting team agreements, leaning on the Retrospective Prime Directive, and using tools that allow anonymous input. Running regular team health checks helps track whether safety is improving over time.
---
# How to defrost a team (even one that hates icebreakers)
URL: https://www.teamretro.com/guides/team-dynamics/how-to-defrost-a-team/
Defrosting a team means deliberately warming up a cold, new, or distributed group so it can do real work together. A guarded team sits in a frozen equilibrium: people hold back and wait to see who is safe. Defrosting lowers that guard on purpose, through icebreakers, then recurring check-ins, then norms, until honest work can start.
Most advice files warming up a team under nice-to-have, a thing you bolt onto the front of a meeting when there is time. It is closer to a prerequisite. You cannot norm a team you have not thawed, and no process fixes a room where nobody trusts anyone enough to disagree out loud. This chapter is the mechanism behind that, plus an honest account of when the whole idea backfires.
## A cold team is a frozen equilibrium
The thaw metaphor comes from the Lewin–Schein tradition of change. Kurt Lewin described group behavior as a balance of forces that holds a team in a steady state until something disturbs it. The tidy slogan people quote from that tradition, unfreeze then change then refreeze, was assembled by others after Lewin died in 1947, so it is fairer to credit the lineage than to call it [Lewin's model](https://journals.sagepub.com/doi/abs/10.1177/0021886319892685).
A new or wary team is frozen. People are polite and careful, they protect themselves by staying quiet, and the group holds an equilibrium that looks calm while producing nothing honest. To change how the team works, you have to unfreeze it first.
Edgar Schein sharpened what unfreezing takes. In his account, people let go of a safe status quo only when staying put becomes more uncomfortable than changing, and that shift needs enough [psychological safety](https://www.mindtools.com/ad2hsdw/edgar-schein-on-kurt-lewin/) for someone to risk looking incompetent while they learn. Warming up a team is that safety, built on purpose. Amy Edmondson's field study of 51 work teams supplies the modern evidence: teams that feel safe are associated with more [learning behavior](https://journals.sagepub.com/doi/10.2307/2666999), which is what lets people speak up. We go deep on this in [building trust and psychological safety](/guides/team-dynamics/building-trust-and-psychological-safety/); here the point is narrower. The thaw is what turns forming into norming, instead of leaving conflict to fester underground.
## Icebreakers thaw, charters refreeze
That gives you a plain mechanism with three moves. Icebreakers thaw, charters refreeze, and the check-ins in between stop the team freezing solid again.
### Icebreakers are the unfreeze step
An icebreaker earns its place by lowering defensiveness, so the first honest sentence costs less than it would in a cold room. Fun is a bonus, not the job. A short round of [check-in questions](/icebreakers/check-in-questions/) or a quick game of [Two Truths and a Lie](https://games.teamretro.com/games/two-truths-and-a-lie/) does one useful thing: it gets everyone to speak early, so the silence breaks before the stakes are high. If people stall on inventing statements, seed the round from a bank of [two truths and a lie ideas](/icebreakers/two-truths-and-a-lie/). There is a real difference between a [warm-up and an icebreaker](/blog/warm-up-or-icebreaker-which-one-should-you-use/), and it pays to pick the right one for the moment.
Treated as filler at the top of a call, an icebreaker is a tax on time. Treated as the deliberate move that lets forming begin, it is five minutes that pays for itself. You will find a catalog of formats in the [icebreakers](/icebreakers/) library, and you can run most of them live with a remote team.
### Check-ins are the recurring thaw
A team does not thaw once and stay warm. Left alone it refreezes, because people get busy and drift back to guarded. A short check-in at the top of each meeting is the recurring thaw, a low-cost ritual that keeps the group warm without a big event. The [science behind a good check-in question](/blog/the-science-behind-good-check-in-questions/) is that it asks for a small, real answer anyone can give without performing.
### Norms and charters are the refreeze
Once a team is warm and disagreeing productively, you want to lock that state in. That is the refreeze. A [team charter](/guides/team-charter/) captures the norms the team just discovered it needs: how decisions get made, how disagreement gets aired, what counts as a reasonable response time. Writing them down is how you [turn agreements into culture](/blog/create-social-contracts-with-team-agreements-that-improve-culture/) instead of good intentions that fade by Friday. We cover the full session in [team norms and working agreements](/guides/team-dynamics/team-norms-and-working-agreements/).
Here is the counterintuitive part. A team refreezes every time membership changes, so the day a new person joins you are back near forming and the charter needs a re-thaw. That is not the model breaking. As we argue in [the stages of team development](/guides/team-dynamics/stages-of-team-development/), Tuckman describes a team, it does not predict one, and it resets to forming the day someone new joins. Re-thawing on purpose is the maintenance that keeps the reset short.
## Why so many people hate icebreakers
Plenty of readers will get this far and think their team would rather eat glass than sit through an icebreaker. They are right to be wary. [Acas](https://www.acas.org.uk/) found that team-building is the most disliked workplace social activity, with 31% of employees saying they dislike it. Forced fun has a bad name for good reasons.
The problems are specific. A mandatory round of personal questions is emotional labor dressed up as a game, and "share your greatest fear" is a bad ask at work. The format tilts toward extroverts, rewarding whoever is comfortable performing and putting quieter people on the spot in front of an audience. It often runs before any real work, so it reads as a cost rather than a way into the task. And it quietly excludes people: introverts, non-native speakers who need a beat to compose a sentence, and anyone who finds public disclosure uncomfortable all pay a higher price for the same exercise.
The skeptics also have a real alternative worth taking seriously. What builds connection, in their experience, is shared real work, like pairing on a hard problem or walking through a design review together, plus optional low-stakes social that people can skip without penalty, and short opt-in check-ins that stay close to the work instead of mining for feelings. Connection grows out of good work and real autonomy. You cannot put it on a calendar.
None of this kills the unfreeze step. It disciplines it, which is exactly what [icebreakers built for teams that hate icebreakers](https://games.teamretro.com/use-cases/teams-that-hate-icebreakers/) are for.
| Forced fun that backfires | The version that works |
|---|---|
| Mandatory, performed in front of the group | Optional, easy to sit out |
| Deep personal disclosure ("your biggest fear") | Small, work-adjacent, low-stakes |
| Bolted on before the real work | Woven into shared real work |
| Answer live, on the spot | Written first, so quieter voices land equally |
Keep the icebreaker short and opt-in, stay close to the work, and never force vulnerability. A check-in a burned-out engineer will not roll their eyes at is one that asks for a work signal rather than a confession. [This or That](https://games.teamretro.com/games/this-or-that/), where everyone marks where they stand between two options and the answers reveal at once, is the kind of low-stakes format that clears this bar, because nobody has to disclose anything they would rather keep private.
## Remote teams start colder and refreeze faster
Distributed teams begin colder than co-located ones. There is no hallway and no coffee queue, so there is no ambient sense of who a colleague is. New remote teams get moving on [swift trust](https://en.wikipedia.org/wiki/Swift_trust_theory): members extend trust up front on the assumption of competence, then verify it through the work. It is enough to start with.
But swift trust is on loan. Jarvenpaa and Leidner's study of global virtual teams found that trust at a distance is ["very fragile and temporal"](https://ideas.repec.org/a/inm/ororsc/v10y1999i6p791-815.html), forming fast and decaying fast without steady communication. Swift trust gets you moving; it does not keep you warm.
That is the whole argument for cadence. A co-located team gets its recurring thaw from the building for free. A distributed team has to schedule it, which is why warmth at distance has to be a weekly rhythm. One good ritual you run every week beats one great offsite you run every quarter. Reach for [virtual icebreakers](/icebreakers/virtual-icebreakers/) built for a screen, and treat the check-in as non-negotiable rather than the thing that gets cut when the agenda is full. We go deeper on the distributed case in [remote and distributed team dynamics](/guides/team-dynamics/remote-and-distributed-team-dynamics/).
It also helps to measure the thaw rather than assume it. A quick [team health check](/health-checks/) tells you whether the team feels warm, not just whether you ran the ritual, and it will flag a group that is quietly refreezing while everyone nods along on the call.
Defrosting is not a project you tick off. It is maintenance. The teams that stay warm are the ones that made the thaw boring and regular, then wrote down what good behavior looks like so it survives the next reorg. Icebreakers thaw, charters refreeze, and the check-ins in between are what keep a team from having to start cold twice.
## Frequently asked questions
### What does it mean to defrost a team?
Defrosting a team means deliberately warming up a cold, new, or distributed group so it can do honest work together. A guarded team sits in a frozen equilibrium where people hold back and wait to see who is safe. Defrosting lowers that guard on purpose, through icebreakers, recurring check-ins, and written norms.
### Do icebreakers work, or are they a waste of time?
They work when they are used as an unfreeze step rather than as entertainment. A short, low-stakes icebreaker gets everyone to speak early, which lowers defensiveness before the stakes rise. They fail when they are mandatory, force personal disclosure, or eat time before real work. Keep them short and optional, and stay close to the work.
### What works better than icebreakers if your team hates them?
Skeptics are usually right that shared real work builds more connection than forced fun. Pair people on a hard problem, run a design review together, and keep any social optional and low-stakes so people can skip it without penalty. Short, opt-in check-ins that stay close to the work beat deep personal disclosure. Connection grows out of good work rather than a scheduled event.
### How do you warm up a remote or distributed team?
Remote teams start colder and lose warmth faster, because swift trust forms and fades quickly without steady contact. So make warmth a cadence rather than an event: a short check-in at the top of every meeting, virtual icebreakers built for a screen, and a written charter everyone can see. Measure it with a periodic team health check.
---
# How to run an effective standup: facilitation and rules
URL: https://www.teamretro.com/guides/daily-standup-guide/how-to-run-a-daily-standup/
Running an effective daily standup is a facilitation problem, not a format problem. The three questions, the board, the timebox: every team knows the parts. What separates a standup worth fifteen minutes from one people quietly skip is whether someone holds the shape: opens on the goal, keeps it moving, refuses to let it become a status report.
This chapter is the how. The rules are few and most of them are about what you *don't* do in the meeting.
## Start before the meeting starts
The best facilitators don't walk in cold. A few minutes beforehand, glance at the board: what moved, what's stuck, what's been sitting in the same column too long. That short prep is the difference between a facilitator who *runs* the standup and one who merely *opens* it and hopes.
Cold facilitation is how a standup drifts. You open the floor, someone starts narrating, and forty minutes later you're still going round the room. Two minutes of prep buys you the authority to say "that card's been in review three days. What's it waiting on?" instead of waiting for someone to volunteer it.
## The rules that keep it fifteen minutes
The timebox holds only because problem-solving is pushed outside it. Anything that needs longer than a sentence leaves the box. That's the whole trick.
Four rules do almost all the work:
1. **Surface problems; don't solve them.** The single most important rule. The instant two people start debugging, everyone else is paying for a conversation they're not in. Name it, note who's needed, park it.
2. **Hold a hard timebox.** End on time even mid-sentence. The overrun is a signal, not something to absorb. If you keep letting it run to thirty minutes, thirty minutes becomes the norm.
3. **Aim it at the team, not the front of the room.** If updates start drifting toward the manager or Scrum Master, redirect: "tell the team, not me." Where the updates point decides whether you get problems or performance.
4. **Blockers first.** Ask for what's stuck before what got done, while attention is still fresh.
**Pro tip:** the parking lot is the mechanism that makes rule 1 real. When a discussion goes deep, say it out loud ("let's park that; Priya and Sam, five minutes right after") and move on. The deep conversation still happens. It happens with the two people it concerns, immediately, instead of with the whole team, never. See the [daily standup agenda](/guides/daily-standup-guide/daily-standup-agenda/) for where it sits in the run of show.
## Handling the hard cases
Most standup trouble is one of three people, and each has a structural fix: reach for the format, not the personal callout.
**The rambler** gives a five-minute answer to a one-line question. Don't correct them mid-flow; change the format. Walking the board caps rambling naturally, because the conversation is about the card, not the person's day. If it persists, a private "keep it to your one main thing" lands better than an interruption in front of the team.
**The dominator** takes more airtime than the format allows, every day. Switch to walking the board so airtime follows the work. If one person still needs more than the meeting can give, that's a coaching conversation to have privately, not a standup to let sprawl.
**The silent update** ("nothing to report, same as yesterday") is the one to watch. Sometimes it's fine. Sometimes it's a stuck person who doesn't want to say so. A gentle, specific follow-up ("still on the migration? anything slowing it down?") surfaces the blocker that "nothing to report" was hiding.
## What good looks like
You'll know the standup is working less from what happens in it than from what happens right after. On a healthy team, the meeting ends and two or three useful side-conversations start immediately: the blockers it surfaced getting picked up by the people who can clear them. That's the meeting doing its job: it's a router for problems, not a container for solutions. A [daily standup tool](/standups/) that carries each blocker forward until it's cleared, and lets you add an action with an owner, keeps that routing from getting lost the moment the call ends.
The opposite tell is a standup that ends and everyone just goes back to their desks unchanged. If nothing the meeting produced altered anyone's day, you ran a status report. The [standup anti-patterns](/guides/daily-standup-guide/standup-anti-patterns/) chapter is the diagnostic for when it's gone wrong; the [format catalog](/guides/daily-standup-guide/standup-meeting-ideas/) is where to look when it's merely gone stale.
For where the standup sits among the sprint's other meetings, see the [agile ceremonies guide](/guides/agile-ceremonies-guide/); to make the daily habit stick, hand the team [copy-paste templates](/guides/daily-standup-guide/daily-standup-templates/); and for the formats and failure modes, work through the rest of [the daily standup guide](/guides/daily-standup-guide/).
## Frequently asked questions
### Who runs the daily standup?
The team owns it; someone facilitates it. On a Scrum team the Scrum Master often facilitates early on, but the goal is a team that runs its own standup without a designated timekeeper. The facilitator's job is narrow: open on the goal, keep the board moving, park the deep dives, end on time. It is not to receive updates, which is the fastest way to turn a sync into a status report.
### What makes a good daily standup?
It's short, it leads with blockers, and it's aimed at the team rather than a manager. A good standup sends people away knowing what changed, what's stuck, and what they're doing about it, and it ends on time. The tell is what happens after: on a good team, useful side-conversations start the moment it ends, because the meeting surfaced the right problems instead of burying them in status.
### How do you handle someone who dominates the standup?
Name the pattern kindly and structurally, not personally. Switch to walking the board so airtime follows the work rather than the person, hold a hard timebox, and when a deep dive starts, park it: "good one, you and Sam grab five minutes after." If one person routinely needs more airtime than the format allows, that's a coaching conversation to have privately, not a standup to let run long.
### How do you keep a standup from running long?
Ban problem-solving in the meeting and route it to a parking lot, hold a hard end time even mid-sentence, and walk the board instead of going person by person. A standup that regularly overruns isn't undisciplined, it's mis-scoped: the team is trying to do work in a meeting built only to coordinate it. Fix the parking-lot habit before you shorten anyone's update.
---
# How to run a planning poker session
URL: https://www.teamretro.com/guides/agile-estimation-guide/how-to-run-planning-poker/
A planning poker session works when it produces useful estimates without sliding into its second hour. That comes down to three things: prepare the backlog, protect the private-vote-then-reveal mechanic, and time-box hard. Here's the run of show.
## Before the session: refine, then anchor
Most bad sessions trace back to bad prep, not bad facilitation. Two things to settle first.
**Refine the backlog.** Every story needs clear [acceptance criteria](/guides/agile-estimation-guide/acceptance-criteria/), a known owner area (or an explicit cross-cutting flag), and roughly the same level of detail as its neighbors. If half your items are one-line tickets and the other half are multi-paragraph specs, the estimates won't be comparable, and the session turns into a refinement meeting in disguise.
**Pick a reference story.** Take one already-shipped story and agree to call it the team's baseline (a 5, say). Every other estimate is made relative to that anchor. It's the single cheapest thing you can do to keep a scale stable over time.
**Pro tip:** the reference story is the anchor the whole scale hangs on. Re-pick it every quarter, or after any real change in team makeup. Without one, the meaning of a 5 drifts and your velocity turns into a random walk.
Good prep gets the session started; these are the habits that keep the numbers honest once you're in it.
**Define the task and take questions before anyone votes.** Read the item together, let the team ask what's unclear, and don't start voting until those questions are answered. A vote taken before the room understands the story isn't an estimate; it's a guess with a number attached. This costs a minute up front and saves a re-vote later.
**Watch for the hours translation.** The moment someone says "a 3 is about half a day," the estimate has quietly stopped being about complexity and started being about time, which is exactly what points exist to avoid. If it keeps happening, that's the thing to correct, not the number itself.
**Cap re-votes at two.** First reveal shows the spread. On the second, after the high and low voters explain their reasoning, the team should converge. If it doesn't, the story isn't estimable yet: split it or send it back for refinement rather than voting a third time and hoping.
**Bring the whole delivery team, not just engineering.** QA and design see effort a ticket description doesn't mention. A story that reads as a 2 to the developer can be an 8 once someone asks who's writing the test plan.
**Judge estimation quality at the team level, never the individual.** The instant a vote feels like it's being graded, you get safe estimates instead of honest ones, for the same reason velocity isn't a performance score. If you want to know whether estimation is actually improving, look at how tight the spread is across a sprint's items, not who called it closest.
## Set the ground rules
Say these out loud at the top, especially with new teammates:
1. You're estimating **relative effort**, not hours.
2. Don't reveal a card or say a number aloud until everyone has played.
3. The highest and lowest cards explain themselves. That's a feature, not a penalty.
4. `?` means you genuinely can't estimate this. `☕` means you need a break.
## The four phases of a round
Each story moves through the same short loop.
**1. Read and clarify (1–2 min).** The facilitator reads the story aloud. Anyone, not just engineers, can ask clarifying questions. The goal is shared understanding, not design. If the room starts solving *how* to build it, park that and move on.
**2. Vote (10–30 sec).** Everyone plays a card privately. In a tool the cards stay hidden automatically; in the room, keep them face-down until the reveal.
**3. Reveal and discuss (1–4 min).** Flip every card at once. If the spread is a single step (all 3s and 5s), take the higher number and move on. If it's wider, ask the highest and lowest to explain. Nine times in ten you'll find one of three things: the story isn't well understood and needs splitting, someone knows about hidden complexity, or someone has done this before and knows it's smaller than it looks.
**4. Re-vote (10 sec).** Quick discussion, then re-vote. Most rounds settle in two. If you're heading for a third, the story needs more [refinement or splitting](/guides/agile-estimation-guide/splitting-user-stories/), not more discussion.
## Which deck should you use?
The numbers on the cards shape how the team thinks about effort, so choosing a deck is part of the work, but you don't need to overthink it.
**Fibonacci (1, 2, 3, 5, 8, 13, 21…)** is the default for most teams, and for good reason. The gaps widen on purpose: the bigger the work, the less anyone knows, so the choices spread apart and you decide "8 or 13?" instead of arguing over a 9 versus a 10. The friction is the feature. (More on [why Fibonacci](/guides/agile-estimation-guide/why-fibonacci/).)
**Modified Fibonacci** adds ½ for trivial-but-trackable work, and 40 and 100 at the top end. The 100 isn't an estimate; it's a stop sign meaning "too big to size; break it up first."
**T-shirt sizes (XS–XL)** are deliberately fuzzy, which is sometimes exactly right for early refinement, or portfolio-level sizing where the conversation is about scope, not sprint capacity. The catch: T-shirts don't add up, so they can't feed a [velocity](/guides/agile-estimation-guide/velocity/) number.
**Powers of two (1, 2, 4, 8, 16…)** suit engineering teams that already reason in doublings; the jumps get aggressive fast, which is the point.
Starting fresh? Use Fibonacci. Switch to T-shirts only if you catch the team debating single-point differences, and to modified Fibonacci once you want to flag oversized stories explicitly.
The free planning poker tool itself offers six decks: Scrum, Fibonacci, Sequential, Half card, Power of two, and T-shirt size. Three of those (Scrum, Sequential, Half card) aren't covered above, so here's where they fit.
**Scrum (0, ½, 1, 2, 3, 5, 8, 13, 20)** is the tool's own default, and it's a close cousin of Fibonacci rather than a different philosophy. It has the same widening gaps, with two practical additions: an explicit 0 for "already done" or "not real work," and a ½ so trivial items don't get rounded up to a full point. If your team is already using Fibonacci and wondering why the app's default deck looks slightly different, this is why. Pick whichever of the two your team settles into faster; neither is more "correct."
**Half card (1, 1½, 2, 2½, 3, 3½, 4, 4½, 5, 5½)** adds resolution at the low end for backlogs that keep clustering everything into "1 or 3" with nothing in between. If your estimation conversation keeps circling "is this really a 1, or closer to a 2," Half card is the fix. It's solving a real problem, not adding choice for its own sake.
**Sequential (1, 2, 3, 4, 5…)** is the one to reach for least. Equal gaps between numbers remove the pressure the other decks build in on purpose: a Fibonacci-style deck makes a 13 feel deliberately uncomfortable next to an 8, which is what pushes teams to split the story instead of shrugging and moving on. Sequential only makes sense when items are genuinely similar in kind and you're closer to counting than estimating: a checklist of near-identical migration tasks, not a mixed backlog.
**Still not sure? Match the deck to the tool, not the other way round.** If your team is starting in TeamRetro's free planning poker room, the Scrum deck is already selected, and there's no reason to switch to plain Fibonacci unless a specific problem shows up first.
**Need more than six presets?** The free room is built for a quick, no-account session with a fixed set of decks. TeamRetro's paid Estimations platform lets your team build a fully custom deck, with your own values and your own labels, instead of picking from presets, and wires estimation into the rest of your workflow: pull items straight from your backlog, sync agreed points back to Jira, Azure DevOps, GitHub, or Linear, and turn what the discussion surfaces into follow-up actions and team agreements before anyone leaves the session.
### The special cards: ?, coffee, and 100
A few cards aren't numbers, and each carries real information:
- **`?`: I can't estimate this.** A stop sign, not a shrug. It usually means the team is missing context, or the story isn't defined enough yet. Surface it; don't wave it through.
- **`☕`: I need a break.** Take it at face value. Estimation fatigue tanks the quality of every round that follows, and five minutes is cheaper than a bad sprint.
- **`100`: this is too big to estimate.** A flag, not a number. Don't talk yourselves down to a 40 to dodge the refinement work; split the story instead.
## Time-box the session, not just the stories
Per-story time-box: three to five minutes. Session time-box: 30 to 45. When you hit either, ship the current estimate or punt the story back to the backlog. Teams that know you'll actually enforce the box prepare better for next time. If there's a long tail of items to size, don't grind through it here; reach for a [faster technique](/guides/agile-estimation-guide/estimation-techniques/) like bucket sizing.
## Running remote and hybrid sessions
Run the session over video. You want tone of voice and the visual cue of someone about to speak. Use a planning poker tool to keep votes genuinely hidden; the honor system in a chat thread is an anchoring accident waiting to happen. [TeamRetro's free planning poker](/free-planning-poker-for-agile-teams/) hides every card until the reveal, so a distributed team gets the same mechanic as one gathered around a table.
New to the technique? Start with [what planning poker is](/guides/agile-estimation-guide/what-is-planning-poker/). Already fluent, and want to know where it goes wrong? [Planning poker mistakes](/guides/agile-estimation-guide/planning-poker-mistakes/) is the field guide.
## Frequently asked questions
### What are the steps in a planning poker session?
Refine the backlog and pick a reference story first. Then, for each item: the facilitator reads it and the team clarifies, everyone votes privately, all the cards are revealed at once, and the highest and lowest cards explain any wide spread before a re-vote. Most items settle within two votes.
### How long should a planning poker session last?
Time-box the session to about 30 to 45 minutes and each story to three to five. Estimation quality drops sharply past 45 minutes as people tire and start playing whatever the lead plays. If there is more backlog to size, schedule a second session or switch to a faster technique.
### Which planning poker deck should we use?
Start with Fibonacci (1, 2, 3, 5, 8, 13) for most sprint work; it has enough granularity to plan with and enough friction to keep arguments short. Move to modified Fibonacci when you want to flag oversized stories, and to T-shirt sizes for early, roadmap-level sizing where the numbers do not need to add up.
### What do the ? and coffee cards mean?
The question-mark card means someone genuinely cannot estimate the story yet. Treat it as a stop sign that the item needs more context, not as a non-vote. The coffee card means someone needs a break; take it seriously, because a tired room produces worse estimates every round after.
### What is a reference story?
A reference story is one already-shipped story the team agrees to treat as a fixed baseline (a 5, say), so every other estimate is made relative to it. Without an anchor, the meaning of a 5 drifts sprint to sprint and the resulting velocity becomes a random walk.
---
# How to run a great online retrospective
URL: https://www.teamretro.com/guides/scrum-masters-retrospective-guide/how-to-run-the-best-online-retrospective/
To run a great online retrospective, give people time to connect, set clear meeting etiquette, use real-time feedback tools, sort out the tech in advance, and keep the fundamentals of an agile retro in place. Here are 5 of our own learnings and reflections from when we ran our own retros with our remote teams.
1. **Allow time to say hello and goodbye.** Even just a few minutes matters, so ask people to sign in a little early or on time. It could start with an icebreaker, but a simple question about how everyone is doing, or asking for a number out of 10, engages everyone early on. Likewise, it's too easy to press a button that cuts everyone off, so allow time for people to say goodbye at the end of the meeting.
2. **Set the etiquette for your remote meetings.** This could mean turning on cameras, use of backgrounds, typing in chat for check-in, or how people actually engage in the meeting that day. Online etiquette is real. Imagine if video meetings happened in a face-to-face environment and you'll immediately see why things like background noise, how to leave the meeting, and how to ask questions and make comments suddenly become very real issues.
3. **Use comments and real-time feedback mechanisms.** One of the advantages of going digital is that people can brainstorm individually without distraction, vote for ideas independently without bias, and add comments to others' ideas that could be worth their weight in gold. Rather than being hindered by production blocks, asking people to write down their thoughts as comments can enrich the discussion. A purpose-built [online retrospective tool](/retrospectives/) gives you all three in one place: private brainstorming, independent voting, and threaded comments.
4. **Sort out the logistics.** Just as you would check the room for your in-person retro to ensure it wasn't double-booked, that the heating or cooling was on, and that you had the right tools, the same applies to a quick tech check for your remote retro. Get the tools up and running, links ready to go, and have a tech buddy or colleague support this process, so you'll be able to focus more on the conversation than the technology when the time comes. If you are working across time zones, negotiating a day and time that works for most people can be tricky, and it might mean alternating times for fairness or considering asynchronous retrospectives.
5. **Don't forget the basic elements of agile retrospectives.** A remote retrospective does not mean that the fundamentals of an agile retrospective are cast aside. Ensuring accountability, a focus on culture and continuous improvement, follow up and follow through, and that people are focused on the retrospective and not trying to solve problems in the same meeting, all continue to apply.
---
# Is velocity a useful metric? Our verdict
URL: https://www.teamretro.com/guides/agile-verdicts/is-velocity-a-useful-metric/
**Yes inside the team, harmful outside it. Velocity is a forecasting input the team steers by; the moment it becomes a target or a cross-team comparison, it inflates and stops meaning anything.** It isn't one of [DORA's delivery metrics](/guides/agile-metrics/dora-metrics/).
Almost everyone in the discourse agrees velocity should never leave the team, and almost every organization lets it leave anyway. That gap is the whole argument. The metric is genuinely useful for one job and reliably destructive for the others, so the verdict has to be split.
## The case that velocity is useful
Used inside the team, velocity does real work. It lets you forecast: divide the remaining scope by the team's recent average and you have a rough number of sprints to ship. It lets you [size a realistic sprint](/guides/sprint-planning-guide/velocity-and-capacity/): pick stories until they sum to roughly eighty to ninety percent of the recent average, leaving room for the unplanned. And it flags real change: a thirty-percent drop is a signal worth a conversation, not an accusation.
The management wish behind velocity-as-a-metric is also legitimate, and worth stating fairly. Leaders are accountable for delivery and want visibility into it. "If we can't measure the team somehow, how do we know it's delivering?" is a reasonable question, not a villain's line. The problem isn't the wish. It's that velocity is the wrong instrument for it.
Two easy sprints pull the average above the team's sustainable rate. Velocity is useful for planning to the typical sprint, and misleading the instant it becomes a number to push upward.
## The case that velocity is a trap
Point velocity outward and it breaks in predictable ways. Set it as a target ("increase velocity twenty percent this quarter") and the team obliges, by sizing the same work bigger rather than doing more of it. Turn a couple of threes into fives and the number climbs for no real increase in output. This is Goodhart's law running on a two-week cycle, and it isn't a hypothetical: even Mike Cohn, the leading advocate *for* story points, concedes that the slightest indication velocities will be compared produces gradual but consistent point inflation.
Cross-team comparison is worse, because it looks rigorous while being meaningless. Two teams sizing the same backlog produce different numbers because they calibrate against different reference stories, which is the entire point of relative estimation. Averaging or ranking them corrupts both teams' calibration to feed a dashboard. The tell that an org has this wrong is when someone senior has to personally shield their teams from velocity-as-a-KPI, a fix that works exactly as long as that person stays in the role.
The [velocity ratchet](/guides/agile-theatre/agile-theatre-glossary/#velocity-ratchet), velocity treated as an ever-rising productivity target, guarantees inflation. The team is not cheating when it responds; it is doing exactly what the incentive asks. If the number must go up every quarter, the sizing will, and the forecast velocity was supposed to produce quietly stops working.
## Where we would change our mind
We would keep velocity without reservation for any team that uses it only to forecast and plan, and never lets it leave the room. Used that way it isn't a trap at all. It's just arithmetic the team does for itself.
We would drop it entirely in two cases. First, if the work is uniform enough that [counting stories forecasts as well as summing points](/guides/agile-verdicts/story-points-vs-noestimates/), then velocity is overhead, and throughput is simpler and harder to game. Second, if the organization can't stop itself weaponising the number. When the ratchet is culturally locked in and no individual can hold it back, the honest move is to stop producing the number that is being abused and switch to flow metrics that are not.
## The practical take
Give leadership DORA's delivery metrics, which are hard to game, and keep velocity inside the team as a planning input, never a number pushed upward.
- Velocity measures [pace, not productivity](https://web.archive.org/web/20250430193923/https://www.pivotaltracker.com/blog/velocity-is-a-measure-of-pace-not-productivity). Say it out loud in the room the first time someone reads it as an output metric.
- Never compare teams, never set it as a target, never convert it to expected hours per developer. Each is the same mistake wearing a different hat.
- Report outcomes upward, not point counts. [DORA's five metrics](https://dora.dev/guides/dora-metrics/), deployment frequency, lead time for changes, change-failure rate, time to restore and deployment rework rate, measure delivery without inviting gaming and, unlike points, mean the same thing across teams. That's the metric set leadership actually wants.
- Don't re-point the backlog when the team speeds up. The stories didn't shrink. The team got faster, and the velocity number will rise on its own. Re-pointing to keep velocity flat is the ratchet running in reverse, and it wrecks the forecast the same way.
Velocity is for the team to steer by, not for managers to grade with. Keep it in the room and it's one of the more useful numbers in agile. Let it out, and it becomes the cleanest example of a [Power failure mode](/guides/agile-theatre/power-agile-theatre/) there is.
## Frequently asked questions
### Is velocity a productivity metric?
No. Velocity measures pace, not productivity: how many story points a specific team completes per sprint at its own calibration. It cannot tell you whether the work was valuable, and it was never designed to. Velocity isn't one of DORA's delivery metrics either.
### Can you compare velocity across teams?
No. Two teams sizing the same work produce different velocity numbers because they use different reference stories, which is the whole point of relative estimation. Comparing them is like comparing two thermometers with different zero points. Mike Cohn, who argues for story points, concedes that the slightest hint velocities will be compared produces consistent point inflation.
### What should we report to management instead of velocity?
Report outcomes, not point counts. DORA's five metrics (deployment frequency, lead time for changes, change-failure rate, time to restore service and, since 2024, deployment rework rate) measure delivery in ways that do not invite gaming and mean the same thing on every team, though DORA cautions against using them to rank teams. Velocity stays inside the team as a planning input; DORA's metrics are what leadership should actually watch.
## Related reading
- [Velocity: what it's for and how to calculate it](/guides/agile-estimation-guide/velocity/): the mechanics, and why it breaks the moment it becomes a target.
- [Story points vs #NoEstimates](/guides/agile-verdicts/story-points-vs-noestimates/): the upstream fight: what the number is worth before it becomes a forecast.
- [Story points vs hours](/guides/agile-estimation-guide/story-points-vs-hours/): why converting either one to hours re-creates the problem velocity replaces.
- [What is a burndown chart?](/guides/agile-metrics/burndown-chart/): tracking committed points within a sprint, an honest use of the number.
- [Agile Theatre: the Power failure mode](/guides/agile-theatre/power-agile-theatre/): how metrics like velocity get turned into instruments of control.
---
# Lead time vs cycle time: flow metrics explained
URL: https://www.teamretro.com/guides/agile-metrics/lead-time-vs-cycle-time/
**Lead time runs from the moment someone asks for a piece of work to the moment it's delivered. Cycle time runs from the moment the team starts that work to the moment it's finished.** Lead time is the customer's wait; cycle time is the part of that wait the team controls. This page uses those Kanban definitions. DORA's "change lead time" is a third, narrower clock that starts at the commit, and it is covered below so you can tell them apart.
Both are flow metrics: measures of how work moves through a system, not how much effort it took. The reference for cycle time and the other flow measures is the [Kanban Guide](https://kanbanguides.org/the-kanban-guide/) by John Coleman and Daniel Vacanti (May 2025 edition); the lead time definition comes from Kanban University. This chapter of the [agile metrics guide](/guides/agile-metrics/) covers the clocks, the four measures the guide makes mandatory, flow efficiency, and Little's Law.
## Where each clock starts and stops
One work item from request to delivery. Lead time covers the whole span, including the wait before anyone starts. Cycle time starts when work begins. DORA's change lead time covers only the stretch from commit to production.
- **Lead time** starts when the request is received and stops when it is delivered. Kanban University defines customer lead time as ["the time between receiving the customer's request and delivering on it"](https://kanban.university/what-to-know-about-lead-time-and-customer-lead-time/). Backlog wait counts.
- **Cycle time** starts when the team starts the item and stops when it is finished. The Kanban Guide: "The elapsed time between when a work item started and when a work item finished."
- **Change lead time** (DORA) starts when a change is committed to version control and stops when it is deployed in production, per [dora.dev](https://dora.dev/guides/dora-metrics/).
Lead time always contains cycle time. The gap between them is the queue: how long work sits after it is asked for and before anyone picks it up. A team can cut cycle time in half and leave the customer's wait almost unchanged if most of the lead time is backlog.
| Clock | Starts | Stops | Answers | Defined by |
|---|---|---|---|---|
| Lead time | Request received | Delivered to the customer | How long does the customer wait? | Kanban University (customer lead time) |
| Cycle time | Team starts the item | Item meets the team's "finished" point | How long does our process take, once started? | Kanban Guide |
| Change lead time | Commit to version control | Deployed in production | How fast is our delivery pipeline? | DORA |
| Cycle time (manufacturing) | One unit or process step begins | That unit or step completes | How long does one part take to make? | Lean Enterprise Institute |
## Why the definitions don't agree
When two articles give different start points, each is usually quoting a real source. Four things cause the disagreement.
**The Kanban Guide doesn't define lead time at all.** It names four measures and leaves the start and finish points to the team: a Kanban system needs "a definition for when work items are started and finished," and a workflow "may have more than one started or finished point." So two Kanban teams' cycle times are rarely comparable.
**Kanban University changed its own definition.** It used to measure customer lead time from the commitment point, when the team accepts the request. In April 2023 it [moved the start to the moment the request is received](https://kanban.university/what-to-know-about-lead-time-and-customer-lead-time/), because the older definition was "creating confusion due to other established definitions of customer lead time." Its separate "system lead time" still starts at the commitment point.
**DORA measures a different stretch.** DORA's metric covers commit to production only. It called this "lead time for changes" in its 2014 study, and its current five-metric model calls it "change lead time" ([DORA's metric history](https://dora.dev/insights/dora-metrics-history/)). It leaves out discovery, design and backlog wait, so it isolates the delivery pipeline. A team can have a change lead time of hours and a customer lead time of months. The [DORA metrics chapter](/guides/agile-metrics/dora-metrics/) covers it alongside DORA's other measures.
**Manufacturing uses the same words differently.** The Lean Enterprise Institute defines [cycle time](https://www.lean.org/lexicon-terms/cycle-time/) as "the time required to produce a part or complete a process," and production lead time as the time "to move all the way through a process or a value stream from start to finish." [Takt time](https://www.lean.org/lexicon-terms/takt-time/), the third term in most manufacturing comparisons, is "the available production time divided by customer demand": a target pace, not a measured duration.
The fix is a [written board policy](/guides/team-dynamics/team-norms-and-working-agreements/): name the column where each clock starts and stops, and keep it fixed long enough for the trend to mean something.
TeamRetro's [Flow Metrics Self-Assessment for Teams](/health-check-templates/flow-metrics/) asks whether the team shares those definitions, along with how it experiences WIP, stuck work and predictability.
## The four flow measures
The Kanban Guide makes four measures mandatory and says teams "may and often should use additional context-specific measures."
| Measure | Kanban Guide definition | Unit | Misleads when |
|---|---|---|---|
| Work in progress (WIP) | "The number of work items started but not finished" | Items | Items vary wildly in size, or blocked items are moved off the board |
| Throughput | "The number of work items finished per unit of time" | Items per week | Items are split smaller to inflate the count |
| Work item age | "The elapsed time between when a work item started and the current date" | Days | Nobody looks at it until the item finishes |
| Cycle time | "The elapsed time between when a work item started and when a work item finished" | Days | It's reported as one average instead of a distribution |
**WIP** is the measure you control directly. The Kanban Guide on limiting it: "An effect of controlling WIP is that it should create a pull system." New work starts when something finishes, not when someone asks.
**Throughput** counts finished items, not points, which is why it is harder to inflate than velocity. Our [velocity verdict](/guides/agile-verdicts/is-velocity-a-useful-metric/) argues that teams with uniform work can forecast from throughput and skip story points.
**Work item age** is the only one of the four that looks at unfinished work, which makes it the early warning. Cycle time tells you an item took 30 days after it has taken 30 days. Age tells you on day 12 that it is already older than most items ever get. Vacanti's [*Actionable Agile Metrics for Predictability*](https://leanpub.com/aamfp-10th) gives the work item aging chart two chapters.
**Cycle time** is a distribution, not a number. The Kanban Guide's answer is the service level expectation (SLE), which has "two parts: a period of elapsed time and a probability associated with that period." Its example: "85% of work items will be finished in eight days or less." An SLE is built from your historical cycle times, so it is a forecast you can defend.
## Flow efficiency
Flow efficiency is the share of lead time an item spends being worked on. Julia Wester's [Lean Kanban University article](https://kanban.university/flow-efficiency-a-great-metric-you-probably-arent-using/) (2016) calculates it by "dividing the active work time by the overall lead time," expressed as a percentage. An item that took 20 days end to end and was worked on for 4 of them is at 20%.
The same article says the most generous estimate Wester had seen puts teams that haven't paid attention to it "around the 15% mark," and quotes David J. Anderson that anything above 40% is good. At 15%, an item spends most of its life waiting, which is why cutting wait time usually beats speeding up the work.
Two cautions. Flow efficiency needs a board that separates waiting states ("ready for review") from working states ("in review"); without them you're estimating. And, as Wester notes, the result "will not tell you how to improve your efficiency."
Mik Kersten's Flow Framework, introduced in [*Project to Product*](https://flowframework.org/ffc-discover/) (2018), is a separate model with its own named metrics and work item types. Check which model a dashboard uses before comparing its numbers with the Kanban measures here.
## Little's Law in plain words
John Little proved it in 1961. In his own [50th-anniversary paper](https://pubsonline.informs.org/doi/10.1287/opre.1110.0940) (*Operations Research*, 2011): "the average number of items in a queuing system ... equals the average arrival rate of items to the system ... multiplied by the average waiting time of an item in the system." For a team's board, that becomes:
**Average cycle time = average WIP ÷ average throughput**
**A worked example.** Over the last quarter your team averaged 12 items in progress and finished 4 items a week. Average cycle time is 12 ÷ 4 = 3 weeks. Now hold throughput at 4 a week and cap WIP at 6: average cycle time drops to 1.5 weeks. Nobody worked faster. Each item simply spent less time queued behind the others.
That is the argument for WIP limits in one line of arithmetic: if throughput doesn't change, starting more work only lengthens cycle time.
**The assumptions.** Little's paper is clear that the law describes averages over a period you have already measured: "we are in the measurement business, not the forecasting business." Teams also plug in throughput, the rate work leaves, where Little's formula uses the rate work arrives, and that swap only holds when the period is stable. The conditions usually listed come from Vacanti's work (his book's appendix on the law has a section headed "It is all about the Assumptions"), as summarized in Planview's documentation:
1. Work arrives about as fast as it leaves.
2. Work that is started eventually finishes, rather than being abandoned in place.
3. WIP is roughly the same at the start and end of the period.
4. The average age of WIP is neither rising nor falling.
5. Cycle time, WIP and throughput use consistent units (all days, all items).
When these break, the formula still produces a number, but it stops describing your system. A team whose WIP climbed all quarter has already broken the first and third.
## Reading flow metrics as a set
The useful readings come from combinations:
- **WIP rising, throughput flat:** the team is starting more than it finishes. Cycle time will rise next.
- **Throughput steady, a few items very old:** something specific is stuck. Look at age, not averages.
- **Cycle time fine, lead time long:** the delay is in the queue before work starts, which is a prioritization problem, not a delivery one.
- **Flow efficiency low everywhere:** handoffs and waiting states, not effort, are the constraint.
An aging chart can show that three items have been stuck in review for nine days; the people on the team know whether that is one overloaded reviewer, an unclear acceptance test, or a dependency on another team. That conversation belongs in the retrospective, and [From numbers to actions](/guides/agile-metrics/from-metrics-to-action/) covers how to bring the charts into the room. TeamRetro's [Kanban Flow Retrospective](/retrospective-templates/kanban-flow-retrospective/) template structures that discussion around what flowed well, where the bottlenecks were, and whether WIP limits and policies are working.
Sprint teams can use all of these too. The [scrum metrics chapter](/guides/agile-metrics/scrum-metrics/) covers the sprint-shaped measures, such as carry-over, that sit alongside them.
## Frequently asked questions
### What is the difference between lead time and cycle time?
Lead time runs from the moment a request is received to the moment it is delivered, so it includes the time the item waits in the backlog. Cycle time runs from the moment the team starts the item to the moment it is finished. Lead time is what the customer experiences; cycle time is the part of it the team controls directly.
### Is DORA's lead time the same as Kanban lead time?
No. DORA's change lead time runs from a change being committed to version control to that change being deployed in production. It leaves out the design work and the backlog wait that Kanban lead time includes, so it measures the delivery pipeline, not the customer's whole wait.
### What are the four flow metrics in Kanban?
The Kanban Guide names four mandatory flow measures: work in progress (items started but not finished), throughput (items finished per unit of time), work item age (time since an unfinished item started) and cycle time (time from start to finish).
### How do you calculate flow efficiency?
Divide the time an item was actively worked on by its total lead time, then multiply by 100. An item that took 20 days end to end but was only worked on for 4 of them has a flow efficiency of 20%.
### What does Little's Law say about work in progress?
Little's Law says that, in a stable system, average work in progress equals average throughput multiplied by average cycle time. Rearranged, average cycle time equals average WIP divided by average throughput. If throughput holds steady, carrying less work in progress shortens the average time each item takes. It describes averages over a period you have already measured; it is not a forecast for a single item.
## Related reading
- [Agile and engineering metrics](/guides/agile-metrics/): the hub, with every framework in this guide on one map.
- [What are DORA metrics?](/guides/agile-metrics/dora-metrics/): change lead time in context, next to deployment frequency and DORA's stability measures.
- [Scrum and sprint metrics](/guides/agile-metrics/scrum-metrics/): carry-over, sprint goal success and the other sprint-shaped measures.
- [From numbers to actions](/guides/agile-metrics/from-metrics-to-action/): turning a flow chart into a cause and a change.
- [Is velocity a useful metric?](/guides/agile-verdicts/is-velocity-a-useful-metric/): why throughput is the harder number to game.
---
# Measuring what dashboards can't: health checks and maturity models
URL: https://www.teamretro.com/guides/agile-metrics/maturity-models-and-health-checks/
**System metrics show what your delivery pipeline does. They can't show how the work feels to the people doing it, or how developed your practices are. Health checks and maturity models fill those two gaps with structured perception data.** A health check asks the team how things are right now. A DevOps maturity model rates your practices against written levels. Both are most useful as the start of a team conversation, and both break when they become a scorecard for ranking teams.
This chapter of the [agile metrics guide](/guides/agile-metrics/) covers why perception data is real data, what DevOps maturity models assess, the main criticism of them, and the public models you're most likely to meet.
## Why perception data counts as data
DORA, the research program behind the [DORA metrics](/guides/agile-metrics/dora-metrics/), measures culture with surveys rather than system logs, and its [guidance on generative culture](https://dora.dev/capabilities/generative-organizational-culture/) says why: "Organizational culture is a perceptual measure, and therefore, best measured using survey methods." Its culture survey asks people to rate statements such as "On my team, information is actively sought" and "Messengers are not punished when they deliver news of failures or other bad news" on a seven-point agree/disagree scale, then averages them into a single Westrum culture score. Westrum's model describes cultures as pathological, bureaucratic or generative.
That is not a soft add-on. On the same page, DORA reports that "a high-trust, generative culture predicts software delivery and organizational performance in technology," and cites its 2019 report finding that psychological safety predicts software delivery performance, organizational performance and productivity. So the human side of the work can be a cause of the delivery numbers, not just a nice-to-have alongside them. Our [psychological safety guide](/guides/psychological-safety-at-work/) covers how to build and measure that part.
Perception data beats system data in three situations:
- **When the thing you care about has no log.** Trust, morale, whether people raise bad news, whether the mission is clear. No pipeline records these. The [SPACE framework](/guides/agile-metrics/space-framework/) makes satisfaction and well-being a dimension of its own for this reason, and [developer experience metrics](/guides/agile-metrics/developer-experience-metrics/) build on how developers perceive their work.
- **When you have no instrumentation yet.** A new team, or delivery data spread across tools, can still ask good questions this week. DORA's [metrics guide](https://dora.dev/guides/dora-metrics/) warns against putting measurement ahead of improvement and suggests it "might be better to start with having conversations."
- **When you need the reason behind a number.** This is the gap between what and why. A deployment-frequency chart shows the drop, and a health check shows that "easy to release" went from green to red the same quarter. Neither tells you the cause. That comes from the team talking it through.
System data still wins for counts and durations, such as how often you deploy. People are poor stopwatches.
## Health check vs maturity model
Both use a team survey and a rating scale, so they get confused. They answer different questions.
| | Health check | Maturity model |
|---|---|---|
| Question | How does it feel to work here right now? | How developed are our practices? |
| What is rated | Dimensions of team life (speed, quality, mission, fun, support) | Specific practices against written level descriptions |
| Scale | Traffic light or agree/disagree | Levels, usually ad hoc to optimized |
| Typical cadence | Usually quarterly | Every six to twelve months |
| Output | A trend and a conversation | A gap list and an improvement plan |
| Main risk | Teams compared on color counts | Levels chased as targets |
A health check reads the temperature; a maturity model shows where your practices sit on the map. A team can be happy with immature practices, or disciplined and worn out, and you only see that with both readings.
If a health check keeps flagging the same delivery dimensions quarter after quarter, that is usually the cue to zoom out to a maturity model and look at the practices underneath. For running health checks themselves, see the [team health check guide](/guides/team-health-check/).
## What a DevOps maturity model assesses
A DevOps maturity model rates the practices that take a change from commit to production and keep it running. Most models group them into a handful of areas. The Continuous Delivery Maturity Model, [published on InfoQ](https://www.infoq.com/articles/Continuous-Delivery-Maturity-Model/) in 2013 by Andreas Rehn, Tobias Palmborg and Patrik Boström, uses five: Culture & Organization, Design & Architecture, Build & Deploy, Test & Verification, and Information & Reporting.
Within each area, the model describes what a practice looks like at each level. "Deployment" at a low level might read as a manual, documented runbook; at a high level, as an automated, low-risk, repeatable release any team member can trigger. The team reads the descriptions, agrees where it sits, and notes the evidence.
That is the difference from the [DORA metrics](/guides/agile-metrics/dora-metrics/). DORA measures outcomes of the delivery system (how fast, how stable). A maturity model rates the practices that produce those outcomes. The two pair well: the maturity model suggests what to change, and the outcome metrics show whether the change worked.
### Common level schemes
There is no single standard scale. Two shapes are common.
**CMMI-style levels.** CMMI's maturity levels, published by the [CMMI Institute](https://cmmiinstitute.com/learning/appraisals/levels), run from 0 to 5:
| Level | Name | CMMI's description |
|---|---|---|
| 0 | Incomplete | Ad hoc and unknown |
| 1 | Initial | Unpredictable and reactive |
| 2 | Managed | Managed on the project level |
| 3 | Defined | Proactive, rather than reactive |
| 4 | Quantitatively Managed | Measured and controlled |
| 5 | Optimizing | Stable and flexible |
CMMI separates these staged maturity levels from capability levels (0 to 3), which rate one practice area at a time. That distinction is worth keeping in a DevOps model: rating each capability on its own tells you more than one overall level.
**Practitioner levels.** The Continuous Delivery Maturity Model uses Base, Beginner, Intermediate, Advanced and Expert. Its authors state that the levels are "not strict and mandatory stages that needs to be passed in sequence", and advise keeping maturity roughly even across categories, since the categories affect each other.
TeamRetro's [DevOps Maturity Assessment](/health-check-templates/devops-continuous-delivery/) follows the per-capability pattern: the team rates 15 capabilities in five groups on a five-level scale from Ad Hoc to Optimized.
## The criticism: maturity models reward box-ticking
A pointed critique comes from the researchers behind DORA. In *Accelerate* (Forsgren, Humble and Kim, 2018), a section titled "Focus on capabilities, not maturity", [excerpted on TechTarget](https://www.techtarget.com/it-infrastructure/opinion/DevOps-Research-and-Assessment-team-dispels-maturity-model-myths), makes four points:
- Maturity models help an organization "arrive" at a mature state and declare the journey done, where improvement should be continuous.
- "Maturity models assume that 'Level 1' and 'Level 2' look the same across all teams and organizations." They don't.
- Maturity models often measure tooling or proficiency without tying it to outcomes. Capability models focus on the capabilities that drive outcomes.
- Maturity models define a static target. Capability models allow for a changing environment.
In practice, that shows up as box-ticking. A team "reaches Level 3" by installing the tool the Level 3 description names, without changing how it works, and a leadership dashboard averages levels across teams with very different systems. This is the target problem covered in [from metrics to action](/guides/agile-metrics/from-metrics-to-action/), applied to a rating instead of a number.
## How to use a DevOps maturity model well
None of this means throwing the model out. Written descriptions of good practice give a team a shared vocabulary. The fixes are in how you run it.
1. **Let the team rate itself.** Ratings by an outside assessor turn the model into an audit. Self-rating with evidence ("we say Level 3 because a release needs one approval and runs in under an hour") turns it into a conversation.
2. **Rate capabilities, not the team.** Report a profile across capabilities, never one overall level. The gaps are the useful part.
3. **Pick one or two capabilities to move.** Not "get to Level 4". Choose the capability that is the current constraint, agree what the next level looks like for you, and stop there.
4. **Check it against outcomes.** If trunk-based development "moved up a level" but change lead time didn't move, the rating was optimistic or the capability wasn't the constraint. Pair the model with [DORA](/guides/agile-metrics/dora-metrics/) or [flow metrics](/guides/agile-metrics/lead-time-vs-cycle-time/).
5. **Never compare teams on levels.** Different systems, different constraints. Compare a team with its own last assessment.
6. **Revisit every six to twelve months.** Practices change slowly, and a quarterly maturity rating tends to measure mood more than practice.
## Well-known public models
### The Spotify Squad Health Check (2014)
Henrik Kniberg and Kristian Lindwall published the [Squad Health Check](/health-check-templates/squad-health-check/) model on [Spotify's engineering blog](https://engineering.atspotify.com/2014/09/squad-health-check-model) in September 2014. Squads rate ten default indicators (Easy to release, Suitable process, Tech quality, Value, Speed, Mission, Fun, Learning, Support, and Pawns or players) as green, yellow or red, plus an arrow for whether each is improving or getting worse. The authors suggest quarterly as a starting cadence and prefer face-to-face workshops to online surveys, because a survey "cuts out the conversation, and that's the biggest part of the value."
They are just as clear about the limits. It is "a support tool, not a judgement tool"; it "only works in a high-trust environment"; and "Beware of comparing teams." It is a health check, not a maturity model: there are no levels to climb.
### DORA's capabilities
DORA publishes a [catalog of capabilities](https://dora.dev/capabilities/) that its research links to better software delivery and organizational performance, among them continuous integration, trunk-based development, test automation, loosely coupled teams, generative organizational culture and well-being. DORA's [research page](https://dora.dev/research/) describes the DORA Core Model as "a collection of capabilities, metrics, and outcomes that represent the most firmly-established findings."
It is a capability model, not a level scheme: there's no Level 3 to reach, only the capability that constrains your team now.
### The Five Ideals (Gene Kim)
The [Five Ideals](/health-check-templates/five-ideals-of-devops/) come from Gene Kim's novel *The Unicorn Project* (IT Revolution, 2019), and [IT Revolution's summary](https://itrevolution.com/articles/five-ideals-of-devops/) lists them as Locality and Simplicity; Focus, Flow, and Joy; Improvement of Daily Work; Psychological Safety; and Customer Focus. They describe the conditions developers need rather than practice levels, which makes them a good fit for an agree/disagree survey with one statement per ideal.
If your question is about agile practices rather than the delivery pipeline, TeamRetro's [assessment page](/health-checks/agile-maturity-assessment/) and its companion article on [measuring and improving agile maturity](/blog/agile-maturity-assessment-how-to-measure-and-improve-your-team/) cover that side.
## Frequently asked questions
### What is a DevOps maturity model?
A DevOps maturity model rates a team's delivery practices, such as integration, testing, deployment, operations and security, against a defined scale of levels, usually from ad hoc to optimized. It answers how developed the practices are, not how fast the pipeline runs or how the team feels. Its value is the conversation about evidence for each rating and the one or two capabilities the team chooses to improve next.
### What are the levels of a DevOps maturity model?
There is no single standard. Many models borrow a five-step shape from CMMI, whose maturity levels run Initial, Managed, Defined, Quantitatively Managed and Optimizing (with Level 0, Incomplete, below them). The Continuous Delivery Maturity Model uses Base, Beginner, Intermediate, Advanced and Expert. Treat the levels as descriptions of practice to discuss, not as stages to pass in order.
### What is the difference between a health check and a maturity model?
A health check asks the team how things are right now, on dimensions like speed, quality, mission and fun, and it is subjective by design. A maturity model rates specific practices against written level descriptions. The health check is a thermometer you read often; the maturity model is a map you revisit every six to twelve months. Most teams get more from using both than from either alone.
### Are maturity models still useful?
Yes, with care. The authors of *Accelerate* argue for focusing on capabilities rather than maturity, because maturity models treat improvement as a destination and assume every team's Level 2 looks the same. A maturity model stays useful when the team rates itself, discusses the evidence, picks one or two capabilities to improve, and checks the result against outcome metrics such as the DORA measures.
## Related reading
- [Agile and engineering metrics](/guides/agile-metrics/): the hub, with a map of every framework in this guide.
- [What are DORA metrics?](/guides/agile-metrics/dora-metrics/): the outcome measures to pair with a maturity model.
- [The SPACE framework](/guides/agile-metrics/space-framework/): where perception data sits alongside system data.
- [From numbers to actions](/guides/agile-metrics/from-metrics-to-action/): turning a rating or a metric into one change the team makes.
- [Team health checks](/guides/team-health-check/): how to run one, which questions to ask, and what to do with the trend.
---
# Online vs in-person retrospectives
URL: https://www.teamretro.com/guides/scrum-masters-retrospective-guide/online-vs-in-person-retrospectives/
Online and in-person retrospectives chase the same agile goals; they differ mainly in logistics. In-person retros need a room, boards, and sticky notes; online retros need a video call and a collaborative tool, but unlock anonymity, independent voting, and easy capture of ideas.
Even if a remote or online retro means that not everyone is physically in the same room, the goals and principles of Agile do not change. Agile is about the process.
An in-person retrospective means you have to book a room, set it up, draw things on boards, check the logistics and collate sticky notes afterward. For remote retros, the focus is more on having the right video conferencing tool (Zoom, MS Teams, Skype) and having an [online retrospective tool](/retrospective-tool/) to collaborate effectively. It's not just a stream of chats, unorganized sticky notes, or someone trying to scribe what is said and not being able to join in themselves.
According to the 3,500-respondent State of Remote Work report, working from home is on the rise, with flexibility, no commute, and family time being some key benefits. On the other hand, collaboration, communication, and loneliness represent 40% of the biggest challenges. Retrospectives are therefore both an opportunity and a challenge: a time when people can come together and share and learn from each other in a supportive environment. The pros and cons of remote online retrospectives are:
## What are the pros of online retrospectives?
- Easier for people to meet
- Ability to have asynchronous retrospectives
- Real-time feedback
- No manual collation
- Equal opportunity for people to contribute
- Independent brainstorming and voting
- Anonymous options
- More time for discussion and team bonding
- No more production blocks or anchoring (1 person talking about their idea)
- No room set up
## What are the cons of online retrospectives?
- A loss of all body language cues
- A potential loss in a general sense of togetherness
- Reliance on technology for video conferencing and collaboration tools
- Facilitating a remote retrospective is more challenging
It's important with online retrospectives to find ways to build rapport and ensure that every voice in the room is "heard". You may not have to prep a room, but you still need to prep for the session.
The need to continue to build engagement, connection, participation, and buy-in to decisions applies to both types of retrospectives, albeit with slightly different strategies. This becomes even more important when your team is distributed. See [why remote retrospectives are key to the agile process](/guides/scrum-masters-retrospective-guide/why-remote-retrospectives-are-key/).
While online meetings don't have everyone standing side by side, this doesn't mean they have to be impersonal or cold. They can lend themselves to understanding a bit more about each person on the team, finding out more about them, and having them share a little of their lives with everyone. Having activities for online meetings that connect, energize, challenge, or engage the team (including your retrospective) ensures there is an opportunity to build these relationships.
## Frequently asked questions
### Are online retrospectives as effective as in-person ones?
Yes. A well-run online retrospective can be as effective as an in-person one, and sometimes more so. The goals are identical: reflect on the sprint and agree improvements. Online tools add real advantages such as anonymous input, automatic capture of ideas, and easy participation for remote or hybrid teams. What changes is the logistics, not the value.
### What is the difference between an online and an in-person retrospective?
The difference is logistics, not purpose. In-person retrospectives rely on a shared physical space, whiteboards, and sticky notes; online retrospectives use a collaborative tool that everyone joins remotely. Online formats make it easier to include distributed teammates, contribute anonymously, and capture and share the results automatically.
### How do you make a remote retrospective engaging?
Give people time to connect at the start, use a tool that lets everyone contribute at once (ideally anonymously), keep cameras on where you can, and vary the template so the meeting does not feel repetitive. The aim is equal participation (every voice heard), which a good online retrospective tool is designed to support.
---
# Performance: the ceremony you run for the audience
URL: https://www.teamretro.com/guides/agile-theatre/performance-agile-theatre/
A ceremony becomes theatre the moment its real audience stops being the team.
That's the whole test, and it cuts across every meeting on the sprint calendar. A standup performed for a manager's eyeline. Estimates recited to look rigorous. A retrospective held because the recurring invite fired, not because anyone expects it to change anything. In each case the ritual is intact and the function is gone, and the team, who can always tell, quietly stops investing. Performance is the first failure mode of agile theatre, and it's the substrate the other three grow out of.
Agile theatre in four modes. Performance is the common substrate; Power, Overload and the Void are the sharper forms it hardens into, a chapter each.
## The status-theatre standup
The daily standup is the most-performed ceremony in software, because it's the easiest to hijack. Per the [Scrum Guide](https://scrumguides.org/scrum-guide.html), the Daily Scrum exists for the developers to coordinate their own plan for the day. The manager isn't supposed to be running it, or in many teams even attending. What it becomes instead is a status report wearing a team-huddle costume: everyone recites what they did yesterday to the person who signs off on their review, and no one actually talks to anyone else.
Same fifteen minutes, two different meetings: updates aimed at the manager's eyeline, or at the board the team coordinates around.
You can spot the performance by where people are looking. In a coordination standup, developers talk to each other and to the board; someone says "I'm touching the auth module today" and someone else says "wait, so am I, let's sync after." In a status standup, each person reports to one face and the rest wait their turn. The tell is even sharper in the coping behavior: on a good week people hold a little work back so they've got something to report on a bad one, and the update becomes a small daily exercise in managing appearances rather than sharing information. When 60% of the ritual is keeping up a certain kind of face, the meeting has stopped being coordination.
The fix isn't to add energy to the performance. It's to change the audience. Point updates at the work, not the boss: walk the board, not the room. If the status already lives in the tracker, the pull requests and the chat, then reciting it aloud is pure ceremony; the meeting's only real jobs are surfacing blockers and coordinating today's overlaps. Everything else can be read asynchronously, from updates people post in a [standup tool](/standups/) on their own schedule. Our [standup anti-patterns](/guides/daily-standup-guide/standup-anti-patterns/) chapter catalogs the specific tells, and the [async and remote standup](/guides/daily-standup-guide/async-and-remote-standups/) chapter covers how to move the status part off the clock entirely.
## The cargo-cult estimate
Estimation theatre is quieter but just as common. A team runs planning poker because planning poker is what you do (cards come out, numbers get voted, a Fibonacci sequence lends an air of science), and then everyone privately converts the points back into hours anyway. The mechanics are performed flawlessly while the purpose evaporates. Practitioners have a withering shorthand for it: a group of adults arguing about what color paper a work item should be, a cargo cult that mimics the form of estimation in the hope the outcome follows.
Here's the thing the ritual obscures: the number was never the deliverable. As Eisenhower put it, "plans are worthless, but planning is everything." The estimate is worthless, but the estimating is the point. Planning poker isn't a prediction machine; it's a disagreement detector. When one engineer votes a 3 and another votes a 13 on the same story, that eight-point gap means they are picturing two different pieces of work, and the conversation that closes the gap is the entire value of the meeting. A team that votes, splits the difference, and moves on has performed the ceremony and skipped the work.
**If your planning session would produce the same numbers with the discussion removed, you're not estimating. You're voting on tickets nobody analyzed.** The output that matters isn't the point total; it's the shared understanding two people didn't have before they compared cards. Silence the loudest voice, have the highest card explain first, and treat every wide spread as a question, not an average to compute.
Concretely: run a silent first round so the tech lead's card doesn't anchor everyone; make the high estimate speak before the low one; and if nobody can explain a story well enough to size it, that's not a number problem, it's a refinement problem. Our [how to run planning poker](/guides/agile-estimation-guide/how-to-run-planning-poker/) and [planning poker mistakes](/guides/agile-estimation-guide/planning-poker-mistakes/) chapters go deep on defeating the anchoring the ceremony is supposed to prevent, and [what story points actually are](/guides/agile-estimation-guide/what-are-story-points/) explains why the points-to-hours conversion is the failure, not the fix.
## The box-ticking retro
Then there's the retrospective that runs because the calendar says so. Same format every fortnight, same stickies, same three columns, same silence. Practitioners describe it exactly: a box-ticking exercise, a shortened ritual with no useful effect, meetings that felt forced and awkward. The ceremony persists as a habit long after anyone believes in it.
The reflex is to reach for a new format: swap the columns for a sailboat, try a starfish, download a fresh template. Sometimes that helps. But be honest about what a format can and can't fix. As one sharp practitioner argument goes, your retrospective format doesn't matter: changing the activity is lipstick if the real problem is that nothing ever happens afterward. A stale ritual is a Performance problem you can solve with variety and better facilitation. A ritual that produces words and no change is a different failure entirely. That's the [follow-through void](/guides/agile-theatre/the-follow-through-void/), the fourth mode, and no amount of format-chasing touches it.
So diagnose before you redecorate. If the room is going through the motions, freshen the format and put one concrete thing at the top of the agenda: last retro's single improvement, and whether it happened. If the room is engaged but nothing changes downstream, the format was never the issue. Our [retrospective guide](/guides/scrum-masters-retrospective-guide/) covers both, and the [psychological safety](/guides/scrum-masters-retrospective-guide/how-to-build-a-psychologically-safe-space/) chapter addresses the silence that so often reads as apathy but is usually something colder.
## "Real Scrum has never been tried"
Every critique of a performed ceremony draws the same rebuttal: you're just doing it wrong, that wasn't real agile. It's the agile equivalent of "real communism has never been tried," and it's worth naming because it's how Performance defends itself. If every failure can be waved away as "not the real thing," the framework becomes unfalsifiable, and a practice you can't criticize is a practice you can't improve.
But the rebuttal isn't always a dodge. The retrospective and the standup have *published definitions*: the [Scrum Guide](https://scrumguides.org/scrum-guide.html), the [Agile Manifesto](https://agilemanifesto.org/), the standard practitioner texts. Measuring a bad ceremony against what it's *supposed* to be isn't a no-true-Scotsman move; it's using the actual spec. The line to hold is this: "you're doing it wrong" is a cop-out when it's the fifth team in a row that's somehow doing it wrong, and it's fair when it names the gap concretely. The Scrum Guide time-boxes the daily at fifteen minutes and yours runs forty; the retrospective belongs to the team and yours is chaired by the manager. One of those is a dodge; the other is a diff. The four modes in this guide are our attempt to name those gaps precisely enough that "do it right" means something.
Performance is where theatre starts, but it's rarely where it ends. When appearance-management collides with a power imbalance, the performance turns coercive. That's [Power](/guides/agile-theatre/power-agile-theatre/). When the ceremonies pile up past the point of use, that's [Overload](/guides/agile-theatre/ceremony-overload/). And when the meeting runs beautifully and nothing changes, that's the [Void](/guides/agile-theatre/the-follow-through-void/). Start by asking the Performance question of every ceremony you run, *who is this actually for?*, and you'll find the other three hiding behind it.
## Frequently asked questions
### How do I know if our standup is just a status meeting?
Watch where people look. In a coordination standup the team talks to each other and to the board; in a status meeting everyone reports to one person's eyeline and nobody responds to anyone else. If the manager's absence would change the meeting, it was theirs, not the team's.
### Is planning poker a waste of time?
Only if you skip the part that matters. Voting on tickets nobody analyzed is theatre. The value isn't the number. It's the disagreement it surfaces. When one person votes 3 and another votes 13, the gap is the whole point of the meeting.
### Does the retrospective format matter?
Less than vendors selling formats want you to think. Swapping Mad/Sad/Glad for a sailboat is lipstick if nothing changes afterward. A fresh format fixes a stale ritual; it does nothing for a retro whose real problem is that no one acts on it.
### What is agile theatre?
A ceremony run for appearance rather than function: going through the motions of a standup, planning session or retrospective so the process looks followed, while the thing the ceremony exists to produce quietly doesn't happen. Performance is the first and most common of its four failure modes.
## Related reading
- [Power: when authority captures the ceremony](/guides/agile-theatre/power-agile-theatre/): where performance turns coercive.
- [The follow-through void](/guides/agile-theatre/the-follow-through-void/): the retro that runs well and changes nothing.
- [Standup anti-patterns](/guides/daily-standup-guide/standup-anti-patterns/): the specific tells of a status-theatre standup.
- [The daily standup (daily scrum)](/guides/agile-ceremonies-guide/the-daily-standup/): what the ceremony is for, before it becomes a status performance.
- [How to run planning poker](/guides/agile-estimation-guide/how-to-run-planning-poker/): running estimation for the conversation, not the number.
- [Agile Theatre glossary](/guides/agile-theatre/agile-theatre-glossary/): the four coined failure modes, defined.
---
# Planning poker mistakes and anti-patterns
URL: https://www.teamretro.com/guides/agile-estimation-guide/planning-poker-mistakes/
Most failed planning poker sessions trace back to a short list of causes: bad refinement, anchored discussion, treating points as hours, and velocity used as a weapon. The ritual is robust enough to survive any of them in a single session, provided someone in the room notices. Here's what to watch for, grouped by where it goes wrong.
## In the room: voting and reveal mistakes
### Estimating in hours
The team starts converging on hour-equivalents: 3 is half a day, 5 is a day, 8 is a couple. Once that mapping appears, you're doing time-based estimation with a Fibonacci coat of paint, and the relative-effort property that [story points](/guides/agile-estimation-guide/what-are-story-points/) exist to give you is gone. Re-anchor on the reference story and ban hour-talk for a round. If the team can't have the conversation without translating to time, the problem is usually upstream: a stakeholder who only believes in dates.
### Just averaging the cards
Someone plays a 3, someone plays a 13, the facilitator splits it at 8 and moves on. The whole point of the simultaneous reveal was to surface that disagreement; the average buries it. On a one-step spread (3s and 5s) take the higher number. That's not averaging, it's defaulting to the more cautious read. On a spread of two steps or more, you have a conversation, not an arithmetic problem.
### The senior person's number wins
Hidden cards stop the lead engineer from anchoring the *vote*, but not from ending the *discussion*. After the reveal, whoever speaks first with confidence still tends to win the room. Ask the lowest card to explain first, then the highest, then everyone else. Junior voices that get to anchor the discussion early keep their context instead of folding to seniority.
### Re-voting until everyone gives up
By the third or fourth re-vote, the spread narrows because people are tired, not because they agree. The estimate that falls out is socially negotiated, not shared. Two votes per story is the right ceiling. Heading for a third? The story isn't ready, so split it, send it back to refinement, or punt. (The [four-phase loop](/guides/agile-estimation-guide/how-to-run-planning-poker/) has the full sequence.)
### Ignoring the ? card
Someone plays a `?` and the room treats it as a non-vote ("anyone with a real number?") instead of a stop sign. A `?` is real information: someone can't responsibly size this, which usually means the story is missing context, or isn't defined enough yet. Surface it. The story needs another conversation, not another pass.
## Around the session: process mistakes
### No reference story
The team estimates with no anchor, so "what's a 5?" gets answered differently every sprint and points drift without anyone noticing. Pick one already-shipped story as the baseline and re-anchor every quarter, or after major team changes. Without a reference story, your velocity is a random walk.
### Estimating before refinement
The story is two lines long. Half the team is estimating "the version where we do it properly" and the other half "the smallest thing that matches the description." Both are right; neither is what you'll ship. The fix isn't faster estimation, it's slower refinement: acceptance criteria, owner area, a sense of the edges, *then* estimate. Estimating to find out how big something is, rather than after, is how the same story gets sized 3 in week one and 13 in week three.
### Estimating in absentia
The team sizes a story whose owner area is "the other team," or "whoever's on call when it lands." Whoever's in the room votes confidently because the work isn't theirs to do. Don't estimate work the people in the room won't own. If a story crosses team boundaries, get both teams represented or [split it along the boundary](/guides/agile-estimation-guide/splitting-user-stories/). An estimate from people who won't do the work isn't really an estimate.
### Sessions that drag past 45 minutes
Estimation quality falls off a cliff after about 45 minutes. The cards get smaller, then bigger, then everyone just plays what the lead plays. Time-box the session, not only the stories, and cut at 45. If there's more to size, schedule a second session, or reach for a [faster technique](/guides/agile-estimation-guide/estimation-techniques/) like bucket sizing for the long tail.
### Estimating bugs at feature precision
"Investigate the data-corruption issue" gets a 5, the same as "add a checkbox to the export dialog." One has a known scope; the other's whole nature is that you don't know what's in there. Bugs and exploratory work usually deserve a different track: a time-boxed investigation of a day or two, then a follow-up story to fix what you find. Forcing them onto the feature deck pretends you have information you don't.
## In the org: management mistakes
### Velocity as a productivity metric
A manager starts comparing velocity across teams, or asking why this sprint hit 28 points when the last hit 32. Within two sprints, every estimate is 30% bigger.
Story points are a planning tool for the team that owns the work. The moment they're used to *evaluate* that team, the team games them, and correctly so, because they're being measured on them. There is no fix from inside the estimation session; this one has to be solved upstream, by not doing it.
### Story-point inflation
Points drift up sprint over sprint without the work getting any harder. Usually one of three things: velocity is being measured externally (above), the reference story has slipped, or the team has stopped re-anchoring. Audit it by re-estimating five stories you shipped a year ago and seeing where they land now. If they're consistently bigger, your scale has moved. (More in [velocity](/guides/agile-estimation-guide/velocity/).)
### The points-to-hours conversion table
Someone well-meaning writes "1 point = 4 hours" on the wiki. Within a sprint, every estimation conversation is a thinly veiled hour conversation, and the relative-effort property is gone again. Retire the conversion table. If a stakeholder needs a date, project it from the team's actual velocity (points per sprint times the number of sprints), not from a fictional points-to-hours rate.
## What good looks like
A team that runs planning poker well isn't avoiding every one of these — it's noticing them fast. The mechanic is robust enough to recover from any single mistake in one session, as long as someone is paying attention to the spread, the anchor, and the clock.
New to the technique? Start with [what planning poker is](/guides/agile-estimation-guide/what-is-planning-poker/) and [how to run a session](/guides/agile-estimation-guide/how-to-run-planning-poker/). Or just [open a session](/free-planning-poker-for-agile-teams/) and try it on one easy story before the next one bites.
## Frequently asked questions
### What are the most common planning poker mistakes?
Averaging the cards instead of discussing the spread, estimating in hours, letting the senior person's number win the discussion, re-voting until people give up, estimating before refinement, and treating velocity as a productivity metric. Most failed sessions trace back to one of those.
### Why is averaging story points a mistake?
The simultaneous reveal exists to surface disagreement; averaging buries it. A 3 and a 13 do not mean 8. They mean two people are estimating different stories. Take the higher number on a one-step spread, and have a conversation on anything wider.
### Is it wrong to convert story points to hours?
Yes. The moment 1 point = 4 hours goes on the wiki, every estimate becomes a duration argument and the relative-effort property is gone. If a stakeholder needs a date, project it from the team's velocity, not from a per-story conversion.
### How long should a planning poker session be?
Cap it around 45 minutes. Estimation quality falls off a cliff after that: cards drift and people start playing whatever the lead plays. If there is more backlog, schedule a second session or switch to a faster technique like bucket sizing.
### Should you re-vote in planning poker?
Once, maybe twice. By the third re-vote the spread narrows because people are tired, not because they agree. If you are heading for a third round, the story is not ready, so split it or send it back to refinement.
---
# Power: when authority captures the ceremony
URL: https://www.teamretro.com/guides/agile-theatre/power-agile-theatre/
Every agile ceremony assumes a level playing field. Power is what happens when there isn't one.
Planning poker only defeats anchoring if no one at the table can overrule the cards. A retrospective is only safe if honesty carries no cost. Velocity is only a forecast if no one above the team is grading it. Remove those assumptions (add a manager who signs off promotions, a metric that travels upward, an estimate that hardens into a promise) and the ceremony doesn't just underperform. It inverts. It starts working *against* the people it was built for. This chapter names the three sharpest ways that happens, because naming them is the first step to refusing them.
## The velocity ratchet
Start with the sharpest card of all: the person who invented story points has disowned them. "I like to say that I may have invented story points, and if I did, I'm sorry now," [wrote Ron Jeffries](https://ronjeffries.com/articles/019-01ff/story-points/Index.html) in 2019. He was specific: "I think comparing teams on quality of estimates or velocity is harmful." When the inventor of the unit tells you the unit is being used to hurt teams, the burden of proof shifts to anyone still using it as a scoreboard.
The [velocity ratchet](/guides/agile-theatre/agile-theatre-glossary/#velocity-ratchet) is how that harm arrives. Velocity is meant to be a team's private self-calibration: the rolling average of points completed, used to forecast how long a backlog will take. The moment it leaves the room as a productivity target, it becomes a ratchet: last sprint's number is this sprint's floor, and the only direction it's allowed to move is up. Teams aren't stupid, so they respond the only way the incentive allows. They inflate. A story that was a 3 last quarter is a 5 this quarter, the number climbs, and nothing ships any faster. Even Mike Cohn, the pro-points authority, concedes the mechanism: the slightest hint that velocities will be compared produces gradual, consistent point inflation.
Velocity is a measure of pace, not productivity. The gap between the target line someone wants and the actual line the team can sustain is exactly the space point inflation fills.
The strongest citable basis for keeping velocity in its lane is [DORA](https://dora.dev/guides/dora-metrics/). A decade of research into what predicts software delivery performance produced [four key metrics](/guides/agile-metrics/dora-metrics/) (deployment frequency, lead time, change-failure rate, and time to restore), and velocity is not among them; story points aren't comparable across teams and measure effort, not delivered value. So the rule is simple and defensible: forecast with velocity, never grade on it. If someone outside the team is asking "is your velocity good?", the fix is upstream of the number. The honest reply is "what are you actually trying to measure?" Our [velocity](/guides/agile-estimation-guide/velocity/) chapter shows how to keep it honest, and [velocity and capacity planning](/guides/sprint-planning-guide/velocity-and-capacity/) shows how to use it for the one thing it's good for.
## Estimate laundering
The second distortion is subtler because it looks like accountability. [Estimate laundering](/guides/agile-theatre/agile-theatre-glossary/#estimate-laundering) is the quiet conversion of an estimate (a guess, made with the least information you'll ever have) into a commitment, and then holding the team to it as if they'd signed a contract. The guess goes into the planning meeting; a deadline comes out; and when the deadline slips, it's the developer's fault for "missing their estimate."
The laundering runs as a loop: a guess is relabelled a commitment, hardens into a fixed date, and when it slips the miss is booked against the team. Then it starts over.
Practitioners describe the whole laundering cycle without needing to be prompted: estimates magically become commitments, and if you don't hit the number, it's on you. Estimates get overruled ("that can't be right, do it again") until the team gives whatever figure makes the date fit, at which point planning is a charade with a predetermined answer. There's even a revealing asymmetry in the language: say "this will take ten days" and a manager will press "are you *sure* it can't be nine?"; say "this is ten points" and, for reasons no one can quite defend, the same instinct doesn't fire. Story points were partly meant as armor against exactly that pressure, and estimate laundering is the pressure defeating the armor by converting the points straight back into a date.
The canonical corrective is Mike Cohn's, and it predates our coinage: [separate estimating from committing](https://www.mountaingoatsoftware.com/blog/separate-estimating-from-committing). An estimate is a probability distribution; a commitment is a decision the team makes about what it's confident it can deliver. Keep them apart, out loud. Forecast a range and name the assumptions under it. And watch for the compounding case. When scope, time, *and* cost are all fixed upfront and the work is merely wrapped in two-week sprints, you don't have agile with estimates, you have waterfall in a costume. Forrester's Dave West named that "water-scrum-fall," and estimate laundering is its beating heart. Our [story points vs hours](/guides/agile-estimation-guide/story-points-vs-hours/) chapter unpacks why the conversion is the failure mode, not the fix.
## Feedback banking
The third distortion is the darkest, because it turns the safest-sounding ceremony into a liability. [Feedback banking](/guides/agile-theatre/agile-theatre-glossary/#feedback-banking) is when honest retrospective input gets stored up and quietly withdrawn against you later: at a performance review, a bonus calibration, a quiet conversation about "fit." The retro is sold as a safe space to be candid. Feedback banking is the discovery that candor has a settlement date.
The war stories are specific and they sting. One engineer described their retro feedback resurfacing in a yearly evaluation as evidence that they "complain too much." Another put the mechanism plainly: management banks all the complaints for withdrawal at your annual bonus review. The chilling effect doesn't even require malice. The person who signs off on promotions doesn't have to say a word in the room. Their presence alone is enough to turn honest input vague, and to teach everyone that the smart move is to perform contentment. Our [why retrospectives fail](/guides/scrum-masters-retrospective-guide/why-retrospectives-fail/) chapter covers designing the session so honesty stops carrying a career cost.
This is where the safety literature stops being hand-waving. Amy Edmondson's work on psychological safety, and Google's [Project Aristotle](https://rework.withgoogle.com/intl/en/guides/understand-team-effectiveness), two years studying 180 teams, found psychological safety the strongest of the five factors it identified: the one the other four rest on. A team that has learned its feedback is being banked has no psychological safety, by definition, and the retro that pretends otherwise is theatre with a legal risk attached. The [Scrum Guide](https://scrumguides.org/scrum-guide.html) frames the retrospective as the team inspecting *itself*. So why is the manager in the room taking notes?
**No facilitation technique fixes a power problem.** The moment a number leaves the room as a promise, or a complaint leaves the room as a performance note, the ceremony has been captured, and a better icebreaker won't uncapture it. The fixes here are structural: keep velocity inside the team, separate estimating from committing on the record, exclude authority from the retro, and make anonymity available per item so the sensitive thing can still be said.
## Don't rely on a hero
There's a failure mode inside the fix. These distortions usually get held back because someone senior (a lead, an EM with spine) personally shields the team: refuses to hand velocity upward, reframes estimates as forecasts, keeps the retro's contents in the room. It works, but only while that person stays. A shield is not a system. If the honesty of your ceremonies rests on one manager's willingness to absorb pressure, you don't have safe ceremonies. You have a temporarily benevolent one, and the theatre resumes the day they leave.
That's the difference between Power as a failure mode and Power as a fixed thing. The [psychological safety](/guides/scrum-masters-retrospective-guide/how-to-build-a-psychologically-safe-space/) chapter covers building candor that doesn't depend on who's in the room, and the [Prime Directive](/guides/scrum-masters-retrospective-guide/what-is-the-retrospective-prime-directive/) covers the norm that makes it stick. When the captured ceremony finally produces nothing but managed appearances, you've arrived at the [follow-through void](/guides/agile-theatre/the-follow-through-void/): the fourth mode, and the one where feedback banking does its quietest damage.
## Frequently asked questions
### How do I stop management using velocity against my team?
Keep the number in the room. Velocity is a forecasting input, not a performance metric. It isn't one of DORA's delivery metrics, and points aren't comparable across teams anyway. If a manager outside the team is asking whether your velocity is good, the honest answer is a question back: what are you actually trying to measure? Report outcomes and delivery, not point totals.
### Can retrospective feedback be used against me in a performance review?
It happens, and the fear is rational. Practitioners report honest retro input resurfacing months later as a note that they complain too much. That's feedback banking, and it's why anonymity, manager-exclusion and the Vegas rule exist. A retro where candor is a career risk isn't psychologically safe, and no facilitation technique fixes it. Fix the power setup, not the wording.
### How do I stop estimates from becoming deadlines?
Separate estimating from committing, out loud and on purpose. An estimate is a probability; a commitment is a promise; laundering one into the other and then holding the team to it is where the trust breaks. Forecast a range, name the assumptions, and never let a guess made in a planning meeting get quoted back as a date the team signed up for.
### Should my manager attend the retrospective or run the standup?
Generally no. The Scrum Guide frames the retrospective as the team inspecting itself and the daily as the developers' own coordination. An authority figure in the room doesn't have to say a word to dampen honesty. The person who signs off promotions is a chilling presence by default. Share the action items upward, not the seats.
## Related reading
- [The follow-through void](/guides/agile-theatre/the-follow-through-void/): where banked feedback and powerlessness meet.
- [Performance: the ceremony you run for the audience](/guides/agile-theatre/performance-agile-theatre/): the theatre that Power makes coercive.
- [Velocity: what it's for and how to calculate it](/guides/agile-estimation-guide/velocity/): using the number for forecasting, never grading.
- [Story points vs hours](/guides/agile-estimation-guide/story-points-vs-hours/): why the conversion feeds estimate laundering.
- [Sprint planning (the ceremony)](/guides/agile-ceremonies-guide/sprint-planning/): where an estimate is meant to stay a forecast the team owns, not a commitment.
- [How to build a psychologically safe space](/guides/scrum-masters-retrospective-guide/how-to-build-a-psychologically-safe-space/): candor that doesn't depend on who's in the room.
- [Agile Theatre glossary](/guides/agile-theatre/agile-theatre-glossary/): estimate laundering, feedback banking and velocity ratchet, defined.
---
# Relative vs absolute estimation (and why relative wins)
URL: https://www.teamretro.com/guides/agile-estimation-guide/relative-vs-absolute-estimation/
People are bad at "how long will this take." They're good at "is this bigger than the one you already shipped." Relative estimation uses the second question, and that's the whole trick.
Absolute estimation asks for a duration, and humans are predictably bad at it. We round optimistically, miss the compounding work, and forget the hidden parts. Relative estimation asks for a comparison instead, and we're surprisingly good at that: we can see sizes side by side without committing to any single number of hours.
## Why relative estimation works
[Planning poker](/guides/agile-estimation-guide/how-to-run-planning-poker/) exploits the asymmetry. The reference story is the team's anchor, and new work gets sized against it: bigger, smaller, much bigger, about the same. The [points scale](/guides/agile-estimation-guide/what-are-story-points/) isn't a duration scale; it's a spread-of-comparison scale. That's why the gaps are [non-uniform](/guides/agile-estimation-guide/why-fibonacci/): the precision is real for small sizes and gets deliberately fuzzier for large ones, because that's how confidence actually behaves.
The property that falls out of this is stability. Because a relative estimate is tied to the work rather than to a person's speed, it holds up when the team composition changes. The size of the story is the same whoever picks it up. The team's *rate* of delivering those sizes is what varies, and that's exactly what [velocity](/guides/agile-estimation-guide/velocity/) is there to track.
## Why teams reach for absolute anyway
Stakeholders ask "when will it be done." That's an absolute question, and the team feels obliged to answer in absolute units. The right move is to translate at the team level: through velocity, not through per-story duration estimates. Velocity gives you a date with the team's noise built in; a per-story hour estimate gives you a date that pretends the noise doesn't exist, which is [the conversion trap](/guides/agile-estimation-guide/story-points-vs-hours/) in another costume. For the capacity side of that same translation, see [velocity and capacity planning](/guides/sprint-planning-guide/velocity-and-capacity/).
## Affinity estimation: relative at scale
For a backlog-wide first pass, affinity estimation is relative estimation done in bulk: drag stories into size groups by comparison, no cards involved. It's faster than planning poker and fuzzier in output, which makes it a good pre-refinement pass before the team sizes the near-term work properly. It's one of several [estimation techniques](/guides/agile-estimation-guide/estimation-techniques/) that lean on comparison rather than the clock.
## Frequently asked questions
### What is the difference between relative and absolute estimation in agile?
Absolute estimation assigns a specific duration to a task: hours or days. Relative estimation compares a task to others and sizes it on an abstract scale like story points, without committing to a duration. Relative sizing is faster and holds up better, because people judge comparison well and absolute time badly.
### What is relative estimation in agile?
Relative estimation sizes a piece of work by comparing it to a reference story the team has already delivered (bigger, smaller, about the same) instead of predicting how many hours it will take. Story points and planning poker are the common way teams do it.
### Why is relative estimation better than estimating in hours?
Because people are unreliable at absolute time and surprisingly good at comparison. Relative estimation avoids anchoring on the loudest voice and the seniority bias hour estimates invite, and, through velocity, still produces a date when someone needs one.
## Related reading
- [What are story points?](/guides/agile-estimation-guide/what-are-story-points/): the unit relative estimation produces.
- [Agile estimation techniques compared](/guides/agile-estimation-guide/estimation-techniques/): planning poker, affinity, bucket and the rest.
- [Velocity](/guides/agile-estimation-guide/velocity/): how a relative estimate becomes a date.
- [Agile estimation guide](/guides/agile-estimation-guide/): the full estimation cluster.
- [Free planning poker for agile teams](/free-planning-poker-for-agile-teams/): relative sizing, in real time, with your team.
---
# Remote team dynamics: what changes when your team is distributed
URL: https://www.teamretro.com/guides/team-dynamics/remote-and-distributed-team-dynamics/
Remote team dynamics are the everyday forces of any team operating without a shared room to carry them. The same trust and communication still decide how well people work together, but distance strips out the accidental contact that used to build them. So distributed teams have to create connection on purpose instead of absorbing it from a shared space.
Most teams go remote by keeping every office habit and bolting on video. It rarely works. The office was doing a lot of invisible labor: it carried context down the hallway and built trust over lunch without anyone scheduling it. Take the room away and that labor does not vanish. Someone now has to do it on purpose.
## Why remote and distributed teams behave differently
Distance changes measurable things about how a team works. Three of them show up again and again in the research, and none of them are about your video tool. For the wider picture, the [remote and hybrid working statistics](/guides/agile-statistics/#remote-hybrid-and-async-teams) collect what the major annual surveys measure, and where they disagree.
### Collaboration gets more siloed
The most robust finding comes from Microsoft. When researchers tracked more than 61,000 employees before and after the 2020 shift to full remote work, cross-group collaboration fell by roughly 25 percent. Networks became more static and siloed: people talked more to their immediate team and less across the organization, and communication shifted toward asynchronous channels like email and chat. The study was [published in *Nature Human Behavior*](https://www.nature.com/articles/s41562-021-01196-4) in 2021 (Yang, Holtz and colleagues). The practical translation is that the weak ties between teams (the loose connections that carry fresh information and keep silos from forming) decay at a distance unless something replaces them.
### The hard part is human, not technical
Remote workers are not asking for better software. Buffer's [2023 State of Remote Work](https://buffer.com/state-of-remote-work/2023) surveyed around 3,000 people, and 98 percent said they want to work remotely at least some of the time. The struggles they named were about people and boundaries, not tooling: spending too much time at home (33 percent), loneliness (23 percent), not being able to unplug (22 percent), and working across time zones (19 percent). Technical collaboration difficulty had fallen year on year. The tools are largely solved. Belonging and boundaries are not.
### Proximity bias is real, and leaders admit it
When some people are visible in an office and others are squares on a screen, attention drifts to the people in the room. Envoy's [2022 workplace survey](https://envoy.com/press-release/proximity-bias-is-real-96-of-leaders-notice-employee-contributions-more-at-the-office-envoy-at-work-survey-reveals) found that 96 percent of leaders notice the contributions of in-office employees more than those of remote ones. That is not a rumor. It is leaders reporting it about themselves. Harvard Business Review's Gleb Tsipursky [describes proximity bias](https://hbr.org/2022/10/what-is-proximity-bias-and-how-can-managers-prevent-it) as rooted in "the antiquated assumption that those who work remotely are less productive than those who work from the office."
The bias has a measurable tail. An analysis of about two million workers by Live Data Technologies, [reported by Fortune](https://fortune.com/2024/01/16/remote-workers-receive-fewer-promotions-office-colleagues-no-difference-hybrid-working-always-in-person-nber-study/) in early 2024, found that 5.6 percent of fully in-office and hybrid employees were promoted in 2023, against 3.9 percent of fully remote ones. That is the source of the widely repeated line that remote workers are about 31 percent less likely to be promoted. This is commercial data rather than a peer-reviewed study, so treat it as a signal, not a law. One detail gets lost in the headline: hybrid workers were not penalized against fully in-office ones. The gap, where it existed, hit fully remote workers, and it looks a lot like proximity bias operating at promotion time.
## What works for remote team dynamics
None of this makes remote work a bad idea. It makes the informal parts of team life something you have to design rather than assume. Here is what the teams that do it well have in common.
### Go async-first and write decisions down
The single most useful move is to make writing the default. In an async-first team, a decision lives in one written source of truth that anyone can read later, not in a meeting that only the people present can replay. GitLab, one of the largest all-remote companies, runs on a public handbook it calls the single source of truth, and treats [asynchronous communication](https://handbook.gitlab.com/handbook/company/culture/all-remote/non-linear-workday/) as the default rather than the exception. This directly counters the siloing Microsoft measured: a written record travels across time zones and teams in a way a synchronous conversation never will.
### Rebuild weak ties on purpose
The 25 percent decay in cross-team connection will not reverse on its own. You have to schedule the contact the office used to create by accident. Rotating coffee pairings work. So does a standing channel for non-work talk, and a short, deliberate opener before meetings. The point is that connection becomes a cadence someone owns rather than a happy accident.
This is where a light game earns its place. Opening a distributed meeting with a two-minute round of [virtual icebreakers](/icebreakers/virtual-icebreakers/) or a few [check-in questions](/icebreakers/check-in-questions/) rebuilds the small talk a shared kitchen used to provide. If you want something livelier for a distributed group, you can [run Two Truths and a Lie live with your team](https://games.teamretro.com/games/two-truths-and-a-lie/). For deeper connection, a rotating cadence of [team-building activities](/icebreakers/team-building-games-for-work/) keeps weak ties warm between the intense delivery periods.
### Agree overlap hours, not a single clock
Time zones are the struggle that tooling cannot fix, so name a rule for them. Most distributed teams that work well agree on a few core overlap hours, say 10:00 to 13:00 in a shared reference zone, when live calls can be scheduled, and treat everything outside that window as async by default. This answers the timezone problem without forcing everyone onto one clock, which is the fastest way to burn out the people furthest from headquarters.
### Write your communication norms down
Distributed teams cannot rely on picking things up by osmosis, so the unwritten rules have to become written ones. Agree which channel is for what, how fast a reply is reasonable in each, and when a document beats a meeting. A useful default: chat within a few working hours, email within a day, and nothing expected outside someone's posted working hours. These are exactly the kind of commitments a team should agree together rather than have imposed. Our chapter on [team norms and working agreements](/guides/team-dynamics/team-norms-and-working-agreements/) has a copy-pasteable library of them, and a [team charter](/guides/team-charter/) is where the distributed version of these agreements usually lives.
### Keep meetings honest, and cameras by consent
Meeting hygiene matters more when synchronous time is the scarce resource. A simple rule works: no agenda, no meeting. Use async updates for status, and save live time for the two things that need it, which are decisions and human connection. Cameras deserve the same care. The workable version is a norm the team agrees by consent, not a rule management imposes; a common landing point is cameras on for the first few minutes to say hello, then optional. Mandating cameras tends to signal distrust, which is the opposite of what a remote team needs.
## Hybrid: the two-tier problem
Hybrid is where remote dynamics get hardest, because the default hybrid meeting has two tiers. The people in the room make eye contact, catch the side comments, and dominate the conversation, while the people on the screen watch a distant camera and struggle to break in. Left alone, hybrid quietly recreates proximity bias in real time. Four moves flatten it:
- **One person, one screen.** If anyone is remote, everyone joins from their own laptop, so the meeting has one tier instead of two.
- **Call on remote people first.** A facilitator who states the norm up front and brings in remote voices by name before the room takes over resets the balance.
- **Put the work in a shared space.** A shared doc or board that everyone can edit beats a whiteboard only the room can see.
- **Evaluate by output, not visibility.** Judge people on what they produce, not on how often you see them at a desk. This is the structural antidote to proximity bias, and it is the one that changes who gets promoted.
## Remote is different, not worse
Here is the honest limitation, and it cuts in remote's favor. The most rigorous evidence we have says remote and hybrid work are different, not worse. In a randomized controlled trial published in *Nature* in 2024, Stanford's Nicholas Bloom and colleagues put 1,612 employees at Trip.com on a hybrid schedule of two work-from-home days a week. Over two years, hybrid working cut quit rates by about a third, from 7.2 percent to 4.8 percent, improved job satisfaction, and had [no effect on performance grades or promotions](https://www.nature.com/articles/s41586-024-07500-2). Retention improved and output held.
An earlier Bloom randomized trial at Ctrip, [published in 2015](https://www.nber.org/papers/w18871), found a 13 percent productivity gain from working from home and roughly halved attrition. (The often-quoted "15 percent" figure is a misreading of that study; the number is 13 percent.) That 2015 trial also caught an early warning about proximity bias: promotion rates conditional on performance fell for home workers, the same pattern the promotion data still shows today.
So the trade is real, but it is a trade rather than a loss. Remote buys you deep-focus time, durable documentation, the inclusion of quieter and asynchronous voices, and access to talent regardless of geography. It taxes spontaneous connection and the easy sense of belonging a shared room provides, and it makes cross-team serendipity something you now have to engineer. The rituals above are the payment for that tax. They are the work, not overhead.
## Make the informal deliberate
The thread through all of this is the same. In an office, connection and context are byproducts of sharing space. Remove the space and they stop being free, so a distributed team has to produce them on purpose. That sounds like more work because it is, but it is work with a payoff: teams that write their norms down and schedule the connection they used to get for free tend to be more inclusive and more durable than the office they replaced.
It also has to be a cadence rather than a one-off. A single kickoff offsite wears off. What lasts is a rhythm. A regular check-in keeps people connected. A recurring [health check](/health-checks/) surfaces a slipping sense of belonging before it turns into attrition, and a [remote retrospective](/guides/scrum-masters-retrospective-guide/why-remote-retrospectives-are-key/) turns friction into a concrete change. The change then has to land. Across a sample of hundreds of thousands of retrospective action items, TeamRetro's own Follow-Through Index found that about 73 percent get completed, which is the difference between a team that talks about its remote problems and one that fixes them.
Distributed teams also start colder than co-located ones, and they take longer to build the trust that makes candor possible. It helps to be deliberate about warming up a new or distributed group. Our chapters on [how to defrost a team](/guides/team-dynamics/how-to-defrost-a-team/) and [building trust and psychological safety](/guides/team-dynamics/building-trust-and-psychological-safety/) go deeper on both.
## Frequently asked questions
### What are remote team dynamics?
Remote team dynamics are the forces that decide how well a distributed team works together, like trust and communication, operating without a shared office to carry them. The forces are the same as any team's, but distance strips out the accidental contact that builds them, so remote teams have to create connection deliberately instead of absorbing it from a shared space.
### Are remote teams less productive than in-office teams?
No. The most rigorous evidence shows no productivity penalty. A 2024 *Nature* randomized controlled trial led by Stanford's Nicholas Bloom found hybrid work cut quit rates by about a third with no measurable effect on performance or promotions. Remote work is different from office work, not worse. It trades spontaneous connection for gains in focus and retention, which is why the connecting rituals matter.
### What is proximity bias and how do you reduce it?
Proximity bias is the tendency to favor the people you can see. In a 2022 Envoy survey, 96 percent of leaders admitted they notice in-office contributions more than remote ones. You reduce it structurally: give everyone their own screen in hybrid meetings, and judge people by their output rather than how visible they are at a desk.
### What is the hardest part of remote teamwork?
It is human, not technical. Buffer's 2023 State of Remote Work found the top struggles were spending too much time at home, loneliness, not unplugging, and working across time zones, while technical collaboration difficulty had fallen year on year. The tools are largely solved. Belonging and boundaries are the real work, and they respond to norms and rhythm rather than software.
---
# How to choose a retrospective template
URL: https://www.teamretro.com/guides/scrum-masters-retrospective-guide/retrospective-templates/
A retrospective template is a ready-made board of prompts that guides your team's reflection and captures their responses in one place. The right template depends on what you want to achieve, and this chapter helps you choose, with 15 hand-picked examples for people, process, product, bad sprints, and fun, drawn from TeamRetro's [library of 250+ free retrospective templates](/retrospective-templates/).
## What is a retrospective template?
A retrospective template is both a guide for and a record of a retrospective meeting. It takes the form of a board that includes simple prompts designed to facilitate a team's reflection of their last sprint. It is also where responses to those prompts can be captured. Once the retrospective template is populated, it is then used as the foundation for discussions that will shape the team's next steps.
Retrospective templates can come in a variety of forms. They can be built using whiteboards and markers, flip charts and pens, or even windows with post-its. They can be delivered online using a range of collaborative tools from virtual whiteboards to the [online retrospective templates curated by TeamRetro](/retrospective-templates/).
## Why are retrospective templates important?
Retrospective templates are important because they help to maximize the success of the retrospective meeting. As mentioned in [Chapter Two – Why are retrospectives a useful agile tool?](/guides/scrum-masters-retrospective-guide/why-retrospectives-a-useful-agile-tool/) – the meeting is a chance for the team to come together to reflect on their sprint. During the meeting, they share, explore and propose ideas that will help them improve. This came with the caveat that the retrospective must be run with intention and focus, as well as be engaging and time-efficient. The retrospective template is the tool that helps to deliver that intent, focus, engagement, and efficiency.
As well as supporting all five of Derby and Larsen's sprint retrospective process steps that we touched upon in [Chapter 1 – What is a sprint retrospective?](/guides/scrum-masters-retrospective-guide/what-is-a-sprint-retrospective/) – a retrospective template delivers a lot of value. A template:
- helps set the tone of the meeting
- provides a framework for ideation and discussion
- allows all participants to contribute equally, so it encourages engagement, fosters collaboration, and supports equity
- provides focus and reinforces the purpose of the meeting
- facilitates the easy capture of ideas
When delivered online, retrospective templates are particularly beneficial. As well as delivering the above value, they can also:
- deliver a clear structure that supports a transparent meeting process
- allow participants to contribute anonymously. This helps to address group-think, ensure all voices are heard, and support psychological safety
- automatically capture ideas and comments inputted by participants, significantly streamlining the meeting documentation process
- automatically generate reports that can be shared with all participants
- be used online with co-located, remote, and hybrid teams
Additionally, a template can be leveraged to:
- energize the team
- support team connectedness and team building
- reinforce the Scrum Values
- open the lines of communication to safely address issues
or even:
- help make the meeting fun
In short, the impressive range of retrospective templates available can help a Scrum Master address an equally impressive number of anti-patterns and team issues.
## Why change retrospective templates?
There are two important reasons a Scrum Master should regularly change the retrospective template they use. First of all, change itself is valuable for the team. Secondly, different retrospective templates can help to deliver different benefits.
Change helps us improve. It helps us progress, develop and deliver new things. It offers us variety and fresh perspectives that spark creativity. In a nutshell, change helps us grow.
Simply by changing the template used to support a retrospective meeting, a Scrum Master can offer their team a fresh lens through which they can view their last sprint. With a different template, the team is gently calibrated to consider different words, phrases, and fresh perspectives.
At the same time, the Scrum Master helps to side-step the potential monotony sometimes inherent in regular meetings. This also helps mitigate the risk of team members allowing their 'retro autopilot' to kick in; when they offer standard or clichéd feedback rather than considered and creative responses.
## How do I choose the right retrospective template for my meeting?
Choosing the right retrospective template boils down to what you hope to achieve with your team during your Sprint Retrospective.
Your choice of retrospective template can be informed by a number of factors. One approach is to consider where you wish the team to focus:
- People (this includes communication and connectedness)
- Process (how you do what you do)
- Product (the vehicle to deliver value)
Another approach is to consider context:
- That of the team (interests, maturity, size, diversity)
- That of the Scrum Master (new to Scrum, highly experienced)
- That of the last sprint (everything went wrong, it was ok, it was great)
The choice of template could also be behaviorally based:
- Specific anti-patterns you wish to address
- Aspects of psychological safety you wish to support
- Elements of play you hope to foster
Of course, all good templates should deliver meetings that are: engaging and focused; relevant and purposeful; and productive and fun.
## The retrospective template to use if you've never retro'ed before
If you're preparing to run your first retrospective you can't go past the Agile retrospective template.
Agile: The Agile retrospective asks four basic questions that get the team thinking about the outcomes of the last sprint, and what actions they should focus on next. While it is straightforward, it sends a clear message that you are listening and geared for improvement.
## Great retrospective templates to use to support people
A supported team is a productive team. Here are three of the templates we use that deliver effective meetings and shine a spotlight on team empowerment and support.
Four Ls: The Four L's retrospective presents your team with the opportunity to share both thoughts and feelings about their last sprint in a safe way. You can use it to gain insight into how they prefer to be supported and their aspirations.
Personal Growth: The Personal Growth retrospective has been designed to support the empowerment and well-being of your team members. It gives each team member the space to set goals and identify how others can support their efforts.
Scrum Values: The Scrum Values retrospective is a deep dive into the behaviors and actions each person takes in their daily life and work practices that reflect the values of Scrum. It's an opportunity to explore the connection between the Scrum Values and those of the team.
## The best retrospective templates to use to support the process
When things aren't progressing as well as planned it might be time to look at processes. These are three of the templates we use when it comes to process. They help us drill down into what's happening and help us shape steps to get things back on track.
Stop Start Continue: The Start Stop Continue retrospective throws processes into sharp focus. It's a great tool to hone in on actions and quickly identify those that deliver value and those that don't.
KALM: The KALM retrospective creates a safe space in which a team can fine-tune its processes. It promotes a sense of agency and utility allowing the team to come up with ideas to help them move forward.
Starfish: The Starfish retrospective supports an examination of the varying degrees of value delivered by actions and activities. It helps the team look at current practices and which ones should have more or less energy directed toward them.
## The best retrospective templates to support product management
A Scrum Team's purpose is to deliver outputs that address the requirements of Stakeholders. Product management, therefore, is core to their success.
Must Should Could Won't: The Must Should Could Won't retrospective is a great tool that offers the team a mechanism to step into the shoes of a customer and view the product from their perspective. It is a particularly useful tool to maintain focus on priorities for projects with a large number of feature requests and competing stakeholders.
Three Little Pigs: The Three Little Pigs retrospective offers your team a creative sprint retrospective idea to help identify short, medium, and long-term actions that will bring stability and value-added features to your product. It helps analyze the current product or technology stack and which elements can be easily broken, need fixing up, or are part of the foundational core to deliver your service.
Rose Bud Thorn: The Rose, Bud, Thorn retrospective is an effective technique designed to help identify the positive outcomes, the opportunities, and the challenges from your last sprint. This is a great retrospective to use if you wish to help remind your team to view challenges as manageable accompaniments to the delivery of value.
## Great retrospectives to use if you've had a bad sprint
We're human. We will have good days and bad days. Our team will have good sprints and bad sprints. When it comes to the bad, the important thing is we learn from them.
What? So what? Now what?: The What, so what, now what? retrospective was designed to bring a neutral pragmatism to the review of a sprint. It helps your team suspend emotion and side-step bias in order to create a safely objective space to conduct your retrospective.
Working Not Working: The Working Not Working retrospective gets straight to the point. Its simplicity makes it impactful. If your team needs a direct approach to get them moving again, then this is the retrospective template you should use.
And when the sprint went wrong but nobody quite agrees why, run a root cause analysis before you pick fixes. The [Fishbone (Ishikawa) retrospective](/retrospective-templates/fishbone-ishikawa-retrospective/) maps the causes behind a problem (people, process, tools) using the classic Ishikawa diagram, so your team debates the actual cause rather than the loudest theory.
## Easy retrospectives to use when it's time to have fun
Bringing an element of play into the workplace has been shown to deliver a myriad of benefits. It helps build teams and even supports individual well-being. For more ways to lighten the meeting without losing the point, see our [fun and easy retrospective ideas](/blog/fun-and-easy-retrospective-ideas/).
Witches and Warlocks: The Witches and Warlocks retrospective has been deliberately crafted to position team members to adopt an optimistic view of the sprint. It's a sprint retrospective idea that shows creativity and fun bring value to a project, and can be embraced without sacrificing productivity, focus or purpose.
Oscar Academy: The Oscar Academy retrospective creates a stage where people can learn from stories, are recognized for their contributions, and celebrate their successes. It embraces deliberate cheerfulness as a gentle reminder to team members to adopt a perspective of optimism when reflecting on the sprint.
Superhero: The Superhero retrospective is a fun, creative exercise that can be especially engaging for remote teams that have to come together to solve a common problem or work toward a goal. Of course, each team has its own set of superpowers, but they will also have their vulnerabilities and this retrospective template can help uncover these.
## Frequently asked questions
### What is a retrospective template?
A retrospective template is a ready-made board of prompts that guides a team's reflection and captures their responses in one place. It both structures the meeting (the questions the team answers) and records its output (the ideas, themes, and actions), which becomes the basis for the team's next steps.
### How do I choose the right retrospective template?
Start from what you want to achieve. Choose by focus (people, process, or product) or by context, such as how the last sprint went and how experienced the team is. A simple format like the Agile or Start/Stop/Continue retrospective suits new teams; themed or playful templates help re-energize teams that have fallen into autopilot.
### Should you use the same retrospective template every time?
No. Changing the template regularly keeps the meeting fresh and surfaces different insights, because each format frames the sprint through a different lens. Reusing one template indefinitely invites "retro autopilot," where people give standard answers instead of considered ones. Rotating templates is one of the simplest ways to keep retrospectives engaging.
---
# Running the AI collaboration retro
URL: https://www.teamretro.com/guides/ai-agent-retrospectives/running-the-ai-collaboration-retro/
*At TeamRetro we're interested in every continuous-improvement cycle a team runs. AI-assisted work is a new area we've been thinking through via our retrospective lens; this guide shares where we've landed so far. Take it, adapt it, run it in whatever tool or ceremony you already have.*
## Part 1: the guide
### Why this belongs in a team ceremony
Somewhere on your team this month, an AI assistant spent forty minutes auditing a "broken" ad campaign that had been deliberately paused, because the brief didn't say so. The person running the session corrected it, shrugged, and moved on. If four colleagues hit versions of the same gap, that's hours of silent waste per month, and nobody knows, because each person absorbed it alone.
That's the pattern with AI-session friction: it's chronic and minor, so it never triggers a postmortem, and it's ephemeral, so it evaporates when the session ends. Most teams can already *watch* it (around 90% instrument their agent traces), but far fewer turn it into fixes: only about 37–52% systematically evaluate what they capture ([LangChain, Jun 2026](https://www.langchain.com/state-of-agent-engineering)).
The improvement loops that do exist are good, and this practice builds on all of them: `AGENTS.md` and context-file updates, memory systems, vendor self-improvement pipelines, error analysis on traces ([Husain & Shankar, evals FAQ](https://hamel.dev/blog/posts/evals-faq/)). Even the vendors reach for the retro word: OpenAI's Codex guidance reads *"when Codex makes the same mistake twice, ask it for a retrospective and update AGENTS.md"* ([best practices](https://learn.chatgpt.com/guides/best-practices)). But nearly all of these loops are solo: one person and their agent, or one platform and its fleet. What the team layer adds is **aggregation**: friction that's five shrugged-off minutes per person becomes a top team cost only in the aggregate view, and acting on it (rewrite the shared template, change the intake process, buy the tool) needs a decision ceiling no individual has. Rahul Garg's Feedback Flywheel names the venue, *"an agenda item in the existing sprint retrospective: what worked with AI this sprint?"* ([martinfowler.com](https://martinfowler.com/articles/reduce-friction-ai/feedback-flywheel.html)), and this guide is one way to run it.
One honest concession up front: what this needs is a recurring, blameless, evidence-fed ceremony with the fix-owners in the room. For most teams that's the [retro](/retrospectives/), but a sprint planning slot, a monthly ops review, or a media team's account review can host it just as well. The retro, or your existing ceremony of equivalent shape.
Worth knowing as a facilitator: Scrum.org approaches the same territory from the metrics side; their [guide to running the sprint retrospective when half your team is AI agents](https://www.scrum.org/resources/blog/how-run-sprint-retrospective-when-half-your-team-ai-agents) reframes the event as a data-driven review of agent performance (prompt rewrites, deviation rates, token burn). This guide takes the complementary path: root causes and fixes across the whole collaboration, with the agents contributing their own account of the work, filed via the [TeamRetro MCP server](/mcp/) if you use TeamRetro. Teams with heavy agent fleets may want elements of both.
### How the practice works, end to end
1. **Capture, per session.** At the end of each substantial AI-assisted session, the agent writes a [short structured entry](/guides/ai-agent-retrospectives/ai-friction-records/): what went well, what dragged (each item labeled with a root cause and a proposed fix), what it guessed, and the single highest-leverage fix. One file per entry, in a shared log.
2. **Synthesize, after ~5 entries.** Before the ceremony, the agent condenses the log into a one-page brief: recurring themes ranked by frequency × cost, a root-cause distribution, a check on whether past fixes were adopted, and the top three recommended actions.
3. **Decide, in 15 minutes.** The brief is one agenda item in your existing retro, not a new meeting. The team triages: keep or kill each friction, confirm where each fix should land, assign owners to the top actions. Next cycle's brief reports whether the friction actually dropped.
The capture and synthesis steps are implemented as open-source agent skills in our [teamretro-skills repo](https://github.com/TeamRetroHQ/teamretro-skills) if you want a running start.
The agent reports ungated: an agent that needs permission to record friction [under-reports](/blog/gather-feedback-from-ai-agents/), and human corrections after the fact are additive signal, not a checkpoint the loop waits on. Judgment stays with the team, and not as a courtesy: the fixes land in budgets, documents, processes, and tools that people own and answer for. The agent brings evidence and drafts; the room decides.
### What a good entry looks like
Here's a real-shaped example, deliberately not a coding session:
```markdown
# 2026-07-16: Monthly ads account review
**Session size:** ~25 turns, 1 deliverable
**Outcome:** shipped
## Went well
- Exec summary shipped in one pass; the account structure doc from last month held up
## Friction
- **[missing-context]** The brief didn't say the French campaigns were deliberately
paused for Q3; ~40 min (est.) auditing a "broken" campaign that was fine.
→ Fix (altitude: process): add campaign-status flags to the monthly brief template
## Guesses made
- Assumed the target CPA unchanged from June, unverified
## Do this first
Campaign-status flags in the brief template. Kills the largest single time sink this month.
```
Notice the discipline. Every friction item cites a moment and a cost (soft estimates marked `(est.)`), carries exactly one root-cause label from a small fixed vocabulary (labels like `ambiguous-instruction`, `missing-context`, `missing-documentation`, `missing-access-or-tool`, `agent-error`, or `work-material-friction`, where the material itself was the drag: a tangled campaign structure, a legacy spreadsheet, a module nobody wants to touch, always with the concrete material named), and ends with a ticket-sized fix that names its [**altitude**](/guides/ai-agent-retrospectives/where-should-the-fix-land/): does this fix belong in a private memory note, a procedure, the environment, the docs, the work material itself, the process, or upstream with a vendor? Fixed labels are what make entries comparable across people and sessions; "the docs were confusing" can't be aggregated, but eight `missing-documentation` entries can. Vague is the failure mode; "nothing notable" is a valid entry.
A good **brief** is one page: themes with prevalence ("4 of 9 sessions") and dated examples, a plain statement of which root-cause group dominates (briefing, documentation, work material, tooling, or agent; that's where the team's attention should go), the adoption check on past suggestions, and three owner-assignable actions. It feeds the conversation; it doesn't replace it.
The check that turns a report into a loop: last cycle's fix set beside this cycle's brief: adopted and the friction gone, or the same note back again because nothing shipped.
### Scope: one log per review scope
Keep one log per **review scope**: the boundary where fixes would land. For dev work that's usually the repo, because its docs, config, and conventions live there. For non-code work it's the ads account, the support inbox, the client engagement; the log lives in that workspace's document home. An entry filed outside its scope is one the eventual fix-owner never finds. The schema stays identical everywhere; the schema, not the storage, is what makes entries aggregate.
### The never-log rules
Entries are committed, shared, and outlive their context, so some things never go in one: secrets, credentials, or keys in any form; customer data or personal information; unreleased business figures; and, most important for retro culture, **names, roles, or anything that identifies a person**. Describe the gap and what it cost, never who caused it: "the brief left the audience open," not "X's brief." Friction items critique inputs and systems, not people. If a scope's friction can't be described without sensitive context, keep those entries private and share only the aggregated brief.
## Part 2: the "AI Collaboration Retro" template
A ready-to-use format: five prompts, grounded in the entry schema, runnable in [TeamRetro](/retrospectives/) or on any whiteboard:
| Column | Prompt | One-liner |
|---|---|---|
| **Went well** | What did AI-assisted work make faster or better this cycle? | Evidence-cited wins only: what to protect and repeat, not praise-padding. |
| **Friction, with the cause** | Where did it drag, and which root cause was it? | Each card names the moment, the rough cost, and one label from the team's fixed vocabulary. |
| **Guesses we let stand** | What did the agent (or we) assume without enough information? | Latent friction that hasn't hurt yet; flag anything still unverified. |
| **Keep or kill** | Which of these frictions did we choose on purpose? | Review gates and approval steps can be deliberate control points ([recap of Ronacher's AIE Europe talk](https://www.youtube.com/watch?v=_Zcw_sVF6hU)); removing one is a team decision. |
| **Do this first** | Of everything here, which one fix pays off most, and at what altitude? | Top three max, each with an owner and the level it lands at: docs, environment, process, material, or upstream. |
Not all friction is waste. Some of it is a control point the team chose on purpose. Triage sorts the deliberate from the disposable before anything gets "fixed."
## Part 3: facilitator prompt cards
Questions to ask when a team brings an AI-retro brief to the ceremony. One per card; use the ones the conversation needs.
1. **"Which session is this from, and what did it cost?"** Pattern claims need dated evidence; a card without a moment and a cost can't be triaged.
2. **"Is this friction a control point we chose?"** Keep-or-kill first: some friction is the steering ([recap of Ronacher's AIE Europe talk](https://www.youtube.com/watch?v=_Zcw_sVF6hU)), and frictionless isn't free; Thoughtworks warns of the cognitive debt it accrues ([announcement](https://www.thoughtworks.com/about-us/news/2026/combat-ai-cognitive-debt-radar-v34)).
3. **"We suggested this fix last time. What stopped it?"** Unadopted repeat suggestions are the highest-signal item in any brief; without this question the flywheel is theatre.
4. **"This cost each of you ten minutes, what does it cost the team per month?"** Aggregation is the team layer's whole edge; ask it whenever a card gets shrugged at.
5. **"Does this fix belong in the docs, the environment, or how we brief the work?"** The altitude question. Under-target and the friction recurs; over-target and you bloat the wrong artifact.
6. **"Who owns the artifact this fix lands in?"** An action without an owner is a wishlist item. If the owner isn't in the room, that's a finding too.
7. **"Before we call this the agent's error, were its inputs adequate?"** `agent-error` is the residual label, not the default; the default worth rejecting is blaming the agent when the harness or the brief was the problem, so fix the harness instead ([Osmani, *Agent Harness Engineering*](https://addyosmani.com/blog/agent-harness-engineering/)).
8. **"Which root-cause group dominates the distribution, and is that where our attention is going?"** The brief's counts tell you whether the problem is briefing, documentation, the work material, tooling, or the agent setup. Attention should follow the data.
9. **"Did a person catch this, or did the agent?"** Human correction is still the dominant sensor: one production study found ~70% of silent failures were first caught by a person noticing something off ([arXiv 2606.14589](https://arxiv.org/abs/2606.14589)). Treat those catches as first-class evidence, not interruptions.
10. **"Is this our scope's friction, or another team's?"** Fixes land at their review scope; a card about the shared template or another team's process should be routed, not absorbed.
11. **"Is this a discussion or a filing?"** The obvious fixes go straight to the tracker; spend the fifteen minutes only on the contested calls: keep-or-kill, altitude disputes, priorities.
12. **"Is this decision above any one of us?"** Buying a tool, changing intake, escalating to a vendor: the reweighted priority list often crosses the individual decision ceiling. Naming that is why the item is in the room at all.
---
**Next chapter:** [Get started in ten minutes](/guides/ai-agent-retrospectives/get-started/). Install the skills and run your first capture, or take the template above to whatever board your team already uses. Part of the [AI agent retrospectives guide](/guides/ai-agent-retrospectives/).
---
# The three Scrum artifacts
URL: https://www.teamretro.com/guides/scrum-masters-retrospective-guide/scrum-artifacts/
Scrum has three artifacts: the **Product Backlog**, the **Sprint Backlog**, and the **Increment**. Each one represents work or value, and each exists to create **transparency**, so the team and its stakeholders share the same honest picture of what is planned, in progress, and done. In the 2020 [Scrum Guide](https://scrumguides.org/), every artifact also carries a *commitment* that keeps it focused.
## The three Scrum artifacts and their commitments
### The Product Backlog: commitment to the Product Goal
The Product Backlog is the single, ordered list of everything that might be done to improve the product. It is owned by the Product Owner, and it is never complete. It evolves as the product and its market change. Its commitment, the **Product Goal**, describes the longer-term objective the team is working towards, so the backlog is always ordered in service of something concrete.
### The Sprint Backlog: commitment to the Sprint Goal
The Sprint Backlog is what the Developers select from the Product Backlog for the current sprint, plus their plan for delivering it. Its commitment is the **Sprint Goal**, the single objective for the sprint that gives the work coherence and helps the team make trade-offs when reality intervenes. The Sprint Backlog is the team's own plan, updated throughout the sprint as it learns more.
### The Increment: commitment to the Definition of Done
The Increment is a usable, valuable step toward the Product Goal, the sum of all the completed work. Its commitment is the **Definition of Done**, the shared standard a piece of work must meet to count as complete (for example: reviewed, tested, documented, deployable). Work that does not meet the Definition of Done is not part of the Increment. Teams often revisit and tighten their Definition of Done in the [retrospective](/guides/scrum-masters-retrospective-guide/what-is-a-sprint-retrospective/).
## How the artifacts create transparency
The artifacts are not paperwork. They are how Scrum stays honest. Each is inspected at a [Scrum ceremony](/guides/scrum-masters-retrospective-guide/scrum-ceremonies/): the Product Backlog at refinement and planning, the Sprint Backlog at the Daily Scrum, and the Increment at the Sprint Review. When the artifacts are kept transparent and their commitments are clear, the team's inspect-and-adapt loop works; when they are vague or out of date, decisions are made on bad information. That is why keeping the Definition of Done meaningful is a frequent and valuable retrospective topic.
## Frequently asked questions about the Scrum artifacts
### What are the three Scrum artifacts?
The three Scrum artifacts are the Product Backlog, the Sprint Backlog, and the Increment. Each represents work or value and is designed to maximize transparency, so the whole team and its stakeholders share the same understanding of what is planned, what is in progress, and what is done.
### What are the commitments for each Scrum artifact?
Each artifact has a commitment that gives it focus. The Product Backlog's commitment is the Product Goal, the Sprint Backlog's commitment is the Sprint Goal, and the Increment's commitment is the Definition of Done. These commitments were added in the 2020 Scrum Guide to strengthen transparency and keep each artifact pointed at a clear outcome.
### What is the difference between the Product Backlog and the Sprint Backlog?
The Product Backlog is the single, ordered list of everything that might be done on the product. It is owned by the Product Owner and is never finished. The Sprint Backlog is the subset the Developers select for the current sprint, plus their plan for delivering it and the Sprint Goal. In short, the Product Backlog is the whole roadmap of possibilities; the Sprint Backlog is this sprint's committed slice.
### What is the Definition of Done?
The Definition of Done is the shared standard a piece of work must meet to be considered complete, the commitment attached to the Increment. It might include code reviewed, tested, documented, and deployable. A clear Definition of Done prevents "done but not really done" work and is something teams often revisit and tighten in their retrospectives.
## Related reading
- [The four Scrum ceremonies explained](/guides/scrum-masters-retrospective-guide/scrum-ceremonies/): where each artifact is inspected.
- [The three Scrum roles](/guides/scrum-masters-retrospective-guide/scrum-roles/): who owns each artifact.
---
# The four Scrum ceremonies explained
URL: https://www.teamretro.com/guides/scrum-masters-retrospective-guide/scrum-ceremonies/
The four Scrum ceremonies are **Sprint Planning**, the **Daily Scrum**, the **Sprint Review**, and the **Sprint Retrospective**. Each one has a clear purpose, a fixed timebox, and a defined set of attendees, and together they give a Scrum team its regular rhythm of planning, coordinating, demonstrating, and improving.
A quick note on names: the current [Scrum Guide](https://scrumguides.org/) calls these meetings *events* rather than *ceremonies*, and it counts five, because the Sprint itself is the container that holds the other four. Most teams still say "ceremonies" out of habit, and this chapter uses the two words interchangeably. What matters is not the label but understanding what each meeting is for.
## What is a Scrum ceremony?
A Scrum ceremony is a regular, timeboxed meeting that gives a Scrum team a predictable structure for its work. Rather than calling meetings ad hoc, the team agrees a fixed set of ceremonies that recur every Sprint. This consistency is the point: it removes the overhead of deciding when to meet, it makes sure the important conversations actually happen, and it creates the cadence of *inspect and adapt* that Scrum is built on.
The Sprint is a fixed-length period of work, usually one to four weeks and most often two, and the four ceremonies bookend and punctuate it. Planning opens the Sprint, the Daily Scrum keeps it on track, and the Review and Retrospective close it.
## The four Scrum ceremonies
### 1. Sprint Planning
**Purpose:** to agree what the team will deliver in the coming Sprint and how. The team selects items from the Product Backlog, shapes a Sprint Goal, and forms an initial plan for the work.
**Timebox:** up to about four hours for a two-week Sprint (longer for a longer Sprint).
**Who attends:** the whole Scrum Team: the Developers, the Product Owner, and the Scrum Master.
Sprint Planning answers three questions: *why* is this Sprint valuable (the Sprint Goal), *what* can be done this Sprint, and *how* will the chosen work get done. Sizing the selected items is part of this conversation, and many teams use [Planning Poker, a free agile estimation tool](/guides/agile-estimation-guide/estimation-techniques/), to reach a shared estimate quickly.
### 2. The Daily Scrum
**Purpose:** a short daily check-in for the Developers to inspect progress toward the Sprint Goal and adapt the plan for the next 24 hours. It is about coordination, not status reporting to a manager.
**Timebox:** 15 minutes, every working day, regardless of Sprint length.
**Who attends:** the Developers. The Product Owner and Scrum Master attend if they are working on Sprint Backlog items.
The Daily Scrum is also known as the **daily standup**, a name that comes from the habit of holding it standing up to keep it short.
### 3. The Sprint Review
**Purpose:** to inspect the *outcome* of the Sprint and decide what to do next. The team demonstrates the work it has completed and gathers feedback from stakeholders, which may lead to adjusting the Product Backlog.
**Timebox:** up to about two hours for a two-week Sprint.
**Who attends:** the Scrum Team plus key stakeholders invited by the Product Owner.
The Sprint Review is a working session, not a one-way presentation. Its value is the conversation and feedback it produces.
### 4. The Sprint Retrospective
**Purpose:** to inspect how the last Sprint went in terms of people, relationships, process, and tools, and to plan improvements for the next Sprint. Where the Review looks at *the product*, the retrospective looks at *the way the team works*.
**Timebox:** up to about 90 minutes for a two-week Sprint.
**Who attends:** the Scrum Team.
The retrospective is the team's main engine of continuous improvement. It is where the team turns reflection into a short list of concrete actions. The rest of this guide is dedicated to running it well; start with [Chapter 1: What is a sprint retrospective?](/guides/scrum-masters-retrospective-guide/what-is-a-sprint-retrospective/) for a full breakdown, and see [how to choose a retrospective template](/guides/scrum-masters-retrospective-guide/retrospective-templates/) when you are ready to run one.
## How the ceremonies fit together
The four ceremonies form a loop. Sprint Planning sets the direction, the Daily Scrum keeps the team coordinated day to day, the Sprint Review checks the product against stakeholder needs, and the Sprint Retrospective improves the team itself, feeding directly back into the next round of planning. Run consistently, this loop is what lets a Scrum team inspect and adapt rather than repeat the same mistakes Sprint after Sprint.
## Frequently asked questions about Scrum ceremonies
### What are the four Scrum ceremonies?
The four Scrum ceremonies are Sprint Planning, the Daily Scrum (or daily standup), the Sprint Review, and the Sprint Retrospective. Together they create a regular rhythm of planning, coordinating, demonstrating, and improving across every Sprint. The Sprint itself is sometimes counted as a fifth event because it is the container that holds the other four.
### Are Scrum ceremonies the same as Scrum events?
Yes. "Ceremony" is the older, informal word and "event" is the term used in the current Scrum Guide, but they refer to the same set of meetings. You will hear teams use both interchangeably for Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective.
### How long should each Scrum ceremony take?
Timeboxes scale with the length of the Sprint. For a typical two-week Sprint, Sprint Planning runs up to about four hours, the Daily Scrum is 15 minutes, the Sprint Review runs up to about two hours, and the Sprint Retrospective runs up to about 90 minutes. A one-month Sprint roughly doubles the planning, review, and retrospective timeboxes; the Daily Scrum stays at 15 minutes regardless of Sprint length.
### Is the Sprint Retrospective a Scrum ceremony?
Yes. The Sprint Retrospective is one of the four Scrum ceremonies and the last event of each Sprint. It is the team's dedicated opportunity to inspect how the last Sprint went (people, process, and tools) and to agree on concrete improvements for the next one. The other three ceremonies focus on the work; the retrospective focuses on the way the team works.
## Related reading
- [Agile ceremonies: the complete guide](/guides/agile-ceremonies-guide/): each ceremony explained on its own page, plus backlog refinement and the events-vs-ceremonies question.
- [Nine top agile retrospective ideas and games](/blog/nine-top-agile-retrospective-ideas-and-games-to-keep-your-team-engaged/): formats to keep the retrospective fresh.
- [The seven habits of highly successful Scrum Masters](/blog/top-7-habits-of-highly-successful-scrum-masters-and-agile-teams/): what great facilitators do across all four ceremonies.
- [What is a Scrum Master, and why does the role matter in a retrospective?](/blog/what-is-a-scrum-master-and-why-is-their-role-so-important-in-a-retrospective/)
---
# Scrum events vs ceremonies: the terminology, and whether there are four or five
URL: https://www.teamretro.com/guides/agile-ceremonies-guide/scrum-events-vs-ceremonies/
"Ceremonies" and "events" are the same meetings under two different names. *Event* is the word the current [Scrum Guide](https://scrumguides.org/) uses; *ceremony* is the older, colloquial term teams still say out of habit. Neither is more correct, and the distinction only matters in one place: the count. Ask how many agile ceremonies there are and you'll hear "four" from one person and "five" from the next. Both are right. They're counting different things.
## Events or ceremonies: does the word matter?
Not really. The 2020 Scrum Guide dropped "ceremony" in favor of "event," partly for precision and partly because "ceremony" oversells what is, in practice, a set of working meetings. But the industry didn't follow in lockstep: Atlassian, Asana, and most teams still say "ceremonies" day to day.
Use whichever your organization uses. If you're writing something formal or studying for certification, "events" is the current term. In a standup, nobody will correct you for saying "ceremony." What's worth getting right isn't the label; it's understanding what each meeting is *for*, which is what the rest of [this guide](/guides/agile-ceremonies-guide/) covers.
## Four or five? The sprint is the fifth
Here's the source of the disagreement.
Four meetings sit inside one container. Count only the meetings and you get four ceremonies; count the sprint that holds them and you get five events. The Scrum Guide counts five.
The four meetings everyone agrees on are **sprint planning**, the **daily scrum**, the **sprint review**, and the **sprint retrospective**. When someone says "the four agile ceremonies," they mean these.
The Scrum Guide, though, lists **five events**, because it counts the **sprint itself** as an event: the fixed-length container that holds the other four. It isn't a meeting; it's the timebox the meetings punctuate. So "five" adds the sprint to the four; "four" leaves it out because it isn't something you sit down for. Once you see that, the argument evaporates: one side is counting meetings, the other is counting events, and the Scrum Guide is firmly on the side of five.
Some guides (Asana's among them) get to a different fifth by adding [backlog refinement](/guides/agile-ceremonies-guide/backlog-refinement/) to the four meetings. That's defensible in spirit (refinement is real, recurring work), but it isn't how the Scrum Guide counts, because refinement is an ongoing activity, not a formal event.
## The five events, at a glance
Each links to its full treatment:
| Event | Purpose | Timebox (2-week sprint) |
|---|---|---|
| **The sprint** | The container: a fixed-length cycle of work | 1–4 weeks (the container) |
| [**Sprint planning**](/guides/agile-ceremonies-guide/sprint-planning/) | Agree the goal and the plan | Up to ~4 hours |
| [**Daily scrum**](/guides/agile-ceremonies-guide/the-daily-standup/) | Re-plan the day toward the goal | 15 minutes |
| [**Sprint review**](/guides/agile-ceremonies-guide/sprint-review/) | Show the product, gather feedback | Up to ~2 hours |
| [**Sprint retrospective**](/guides/agile-ceremonies-guide/sprint-retrospective/) | Improve how the team works | Up to ~90 minutes |
For a per-ceremony explainer of the four meetings on a single page, the retrospective guide's [four Scrum ceremonies](/guides/scrum-masters-retrospective-guide/scrum-ceremonies/) covers them together.
## The 3-5-3 rule, and where the events fit
If you've heard the **3-5-3 rule**, it's a mnemonic for the whole shape of Scrum, and the events are the middle number:
- **3 roles**: the product owner, the scrum master, and the developers. See [Scrum roles](/guides/scrum-masters-retrospective-guide/scrum-roles/).
- **5 events**: the five above.
- **3 artifacts**: the product backlog, the sprint backlog, and the increment. See [Scrum artifacts](/guides/scrum-masters-retrospective-guide/scrum-artifacts/).
It isn't a rule the Scrum Guide states, but it's a fair map: roles are *who*, events are *when*, artifacts are *what*. Some versions extend it to 3-5-3-3 by adding the three commitments (the product goal, the sprint goal, and the definition of done). And underneath all of it sit the [five Scrum values](/guides/scrum-masters-retrospective-guide/scrum-values/): commitment, courage, focus, openness, and respect. Those are what keep the events from becoming empty ritual.
That last point is the one worth keeping. The events are a skeleton; run them without the values and you get [agile theatre](/guides/agile-theatre/), where the meetings happen on schedule and change nothing. The count is trivia. Whether the ceremonies actually inspect and adapt is the only question that matters.
## Frequently asked questions
### What are ceremonies in Agile?
Agile ceremonies are the recurring, timeboxed meetings a Scrum team runs to plan, coordinate, review, and improve its work: sprint planning, the daily scrum, the sprint review, and the sprint retrospective. "Ceremony" is a colloquial label (the Scrum Guide calls these meetings "events"), but the two words point at the same set of meetings.
### What are the 4 core Agile ceremonies?
Sprint planning (agree what the sprint will deliver), the daily scrum or standup (re-plan the day in 15 minutes), the sprint review (show the product to stakeholders and gather feedback), and the sprint retrospective (improve how the team works). Most "four ceremonies" lists mean exactly these.
### What are the five ceremonies of Agile?
The fifth is the sprint itself. The current Scrum Guide counts five events, because it treats the sprint as a container event that holds the other four. So "four" counts only the meetings; "five" adds the sprint they happen inside. Both are right. They're just counting different things.
### What is the 3-5-3 rule in Agile?
A mnemonic for the shape of Scrum: 3 roles (product owner, scrum master, developers), 5 events (the sprint plus sprint planning, the daily scrum, the sprint review, and the retrospective), and 3 artifacts (product backlog, sprint backlog, increment). It's a memory aid, not a rule in the Scrum Guide, but it's a fair map of the framework.
### What are the 5 C's of Agile?
There's no canonical "5 C's of Agile" in Scrum: different sources invent different lists (commitment, courage, communication, and so on). If you're looking for the values that underpin Scrum, the real, defined set is the five Scrum values: commitment, courage, focus, openness, and respect.
---
# Scrum Master's retrospective guide
URL: https://www.teamretro.com/guides/scrum-masters-retrospective-guide/
This is the long version. If you facilitate retrospectives for a Scrum team and want
the whole subject in order (what the event is for, how to run it, and what to do when
it stops working), the chapters below cover it end to end. Read them in sequence, or
drop into the one you need.
Start with the shorter guide to [running effective retrospectives](/guides/running-effective-retrospectives/)
if you want the practical version on one page: what a retrospective is, the five
phases, a 60-minute agenda you can copy, and how to pick a format. This guide is what
comes after that.
**Who it's for.** A Scrum Master, team lead or delivery manager who runs these
regularly. It assumes you know what a sprint is. It does not assume you have
facilitated much.
**How the 16 chapters are organized.** Four groups, roughly in reading order:
- **What a retrospective is, and why it earns its hour:** the Sprint Retrospective itself, why retros matter, and the Prime Directive that sets the tone.
- **Running one:** online versus in person, why remote retros carry more weight, how to run a good online session, and a before, during and after checklist.
- **Formats, games and safety:** choosing a template, agile games for team building, and how to build a room where people say the real thing.
- **The Scrum context, and what goes wrong:** the four Scrum ceremonies, Sprint Review versus Sprint Retrospective, the Scrum values, roles and artifacts, [burndown charts](/guides/agile-metrics/burndown-chart/), and finally [why retrospectives fail](/guides/scrum-masters-retrospective-guide/why-retrospectives-fail/).
**How to work through it.** Nobody needs all of it at once. If you are running your
first retrospective this week, read the Sprint Retrospective chapter, the Prime
Directive, and the checklist, then come back for formats once the habit holds. If
your retros run but nothing changes afterwards, skip straight to why retrospectives
fail. If you need numbers rather than method, our compilation of
[agile and retrospective statistics](/guides/agile-statistics/#sprint-retrospectives-and-continuous-improvement)
gives each figure with its study, its year and a link to the primary source. For the
rest of the library, browse [all TeamRetro guides](/guides/).
---
# Scrum metrics: the sprint metrics worth keeping
URL: https://www.teamretro.com/guides/agile-metrics/scrum-metrics/
**The scrum metrics worth keeping are the ones that help a team inspect its own sprints: sprint goal success, carry-over, escaped defects, a burnup for anyone forecasting a release, and, used carefully, the say/do ratio.** Each one has an audience it serves and a way it gets gamed. Almost all of them break once someone turns them into a target.
The [Scrum Guide](https://scrumguides.org/scrum-guide.html) itself names no metrics. Its only line on the subject is about forecasting: "Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism." A sprint metric earns its place if it helps the team inspect and adapt, and loses it the moment it becomes a scoreboard. This chapter of the [agile metrics guide](/guides/agile-metrics/) goes through the common ones, what each is for, who should see it, and how it goes wrong.
## Start from what scrum asks a team to commit to
The 2020 Scrum Guide gives each artifact one commitment: the product goal for the product backlog, the sprint goal for the sprint backlog, and the definition of done for the increment. The sprint goal is "the single objective for the Sprint," and it "provides flexibility in terms of the exact work needed to achieve it."
That gives a simple test. The strongest scrum metrics line up with one of those commitments:
- **Sprint goal** → sprint goal success.
- **Definition of done** → escaped defects.
- **Product goal** → a burnup toward the release or goal.
Carry-over and the say/do ratio sit one level down. They measure how well the team plans, which is useful for the team's own calibration and much less useful to anyone else.
## Velocity and burndown, briefly
**Velocity** is the average number of story points a team completes per sprint over the last few sprints. It is a forecasting input for the team, explained in the [velocity chapter](/guides/agile-estimation-guide/velocity/) and paired with capacity in [velocity and capacity planning](/guides/sprint-planning-guide/velocity-and-capacity/). Set it as a target or compare it across teams and it inflates; our [velocity verdict](/guides/agile-verdicts/is-velocity-a-useful-metric/) makes that case in full.
**The sprint burndown** plots work remaining against the days of the sprint, with an ideal line for comparison. It helps the team steer the current sprint, but it hides scope change, because added work just looks like a stall. The [burndown chart chapter](/guides/agile-metrics/burndown-chart/) covers how to read one.
## Burnup: the forecast stakeholders can read
A burnup chart plots work completed rising toward a second line for total scope. The [Agile Alliance glossary](https://www.agilealliance.org/glossary/burndown-chart/) puts the advantage plainly: "The burn-up chart resolves this issue by showing a separate line for overall backlog size." When scope grows, the top line moves, and nobody mistakes added work for a slow team.
**What it's for.** Release and product-goal forecasting across many sprints. Where the completed line is heading relative to the scope line gives a range of likely finish dates, and the gap between them is the conversation the Product Owner needs to have about scope.
**Who should see it.** The team and stakeholders. Of the charts on this page, it is the one built to leave the room, because it answers the stakeholder question (when will it be done, and what changed?) without exposing the team's internal calibration.
**How it gets gamed.** Quietly redrawing the scope line to make the gap close, or letting point inflation make the completed line climb faster. The defense is to keep a dated history of the scope line and to forecast from a range of recent sprints, not the best one. The glossary's own caution applies too: neither chart shows "which product backlog items have been completed." It is a trend, not a status report.
## Sprint goal success
**What it is.** Did the sprint meet its sprint goal, yes or no, recorded at the [sprint review](/guides/agile-ceremonies-guide/sprint-review/) and tracked over recent sprints as a rate. Mark C. Layton, co-author of *Agile Project Management For Dummies*, puts it first in his [list of ten scrum metrics](https://www.dummies.com/article/business-careers-money/business/project-management/10-key-metrics-for-scrum-143087).
**What it's for.** It measures the commitment scrum actually asks for. A team can finish 9 of 10 items and miss the goal, or drop 3 items and meet it. Scrum counts the second as the success: the goal is the commitment, and Developers "collaborate with the Product Owner to negotiate the scope of the Sprint Backlog" when the work turns out different. Of all the sprint metrics, it is the closest to an outcome.
**Who should see it.** The team and stakeholders. The sprint review is a working session to "inspect the outcome of the Sprint," and this is that outcome in one line.
**How it gets gamed.** Goals too vague to miss ("progress on checkout"), goals written after the sprint to match what got done, or a goal that is just the item list restated. A rate of 100% over many months usually means goals that are too safe, not a perfect team. The [sprint goal chapter](/guides/sprint-planning-guide/sprint-goal/) covers what makes a goal specific enough to miss.
## Carry-over
**What it is.** The items planned into a sprint that weren't done when it ended. Count them, and note how many sprints each one has been carried.
In scrum, unfinished work doesn't roll forward automatically. The Scrum Guide says an item that doesn't meet the definition of done "returns to the Product Backlog for future consideration." Moving it straight into the next sprint out of habit is how the same story ends up carried four times.
**What it's for.** Spotting overcommitment, items too big to finish in a sprint, and unplanned work crowding out planned work. An item carried more than once is an aging item, the same signal [work item age](/guides/agile-metrics/lead-time-vs-cycle-time/) gives a Kanban team.
**Who should see it.** The team. It's a planning-calibration signal, and outside the team it reads as failure.
**How it gets gamed.** Splitting an item at sprint end so half of it counts as done, closing a ticket and opening a "new" one for the remainder, or planning so little that nothing carries over. All three make the number look better and the plan less accurate about the work.
## Escaped defects
**What it is.** Defects "discovered by end-users or customers in a production environment," in the [Ministry of Testing's](https://www.ministryoftesting.com/software-testing-glossary/bug-escape-rate) wording, that the team's testing didn't catch. The same glossary gives an escape rate: escaped defects divided by all defects found, before and after release. Ten found in production against 100 found before release is an escape rate of about 9%.
**What it's for.** It tests the definition of done. Among the Developers' accountabilities, the Scrum Guide lists "Instilling quality by adhering to a Definition of Done," and an escaped defect is a case where the done-check said yes and reality said no. Each one is worth a look at the [definition of done](/guides/agile-estimation-guide/definition-of-done/) it slipped past. At the delivery level it sits next to DORA's change fail rate, covered in the [DORA metrics chapter](/guides/agile-metrics/dora-metrics/).
**Who should see it.** The team and stakeholders, as a trend over sprints or releases. Never per person: attributing escaped defects to individuals tends to teach people to stop reporting them.
**How it gets gamed.** Reclassifying bugs as feature requests, arguing every one down to low severity, or simply not logging what support fixes quietly. Agree the definitions first: which severities count, and how long after release a defect still counts as escaped.
## Say/do ratio
**What it is.** Work completed divided by work committed at sprint planning, as a percentage. One worked definition, from Profit.co: "Say-Do Ratio = (Completed Work / Committed Work) × 100." Freeze the committed list when the sprint starts, so anything added later counts as unplanned work rather than as part of the "say."
**What it's for.** Calibrating how much the team takes on. It measures forecasting accuracy, not delivery of value: a team can hit 100% on the wrong work.
**Who should see it.** The team only. Read it next to sprint goal success, because under the 2020 Scrum Guide the team's commitment is the goal, not the item list. A sprint at 70% say/do that met its goal may well have been a good sprint.
**How it gets gamed.** Sandbagging. The same Profit.co piece warns that if the number "turns into a stick, you will create a culture of sandbagging and silence around risk," and that a ratio consistently around 120% or higher often means the team is committing to too little. A team graded on say/do learns to promise less.
A metric that measures the team's own forecasting (velocity, carry-over, say/do) gets worse at forecasting the moment it is used to judge the team. Keep these inside the team. Give stakeholders the burnup, sprint goal success and the escaped-defect trend instead.
## Who should see which metric
| Metric | What it's for | Who should see it | How it gets gamed |
|---|---|---|---|
| Velocity | Forecasting the team's own sprints | Team | Points inflate |
| Sprint burndown | Steering the current sprint | Team | Scope changes hidden |
| Burnup | Forecasting a release or product goal | Team and stakeholders | Scope line redrawn |
| Sprint goal success | Did the sprint achieve its one objective? | Team and stakeholders | Goals too vague to miss |
| Carry-over | Spotting overcommitment and oversized items | Team | Items split or re-opened at sprint end |
| Escaped defects | Testing the definition of done | Team and stakeholders, as a trend | Bugs reclassified or not logged |
| Say/do ratio | Calibrating how much to commit to | Team | Sandbagging |
## Taking sprint metrics into the retrospective
Carry-over doubled; the goal was missed twice running; three defects escaped in one release. The people who did the work usually know why: a production incident ate two days, a story was vaguer than it looked, another team's dependency slipped. That conversation belongs in the [sprint retrospective](/guides/agile-ceremonies-guide/sprint-retrospective/), whose purpose in the Scrum Guide is "to plan ways to increase quality and effectiveness." [From numbers to actions](/guides/agile-metrics/from-metrics-to-action/) covers how to bring the charts into the room without turning it into a defense of the numbers, and the [agile ceremonies guide](/guides/agile-ceremonies-guide/) covers where each conversation sits in the sprint.
For the parts of team health no sprint metric reaches, such as how product ownership or the events are working, teams use a self-assessment; the [health checks and maturity models chapter](/guides/agile-metrics/maturity-models-and-health-checks/) explains when that perception data beats system data. TeamRetro's [Scrum Health Check](/health-check-templates/scrum-health-check/) is one such self-assessment, rating five areas from product ownership and teamwork to technical debt and tooling. Teams running Kanban, or mixing it with sprints, can add the flow measures in [lead time vs cycle time](/guides/agile-metrics/lead-time-vs-cycle-time/).
## Frequently asked questions
### What are the most useful scrum metrics?
The ones tied to what scrum asks a team to commit to. Sprint goal success tracks the sprint goal, escaped defects track the definition of done, and a burnup tracks progress toward a release or product goal. Carry-over and the say/do ratio help the team calibrate its planning.
### What is a say/do ratio?
The say/do ratio divides the work a team completed in a sprint by the work it committed to at sprint planning, as a percentage. Freeze the committed list when the sprint starts so that work added later doesn't distort it. It measures how well the team forecasts its own capacity, so it belongs to the team. Used as a target, it teaches the team to commit to less.
### What is sprint goal success rate?
The share of recent sprints in which the team met its sprint goal, recorded as a plain yes or no at the sprint review. It measures the commitment the Scrum Guide actually asks for, the sprint goal, rather than the list of items.
### What counts as an escaped defect?
A defect found after release, usually by users or in production, that the team's testing and definition of done did not catch. One common form is the escape rate: escaped defects divided by all defects found, before and after release.
### Should scrum metrics be shared with management?
Some should. A burnup, sprint goal success and the escaped-defect trend give stakeholders what they need: progress toward a goal, whether sprints deliver what they set out to, and whether quality is holding. Velocity, carry-over and the say/do ratio are calibration tools for the team. Shared upward, they tend to become targets.
## Related reading
- [Agile and engineering metrics](/guides/agile-metrics/): the hub, mapping scrum metrics against DORA, SPACE and flow.
- [What is a burndown chart?](/guides/agile-metrics/burndown-chart/): reading the ideal and actual lines within a sprint.
- [Velocity: what it's for and how to calculate it](/guides/agile-estimation-guide/velocity/): the mechanics of the team's main forecasting input.
- [Lead time vs cycle time](/guides/agile-metrics/lead-time-vs-cycle-time/): the flow measures that work with or without sprints.
- [How to set a sprint goal](/guides/sprint-planning-guide/sprint-goal/): goals specific enough that sprint goal success means something.
---
# The three Scrum roles (accountabilities)
URL: https://www.teamretro.com/guides/scrum-masters-retrospective-guide/scrum-roles/
Scrum has three roles: the **Product Owner**, the **Scrum Master**, and the **Developers**. Together they form the **Scrum Team**, a small, cross-functional group that has everything it needs to deliver value each sprint. The current [Scrum Guide](https://scrumguides.org/) calls these *accountabilities* rather than roles, to stress that each one describes what part of the team is responsible for, not a job title, but "Scrum roles" remains the everyday term.
## The three Scrum roles
### The Product Owner
The Product Owner is accountable for **maximizing the value of the product**. They own the Product Backlog: what goes in it, how it is ordered, and that it is clear to everyone. They decide *what* the team builds and *why*, balancing the needs of customers, stakeholders, and the business. A good Product Owner says no often, so the team can focus on the most valuable work.
### The Scrum Master
The Scrum Master is accountable for the **Scrum Team's effectiveness** and for the way Scrum is practiced. They are a servant leader, not a manager: they coach the team, facilitate the Scrum events, remove impediments, and protect the team's focus. The Scrum Master usually facilitates the [sprint retrospective](/guides/scrum-masters-retrospective-guide/what-is-a-sprint-retrospective/) and the other [Scrum ceremonies](/guides/scrum-masters-retrospective-guide/scrum-ceremonies/), and works to build the [psychological safety](/guides/scrum-masters-retrospective-guide/how-to-build-a-psychologically-safe-space/) the team needs to improve.
### The Developers
The Developers are the people who do the work of building the increment each sprint, whatever mix of skills that takes (engineering, design, testing, and more). They are accountable for *how* the work gets done: planning the sprint, creating a usable increment, and holding each other to the Definition of Done. In the 2020 Scrum Guide, "Developers" replaced the older term "Development Team," and Scrum no longer recognizes any sub-teams or titles within the group.
## How the three roles work together
The three roles are deliberately balanced. The Product Owner points at *what* matters; the Developers decide *how* to build it; the Scrum Master makes sure the team works well and keeps improving. No one role is "in charge" of the others. They are peers with different accountabilities, and Scrum works best when each respects the others' domain. The retrospective is where the whole Scrum Team steps back together to inspect how that collaboration is going and agree how to make it better.
## Frequently asked questions about the Scrum roles
### What are the three roles in Scrum?
Scrum has three roles, which the current Scrum Guide calls accountabilities: the Product Owner, the Scrum Master, and the Developers. Together they make up the Scrum Team. The Product Owner owns the what and the why, the Developers own the how, and the Scrum Master is accountable for the team's effectiveness and for the way Scrum is practiced.
### What is the difference between a Scrum Master and a Product Owner?
The Product Owner maximizes the value of the product: they own and order the Product Backlog and decide what the team builds and why. The Scrum Master is a servant leader accountable for the team's effectiveness: they coach the team, facilitate the events (including the retrospective), and remove impediments. One focuses on the product, the other on how the team works.
### Are there roles in Scrum or accountabilities?
Both terms describe the same three positions. Older Scrum material says "roles" (Product Owner, Scrum Master, Development Team). The 2020 Scrum Guide reframed these as "accountabilities" and renamed the Development Team to "Developers," to stress that they describe what each part of the team is responsible for rather than a job title. Most teams still say "Scrum roles" day to day.
### Who facilitates the sprint retrospective?
The Scrum Master usually facilitates the sprint retrospective, as part of their accountability for the team's effectiveness and for the Scrum events running well. That said, facilitation can rotate, and a mature team often shares it, but the Scrum Master remains accountable for making sure the retrospective happens and produces real improvement.
## Related reading
- [The four Scrum ceremonies explained](/guides/scrum-masters-retrospective-guide/scrum-ceremonies/): where each role shows up across the sprint.
- [What is a Scrum Master, and why does the role matter in a retrospective?](/blog/what-is-a-scrum-master-and-why-is-their-role-so-important-in-a-retrospective/)
---
# The five Scrum values
URL: https://www.teamretro.com/guides/scrum-masters-retrospective-guide/scrum-values/
The five Scrum values are **Commitment, Focus, Openness, Respect, and Courage**. They were added to the [Scrum Guide](https://scrumguides.org/) to capture the mindset and behavior that make the framework actually work. The roles and ceremonies describe *what* a Scrum team does; the values describe *how* it should do it, and without them the mechanics of Scrum are just empty ritual.
## The five Scrum values explained
**Commitment.** Team members personally commit to the Sprint Goal and to each other. Commitment in Scrum is about dedicating yourself to the team's shared aims and doing your best to achieve them, not about over-promising on scope.
**Focus.** Everyone focuses on the work of the Sprint and the Sprint Goal. Focus means resisting distraction and the temptation to spread effort across too many things at once, so the team makes real progress on what matters most.
**Openness.** The team and its stakeholders are open about the work and the challenges. Openness means being transparent about progress, surfacing problems early rather than hiding them, and being receptive to new ideas and feedback.
**Respect.** Team members respect each other as capable, independent people. Respect means valuing different skills, perspectives, and backgrounds, and assuming good intent, the foundation of any healthy team.
**Courage.** The team has the courage to do the right thing and to tackle hard problems. Courage means raising uncomfortable truths, challenging the status quo, admitting mistakes, and committing to difficult work.
## Why the Scrum values matter
It is entirely possible to run every ceremony, fill every role, and still have Scrum fail. The difference between teams that improve and teams that go through the motions is almost always the values. Commitment and Focus drive real progress; Openness, Respect, and Courage build the trust a team needs to be honest about what is going wrong and brave enough to change it. The values are what make continuous improvement possible.
## How the retrospective brings the values to life
The Sprint Retrospective is where the Scrum values are most visible, and most tested. It takes **Courage** to raise a problem honestly, **Openness** to share what really happened, and **Respect** to listen to a teammate's perspective without blame. A retrospective run with these values produces honest insight and real action; one run without them produces silence and "everything's fine." This is why building [psychological safety](/guides/scrum-masters-retrospective-guide/how-to-build-a-psychologically-safe-space/) matters so much. It is the soil the values grow in.
Many teams go a step further and periodically run a retrospective focused specifically on the values, scoring how well the team is living each one and discussing where to improve. You can run a [Scrum Values retrospective](/retrospective-templates/scrum-values/) for exactly this, or track the values over time with a [team health check](/health-check-templates/team-health-check/). If you would rather start by reflecting on your own practice, the [Scrum Master self-assessment quiz](/scrum-master-self-assessment-quiz/) is a quick way in.
## Frequently asked questions about the Scrum values
### What are the five Scrum values?
The five Scrum values are Commitment, Focus, Openness, Respect, and Courage. They were added to the Scrum Guide to describe the behavior and mindset that make the Scrum framework work. Where the events and roles describe what a team does, the values describe how it should do it.
### Why are the Scrum values important?
The Scrum values are what turn the mechanics of Scrum into an effective way of working. A team can run every ceremony and fill every role and still fail if it is not committed, focused, open, respectful, and courageous. The values build the trust that lets a team be transparent about problems and brave enough to change, which is exactly what continuous improvement depends on.
### How does a retrospective reflect the Scrum values?
The Sprint Retrospective is where the Scrum values are most visible. It takes Courage to raise a problem honestly, Openness to share what really happened, and Respect to listen without blame. A well-run retrospective both depends on these values and strengthens them, which is why many teams periodically run a retrospective focused specifically on the Scrum values themselves.
### Who created the Scrum values?
The Scrum values are defined in the Scrum Guide, authored by Ken Schwaber and Jeff Sutherland, the co-creators of Scrum. The five values (Commitment, Focus, Openness, Respect, and Courage) were formally added to the Scrum Guide in its 2016 revision and remain part of the framework today.
## Related reading
- [Which of the Scrum values is most demonstrated by your team?](/blog/which-of-the-scrum-values-is-most-demonstrated-by-your-team/): a short team exercise on the values.
- [Scrum paradigms: chickens vs pigs and the observer role in agile meetings](/blog/scrum-paradigms-chickens-vs-pigs-the-observer-role-in-agile-meetings/)
---
# The SPACE framework: five dimensions, not five metrics
URL: https://www.teamretro.com/guides/agile-metrics/space-framework/
**The SPACE framework is a way to choose developer productivity metrics, not a set of five metrics.** It names five dimensions (Satisfaction and well-being, Performance, Activity, Communication and collaboration, Efficiency and flow) and asks you to measure across at least three of them, with at least one measure of how people perceive their work.
That correction matters because many explainers present SPACE as five numbers to collect. The paper that introduced it argues the opposite: productivity "cannot be reduced to a single dimension (or metric!)," and the point of the framework is to pick a small set of metrics that pull against each other.
## Where SPACE comes from
SPACE was published in 2021 in [ACM Queue (volume 19, issue 1)](https://queue.acm.org/detail.cfm?id=3454124) as "The SPACE of Developer Productivity: There's more to it than you think," by Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck and Jenna Butler. The authors were researchers at GitHub, the University of Victoria and Microsoft. Forsgren is also a co-author of *Accelerate* and led DORA, so the two frameworks share a lineage; the [DORA metrics chapter](/guides/agile-metrics/dora-metrics/) covers that side.
It was written as the pandemic sent most developers home, which the authors called a rare "natural experiment" in how productivity works. It opens by taking apart five myths:
- Productivity is all about developer activity.
- Productivity is only about individual performance.
- One productivity metric can tell us everything.
- Productivity measures are useful only for managers.
- Productivity is only about engineering systems and developer tools.
Each myth maps to a design choice: activity is one dimension of five, every dimension can be read at individual, team and system level, and "invisible" work such as mentoring and knowledge sharing counts, even though it is "often not measured."
## SPACE is a framework, not five metrics
The authors describe SPACE as a way "to choose metrics carefully in a way that reveals not only what those metrics mean, but also what their limitations are if used alone or in the wrong context." Its example metrics are a menu, and activity metrics in particular "serve as templates to start with and should be customized."
So "our SPACE metrics" should mean a short list your team chose, with at least one metric from three or more dimensions. It should not mean one number per letter. A team tracking commits, pull requests and coding time has three metrics and one dimension, the paper's own example of the trap. Its fix: keep one activity measure and add "perhaps perception of productivity and pull request merge time."
## The five SPACE dimensions
Satisfaction is best captured by asking people; Activity mostly comes from systems; Performance, collaboration and flow need both. A balanced SPACE set mixes the two kinds of data.
The paper's Figure 1 gives example metrics at three levels: one person, a team or group, and end-to-end work through a system. A selection:
| Dimension | Paper's short definition | Individual | Team or group | System |
|---|---|---|---|---|
| Satisfaction and well-being | How fulfilled, happy and healthy one is | Developer satisfaction; satisfaction with code reviews assigned | Developer satisfaction; retention† | Satisfaction with the engineering system (e.g. CI/CD pipeline) |
| Performance | An outcome of a process | Code review velocity | Code review velocity; story points shipped† | Customer satisfaction; reliability (uptime) |
| Activity | The count of actions or outputs | Code reviews completed; coding time; commits; lines of code† | Story points completed† | Frequency of deployments |
| Communication and collaboration | How people talk and work together | Code review score (quality or thoughtfulness); PR merge times | PR merge times; knowledge sharing or discoverability | Knowledge sharing, discoverability (quality of documentation) |
| Efficiency and flow | Doing work with minimal delays or interruptions | Productivity perception; lack of interruptions | Code review timing; handoffs | Velocity/flow through the system |
† The paper's own warning: "Use these metrics with (even more) caution", because they can proxy more things.
**Satisfaction and well-being** covers how fulfilled developers feel with their work, team, tools and culture, and how healthy and happy they are. Surveys are often the best way to capture it. Suggested measures include employee satisfaction, developer efficacy (having the tools and resources to get work done) and burnout. SPACE also floats satisfaction as a possible leading indicator: a drop in satisfaction and engagement could signal burnout ahead.
In its pandemic example, commits and pull-request merge speed went up in some places while qualitative data showed some people were struggling with their well-being. Activity data alone would have called that a good quarter. System metrics can miss that human side of the work. Survey answers are also only as candid as people feel safe to be, which is why [psychological safety](/guides/psychological-safety-at-work/) matters to any measurement plan.
**Performance** is the outcome of a system or process, best judged by what it achieved rather than how much it produced. Put simply: did the developer's code reliably do what it was supposed to do? Example measures fall under quality (reliability, absence of bugs, service health) and impact (customer satisfaction, adoption, feature usage, cost reduction).
**Activity** is a count of the actions or outputs completed while doing the work: commits, pull requests, code reviews, builds, deployments, incidents handled. It's the easiest dimension to collect, since a well-designed engineering system captures it. It should "never be used in isolation" to judge individual or team productivity.
**Communication and collaboration** covers how people and teams communicate and work together. Proxies include discoverability of documentation and expertise, how quickly work is integrated, the quality of reviews, network metrics showing who works with whom, and onboarding time and experience for new members.
**Efficiency and flow** is the ability to make progress with few interruptions or delays, alone or through a system. Examples include handoffs, interruptions, perceived ability to stay in flow, and time through a system (total, value-added and wait time). This is where SPACE cites DORA: deployment frequency and lead time for changes appear as examples of metrics that monitor flow. Flow metrics in the Kanban sense, covered in the [lead time vs cycle time chapter](/guides/agile-metrics/lead-time-vs-cycle-time/), fit here too.
## How to use SPACE well
The paper's guidance is short and specific:
1. **At least three dimensions.** Several metrics across multiple dimensions, with "at least three" recommended.
2. **At least one perception measure.** "At least one of the metrics include perceptual measures such as survey data," because "perceptual data may provide more accurate and complete information than what can be observed from instrumenting system behavior alone."
3. **Tension is the point.** Metrics from different dimensions will pull against each other, and that is "by design." Speed metrics next to quality and satisfaction make any one of them harder to game quietly.
4. **A handful, not a dashboard.** "Having too many metrics may also lead to confusion and lower motivation."
5. **Teams, not individuals.** Report "only anonymized, aggregate results at the team or group level." Individual analysis is for developers who opt in, for their own use.
6. **Check for bias.** The paper flags three: women are more likely to receive negative code review comments, year-long windows penalize people who took parental leave, and cultures differ in how high they score perception questions. So compare a group with its own baseline.
## Measuring each dimension: surveys and system data
| Dimension | From systems | From a survey (example questions) |
|---|---|---|
| Satisfaction and well-being | Retention (lagging and noisy, per the paper) | "How satisfied are you with our tools and pipeline?" "How sustainable was your workload this month?" |
| Performance | Escaped defects, uptime, feature usage | "How confident are you that what we ship works as intended?" |
| Activity | Commits, PRs, reviews, deploys, incidents | Rarely needed; the systems already count it |
| Communication and collaboration | Review turnaround, time to integrate, onboarding time | "Can you find the documentation or expert you need?" "Are reviews useful?" |
| Efficiency and flow | Handoffs, wait time, lead time, DORA throughput | "How often were you interrupted in a typical day?" "How often could you get into flow?" |
A practical set for a product team might be: [a quarterly satisfaction survey](/guides/team-health-check/) (S), change fail rate (P), PR merge time (C), and a perceived-flow question (E). That's four metrics across four dimensions, two from systems and two from people. If you're starting from nothing, that's the set we'd pick: a handful of metrics across at least three dimensions, with perception data in the mix, which is what SPACE asks for.
TeamRetro's [SPACE Framework Health Check](/health-check-templates/space-framework/) is a team survey, so it captures how the team experiences each dimension, including Activity, which the paper expects to come from system data.
## DORA vs SPACE
DORA and SPACE answer different questions, and they work well together.
| | DORA | SPACE |
|---|---|---|
| What it is | A fixed set of five software delivery metrics | A framework for choosing productivity metrics across five dimensions |
| Question it answers | How fast and how safely does this service get changes to production? | Is the way we measure developer productivity balanced? |
| Unit | One application or service | Individual, team or group, and system |
| Measures | Change lead time, deployment frequency, failed deployment recovery time, change fail rate, deployment rework rate | Whatever you choose: at least three dimensions, at least one perceptual |
| Data | Delivery pipeline and incident records, or survey answers (DORA's own research uses a survey) | A mix of system data and surveys, by design |
| People's experience | Not one of the five metrics | Satisfaction and well-being is a dimension |
| Source | DORA research program; five-metric model since the 2024 report | ACM Queue paper, 2021 |
| Common misuse | Turning the metrics into targets; comparing unlike services | Treating it as five metrics; scoring individuals |
**How they fit together.** DORA's metrics slot into SPACE. Deployment frequency appears in the paper's Activity column at system level, and lead time for changes is cited under Efficiency and flow. Change fail rate and recovery time sit naturally under Performance, whose examples include reliability and ongoing service health. A team already reporting DORA has the system half of a SPACE set; adding a satisfaction measure and a collaboration measure makes it balanced.
Asking "how is delivery going on this service"? Start with [DORA](/guides/agile-metrics/dora-metrics/). Asking "are we measuring developers fairly and completely"? Use SPACE to choose the set. For the perception-led approach that followed, see [developer experience metrics](/guides/agile-metrics/developer-experience-metrics/); for every framework side by side, the [agile metrics hub](/guides/agile-metrics/).
## Frequently asked questions
### What does SPACE stand for?
Satisfaction and well-being, Performance, Activity, Communication and collaboration, and Efficiency and flow. The five dimensions come from the 2021 ACM Queue paper The SPACE of Developer Productivity by Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck and Jenna Butler.
### Is SPACE a set of metrics?
No. SPACE is a framework for choosing metrics. The paper offers example metrics for each dimension at individual, team and system level, but it expects you to pick a handful that fit your context, across at least three dimensions, including at least one perception measure such as survey data.
### What is the difference between DORA and SPACE?
DORA is a fixed set of five software delivery metrics for one application or service: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. SPACE is a framework for choosing developer productivity metrics across five dimensions, including satisfaction and collaboration, which DORA's metrics don't cover. DORA measures can serve as part of a SPACE set; the paper itself cites deployment frequency and lead time as flow measures.
### How many SPACE dimensions should you measure?
At least three, per the paper, with at least one perceptual measure such as survey data. The paper also warns against too many metrics: a handful across three or more dimensions is usually enough to show the trade-offs without overwhelming the team.
### Can SPACE be used to measure individual developers?
The paper advises reporting only anonymized, aggregate results at team or group level, and notes that reporting individual productivity isn't legal in some countries. It sees value in individual analysis for developers themselves, on an opt-in basis.
## Related reading
- [Agile and engineering metrics](/guides/agile-metrics/): the hub, with every framework side by side.
- [What are DORA metrics?](/guides/agile-metrics/dora-metrics/): the five delivery measures that make up the system half of most SPACE sets.
- [Developer experience and productivity metrics](/guides/agile-metrics/developer-experience-metrics/): DevEx and DX Core 4, the frameworks that followed SPACE.
- [Health checks and maturity models](/guides/agile-metrics/maturity-models-and-health-checks/): when perception data beats system data.
- [From numbers to actions](/guides/agile-metrics/from-metrics-to-action/): taking a SPACE set into a retro and turning it into a change.
---
# SPIDR story splitting
URL: https://www.teamretro.com/guides/agile-estimation-guide/spidr-story-splitting/
SPIDR is five reliable ways to split a user story: **Spike, Path, Interface, Data, Rules**. Each letter is a cut line, and each cut produces slices that ship independently rather than halves that only work together. It's the splitting technique that survives contact with most backlogs: when a story is too big, one of these five axes almost always yields a slice you'd release.
Five cut lines through one story. You don't use all five. You find the one that produces a slice you'd actually ship.
## The five cut lines
### Spike
The unknown *is* the size. Run a time-boxed investigation, learn the shape, then estimate the real story. This is the cut to reach for when the team can't agree on a number because nobody has done this before. See [running a spike](/guides/agile-estimation-guide/splitting-user-stories/) for what the deliverable should look like.
### Path
The story has multiple flows. Ship the happy path first; bad-data paths, error states, and edge cases become their own stories. The user can complete the goal on the happy path even while the rest is still missing.
### Interface
The story has multiple surfaces: web, mobile, API. Ship one surface first. The rest share the implementation but are deliverable on their own schedules.
### Data
The story handles multiple data shapes or volumes. Ship the simple case first (single tenant, small dataset, common file format), then the variants. Each is a real story, even when the second is mostly a sibling of the first.
### Rules
The story has multiple business rules or roles. Ship the most common rule first; admin overrides, special cases, and exceptions follow. The 80% case is shippable without the 20% case.
**The test for every cut:** if slice one needs slice two to function, it's a [horizontal split](/guides/agile-estimation-guide/horizontal-vs-vertical-slicing/) in disguise, not SPIDR. Each slice has to stand on its own, or you've just rescheduled the work instead of splitting it.
## When SPIDR doesn't help
If none of the five cuts produce a real, shippable slice, you don't have a splitting problem. You have a scope problem. The story is one indivisible piece of work, and the conversation is "do we want all of it this sprint, or none of it." That's a prioritization question, not a splitting one, and no amount of clever slicing will turn it into one.
Pick the cut that produces a slice you'd actually ship. If none of them do, the story isn't asking to be split — it's asking to be prioritized.
## Frequently asked questions
### What does SPIDR stand for?
SPIDR stands for Spike, Path, Interface, Data, Rules: five different axes you can cut a user story along. Each one is a cut line that produces slices which ship independently, rather than halves that only work together.
### How do you use SPIDR to split a user story?
Try each of the five cuts against the story and pick whichever one produces a slice you would actually ship on its own. You don't apply all five. You find the one axis that yields a thin, deliverable slice, and split along it.
### Who created the SPIDR technique?
SPIDR was introduced by Mike Cohn as a compact set of five reliable ways to split a user story. It's popular because the five cuts cover most of the situations teams actually hit, and five letters are few enough to run through in your head mid-refinement.
### What if none of the SPIDR cuts produce a good slice?
Then you don't have a splitting problem. You have a scope problem. The story is one indivisible piece of work, and the real question is whether you want all of it this sprint or none of it. That's a prioritization decision, not a splitting one.
## Related reading
- [Splitting user stories](/guides/agile-estimation-guide/splitting-user-stories/): the diagnostic that tells you a split is what you need, plus the other patterns.
- [Horizontal vs vertical slicing](/guides/agile-estimation-guide/horizontal-vs-vertical-slicing/): why every SPIDR cut has to be vertical.
- [Agile estimation techniques compared](/guides/agile-estimation-guide/estimation-techniques/): for fuzzier stories that survive splitting.
---
# Splitting user stories that won't fit a sprint
URL: https://www.teamretro.com/guides/agile-estimation-guide/splitting-user-stories/
Splitting a [user story](/guides/agile-estimation-guide/what-is-a-user-story/) means cutting one story that's too big into smaller stories that each still deliver something a user can use. A story you can't estimate is usually one you can't ship yet, and splitting is the move that gets it back on the board.
Most "we can't estimate this" conversations are splitting conversations in disguise. The team doesn't have a number-and-effort problem; they have a too-many-unknowns problem. Splitting reduces the unknowns until the story has the shape of work that's been done before, and the estimates converge.
## When to stop estimating and start splitting
A story that won't fit in a sprint isn't a sizing problem; it's a shape problem. Watch for the signals:
- The team votes 13s and 20s, then keeps re-voting to converge instead of splitting.
- "It depends" answers more than a couple of the refinement questions.
- The story spans more than one team's area.
- "Done" requires multiple deploys.
- You can describe it in two sentences but not in two acceptance criteria.
If you push through anyway, the team spends the sprint trying and carries over what's left (badly, because the carry-over is whatever was hardest) or finishes a shippable subset and calls it done while the rest sits half-built. Both are worse than splitting on purpose before the sprint starts.
The story that won't fit becomes three slices that each ship on their own, not two halves of nothing.
## Why a wide vote spread means split, not re-vote
When a team sizes work together with [planning poker](/free-planning-poker-for-agile-teams/), a wide spread is the most useful signal it produces. Cards spread from 3 to 13 isn't a number disagreement. It's two stories pretending to be one. The 3 voter is seeing one scope; the 13 voter is seeing a different scope. Re-voting won't reconcile them; the work is the conversation about which scope is real. Here's what's usually happening underneath:
- One person is sizing the happy path; another is sizing the edge cases.
- One person assumes the design exists; another assumes they're designing it.
- One person is sizing the query; another is sizing the rollout.
- One person knows the dependency exists; another doesn't.
- One person is sizing for someone in the room; the work belongs to a different team.
More detail rarely fixes this: it produces a longer ticket, not a sharper estimate. Splitting does: into a spike if the unknown is the cause, into vertical slices if the unknown is the scope. Two cards spread doesn't mean the team disagrees. It means the team is voting on different stories. Send it back.
## Slice vertically, not horizontally
The split has to be vertical, not horizontal: a thin slice that's actually deliverable on its own. "Backend first, frontend next sprint" splits the story the way a knife splits dough: you get two halves of nothing. A vertical slice touches every layer and ships a working column, one button that works end to end, even if it only handles one input case. See [horizontal vs vertical slicing](/guides/agile-estimation-guide/horizontal-vs-vertical-slicing/) for the principle in full.
## Splitting patterns that work
[SPIDR](/guides/agile-estimation-guide/spidr-story-splitting/) (spike, path, interface, data, rules) covers most splitting situations, and it's the first place to look. A few other patterns recur often enough to be worth naming.
### Workflow steps
A story that spans a user journey (sign up, set preferences, confirm email, see dashboard) often splits cleanly along step boundaries. When it works, it's the cleanest technique in the toolkit: each story ships a recognizable user-visible thing, each can be demoed, each can be scoped on its own.
The test is one question, asked of every step: *would the user benefit from this if we shipped it and nothing else?* "Set preferences" passes: a user with preferences but no email confirmation is still in a usable state. "Submit form" fails: a user whose submission goes nowhere is worse off than before. If the answer is no, the step is a sub-task, not a story, and the workflow doesn't split there.
The faster version of the same test: could each step reach production over three sprints without anything else changing, and leave a coherent experience at every stop? If skipping a step leaves the user looking at a broken page, the split is fake. That's the trap engineering teams fall into: the steps match how the code decomposes (auth service, preferences API, dashboard component), so they feel granular. They are granular. They're also [horizontal slices](/guides/agile-estimation-guide/horizontal-vs-vertical-slicing/) with workflow vocabulary on top, and none of them ship anything to the user. The tell: each "step" is owned by exactly one specialist. Real workflow steps cross the stack, because real user-facing steps do.
### Business-rule variations
A story with multiple rules or roles (regular user, admin, API client) splits by rule. Ship the most common rule first; the variants follow. Each variant is a real story with its own users.
### Happy path, then unhappy path
Closely related to SPIDR's *Path* cut. Ship the happy path; error handling, retries, and edge cases follow. The user can succeed even before the failure modes are fully handled, as long as you accept worse failure behavior in the meantime and you actually come back for it.
### Deferred quality
Ship the slice without the polish (no tooltips, no animations, no admin overrides), then ship the polish as its own story. This works *if* you actually ship the polish. Teams that punt quality and never return end up with permanent half-features.
### Operations
A story that's part user feature, part operational concern (logging, monitoring, alerting) splits along that line. Ship the user-facing slice first; the operational slice is a follow-up that often goes faster, because the feature is already in production and the gaps are visible.
## What isn't a real split
"Frontend this sprint, backend the next" isn't splitting; it's deferring delivery, because neither half ships anything alone. "Build it, then write the tests" is the same shape: untested code is a liability, not a slice. If a piece of work only has value once its sibling lands, you haven't split the story. You've scheduled it.
## When a story can't be split: run a spike
Sometimes the unknown is the size itself: nobody's done this before, the vendor's API doesn't answer the load-bearing question, or the work depends on a measurement nobody has yet (current p99, current call volume, current data shape). That's when you run a spike: a time-boxed investigation whose output is knowledge (a doc, a prototype, a recommendation, a measurement), not shipped product code. You come back able to estimate the real story honestly.
**A spike needs two things, both non-negotiable: a clock and a deliverable.** A spike with no clock turns into the work. A spike with no deliverable produces nothing the team can act on. And a spike is a time-box, not a story, so it doesn't carry [story points](/guides/agile-estimation-guide/what-are-story-points/). The number on the card is a budget, not a forecast.
Spikes get misused as "let's just start and see what happens." That isn't a spike; it's an unestimated story with extra steps. Two signals you've got the wrong tool: there's no specific question being answered, or the deliverable is "the feature is built." The first means the team isn't actually unsure; the second means it's a story.
If a single slice still won't fit, the story isn't ready yet; it's a project. Size it as one, communicate the timeline, and stop pretending a sprint will hold it.
## Frequently asked questions
### How do you split a user story?
Split it vertically, along user outcomes, so each slice touches every layer and ships something a user can use, even if it only handles one case. SPIDR gives five reliable cut lines: spike, path, interface, data, rules. Pick whichever one produces a slice you would actually release.
### What do you do when a user story is too big for a sprint?
Split it before the sprint starts, on purpose. A story that won't fit gets carried over badly (the leftover is whatever was hardest) or shipped as a half-built subset. Both are worse than a deliberate vertical split into slices that each ship on their own.
### When should you split a story instead of estimating it?
When the team can't fit it in a sprint, when the vote spreads wide (a 3 next to a 13), when "it depends" answers more than a couple of refinement questions, or when the story spans more than one team. A wide spread isn't a number disagreement; it's two stories pretending to be one.
### What is a spike in agile?
A spike is a time-boxed investigation, run when the team can't size a story without learning more. The output is knowledge (a doc, a prototype, a measurement), not shipped product code. Two things make it a spike rather than open-ended work: a clock and a deliverable.
### What are the common ways to split a user story?
Workflow steps, business-rule variations, happy path then unhappy path, deferred quality, and operational concerns, plus the five SPIDR cuts. The test for all of them is the same: would the user benefit if this slice shipped and nothing else did?
## Related reading
- [Agile estimation: the complete guide](/guides/agile-estimation-guide/) is the hub for everything here.
- [SPIDR story splitting](/guides/agile-estimation-guide/spidr-story-splitting/) covers the five reliable cut lines in depth.
- [Horizontal vs vertical slicing](/guides/agile-estimation-guide/horizontal-vs-vertical-slicing/) is the principle underneath every good split.
- [Definition of ready](/guides/agile-estimation-guide/definition-of-ready/) is the gate a split story has to clear before it re-enters the sprint.
- [Backlog refinement](/guides/agile-ceremonies-guide/backlog-refinement/) is the ceremony where splitting actually happens.
---
# How to set a sprint goal (with examples)
URL: https://www.teamretro.com/guides/sprint-planning-guide/sprint-goal/
A sprint goal is a single sentence that says why the sprint is worth doing. It is the one outcome the team commits to: the thing that is meaningfully true when the sprint ends. Everything the team selects should serve it, and when the sprint gets tight, the goal is what tells you which work to protect and which to drop.
Most teams treat the goal as a summary of the tickets they picked. That is backwards, and it is why so many goals are useless.
## The goal comes before the scope
Set the goal *first*, then choose work that serves it. A goal reverse-engineered from a pile of already-selected tickets ("deliver items 4, 7, and 12") is not a goal; it is a table of contents. It cannot help you make a decision, because it has no opinion about what matters.
The order is the whole point. When you agree the outcome before the scope, selection becomes a series of easy questions: does this item move us toward the goal? If yes, pull it. If no, it had better be a very good reason (a security fix, a hard dependency) or it waits. When you pick scope first, every item feels equally load-bearing, and there is nothing to cut when Thursday goes sideways.
The goal is the target; the selected items are arrows aimed at it. An item that points somewhere else is a candidate to cut, not a reason to widen the target.
## What a strong goal does
A goal earns its place when it can do three jobs:
- **It names an outcome, not a task list.** "Users can reset their own password without contacting support" tells you what is different in the world. "Complete the password-reset epic" tells you which Jira board to look at.
- **It makes trade-offs for you.** The real test of a goal is the last day of the sprint, when not everything will land. A good goal tells you instantly what to protect. If the goal is "let users reset their password", you ship the reset flow and let the nice-to-have email restyling slip. If the goal is "finish the tickets", you have no basis to choose, so everything slips a little and nothing ships clean.
- **The team can say it from memory.** A goal nobody can recite is a goal nobody is steering by. If the team has to open the planning doc to remember why they are here, the goal is too long or too vague.
## Weak goals vs strong goals
The gap between a weak goal and a strong one is almost always the gap between naming activity and naming an outcome.
| Weak goal | Why it fails | Strong goal |
|---|---|---|
| "Work on the checkout redesign." | Names an area, not a result. No finish line. | "A returning customer can complete checkout in under a minute on mobile." |
| "Close 40 story points of backlog." | An output measure the goal should serve, not be. | "Cut the top three reasons customers contact support about billing." |
| "Improve performance and fix bugs." | Two goals, no priority, no way to trade off. | "The dashboard loads in under two seconds for accounts with 10,000+ records." |
| "Finish the reporting feature." | 'Finish' hides the scope; whose definition of done? | "Managers can export a weekly team report as a PDF without help from us." |
Notice the strong goals share a shape: a specific user or system, doing a specific thing, to a specific standard. You could demo each one and the room would agree, without argument, whether it was met.
**Pro tip:** after drafting the goal, ask "if we finished only this and nothing else, would the sprint have been worth it?" If the answer is no, the goal is aimed at the wrong outcome. If the answer is yes, you have found the thing to protect when the sprint gets tight.
## One goal, not several
Aim for a single goal. One goal is what makes trade-offs possible; with two competing objectives, there is no principle for which to defend when time runs out, and you are back to everything-slips-a-little.
If the work genuinely refuses to fit under one goal, treat that as a signal rather than a problem to paper over. Usually it means the sprint is carrying too much, or that two streams of work have been merged into one sprint that would be clearer as two. Occasionally a small amount of unrelated keep-the-lights-on work rides alongside the goal. That is fine, as long as everyone knows it is the ballast, not the mission.
## Who owns the goal
The product owner brings the intent: the business reason this sprint matters more than the alternatives. The whole team shapes that intent into a goal it can actually commit to, which means the developers have to believe it is achievable with the [capacity](/guides/sprint-planning-guide/velocity-and-capacity/) available. A goal the team does not believe in is a wish with a deadline.
Once you have a goal worth committing to, the rest of planning gets easier: the [agenda](/guides/sprint-planning-guide/sprint-planning-agenda/) uses it as the test for selecting work, and the [daily scrum](/guides/daily-standup-guide/) uses it as the thing progress is measured against. The goal set on Monday is what the team steers by all sprint.
## Frequently asked questions
### What is a sprint goal?
A sprint goal is a single sentence that states why the sprint is worth doing: the one outcome the team is committing to. It is set during sprint planning, before scope, and it gives the team a shared objective that the selected backlog items serve. It is the reason the sprint exists, not a list of the tickets in it.
### What makes a good sprint goal?
A good sprint goal names an outcome, not a task list; it is specific enough to tell you what to drop when the sprint gets tight; and the whole team can state it from memory. If your goal is just "finish these tickets", it cannot help you make trade-offs, which is the one job a goal has.
### Who sets the sprint goal?
The product owner brings the intent (the business reason this sprint matters) and the whole team shapes it into a goal they can commit to during planning. It is a collaboration, not a directive. The developers have to believe the goal is achievable with the capacity available, or it is just a wish.
### Can a sprint have more than one goal?
Aim for one. A single goal is what lets the team make trade-offs under pressure; with two competing goals, there is no principle for which to protect when time runs short. If the work genuinely splits in two, that is often a sign the sprint is trying to do too much, or that two teams' work has been merged into one sprint.
---
# Sprint planning: the ceremony that opens the sprint
URL: https://www.teamretro.com/guides/agile-ceremonies-guide/sprint-planning/
Sprint planning is the ceremony that opens the sprint. The team agrees what it will deliver and sketches how, turning a slice of the product backlog into a sprint backlog and a single, clear sprint goal. Done well it takes a few hours and buys the team two weeks of focus. Done badly it's a queue-filling exercise the team spends the rest of the sprint quietly renegotiating.
This chapter is the ceremony-level summary. For the full run of show (the agenda, the roles, the capacity maths, and worked sprint-goal examples), see [the complete guide to sprint planning](/guides/sprint-planning-guide/).
## Where planning sits in the cycle
Planning opens the sprint; the daily scrum keeps it on track; the review and retrospective close it. Everything downstream runs against the plan this meeting produces.
Sprint planning is the first of the [agile ceremonies](/guides/agile-ceremonies-guide/), and its output is the reference point for every other one. The [daily standup](/guides/agile-ceremonies-guide/the-daily-standup/) checks progress against the sprint goal set here; the [sprint review](/guides/agile-ceremonies-guide/sprint-review/) inspects whether the team delivered it. Get planning wrong and the rest of the sprint is spent absorbing the error.
## What planning answers: why, what, how
The Scrum Guide frames the meeting around three questions (*why* is this sprint valuable, *what* can be done, and *how* will it get done), and the order matters.
Settle the **why** first. A sprint goal you can state in one sentence is worth more than a backlog you can't finish. The goal is the thing the team protects when the plan meets reality mid-sprint; scope flexes around it, it doesn't flex around scope.
Then the **what**: the product owner brings priorities, the developers pull items they believe they can complete, and the two negotiate until there's a commitment both sides trust. And the **how**: the developers break the top items into enough of a plan to start: not a Gantt chart, just enough design to know the work is real.
## Inputs and outputs
Planning is only as good as what you bring to it.
- **Inputs:** a refined product backlog (items already clarified and sized), the team's capacity for this sprint, and a read on recent [velocity](/guides/agile-estimation-guide/velocity/).
- **Outputs:** a sprint goal and a sprint backlog the team actually believes in.
Sizing happens in the room. Most teams reach a shared estimate quickly with [planning poker](/free-planning-poker-for-agile-teams/) rather than argue hours. See [the estimation guide](/guides/agile-estimation-guide/) for why points beat time here.
## The failure mode to watch
Overcommitment. Teams plan to 100% of theoretical capacity and forget that velocity already prices in the meetings, the interrupts, and the person who's out on Thursday. Plan to [capacity, not to hope](/guides/sprint-planning-guide/velocity-and-capacity/): a plan the team finishes builds the trust that a plan the team abandons quietly destroys. The sharper failure is when the estimate the team gave gets quoted back as a promise it never made, laundered into a commitment and held against it, which is where planning tips into [agile theatre](/guides/agile-theatre/power-agile-theatre/).
The other tell is a plan built on an unrefined backlog. If planning turns into a clarification-and-splitting session, [backlog refinement](/guides/agile-ceremonies-guide/backlog-refinement/) isn't happening. Fix that upstream and planning gets calm.
## Frequently asked questions
### How long should sprint planning take?
Timebox it to about two hours per week of sprint, so up to four hours for a two-week sprint, up to a full day for a month-long one. If planning routinely runs to the wall, the backlog arrived unrefined and the team is doing refinement work it should have done earlier.
### Who attends sprint planning?
The whole Scrum Team: the developers, the product owner, and the scrum master. The product owner brings the priorities and the why; the developers decide what they can realistically take on and how they'll build it; the scrum master keeps the session timeboxed and focused. Stakeholders don't attend.
### What is the difference between the sprint goal and the sprint backlog?
The sprint goal is the single sentence that says why the sprint is worth running: the outcome the team is committing to. The sprint backlog is the set of items and tasks the team expects will get it there. The goal is fixed for the sprint; the backlog can flex around it as the team learns more.
---
# Sprint planning agenda: a real timeboxed run of show
URL: https://www.teamretro.com/guides/sprint-planning-guide/sprint-planning-agenda/
A sprint planning agenda is the timeboxed run of show for the meeting that opens your sprint: confirm capacity, agree the goal, select the work, and plan enough of it to start. A good agenda does one thing above all: it stops a single item from eating the whole meeting.
Here is an agenda you can run this afternoon, sized for a two-week sprint with a four-hour ceiling. Scale each block up or down with your sprint length.
## The agenda
1. **Set the scene (10 minutes).** The product owner recaps the last sprint's outcome, any change in priorities, and the candidate direction for this one. Short. This is context, not the goal yet.
2. **Confirm capacity (10 minutes).** Establish the team's real availability: who is on leave, what support or on-call rotation is running, standing meetings, and a realistic buffer for the unplanned. You want the honest number before anyone gets attached to scope. See [velocity and capacity planning](/guides/sprint-planning-guide/velocity-and-capacity/).
3. **Agree the sprint goal (20 minutes).** Draft one sentence the team can commit to. Do this *before* selecting items, so scope serves the goal rather than the goal being reverse-engineered from a pile of tickets. See [setting a sprint goal](/guides/sprint-planning-guide/sprint-goal/).
4. **Select the work (60 minutes).** Walk the backlog from the top. For each item: does it serve the goal, is it ready, is it sized? Pull items until you reach capacity, then stop. Resist "one more small one".
5. **Plan the work (90 minutes).** Break the selected items into tasks and an approach. Surface dependencies and risks. This is where an item that "looked like a 3" reveals itself. Send it back or split it now, not on day nine.
6. **Confirm and commit (10 minutes).** Read the goal and the selected items back. Ask the team, plainly, whether they believe they can finish it. Adjust scope if the answer is soft.
That is roughly three and a half hours with slack. If you are routinely blowing past it, the problem is upstream: the backlog arrived unrefined, and you are doing [refinement](/guides/agile-ceremonies-guide/backlog-refinement/) inside planning.
**Pro tip:** timebox every line item and put the clock somewhere everyone can see it. When a discussion turns into solving the problem rather than sizing it, name it, drop it in a parking lot, and move on. Most overruns are one unresolved debate that nobody was willing to cut short.
## The two-part shape underneath
The six items above collapse into the two passes every good planning meeting runs: **decide the scope**, then **plan the scope**. Items 1–4 are scope: what are we taking on, and why. Items 5–6 are the plan: how, and do we believe it. Keeping the two apart is the difference between a meeting that decides and one that thrashes. The [meeting walkthrough](/guides/sprint-planning-guide/sprint-planning-meeting/) chapter goes deeper on why the order matters.
## Where the 3-5-3 rule fits
Search for sprint planning structure and you will hit the **3-5-3 rule**, a mnemonic for the shape of Scrum itself:
- **3 roles:** product owner, Scrum Master, developers.
- **5 events:** the sprint, sprint planning, the daily scrum, the sprint review, and the sprint retrospective.
- **3 artifacts:** the product backlog, the sprint backlog, and the increment.
Sprint planning is one of the five events, and it is where two of the three artifacts meet: the team pulls from the product backlog to build the sprint backlog. It is a useful map of how the pieces relate. It is not an agenda. Do not confuse knowing the framework with knowing how to run the meeting.
## The five stages of a sprint
The other framing people search for is the **five stages of a sprint**, which map directly onto the five events. The sprint is the container; the other four punctuate it:
1. **Sprint planning** opens the sprint and sets the goal.
2. **The [daily scrum](/guides/daily-standup-guide/)** keeps the team coordinated day to day.
3. The work happens, building toward the goal.
4. **The sprint review** inspects the outcome with stakeholders.
5. **The [sprint retrospective](/guides/scrum-masters-retrospective-guide/)** improves how the team works, then feeds the next planning.
Planning is stage one, but it does not stand alone. A goal set well on Monday only pays off if the daily scrum defends it and the retrospective sharpens how you plan next time. For the full tour of how the events connect, see the [agile ceremonies guide](/guides/agile-ceremonies-guide/).
## Adapt the agenda to your team
The blocks above are a starting point, not scripture. A seasoned team on a one-week sprint might run the whole thing in forty-five minutes because the backlog is always ready and capacity barely moves. A team new to Scrum, or one whose backlog is perpetually raw, will need the full timebox and should invest in [refinement](/guides/agile-ceremonies-guide/backlog-refinement/) between sprints to earn it back.
The invariant is the sequence: capacity, then goal, then scope, then plan, then a genuine check that the team believes it. Change the timings freely. Change the order at your peril.
Ready to run it? The [sprint planning template](/guides/sprint-planning-guide/sprint-planning-template/) turns this agenda into something you can copy into your tool and fill in as you go.
## Frequently asked questions
### What is the 3-5-3 rule in Scrum?
The 3-5-3 rule is shorthand for Scrum's structure: 3 roles (product owner, Scrum Master, developers), 5 events (the sprint, sprint planning, the daily scrum, the sprint review, and the sprint retrospective), and 3 artifacts (the product backlog, the sprint backlog, and the increment). Sprint planning is one of the five events.
### What are the five stages of a sprint?
The five stages map to Scrum's five events: the sprint itself is the container, and inside it sit sprint planning, the daily scrum, the sprint review, and the sprint retrospective. Planning opens the sprint, the daily scrum keeps it on track, and the review and retrospective close it.
### How long should the sprint planning meeting be?
About two hours per week of sprint length: four hours for a two-week sprint, up to eight for a month. Treat it as a ceiling. Timebox each agenda item so one debate cannot eat the whole meeting; park anything that turns into problem-solving.
### Who attends sprint planning?
The whole Scrum team: the developers who make the forecast, the product owner who brings the goal and ordered backlog, and the Scrum Master who facilitates. Invite a subject-matter expert for one item only if a decision genuinely depends on them, then let them go.
---
# Sprint planning: the complete guide
URL: https://www.teamretro.com/guides/sprint-planning-guide/
A working guide to sprint planning: the meeting step by step, a timeboxed agenda, a copy-paste template, setting a sprint goal, and planning capacity you can hit.
---
# The sprint planning meeting, step by step
URL: https://www.teamretro.com/guides/sprint-planning-guide/sprint-planning-meeting/
Sprint planning is the meeting that opens a sprint. In it, the team agrees a **sprint goal** and decides how much of the backlog it can realistically finish, turning a prioritized list into a plan the team actually believes. A backlog is a wish list until someone decides what gets built next. That decision is sprint planning.
Done well, it takes an hour or two and the team leaves knowing what it is doing and why. Done badly, it becomes a backlog-reading session where the product owner assigns tickets and everyone nods, and the "commitment" quietly falls apart by Wednesday.
## Why, what, and how
The Scrum Guide frames sprint planning around three questions, and they are worth keeping in this order:
- **Why is this sprint valuable?** The answer is the sprint goal: one sentence the whole team can rally behind. Agree it before you touch the backlog. [Setting a sprint goal](/guides/sprint-planning-guide/sprint-goal/) is its own skill.
- **What can be done this sprint?** The developers pull items from the top of the backlog that serve the goal, until they hit the edge of their [capacity](/guides/sprint-planning-guide/velocity-and-capacity/). This is a forecast, not a promise extracted under oath.
- **How will the chosen work get done?** The team breaks the top items into enough of a plan to start: tasks, an approach, the obvious risks. Not every item to the last subtask; enough to begin with confidence.
The output is a sprint backlog: the goal, the selected items, and the plan for delivering them.
## Scope first, then plan
The single most useful structural habit is to run planning in two distinct passes rather than one blurry one.
**Part one is scope.** The product owner presents the goal and the candidate items in priority order. The team asks clarifying questions, checks each item against the [definition of ready](/guides/agile-estimation-guide/definition-of-ready/), and pulls work until capacity runs out. Stop there. The temptation to squeeze in "just one more" small story is exactly how sprints overcommit.
**Part two is plan.** Now the team goes deep on the items it selected, decomposing them into tasks, spotting dependencies, agreeing who picks up what first. This is where you find the story that looked like a 3 and is actually a week of work hiding behind a vague acceptance criterion.
Keeping the two apart stops the meeting from thrashing between "should we take this?" and "how would we build it?" on every single item.
Planning is a conversion: refined backlog and known capacity in, a believable sprint backlog out. If the inputs are missing, no amount of meeting fixes the output.
## What you need in the room
Sprint planning only works if its inputs arrive ready. The meeting converts inputs into a plan; it does not manufacture them on the spot.
- **A refined, prioritized backlog.** The top items should already be understood and roughly sized. If planning is the first time the team sees a story, you are doing [backlog refinement](/guides/agile-ceremonies-guide/backlog-refinement/) in the wrong meeting, and it will run long. Refinement is the feeder; planning is the decision.
- **A real capacity number.** Not "two weeks times the team size", but the hours actually available after leave, meetings, support rotations, and the interrupt tax. See [velocity and capacity planning](/guides/sprint-planning-guide/velocity-and-capacity/).
- **The whole team.** The developers make the forecast, so the developers have to be there. Planning by proxy produces commitments nobody owns.
## Who runs it
The **Scrum Master** facilitates: protects the timebox, keeps the two passes separate, and stops the meeting sliding into solutioning every edge case. The **product owner** brings the goal and the ordered backlog, and answers "why" and "what" questions on the spot. The **developers** decide how much they take on and how they will build it.
That last point matters: the forecast belongs to the people doing the work. A plan handed down and accepted in silence is not a commitment. It is a queue.
## How long it should take
The Scrum Guide timeboxes planning at up to eight hours for a one-month sprint, and proportionally less for shorter ones, so roughly **two hours per week of sprint**. A two-week sprint should land around four hours, often less once a team has a steady cadence.
Treat that as a ceiling, not a target. Teams that reliably need the full timebox are almost always refining during planning. Fix the input, and the meeting shortens on its own. If you want a minute-by-minute breakdown, the [sprint planning agenda](/guides/sprint-planning-guide/sprint-planning-agenda/) chapter lays one out.
**Pro tip:** end planning by asking the team a single question: "does everyone believe we can finish this, goal and all?" A quiet room is not a yes. If someone hesitates, cut scope now. It is far cheaper than discovering the gap on the last day.
## Where it goes wrong
Three failure modes account for most bad planning meetings.
**The reading session.** The product owner narrates tickets and the team listens. No decision gets made because no one is deciding; they are being briefed. Planning should feel like the team choosing, not being assigned.
**The overcommit.** Capacity gets treated as a stretch goal. The team pulls its best-ever velocity as a floor and adds a little for ambition. Then a support fire, a sick day, and one under-estimated story turn the sprint into a scramble. Plan with the humble number, not the heroic one.
**Planning without a goal.** The team selects a grab-bag of unrelated tickets, and when the sprint gets tight there is no principle for what to drop, so everything slips a little and nothing ships clean. The goal is what tells you which tickets to abandon under pressure.
Get the inputs ready, keep scope and plan apart, and let the team own the forecast. The rest of this guide goes deep on each piece. Start with the [agenda](/guides/sprint-planning-guide/sprint-planning-agenda/) or grab the [sprint planning template](/guides/sprint-planning-guide/sprint-planning-template/).
## Frequently asked questions
### What is sprint planning?
Sprint planning is the Scrum event that opens a sprint. The team agrees a sprint goal, selects the backlog items it forecasts it can finish, and sketches how the work will get done. It answers three questions: why the sprint is valuable, what will be built, and how.
### How long should sprint planning take?
Timebox it to about two hours per week of sprint, so roughly two hours for a one-week sprint, four for a two-week sprint, up to eight for a month. That is a ceiling, not a target. If you consistently need the full timebox, the backlog usually was not ready going in.
### What are the key steps in sprint planning?
Confirm the team's real capacity for the sprint; agree a sprint goal; pull backlog items that serve that goal until you reach capacity; break the top items into a workable plan; and confirm the team believes the forecast. Scope first, then plan, in that order.
### Who runs sprint planning?
The Scrum Master facilitates and keeps it timeboxed. The product owner brings a prioritized, refined backlog and explains the why. The developers decide how much they can take on and how they will build it: the forecast is theirs to make, not the product owner's to assign.
---
# Sprint planning template (copy-paste)
URL: https://www.teamretro.com/guides/sprint-planning-guide/sprint-planning-template/
A sprint planning template is a simple, repeatable structure for capturing the output of planning: the sprint goal, the team's capacity, the work selected, and whether the team believes it can finish. Its job is to make sure the same four things get decided every sprint, and that nothing important gets left implicit.
Copy the template below into whatever you plan in: a doc, a wiki page, your issue tracker, or [TeamRetro](/standups/). Fill it in *during* the meeting, top to bottom, in the order you run it.
## The template
Copy this into your doc, wiki, or tracker and fill it in as you go:
```markdown
# Sprint planning — Sprint #___
Dates: ___ to ___ · Team: ___
## Sprint goal
One sentence. What is meaningfully different or shippable when this sprint ends?
> ___
## Capacity this sprint
- Working days available: ___
- Known time off / holidays: ___
- Standing meetings & ceremonies: ___
- Support / on-call load: ___
- Realistic capacity: ___ (in the unit you plan in — points or days)
## Selected backlog items
| # | Item | Estimate | Serves the goal? | Owner (first) | Notes / risks |
|---|------|----------|------------------|---------------|---------------|
| 1 | | | | | |
| 2 | | | | | |
| 3 | | | | | |
| | Total| ___ | | | |
Dependencies & risks: ___
Parking lot (raised, not solved here): ___
## Commitment check
Does the whole team believe we can finish the selected work and meet the goal?
[ ] Yes [ ] Not yet — cut scope
```
That is the whole thing. Resist adding fields. Every box that does not change a decision is a box someone fills in out of habit and no one reads.
## How to use it
The order of the fields is the order of the meeting, and it is deliberate.
1. **Capacity before scope.** Fill in capacity first so selection has a hard limit. Teams that leave capacity blank until the end always overcommit, because the pile of tickets sets the number instead of the calendar. Work out the honest figure using [velocity and capacity planning](/guides/sprint-planning-guide/velocity-and-capacity/).
2. **Goal before items.** Write the [sprint goal](/guides/sprint-planning-guide/sprint-goal/) before pulling work, then use it as the test for every candidate item. The "serves the goal?" column is not decoration: an item that earns a "no" is a candidate to cut when the total runs over.
3. **Pull until the total hits capacity, then stop.** Watch the estimate total against your capacity number. When they meet, selection is done. If you are unsure how to size items, that is [estimation](/guides/agile-estimation-guide/), and it belongs in refinement. [Planning poker](/free-planning-poker-for-agile-teams/) is a fast way to reach a shared number.
4. **Make the commitment check real.** The last box is the one people skip, and it is the most valuable. A soft "yes" now is a missed sprint later. If the room hesitates, cut scope until they mean it.
**Pro tip:** keep last sprint's completed template open beside the new one. Comparing what you planned against what actually finished is the fastest way to calibrate capacity, and it turns the [retrospective](/guides/scrum-masters-retrospective-guide/) into a data-backed conversation instead of a vibe.
## Fill it in live, not after
A template completed after the meeting is a record. A template filled in during the meeting is a plan: it forces the decisions to happen out loud, in front of the people who have to deliver them. If the capacity box is still empty at item selection, the meeting knows it has skipped a step.
This is also why a shared, editable surface beats a private doc for remote teams: everyone watches the total tick up against capacity in real time, so overcommitment is visible the moment it happens rather than discovered when the plan is read back.
## When a template turns into a tool
A document is the right place to start, and for a small co-located team it may be all you ever need. You outgrow it at a predictable point: when keeping the template, the estimates, the capacity, and the board in sync by hand becomes its own chore. At that point a purpose-built tool stops being overhead and starts saving time: estimates flow from planning poker into the plan, capacity is tracked per person, and the sprint backlog is the board, not a copy of it. The [sprint planning tools](/guides/sprint-planning-guide/sprint-planning-tools/) chapter covers what to look for and where the honest limits are.
Whichever you use, the four fields do not change: goal, capacity, selection, commitment. Get those written down every sprint and most planning problems never form.
## Frequently asked questions
### What should a sprint planning template include?
Four things at minimum: the sprint goal in one sentence, the team's real capacity for the sprint, the selected backlog items with their estimates, and a commitment check. Everything else (attendees, dates, risks, parking lot) is useful but optional. If a field is not going to change a decision, cut it.
### How do you fill in a sprint planning template?
Work top to bottom in the order you run the meeting: capacity first so scope has a limit, then the goal, then pull items until the estimate total reaches capacity, then confirm the team believes it. Fill it in live during planning, not afterwards. A template completed after the meeting is a record, not a plan.
### Do you need a tool for sprint planning, or is a template enough?
A shared document is enough to start and beats no structure at all. A tool earns its place once you want estimates, capacity, and the board to stay in sync automatically, or when planning is remote and you need everyone editing at once. Start with the template; adopt a tool when the copying-between-places tax gets annoying.
---
# Sprint planning tools: Jira, TeamRetro, and what to look for
URL: https://www.teamretro.com/guides/sprint-planning-guide/sprint-planning-tools/
Sprint planning tools exist to remove friction from the meeting, not to replace the thinking. Before you compare products, get clear on the three distinct jobs planning actually needs covered, because no single tool does all three well, and paying for one that claims to usually means paying for features you will never use.
## The three jobs a tool has to cover
- **Hold the backlog and the board.** Where the work lives, gets prioritized, and moves through the sprint. This is an issue tracker: Jira, Linear, Azure DevOps, GitHub Projects. It is the system of record for *what* the work is.
- **Reach a shared estimate.** A fast, fair way for the team to size items together without the loudest voice anchoring everyone. This is [planning poker](/free-planning-poker-for-agile-teams/), and it is a different job from tracking the tickets.
- **Run the meeting and the ceremonies around it well.** A [goal](/guides/sprint-planning-guide/sprint-goal/) the team can see, a [standup](/guides/daily-standup-guide/) to defend it, and a [retrospective](/guides/scrum-masters-retrospective-guide/) to improve how you plan next time. This is the human layer, and it is the one issue trackers do worst.
Most teams over-invest in the first job and under-invest in the third, then wonder why a well-tracked sprint still misses its goal.
## Where Jira fits
Jira owns the backlog and board for a very large share of software teams, and "jira sprint planning" is one of the fastest-growing searches in this space (up around 84% year on year) because more teams are formalizing how they run the meeting inside it. That growth is a fair reflection of what Jira is good at: a prioritized backlog, a sprint board, capacity fields, and the reporting that follows the work through the sprint.
Where Jira is thin is the human side of planning. Its estimation is a number in a field, not a conversation. That does nothing to stop the senior engineer's guess from becoming the team's estimate. It has no real facilitation for the meeting, and its retrospective story is an afterthought. None of that is a knock on Jira; it is an issue tracker, and a good one. It is just not the whole toolkit.
If Jira is your system of record, keep it. The goal is not to replace it. It is to add the estimation and facilitation layer around it, and to make the two talk to each other instead of maintaining the same information in two places.
## Where TeamRetro fits
TeamRetro deliberately does not try to be your issue tracker. It covers the parts of the planning cycle that a tracker leaves thin, and connects back to the tracker rather than competing with it:
- **[Planning poker](/free-planning-poker-for-agile-teams/)** for estimates the whole team reaches together: private votes revealed at once, so the discussion happens where the numbers disagree instead of everyone deferring to the first guess.
- **[Daily standups](/standups/)** to keep the sprint goal in front of the team and surface blockers while there is still time to act on them.
- **[Health checks](/health-checks/)** to catch the team-level problems (unclear priorities, chronic overcommitment) that quietly wreck planning before they show up in the velocity chart.
- **[Retrospectives](/retrospectives/)** to turn "we overcommitted again" into a tracked change to how you plan, sprint after sprint.
Crucially, it [integrates with Jira](/integrations/jira/) (and [Slack](/integrations/slack/) and [Microsoft Teams](/integrations/microsoft-teams/)), so estimates and outcomes flow back to the board rather than living in a separate silo. For teams standardizing this across many squads, that connective layer (plus SOC 2 Type 2 and cross-team reporting) is what makes rolling it out an easy yes. The [Scrum Master solution](/solutions/scrum-masters-solution/) page covers that scaled-up case in more detail.
## What to look for, and what to ignore
When you do compare tools, weigh them on the jobs above, not on feature-count:
- **Does it reduce a friction you actually have?** Remote teams need everyone editing at once; a co-located team of four may not. Buy for your real problem.
- **Does it integrate, or duplicate?** A tool that makes you re-enter what is already in your tracker adds work. One that syncs removes it.
- **Does it make estimation a conversation?** If sizing is just a field, you will keep getting the loudest person's number.
- **Is the meeting facilitated, or just recorded?** Timeboxing, a visible goal, and a structured flow are worth more than another dashboard.
Ignore long feature lists and "AI-powered" everything. The best planning tool is the smallest set of things that covers the three jobs and gets out of the way. Start with the [template](/guides/sprint-planning-guide/sprint-planning-template/); add a tool the moment keeping things in sync by hand becomes the chore.
## Frequently asked questions
### What is the best tool for sprint planning?
There is no single best tool. Planning needs three jobs covered: a backlog and board (an issue tracker like Jira), a way to estimate together (planning poker), and a way to run the meeting and the surrounding ceremonies well. Pick the issue tracker your team already lives in, add estimation and facilitation around it, and make sure they integrate rather than duplicate.
### Does Jira do sprint planning?
Yes. Jira handles the backlog, sprint board, and capacity tracking, which is why "jira sprint planning" is one of the fastest-growing searches in this space. What Jira does not do well is the human side: shared estimation, a facilitated meeting, and the retrospective that improves your planning. Those are worth adding around it, and TeamRetro integrates with Jira to do exactly that.
### Do you need a dedicated sprint planning tool?
Not to start. A shared template in a document is enough for a small co-located team. You need tooling once estimates, capacity, and the board drift out of sync by hand, or once planning is remote and everyone needs to edit at once. Add tools to remove a real friction, not to look organized.
### How does TeamRetro help with sprint planning?
TeamRetro covers the parts of the planning cycle that an issue tracker leaves thin: planning poker for shared estimates, daily standups to defend the sprint goal, health checks to catch team problems early, and retrospectives to improve how you plan. It integrates with Jira so the estimates and outcomes flow back to your board rather than living in a separate silo.
---
# Sprint planning vs backlog refinement
URL: https://www.teamretro.com/guides/sprint-planning-guide/sprint-planning-vs-backlog-refinement/
Sprint planning and backlog refinement are two different meetings that get confused because they share a cast and a subject. The clean distinction: **refinement gets the backlog ready; planning decides what to commit.** Refinement is the feeder. Planning is the decision. Blur the two and you break both.
## The boundary
Backlog refinement is the ongoing work of getting upcoming items ready: clarifying what they mean, sizing them, splitting the ones too big for a sprint, and attaching enough detail that the team could pick one up without a scavenger hunt. It happens throughout the sprint, ahead of planning, and it never really finishes because the backlog never stops growing.
Sprint planning is a single meeting at the start of the sprint where the team takes those *already-ready* items and decides which to commit to, in service of a [sprint goal](/guides/sprint-planning-guide/sprint-goal/), and how it will build them.
The tell is the question each meeting answers. Refinement answers "is this item ready to be worked on?" Planning answers "which of the ready items are we doing next, and can we finish them?" One prepares; the other commits.
| | Backlog refinement | Sprint planning |
|---|---|---|
| **Job** | Get items ready: clarify, size, split | Decide what to commit and how |
| **Question it answers** | Is this ready to work on? | Which ready items, and can we finish? |
| **When** | Ongoing, through the sprint | Once, at the start of the sprint |
| **Output** | A ready top-of-backlog | A sprint goal + sprint backlog |
| **Led by** | Product owner | Whole team (developers forecast) |
## Why blurring them breaks both
When refinement does not happen, planning absorbs it, and that is where the four-hour planning meeting comes from. The team spends the meeting discovering what items even mean, arguing about size, and realizing a story is too big to fit, all while the clock meant for deciding and planning drains away. You leave with a rushed, low-confidence commitment made under time pressure.
The reverse failure is quieter. When refinement tries to do planning's job (sizing items *and* implicitly committing to them weeks out), the team ends up mentally locked into work it has not agreed to, against a goal that does not exist yet. Priorities shift, and now there is sunk-cost attachment to a plan nobody formally made.
Keep them apart and each does its job well. A steady drip of refinement through the sprint means the top of the backlog is always ready, which means planning can be short and focused on the decision. This is the single biggest lever on planning-meeting length: a planning meeting that runs long is almost always a refinement meeting that never ran.
## How they hand off
Think of it as a pipeline. Refinement keeps a buffer of ready items at the top of the backlog, enough for the next sprint or two. Planning draws from that buffer. If the buffer is full and ordered, planning is a matter of pulling from the top until you hit [capacity](/guides/sprint-planning-guide/velocity-and-capacity/) and agreeing the plan. If the buffer is empty, planning has to refill it on the spot, and the meeting pays for refinement's absence.
The [definition of ready](/guides/agile-estimation-guide/definition-of-ready/) is the contract at the handoff: the checklist an item must pass in refinement before it is eligible for planning. It is what stops half-baked items from leaking into the planning meeting and turning it back into refinement.
## Can you combine them?
You can, and small or early teams sometimes do run a single session that refines the next items and plans the sprint. It is a reasonable compromise when the backlog is tiny and the team is co-located. But it is a compromise, not a target: the combined meeting tends to run long and blur the two jobs, and it scales badly as the backlog grows.
Once you can, split them. A short, regular refinement session, even 30–45 minutes a week, is what buys you a short, focused planning meeting. Most teams that complain planning takes too long do not have a planning problem; they have a refinement gap.
## Where each sits in the bigger picture
Refinement and planning are two links in the sprint's chain of events, and both are covered in the [agile ceremonies guide](/guides/agile-ceremonies-guide/) alongside the daily scrum, review, and retrospective. If you want to fix long planning meetings, start upstream: read the [backlog refinement chapter](/guides/agile-ceremonies-guide/backlog-refinement/) for how to run refinement well, then use this guide's [agenda](/guides/sprint-planning-guide/sprint-planning-agenda/) to keep planning to the decision it is supposed to be.
## Frequently asked questions
### What is the difference between sprint planning and backlog refinement?
Backlog refinement gets upcoming backlog items ready (clarified, sized, and split) so they can be worked on. Sprint planning decides which of those ready items the team commits to next sprint, and how it will build them. Refinement is the feeder; planning is the decision. Refinement is ongoing; planning happens once per sprint.
### Does backlog refinement happen before or during sprint planning?
Before, and ideally not in the same meeting. Refinement runs through the sprint, ahead of planning, so that by the time planning starts the top of the backlog is already understood and sized. If you are clarifying and estimating items during planning, refinement did not happen, and planning will run long.
### Can you combine backlog refinement and sprint planning?
You can, and very small or early teams sometimes do, but it is a compromise, not a best practice. Combined, the meeting tends to run long and blur deciding with getting-ready. Keep them separate once you can: a short, regular refinement session protects a short, focused planning meeting.
### Who runs backlog refinement?
The product owner leads it (they own the backlog and its priority), with the developers doing the clarifying and sizing. The Scrum Master facilitates if needed. It is the same cast as sprint planning, which is part of why the two get confused, but the jobs are different.
---
# Sprint retrospective: the ceremony that closes the loop
URL: https://www.teamretro.com/guides/agile-ceremonies-guide/sprint-retrospective/
The sprint retrospective is the ceremony that closes the sprint. Where the [sprint review](/guides/agile-ceremonies-guide/sprint-review/) inspects the product, the retrospective inspects the team (its process, its habits, the friction it hit) and turns that reflection into a short list of changes to try next sprint. It's the last of the ceremonies and the one that makes the others get better over time.
This is TeamRetro's home ground, so this chapter stays short on purpose: it places the retrospective in the wider cycle and hands you to the guide we've put the most work into.
## Where the retrospective closes the loop
The ceremonies form a loop, not a line. Planning sets direction, the daily scrum keeps it coordinated, the review checks the product, and the retrospective feeds what the team learned straight back into the next round of planning.
That feedback arrow is the whole point. A team that runs planning, standups, and reviews but skips the retrospective can repeat the same mistakes sprint after sprint with perfect cadence. The retrospective is where the loop actually becomes a loop, the place where "how we work" is allowed to change.
Two guardrails make it work, and both are covered in depth in the full guide: keep it **team-only** (it's the counterweight to the outward-facing review, and candor dies with stakeholders in the room), and end with **a small number of owned actions**, not a wall of complaints. One change the team actually makes beats ten it merely names. A retro that reliably produces words and no change has slipped into [agile theatre's follow-through void](/guides/agile-theatre/the-follow-through-void/), the failure mode where the meeting runs fine and nothing downstream moves.
## Go deeper: the retrospective guide
The rest of this ceremony has a guide of its own. Rather than repeat it, start here:
- [What is a sprint retrospective?](/guides/scrum-masters-retrospective-guide/what-is-a-sprint-retrospective/): the full definition, stages, and purpose.
- [The Scrum Master's retrospective guide](/guides/scrum-masters-retrospective-guide/): the complete hub covering psychological safety, facilitation, formats, and templates.
- [Choosing a retrospective template](/guides/scrum-masters-retrospective-guide/retrospective-templates/): when you're ready to run one.
- [Sprint review vs sprint retrospective](/guides/scrum-masters-retrospective-guide/sprint-review-vs-retrospective/): how the two closing ceremonies differ.
And on the product side: [TeamRetro retrospectives](/retrospectives/) and the classic [agile retrospective format](/guides/scrum-masters-retrospective-guide/) if you want to run one now.
## Frequently asked questions
### Is the retrospective a Scrum ceremony?
Yes. The sprint retrospective is the last of the four Scrum ceremonies (or the fifth event, if you count the sprint itself as the container). It's the only one focused on the team rather than the product, and it's the engine of continuous improvement.
### Where does the retrospective sit in the sprint?
Last, after the sprint review and before the next sprint's planning. Running it after the review means the team can carry fresh product feedback into its reflection; running it before planning means the improvements it agrees on can shape how the next sprint is run.
---
# Sprint review: purpose, attendees, and how to run one
URL: https://www.teamretro.com/guides/agile-ceremonies-guide/sprint-review/
The sprint review is the ceremony where the team shows working product to stakeholders and gathers the feedback that reshapes what it builds next. It happens at the end of the sprint, it's timeboxed to about two hours for a two-week sprint, and its output is a changed product backlog. The thing to hold onto: it's a working session, not a performance. The value isn't the demo. It's the decisions the demo triggers.
## What the sprint review is for
The review exists to answer one question with the people who care about the outcome: *given what we just built, what should we build next?*
The team presents the increment (the work that's genuinely done, against the [definition of done](/guides/agile-estimation-guide/definition-of-done/), not the work that's nearly there) and the stakeholders in the room respond. They ask questions, they push back, they notice the thing nobody thought to mention in planning. That reaction is the product of the meeting. It flows straight into the [product backlog](/guides/scrum-masters-retrospective-guide/scrum-artifacts/), which the product owner adjusts on the spot or shortly after.
**Pro tip:** if your sprint review ends and the backlog looks exactly as it did before, the review didn't do its job. A review that changes nothing was a status update wearing a demo's clothes.
## Sprint review vs demo
People use "sprint review" and "the demo" as if they're the same meeting. They're not: the demo is one *part* of the review.
Showing the working software matters: it forces honesty (you can't demo a nearly-finished feature) and it gives everyone the same concrete thing to react to. But if the demo is all that happens (the team presents, stakeholders clap, everyone leaves), you've run a one-way broadcast. The review is the two-way conversation the demo is supposed to start. The demo is the setup; the feedback and the re-prioritization are the point. A demo performed for applause with no decisions behind it is [agile theatre](/guides/agile-theatre/performance-agile-theatre/): the ceremony run for the audience instead of the outcome.
## Who attends, and why it faces outward
The sprint review is the one ceremony built to face outward. Attendees are the whole [Scrum Team](/guides/scrum-masters-retrospective-guide/scrum-roles/) plus the stakeholders the product owner invites: customers, users, sponsors, support, anyone whose reaction should influence the product.
That guest list is a decision, not a formality. Invite people who can give feedback worth acting on, and curate ruthlessly: a room full of spectators produces polite noise; a room with the right three customers produces a re-ordered backlog. This outward stance is exactly what separates the review from the [sprint retrospective](/guides/agile-ceremonies-guide/sprint-retrospective/), which is team-only and private for a reason.
## How to run one that's worth the hour
The format is deliberately light. Keep it a working session, not a stage show.
- **Open with the sprint goal.** Remind the room what this sprint set out to achieve, so the increment is judged against intent, not vibes.
- **Show working product, not slides.** Demo the real thing against the definition of done. Skip the near-done. It invites debate about work that isn't finished.
- **Make space for reaction.** The team should be listening more than presenting. Questions, objections, and "could it also…" are the material you came for.
- **Close by updating the backlog.** Fold the feedback into priorities while it's fresh. That's the artifact the meeting produces.
Preparation is mostly restraint: pick what to show, make sure it actually runs, and resist the urge to build a deck. Ten minutes of a feature working beats forty minutes of screenshots of it.
## Sprint review vs sprint retrospective
The two closing ceremonies get confused constantly, so hold the line: the review inspects **the product** with stakeholders; the retrospective inspects **the team's process**, privately. The review faces outward and runs first; the retrospective faces inward and runs second, so the team can carry fresh product feedback into its own reflection.
They don't combine well. Nobody raises "our testing is rushed" in front of the customer, so merging them quietly kills the honest half. We keep the full comparison, including who attends each and why to keep them apart, in [sprint review vs sprint retrospective](/guides/scrum-masters-retrospective-guide/sprint-review-vs-retrospective/). For where both sit among the rest of the meetings, see [the four Scrum ceremonies](/guides/scrum-masters-retrospective-guide/scrum-ceremonies/) and [this guide's other ceremonies](/guides/agile-ceremonies-guide/).
## Frequently asked questions
### What is the purpose of a sprint review?
To inspect the product increment with stakeholders and adapt what happens next. The team shows what it actually finished, stakeholders react, and that reaction feeds back into the product backlog. The point isn't the applause. It's the course correction. A review that changes nothing about the plan was a status meeting in disguise.
### Who attends a sprint review?
The whole Scrum Team plus the stakeholders the product owner invites: customers, users, sponsors, anyone whose feedback should shape the product. It's the one ceremony that deliberately faces outward. The product owner curates the guest list so the feedback in the room is worth acting on.
### How long should a sprint review be?
Timebox it to about two hours per week of sprint: up to two hours for a two-week sprint, up to four for a month-long one. If it's overrunning, you're probably presenting slides instead of showing working product, or reviewing work that wasn't actually done.
### What is the difference between a sprint review and a demo?
A demo is one activity inside the review: showing the working software. The sprint review is the wider conversation the demo starts: stakeholders reacting, priorities shifting, the backlog changing. Treat the review as only a demo and you get a one-way presentation that produces nods and no decisions.
### What is the difference between a sprint review and a retrospective?
The sprint review inspects the product with stakeholders, to decide what to build next. The retrospective inspects the team's own process, privately, to work better next sprint. The review faces outward and comes first; the retrospective faces inward and comes second. You need both, and they don't combine well.
---
# Sprint Review vs Sprint Retrospective
URL: https://www.teamretro.com/guides/scrum-masters-retrospective-guide/sprint-review-vs-retrospective/
The **Sprint Review** and the **Sprint Retrospective** are two different ceremonies that happen at the end of every Sprint and are often confused. The simplest way to tell them apart: the Sprint Review inspects **the product** with stakeholders, while the Sprint Retrospective improves **the way the team works**. You need both, and they are not interchangeable.
If you are new to the full set of Scrum meetings, see [the four Scrum ceremonies explained](/guides/scrum-masters-retrospective-guide/scrum-ceremonies/) first. This chapter zooms in on the two that close the Sprint.
## Sprint Review vs Sprint Retrospective at a glance
| | Sprint Review | Sprint Retrospective |
|---|---|---|
| **Focus** | The product (what was built) | The process (how the team worked) |
| **Question it answers** | "What should we build next?" | "How can we work better next Sprint?" |
| **Faces** | Outward, to stakeholders | Inward, to the team |
| **Who attends** | Scrum Team + stakeholders | Scrum Team only |
| **Output** | Updated Product Backlog | A short list of team improvements |
| **Order** | First | Second |
| **Timebox (2-week Sprint)** | Up to ~2 hours | Up to ~90 minutes |
## What the Sprint Review is for
The Sprint Review is a working session where the team demonstrates the work completed during the Sprint and gathers feedback. Stakeholders see what is actually done, ask questions, and react. That reaction often reshapes the Product Backlog and the direction of the next Sprint. It is a collaboration about *the product and what to do next*, not a one-way demo or a sign-off meeting.
## What the Sprint Retrospective is for
The Sprint Retrospective is the team's private opportunity to inspect *itself* (its people, relationships, process, and tools) and to commit to concrete improvements. It happens after the Review so the team can fold in any product feedback, and it deliberately excludes stakeholders so people can speak candidly. The output is not a product decision but a small, owned set of actions the team will try next Sprint. This is the engine of continuous improvement, and it is the subject of the rest of this guide. Start with [what a sprint retrospective is](/guides/scrum-masters-retrospective-guide/what-is-a-sprint-retrospective/).
## Why you need both
It is tempting to fold the two together to save time, but they pull in different directions. The Review is outward-facing and product-focused; the Retrospective is inward-facing and team-focused. Combine them and the honest, sometimes uncomfortable, process conversation gets squeezed out. Nobody wants to raise "our testing is rushed" in front of the customer. Keeping them separate protects the psychological safety the retrospective needs (see [building a psychologically safe retrospective](/guides/scrum-masters-retrospective-guide/how-to-build-a-psychologically-safe-space/)).
It is also worth distinguishing the Sprint Retrospective from a longer-cycle review such as a release or project retrospective. For that comparison, see our article on the [sprint retrospective versus the release retrospective](/blog/sprint-retrospective-vs-release-retrospective/).
## Frequently asked questions
### What is the difference between a Sprint Review and a Sprint Retrospective?
The Sprint Review inspects the product, with the team demonstrating what it built and gathering feedback from stakeholders to decide what to do next. The Sprint Retrospective inspects the process, with the team reflecting on how it worked and agreeing improvements for the next Sprint. The Review is about the "what" and faces outward to stakeholders; the Retrospective is about the "how" and faces inward to the team.
### Which comes first, the Sprint Review or the Retrospective?
The Sprint Review comes first, followed by the Sprint Retrospective, and both happen at the end of the Sprint. Reviewing the product with stakeholders first means the team carries that fresh feedback into the retrospective, where it reflects on how it worked and what to change.
### Can you combine the Sprint Review and Retrospective into one meeting?
It is best to keep them separate. They have different goals, different attendees, and different tones. The Review is an outward-facing product conversation with stakeholders, while the Retrospective is a candid, team-only conversation about how to improve. Merging them tends to crowd out the honest reflection the retrospective depends on, because people are reluctant to raise process problems in front of stakeholders.
### Who attends the Sprint Review and the Sprint Retrospective?
The Sprint Review is attended by the whole Scrum Team plus key stakeholders invited by the Product Owner, because its purpose is to gather feedback on the product. The Sprint Retrospective is attended by the Scrum Team only (the Developers, the Product Owner, and the Scrum Master) so the team can speak openly about how it works.
---
# The 5 stages of team development (and what to run at each)
URL: https://www.teamretro.com/guides/team-dynamics/stages-of-team-development/
The stages of team development are the phases a group tends to move through as it comes together: forming, storming, norming, performing, and adjourning. Bruce Tuckman named the first four in a 1965 review of small-group research; the fifth was added in 1977. Each stage has a distinct feeling, an honest signal to read past it, and a specific thing worth running.
The model is famous because it is easy to remember, not because it was ever proven. Read it as a way to take the temperature of a team, not as a timetable the team will keep. The question that matters is not which stage you are in. It is what to do about it.
## Where the model comes from (and what it is not)
Tuckman's 1965 paper, *Developmental Sequence in Small Groups*, was a literature review of roughly fifty studies of therapy and training groups, not an experiment ([Tuckman 1965, summarized by MindTools](https://www.mindtools.com/abyj5fi/forming-storming-norming-and-performing/)). He described a pattern he noticed in other people's data. In 1977, with Mary Ann Jensen, he reviewed a further set of studies and added a fifth stage, adjourning, for the ending of a team ([Tuckman and Jensen, 1977](https://journals.sagepub.com/doi/10.1177/105960117700200404)). So the model is a synthesis of observation, and that origin sets a sensible ceiling on how literally to take it.
## The stages, and what to run at each
Here is the useful version. For each stage: what it feels like, the signal most explanations skip, and the intervention worth running. The table is the map; the detail is below it.
| Stage | What it feels like | What to run |
|---|---|---|
| Forming | Polite and cautious; people defer to whoever leads | Icebreakers, a check-in ritual, a first charter |
| Storming | Friction over who owns what and how work gets done | Working agreements, a safe space, regular retros |
| Norming | The team finds its rhythm and roles get clearer | Lock in the charter, run a health check |
| Performing | The team runs itself with little drama | Protect the cadence, keep measuring |
| Adjourning | Work wraps up and energy dips | A closing retro to capture what you learned |
### Forming: polite, and waiting to be told
**What it feels like.** New teams are careful. People defer to whoever seems in charge, and keep their real opinions soft. There is often energy, but it sits on the surface.
**The honest signal.** Silence is not agreement at this stage. It is people who do not yet feel safe enough to disagree. A forming team that looks harmonious is usually just guarded, and the harmony breaks the moment real work creates friction.
**What to run.** This is the thaw. Lower the cost of disagreement before you need it. Run a round of [icebreakers](/icebreakers/) that surface something real rather than trivia, open every meeting with a short [check-in](/icebreakers/check-in-questions/), and start writing down how the team will work together. The full method for warming a cold or new team is in [how to defrost a team](/guides/team-dynamics/how-to-defrost-a-team/). To do it live, [Two Truths and a Lie](https://games.teamretro.com/games/two-truths-and-a-lie/) or [This or That](https://games.teamretro.com/games/this-or-that/) get a new group talking within a few minutes.
### Storming: friction surfaces
**What it feels like.** Once people are comfortable enough to be honest, the differences appear. There are arguments about who owns what and how the work should be done, and it can feel as though the team is sliding backward.
**The honest signal.** Storming out loud is a good sign. The failure mode is storming underground, where disagreement gets swallowed to keep the peace and then leaks out as quiet resistance. Suppressing conflict to protect harmony is the real problem, not the conflict itself. And if your team never visibly storms, do not force it: in Tuckman's own review, only about half the groups showed a distinct conflict stage ([per the criticism summarized on Wikipedia](https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development)).
**What to run.** Make disagreement safe and give it structure. Agree a set of [team norms and working agreements](/guides/team-dynamics/team-norms-and-working-agreements/) that spell out how you make decisions and handle conflict. Build the [trust and psychological safety](/guides/team-dynamics/building-trust-and-psychological-safety/) that lets hard things get said in the room rather than in the corridor; Amy Edmondson's study of 51 work teams found psychological safety associated with more learning behavior and better performance ([Edmondson, 1999](https://journals.sagepub.com/doi/10.2307/2666999)). A regular [retrospective](/retrospectives/) then gives friction a scheduled, low-stakes outlet.
### Norming: the agreements settle
**What it feels like.** The team finds its rhythm. Roles get clearer, people start to rely on each other instead of routing everything through the manager, and trust begins to compound.
**The honest signal.** Watch for false harmony. Norming can quietly slide into avoiding the very disagreements that made storming useful, which is the leading edge of [groupthink](/guides/team-dynamics/group-dynamics/). A team that has stopped arguing altogether may have stopped thinking critically together.
**What to run.** Lock in what works. This is the refreeze: turn the habits you want to keep into an explicit [team charter](/guides/team-charter/) and put a date in the calendar to revisit it. Then start measuring the team's state with a [health check](/health-checks/), so trust and clarity become something you can see and track rather than guess at.
### Performing: the team delivers
**What it feels like.** The team runs itself. People self-organize and handle disagreement without it turning into drama. This is the stage everyone wants, and the one that is hardest to hold.
**The honest signal.** Performing is fragile, and it rewards maintenance over neglect. The measure that counts is not how good a discussion feels but whether decisions turn into finished work. A team that follows through is performing; a team that only meets well is not.
**What to run.** Protect the cadence. Keep the check-ins and retrospectives even when the work is going well, because that rhythm is what holds the stage in place. Re-run the same health check on a regular beat to catch drift early, while it is still cheap to fix.
### Adjourning: the team ends
**What it feels like.** The work wraps up and the team disbands or reforms. Energy usually dips, and there is a sense of loss even when the project went well.
**The honest signal.** The temptation is to skip the ending and roll straight into the next thing. That wastes the most reflective moment a team ever gets.
**What to run.** Close on purpose. Run a final retrospective to capture what the team learned and to name what each person brought to it. If part of the group carries forward into new work, remember that it starts at forming again, whatever it achieved together before.
## The honest limitation: it describes, it does not predict
This is where most explanations of Tuckman go quiet, so three things are worth saying plainly.
First, the evidence is thinner than the model's fame suggests. It came from reviewing other people's studies, and in the 1965 review only about half of them showed a clear storming stage; some groups moved straight from forming to norming. The stages describe a common pattern, not a law.
Second, teams do not move in a straight line. Even strong teams slide back to earlier stages under pressure, a reorganization, or a missed deadline. Regression is ordinary, not a relapse to be ashamed of.
Third, the model resets. The day a new person joins or a key person leaves, the team is partly back to forming, whatever the org chart says it reached. This is exactly why the what-to-run column never retires: a team that gained a member this quarter needs the forming moves again, not a certificate that says it is performing.
So do not call the model proven, and do not use it to grade a team. Use it to name what the team is feeling and to choose the next intervention.
## The discipline complement: the team performance curve
Tuckman tells you how a team feels as it grows. It says nothing about what a team owes itself to become good. For that, the more demanding companion is Jon Katzenbach and Douglas Smith's team performance curve, from *The Wisdom of Teams* (1993) ([Katzenbach and Smith, via Praxis](https://www.praxisframework.org/en/library/katzenbach-and-smith)). They define a team narrowly: a small number of people with complementary skills, committed to a common purpose and set of goals, who hold themselves mutually accountable for how they get there.
Their curve runs through five points: working group, pseudo-team, potential team, real team, and high-performing team. The warning in the middle is the part worth keeping. A pseudo-team, a group that calls itself a team but shares no real purpose or mutual accountability, performs worse than a plain working group that never pretended to be one. Naming a team is not the same as being one.
Read together, the two models divide the labor. Tuckman tells you where a team sits emotionally. Katzenbach and Smith tell you what to demand of it: a real shared goal and complementary work rather than a pile of overlapping tasks. Above all, accountability that people hold to each other, not up to a boss. A team does not drift into performing. It commits its way there.
Facilitators who prefer a model built around questions sometimes reach for the Drexler/Sibbet Team Performance Model instead, which frames seven stages, from orientation to renewal, as questions a team has to answer ([the Grove](https://www.thegrove.com/methodology/team-performance-model)). It front-loads trust, which makes it a natural fit alongside the warming work in this guide.
## Using both with a real team
In practice, use Tuckman to read the room and the performance curve to decide what to push for. When a team feels stuck in polite forming, the intervention is warmth and clarity: warm it up and give it something concrete to agree on. When a team is comfortable but coasting, the intervention is a harder goal and clearer accountability. Both models circle the same question this guide keeps returning to: [what makes a team work](/guides/team-dynamics/what-is-team-dynamics/) rather than only meet.
## Frequently asked questions
### What are the 5 stages of team development?
The five stages are forming, storming, norming, performing, and adjourning. Bruce Tuckman described the first four in 1965 and added adjourning in 1977 with Mary Ann Jensen. Forming is cautious, storming brings conflict to the surface, norming settles into shared agreements, performing is where the team delivers, and adjourning is the wind-down when the work ends.
### Who created the forming, storming, norming, performing model?
Psychologist Bruce Tuckman published the forming-storming-norming-performing sequence in a 1965 review of small-group studies. It was a synthesis of other researchers' observations rather than an experiment. He and Mary Ann Jensen added the fifth stage, adjourning, in a 1977 follow-up review of further studies.
### Does every team go through a storming stage?
No. In Tuckman's own 1965 review, only about half the studies showed a distinct conflict stage, and some groups went straight from forming to norming. If your team never obviously storms, that is normal. The real warning sign is conflict that gets suppressed to keep the peace rather than aired in the room.
### Do teams move through the stages in order?
Not reliably. The model describes a common pattern; it does not predict a fixed sequence. Teams regress to earlier stages under pressure, and a team resets toward forming whenever someone joins or leaves. Treat the stages as a way to read a team, not a schedule it is bound to keep.
### What should you do at each stage of team development?
Match the intervention to the stage. In forming, run icebreakers and check-ins and start a charter. In storming, agree working norms and make disagreement safe. In norming, lock in the charter and measure with a health check. In performing, protect the cadence. In adjourning, run a closing retrospective to capture what you learned.
---
# Why your standup is broken: the common anti-patterns
URL: https://www.teamretro.com/guides/daily-standup-guide/standup-anti-patterns/
A daily standup doesn't fail loudly. It decays. The meeting keeps happening, people keep showing up, and one sprint at a time it turns from a coordination checkpoint into a fifteen-minute tax that nobody defends and nobody quite cancels. The complaints you hear ("pointless," "a waste of time," "just list out yesterday's tasks") are almost always describing one of a handful of specific anti-patterns.
This chapter is a diagnostic. Find the pattern you recognize, fix that, and resist the urge to cancel the meeting. A broken standup is a symptom, and canceling it just moves the problem somewhere less visible.
## Anti-pattern 1: status theatre
The most common one. Everyone takes a turn narrating what they did, the room half-listens, nothing gets acted on, and the meeting produces the *appearance* of coordination with none of the substance. One team put it perfectly: "we kept talking about small day-to-day tasks, the kind that fill your day but don't move the needle."
Status theatre is the default state the three questions decay into. It feels productive because everyone spoke, but the test is simple: **did anything said change what a teammate does today?** If not, you performed a meeting.
**The fix:** stop organizing around people and organize around work. [Walk the board](/guides/daily-standup-guide/daily-standup-agenda/), lead with blockers, and cut anything that doesn't affect someone else's plan. See [the three standup questions](/guides/daily-standup-guide/daily-standup-questions/) for why the classic format tips into theatre and how to answer the intent instead of the literal words.
## Anti-pattern 2: the daily manager report
The standup where updates are aimed at the manager or Scrum Master at the front, not at the team. This is the anti-pattern that makes people ask whether standups are micromanagement, and when it's run this way, they're not wrong.
A standup is micromanagement when it's a mechanism for a manager to audit activity, and coordination when it's the team's own tool for planning the day. The difference is entirely in *who the meeting is for*. The instant people are describing effort to prove they were busy rather than surfacing problems to get help, the honest material ("I'm stuck and I don't know who to ask") stops being said.
**The fix:** make it explicitly the team's meeting. If a manager attends, their role is to listen and to clear blockers they're uniquely placed to clear, not to question. Redirect updates that drift toward the front: "tell the team, not me." [How to run an effective standup](/guides/daily-standup-guide/how-to-run-a-daily-standup/) has the facilitation moves.
## Anti-pattern 3: the forty-minute standup
A fifteen-minute meeting that reliably runs to forty. There's a well-worn field story here. A coach joins a team's "daily scrum," it lasts forty-two minutes of one-by-one status reports, and the team can't work out why they're moving *slower* every sprint. The two are connected. A standup that long isn't coordinating the team; it's consuming the time the team needs to do the work.
The cause is almost never rambling for its own sake. It's problem-solving. Two people find a real issue and start solving it while eight others watch.
**The fix:** the parking lot, held ruthlessly. Problems get surfaced in the standup and solved outside it. Name the topic, name who's needed, move on, and hold a hard end time even mid-sentence. The [daily standup agenda](/guides/daily-standup-guide/daily-standup-agenda/) shows where the parking lot sits in the run of show.
## Anti-pattern 4: blockers that go nowhere
The subtle one. The standup surfaces blockers just fine (someone says "I'm stuck on X" every morning) but nothing ever comes of it. No owner, no follow-up, and the same blocker resurfaces the next day, and the day after.
This is worse than not raising blockers at all, because the team learns that the standup is where problems go to be acknowledged and then ignored. Once people believe that, they stop bothering to raise the real ones.
**The fix:** every blocker gets a name and a "we'll sort it right after" before the meeting ends, and a [standup tool that tracks blockers](/standups/) with a count of the days each has been open keeps the follow-up honest. A blocker without an owner isn't a blocker that's been raised. It's a blocker that's been narrated.
## Anti-pattern 5: the standup a great team has outgrown
The counterintuitive one. Sometimes the meeting feels pointless because the team genuinely doesn't need it in its current form. A mature, high-trust team already raises blockers the moment they hit them, in the channel, without waiting for a 9:30 slot. For them, a rote daily meeting is friction, not help.
A daily standup is partly a workaround for a team that can't yet see itself clearly. That's not an insult. Most teams need it, and a young or reforming team needs it badly. But if yours has outgrown the workaround, the answer isn't to keep performing the ritual. It's to go async, go lighter, or use the [format catalog](/guides/daily-standup-guide/standup-meeting-ideas/) to find something that fits the team you've become.
## How to actually fix it
Don't reach for a new format first. Diagnose:
- **Nothing gets acted on** → status theatre. Walk the board; lead with blockers.
- **Updates point at the manager** → the manager report. Make it the team's meeting.
- **It runs long** → problem-solving in the room. Parking lot, hard timebox.
- **Blockers recur** → no follow-up. Assign an owner to every blocker.
- **It feels like friction to a strong team** → you've outgrown it. Go lighter or [async](/guides/daily-standup-guide/async-and-remote-standups/).
And put the meeting itself on a [retrospective](/guides/scrum-masters-retrospective-guide/) agenda now and then. "How we run standup" is exactly the kind of process question the retrospective exists to fix, and the two meetings are meant to improve each other.
For the constructive side of all this, how to run a standup worth the fifteen minutes, see the rest of [the daily standup guide](/guides/daily-standup-guide/).
## Frequently asked questions
### Why do daily standups feel like a waste of time?
Usually because the meeting has turned into status theatre. Everyone recites what they did to an audience, nothing gets acted on, and the fifteen minutes produce no coordination. A standup that changes nobody's day is a waste of time, and people are right to resent it. The fix isn't to cancel it; it's to make it about surfacing and clearing blockers, which is the only thing it was ever for.
### Are daily standups micromanagement?
Not by design, but they tip into it easily. A standup becomes micromanagement when it's aimed at a manager who scrutinizes every detail, rather than run by the team to coordinate itself. The tell is the direction the updates point: toward the front of the room, or toward each other. Fix it by making it the team's meeting, cutting the manager's role to listening, and focusing on blockers instead of activity.
### Why does my standup run so long?
Because the team is solving problems in a meeting built only to surface them. The moment two people start debugging, everyone else is stuck watching, and a fifteen-minute sync becomes a forty-minute one. The fix is a hard parking-lot habit: name the deep topic, note who's needed, move on, and hold that conversation right after with only the people it concerns.
### What are the signs a standup is broken?
People multitask or arrive late, updates are aimed at a manager, blockers get aired but never followed up, the meeting regularly overruns, and nothing anyone says changes what a teammate does that day. If updates are just yesterday's task list read aloud, and the sprint feels slower rather than more coordinated, the meeting has become theatre. Diagnose the specific anti-pattern before you change the format.
---
# 14 standup formats to keep it fresh
URL: https://www.teamretro.com/guides/daily-standup-guide/standup-meeting-ideas/
Most standup "ideas" articles are a list of icebreakers. This isn't that. A standup goes stale because it stopped being useful, not because it lacks a fun question of the day. The fix is to change what the meeting is *organized around*, not to bolt novelty onto a broken format.
Below are fourteen formats, each of which fixes a specific failure. Run one long enough to become a habit, then switch deliberately when the energy flattens or a particular problem shows up. Don't rotate daily: the fluency of a familiar format is half of what keeps a standup fast.
## Start with the board, not the people
Walking the board is the format most teams should default to. It talks about work instead of people, which is exactly the shift a stale, status-heavy standup needs.
If you take one format from this chapter, take **walk the board.** Nearly every standup problem (rambling, status theatre, the meeting that rewards the longest task list) softens when you organize around items in progress instead of around who's speaking. The rest of the catalog is variations for when walking the board isn't enough on its own.
## The fourteen formats
**1. Walk the board.** Move right to left across items in progress; talk about the work, not the person. Fixes status theatre and stalled cards. The right default for most teams.
**2. Round-robin.** Classic person-by-person, three questions each. Good scaffolding for a brand-new team; prone to decaying into a status recital, so treat it as training wheels.
**3. Token pass.** Whoever holds the token speaks, then hands it to someone who hasn't gone. Kills the "wait for my turn, then tune out" pattern of a fixed order.
**4. Popcorn.** Speak when you're ready, then nominate the next person. Same attention benefit as the token, lighter weight, with no object to pass around a remote call.
**5. Random order.** A tool or a name-picker chooses who speaks next. Keeps everyone half-ready to go, which sharpens attention across the whole meeting.
**6. Silent start.** Everyone updates the board in silence for two minutes, then the team discusses only the exceptions. Cuts the meeting to its useful core and stops narration of work the board already shows.
**7. Blockers-only.** Skip status entirely; each person names only what's stuck, or passes. Radical, and revealing: if there's nothing to say, you learn the daily meeting may be redundant that day.
**8. Goal-check.** Frame the whole standup around one question: are we on track for the sprint goal, and what changes today if not. Re-anchors a meeting that drifted into disconnected updates.
**9. Metrics-first.** Open on the numbers ([work in progress, aging items, cycle time](/guides/agile-metrics/lead-time-vs-cycle-time/)) before anyone speaks. Good for flow-focused and Kanban teams that steer by the board's health.
**10. Walking standup.** Co-located teams literally walk while they talk. The movement caps the length and loosens the room; it's the original spirit of "standup" taken one step further.
**11. Async written.** Everyone posts a short update to a channel or an [async standup tool](/standups/) by a set deadline. The default for distributed and timezone-split teams, with real tradeoffs covered in the async chapter.
**12. Pairing close.** End the standup by arranging the day's pairs and hand-offs out loud. Turns coordination talk into concrete collaboration before people scatter.
**13. Theme prompt.** Add one rotating question ("anything you learned yesterday worth sharing?"). Use sparingly: a prompt supplements a working standup; it can't rescue a broken one.
**14. No standup.** Skip it on a genuinely light day and let the board and channel carry the load. A team confident enough to skip a pointless meeting is usually a team running good ones.
## How to choose (and when to switch)
Match the format to the failure, not to the calendar:
- Rambling or status theatre → **walk the board**, **silent start**, or **blockers-only**.
- Attention drifting, same person dominating → **token**, **popcorn**, or **random order**.
- The meeting lost its point → **goal-check** or **metrics-first**.
- Distributed team, timezone spread → **async written** (see [async and remote standups](/guides/daily-standup-guide/async-and-remote-standups/)).
**Pro tip:** if changing format doesn't help, the problem isn't the format, it's the facilitation or the premise. Work through [the standup anti-patterns](/guides/daily-standup-guide/standup-anti-patterns/) before cycling through more variations, and shore up the fundamentals in [how to run an effective standup](/guides/daily-standup-guide/how-to-run-a-daily-standup/).
These formats also make good retrospective material. If the team keeps drifting to status, put "how we run standup" on the agenda of your next [sprint retrospective](/guides/scrum-masters-retrospective-guide/). And once you've picked a format, give people [copy-paste templates](/guides/daily-standup-guide/daily-standup-templates/) so it becomes automatic. For the agenda, facilitation and the anti-patterns, see [the daily standup guide](/guides/daily-standup-guide/).
## Frequently asked questions
### How do you make standups more engaging?
Change what the meeting is organized around, not just its trimmings. Walking the board, a token pass, or a silent start all shift the focus from performing an update to moving the work, which is what actually makes a standup feel worth attending. Gimmicks like a random speaking order help with attention, but engagement comes from the meeting producing something useful, not from novelty for its own sake.
### What are some alternative standup formats?
The most useful alternatives to person-by-person round-robin are: walk the board (talk about items, not people), token or popcorn order (whoever finishes picks the next), silent start (update the board first, then discuss only the exceptions), blockers-only (skip status entirely), and goal-check (frame the whole meeting around the sprint goal). Each fixes a different failure: rambling, status theatre, or a meeting that lost its anchor.
### How do you keep a standup from getting stale?
Run one format long enough to become a habit, then change it deliberately when the energy flattens. Changing it every day just creates confusion. Staleness is usually a symptom: a standup that's become a status recital feels stale because it stopped being useful. Switching to walk-the-board or blockers-only often revives it, because it puts the focus back on work that's actually stuck.
### Should you change your standup format regularly?
Change it when it stops working, not on a schedule. A format needs a couple of weeks to become automatic, and constant switching costs the team the fluency that makes a standup fast. Pick a default that fits your team, hold it until the energy drops or a specific problem appears, then reach for the format that fixes that specific problem.
---
# Story points vs hours: why converting them is the trap
URL: https://www.teamretro.com/guides/agile-estimation-guide/story-points-vs-hours/
If you can convert points to hours, you're estimating hours.
Story points and hours are not different units of the same thing. Hours measure duration: how long something will take you. Points measure relative effort: how big this is compared with the reference story everyone already shipped. They're different axes. The moment you write "1 point = 4 hours" on the wiki, you've recast every estimation conversation as a duration argument, and you've thrown away the relative-effort property the technique exists to give you.
Two stories the same size in points can take different amounts of time. The conversion line pretends they can't.
The reason teams reach for the conversion is real: someone outside the team needs a date, and points don't have units. The fix isn't a conversion table; it's [velocity](/guides/agile-estimation-guide/velocity/). Velocity already maps points to time at the team level. Points-per-sprint × number-of-sprints gives you a date that respects the team's actual delivery rate, not a fictional one.
## Why points exist at all
A team that estimates in hours is really two estimates: the one the senior engineer believes, and the one the junior engineer writes down after rounding up to look responsible. Hidden votes plus relative effort dodge both. Points let the team agree "this is bigger than that one we shipped" without agreeing "this will take me four hours," and the disagreement that surfaces on reveal is where the hidden scope comes out.
## What good looks like
A team using points well doesn't talk about hours during the session. They talk about the reference story, the comparable work they've shipped, and the unknowns. The number that comes out is a relative-effort signal that the team, and only the team, can turn into a date through their own velocity.
**The only honest conversion is after the fact.** When they ask "how long?", the answer is velocity × points-remaining, at the team level, never "1 point = N hours," per story.
## "But how long will it take?"
This is the legitimate need hiding under every request to convert points to time, and it deserves a real answer: a date range from velocity. If your team has averaged 30 points per two-week sprint, a 60-point slice of backlog is roughly two sprints, and you communicate it as "about a month, depending on what we hit." That's a date with the team's noise built into it: the meetings they actually have, the on-call rotation, the holidays. A points-to-hours conversion gives you a date with no noise, which is wrong with more confidence.
So track velocity, project from it, and recompute it every few sprints. That's the honest version of turning points into time, and it needs no conversion table. [Cycle time](/guides/agile-metrics/lead-time-vs-cycle-time/) is a separate thing again: a 3-point story can still sit in review for a week, which is a flow problem, not an estimation one.
## Do story points include weekends?
No, because points don't include time at all. A 5 isn't 40 hours; it's "this is bigger than the reference story." Whether the team works weekends, takes Fridays off or runs four-day weeks doesn't enter the estimate, because the estimate isn't a measure of calendar time.
Where weekends *do* matter is in velocity. Velocity is points-per-sprint, and sprint length is calendar time, so a team with a public holiday mid-sprint will post a lower velocity that sprint, because they had fewer working hours to spend the same effort. That's the right place for weekends to show up: in the calendar layer, not the points layer. Points don't have weekends. Velocity does.
Retire the conversion table. Project from velocity instead.
## Frequently asked questions
### How many hours is 3 story points?
There's no fixed answer, and that's the point. Story points measure relative effort, not duration. 3 points is "a bit bigger than our reference story," which takes different teams different amounts of time. Convert at the team level through velocity, never per story.
### Is 1 story point equal to 1 day?
No. A story point isn't a unit of time at all. If your team has settled into "1 point = 1 day," you're estimating in days with a Fibonacci coat of paint, and you've lost the relative-effort signal points exist to give you.
### Why use story points instead of hours?
Because the team can agree "this is bigger than that" without agreeing "this will take me four hours." Hidden votes plus relative sizing dodge the anchoring and seniority bias hour estimates invite, and velocity still gives you a date when you need one.
### Can you convert story points to hours?
Only at the team level, and only after the fact: points completed per sprint (velocity) maps points to calendar time for that specific team. A standing per-story "X points = Y hours" table is the failure mode. Retire it.
### Do story points include weekends?
No, because points don't include time at all. A 5 is "bigger than the reference story," not a number of days. Weekends, holidays and four-day weeks show up in velocity (points per sprint), which is calendar-based, not in the points themselves.
## Related reading
- [What are story points?](/guides/agile-estimation-guide/what-are-story-points/): relative effort, not time, explained from the top.
- [Velocity](/guides/agile-estimation-guide/velocity/): the only honest way to turn points into a date.
- [Velocity and capacity planning](/guides/sprint-planning-guide/velocity-and-capacity/): using that forecast to size a realistic sprint.
- [Agile estimation guide](/guides/agile-estimation-guide/): the full estimation cluster.
- [Free planning poker for agile teams](/free-planning-poker-for-agile-teams/): estimate in points, together, in real time.
---
# Story points vs #NoEstimates: our verdict
URL: https://www.teamretro.com/guides/agile-verdicts/story-points-vs-noestimates/
**Neither camp wins outright. Estimate to build shared understanding and to detect disagreement; don't estimate to predict a date, forecast from throughput instead.** The point number is nearly worthless. The conversation that produced it is the whole asset.
The argument gets framed as a binary, points or no points, and it isn't one. Both camps are right about something, and both have a heavyweight authority behind them. The useful position is the one that takes each side's strongest claim and keeps only the parts that survive contact with a real sprint.
## The case for story points
Mike Cohn's argument, the definitive pro-points position, was never really about the number. It's that the *act* of estimating relatively forces a team to discuss complexity, surface hidden assumptions and agree on what a story actually involves before anyone writes code. Points also sidestep a specific pathology: estimate in days and every number gets haggled; estimate in an abstract unit and the haggling has nothing to grab. The catch is that everyone hears the wink ("we're not estimating time, just complexity, so we can plan the sprint, which is two weeks"), and the abstraction only protects the team for as long as no one converts it straight back to a date.
Steve McConnell supplies the rigorous counterweight to the anti-estimation crowd. His claim is that the root cause of bad estimates is usually a lack of estimation *skill*, not estimating itself, and that serious estimators separate three things the debate keeps mashing together: the estimate (what's likely), the target (what the business wants) and the commitment (what the team promises). Conflate them and of course estimation looks broken. Keep them distinct and it does real work.
## The case for #NoEstimates
Now the other side, at full strength. Allen Holub's objection is that estimates are always inaccurate, usually wildly so, and that story points were meant to *obfuscate* duration so managers would stop pressuring on time, yet teams reverse-engineer them straight back to hours, recreating the exact dysfunction points were invented to prevent. The Fibonacci scale doesn't save you if everyone privately holds a points-to-hours conversion table.
The sharpest data-flavored claim comes from Vasco Duarte: on real projects, simply *counting stories* forecasts about as well as summing their story points. If that holds for your work, the points are pure ceremony. You did arithmetic to arrive at the same answer the count already gave you. Measure [throughput and cycle time](/guides/agile-metrics/lead-time-vs-cycle-time/) instead; a growing queue is a leading indicator you can see coming, where velocity is a lagging one.
And then the sharpest card in the whole debate. Ron Jeffries, who is widely credited with inventing story points, [walked them back in 2019](https://ronjeffries.com/articles/019-01ff/story-points/Index.html): *"I may have invented story points, and if I did, I'm sorry now."* His problem is specifically with using them to predict when work will finish and to compare teams. His alternative isn't "stop planning". It's slicing stories thin enough to need a single acceptance test, ideally under a day each, so there's barely anything left to estimate.
Watch for [estimate laundering](/guides/agile-theatre/agile-theatre-glossary/#estimate-laundering): an estimate quietly converted into a commitment, then held against the team when the guess turns out to be a guess. This is the real dysfunction. It happens with points and without them, which is the tell that the number was never the problem.
## Where we would change our mind
We would go full #NoEstimates for a team whose work is already sliced small and uniform. Once every story is roughly a day, counting stories forecasts as well as summing points, and the estimation meeting is overhead you can delete. McConnell concedes as much, naming fast-cycle work where the mission is simply "do the next most useful thing" as a context where estimates add little.
We would relax our guard against points in the opposite case: an org where estimates genuinely never harden into commitments and nobody compares teams. There, the danger the anti-estimation camp warns about doesn't exist, and points are just a harmless conversation prompt. The trouble is that this org is rare. The weaponisation is the default, which is why our verdict leans the way it does.
## The practical take
The output of planning poker isn't the number, it's the gap. A 3 beside a 13 means two people picture different work, so close it with conversation, don't split the difference.
- Treat [planning poker](/guides/agile-estimation-guide/what-is-planning-poker/) as a disagreement detector, not a prediction machine. A 2 and a 13 on the same story is the signal. It means the team does not share an understanding of the work. Talk until the spread collapses; the agreement is the output, not the final number.
- Forecast from throughput and cycle time, not from summed points. [Velocity](/guides/agile-estimation-guide/velocity/) is a planning input for the team, never a promise to the outside.
- Separate estimating from committing, as Cohn says. An estimate is a guess; the moment it becomes a promise, someone has changed its meaning without telling the team.
- If you keep points, keep them relative. The instant they map to hours you're [estimating duration in disguise](/guides/agile-estimation-guide/story-points-vs-hours/), with all the pressure of hour-estimates plus a layer of obfuscation.
- Slice the story rather than sizing it. Jeffries is right that most of the value the debate fights over disappears when stories are small enough that the estimate barely matters.
The number is worthless; the conversation that made it is the point. That single line resolves most of the fight, and it keeps a [planning poker](/free-planning-poker-for-agile-teams/) session genuinely useful without pretending it can see the future.
## Frequently asked questions
### Should we use story points or #NoEstimates?
Use whichever makes the estimating conversation happen, and stop treating the number as a prediction. Story points are useful as a disagreement detector: a wide spread on one story means the team does not share an understanding of it. #NoEstimates is the right call when your stories are already sliced small and uniform, because then counting them forecasts as well as summing points. Either way, forecast delivery from throughput, and separate estimating from committing.
### Did the inventor of story points really disown them?
Ron Jeffries, who is widely credited with coining story points, wrote in 2019: "I may have invented story points, and if I did, I'm sorry now." His objection is to using them to predict completion dates and to compare or grade teams. His recommended alternative is not "no planning". It is slicing stories small enough to need a single acceptance test.
### How do you forecast a release without estimating every story?
Measure throughput, the number of stories the team actually completes per week, and project the remaining backlog against that rate. Vasco Duarte's finding is that counting stories forecasts about as well as summing story points, so once stories are sliced to a similar size, the points add little the count does not already give you.
## Related reading
- [What are story points?](/guides/agile-estimation-guide/what-are-story-points/): what points measure, and what they do not.
- [Story points vs hours](/guides/agile-estimation-guide/story-points-vs-hours/): why the points-to-hours conversion is the failure mode both camps are really arguing about.
- [Is velocity a useful metric?](/guides/agile-verdicts/is-velocity-a-useful-metric/): the other half of this fight: what happens when the forecast becomes a target.
- [Agile Theatre: the Performance failure mode](/guides/agile-theatre/performance-agile-theatre/): estimation as cargo-cult ritual, and how to tell real estimating from theatre.
- [Free planning poker](/free-planning-poker-for-agile-teams/): a conversation tool, not a prediction machine.
---
# T-shirt sizing in agile: how it works and when to use it
URL: https://www.teamretro.com/guides/agile-estimation-guide/t-shirt-sizing/
Most estimation techniques ask for a number. T-shirt sizing asks a simpler question first: is this thing small, medium, or large compared to the work around it? That trade, dropping precision for speed, is the whole point. It is the technique to reach for when you have a pile of work and need its rough shape in the next ten minutes, not a story-point estimate you would defend in sprint planning.
## What t-shirt sizing is
T-shirt sizing is [relative estimation](/guides/agile-estimation-guide/relative-vs-absolute-estimation/) with the numbers taken off. Instead of asking "how many points is this?", the team labels each item XS, S, M, L, or XL, judged against the other items in front of them. An M is an M because it is clearly bigger than that S and clearly smaller than that L, not because it maps to any particular count of hours or points.
That is a feature, not a shortcut. Numbers invite a false argument, the "is this a 3 or a 5?" debate that eats refinement meetings. Sizes are coarse enough that the argument rarely starts: people agree far faster on "that is a Large" than on which specific number a Large is worth. You lose granularity and you gain speed, and early in planning speed is what you actually need.
The catch is the one every relative technique shares. A size only means something if the team shares a reference for it. Agree, out loud, on a reference Small and a reference Large early in the session, or the sizes drift: one person's M is another person's L, and by the end the backlog is sorted against five private yardsticks instead of one shared one.
## When to use it (and when planning poker is better)
Here is the position, plainly: t-shirt sizing is for shape and speed, not for sprint commitment.
Reach for it when the work is early and rough. A fresh backlog nobody has sized yet. A quarterly roadmap where leadership needs to know whether an initiative is a Small or an Extra Large before anyone writes a story. A first pass across fifty items to find the handful that are clearly too big and need splitting. In all of these you want coverage and momentum, and a coarse size per item is exactly enough signal.
Reach for [planning poker](/guides/agile-estimation-guide/how-to-run-planning-poker/) instead when the stories are near-term and about to be committed. At that point you are not trying to sort the backlog into piles, you are trying to build shared understanding of a specific story before the team promises to deliver it. The [private-vote-then-reveal](/guides/agile-estimation-guide/how-to-run-planning-poker/) mechanic surfaces the disagreement that t-shirt sizing smooths over, and near a sprint boundary that disagreement is the most valuable thing in the room. A quiet L hiding a serious unknown is fine on a roadmap and dangerous in a sprint.
So the two techniques are not rivals: they sit at different distances from delivery. T-shirts do the early, wide, rough pass. Planning poker does the late, narrow, careful one. For a backlog too big to size shirt by shirt, [affinity estimation](/guides/agile-estimation-guide/affinity-estimation/) sorts the whole pile first and labels it after.
## How to run a t-shirt sizing session
The session is short by design. Five steps:
1. **Set the scale.** Decide which sizes you are using (XS to XL is common; some teams use S, M, L only) and, critically, agree on two anchors: a reference Small everyone recognizes and a reference Large everyone recognizes. These two items calibrate the whole session.
2. **Size against the anchors.** Take each remaining item and place it relative to the two references. The question is never "how big is this in the abstract?" but "is this closer to our Small or our Large?"
3. **Work fast and let the coarseness help.** Do not agonize between neighboring sizes. If an item feels like it is on the S or M line, the fact that it is hard to call means the difference does not matter much yet. Drop it in and move on.
4. **Discuss only the disagreements.** Where people land on the same size, there is nothing to talk about: record it and keep moving. Spend the meeting's oxygen only on the items where sizes genuinely diverge, because that gap is a real difference in understanding worth surfacing.
5. **Flag the XLs for splitting.** Anything that lands on XL is usually a signal, not an estimate. It is too big to plan confidently and is a candidate to [split into smaller stories](/guides/agile-estimation-guide/splitting-user-stories/) before it goes anywhere near a sprint.
If most of the backlog lands on a single size, your scale is too narrow for this work, not your estimates. Re-anchor with a smaller Small or a larger Large and pass through again.
## Turning sizes into story points
This is the bridge teams get stuck on, and it is worth being precise about. At some point the early, rough sizes have to become something you can plan a sprint against, and a plain mapping is the most useful thing you can give the team.
A mapping gets you into the right neighborhood. Planning poker settles the exact number.
| T-shirt size | Rough story points | What it usually means |
|---|---|---|
| XS | 1 | Trivial and well understood, done in an hour or two |
| S | 2 | Small and clear, no real unknowns |
| M | 3 to 5 | A normal story with a few moving parts |
| L | 8 | Big or uncertain, a candidate to split |
| XL | 13 or more | Too large to commit, split before sprint planning |
Two warnings come with that table. First, it is a starting band, not a fixed formula. A t-shirt size is deliberately coarse, so the same L can honestly land on a 5 or an 8 once you look closely; the mapping gets you into the right neighborhood, and planning poker settles the exact number. Second, and this is the one that bites: do not use the mapping to skip the re-estimate. The sizes were a fast gut-check across the whole backlog. For any story about to enter a sprint, [re-estimate it with story points](/guides/agile-estimation-guide/what-are-story-points/) properly, using the size only as a sanity check. If the size said L and the team votes it a 2, that mismatch is a conversation, not a rounding error.
Because the sizes do not add up (an S plus an M is not an L), you cannot sum them into a velocity number. That is the hard boundary of the technique: t-shirts give you shape, [story points](/guides/agile-estimation-guide/what-are-story-points/) give you a number you can measure velocity from. Keep the two jobs separate and both stay honest.
## A worked example, start to finish
Say a team sits down with a fresh backlog of six items and ten minutes.
They pick two anchors first: "update the copyright year in the footer" is the reference Small, and "rebuild the checkout flow" is the reference Large. Everything else gets sized against those two.
- Add a tooltip to the settings icon: clearly near the footer change. **XS.**
- Add email validation to the signup form: small and well understood, a touch more than the tooltip. **S.**
- Build a CSV export for reports: a normal story, a few moving parts, no scary unknowns. **M.**
- Add SSO via a new identity provider: big, and nobody is sure how the provider's API behaves. Two people say L, one says XL. That disagreement gets a two-minute discussion, which surfaces the real question (is this one provider or a general SSO framework?) and they settle on **L**, with a note to split it.
- Migrate the reporting database: everyone independently lands on **XL**, so there is nothing to discuss except that it is too big and needs splitting before anyone commits to it.
- Fix a typo in an error message: **XS**, no discussion.
Six items, sized in a few minutes, with the two genuinely uncertain ones flagged for a closer look. The team now knows the shape of the backlog: mostly small, one large item to break down, one extra-large that is really an epic wearing a story's clothes. Next week, when the top of that backlog is refined and heading into a sprint, they will re-estimate those near-term items with planning poker and let velocity build from the points. For a wider view of where t-shirt sizing sits among the alternatives, see the [estimation techniques comparison](/guides/agile-estimation-guide/estimation-techniques/).
## Estimate together in TeamRetro
T-shirt sizing works best when everyone sizes at once and you can see the disagreements at a glance. [TeamRetro's estimation tool](/estimations/) runs the whole session in one place: size items as a team, reveal together, and discuss only where you diverge, then switch to [free planning poker](/free-planning-poker-for-agile-teams/) with story points when the near-term stories are ready to commit. Shape early, commit late, in one shared board.
## Frequently asked questions
### What is t-shirt sizing in agile?
T-shirt sizing is a relative estimation technique where the team sizes each piece of work as XS, S, M, L, or XL instead of assigning a number. It is a fast gut-check of how big something feels compared to the work around it, not a measurement of hours or story points. Because the sizes are coarse, a session moves quickly, which makes it a good fit for early refinement and roadmap planning where you need rough shape, not precision.
### How do you convert t-shirt sizes to story points?
Agree a simple mapping as a team, for example XS to 1, S to 2, M to 3 or 5, L to 8, and XL to 13 or more, then re-estimate the near-term stories with planning poker rather than trusting the conversion. Treat the mapping as a starting point, not a fixed formula: a t-shirt size is a rough band, so the same L can land on 5 or 8 depending on the story. The conversion is for turning a sized backlog into something you can plan against, not for producing a final number you commit a sprint to.
### When should you use t-shirt sizing instead of planning poker?
Use t-shirt sizing when you need to size a lot of work quickly and roughly: a fresh backlog, a quarterly roadmap, or a first pass before anything is refined. Use planning poker when the stories are near-term and about to enter a sprint, because that is when you need the shared understanding and the surfaced disagreement that a private-vote-then-reveal discussion produces. T-shirts are for shape and speed; planning poker is for the commitment.
### Can you measure velocity with t-shirt sizes?
No. Velocity is an average of story points completed per sprint, and t-shirt sizes are categories, not numbers: an S plus an M does not equal an L, so the sizes cannot be summed into a per-sprint total. If you build a conversion table to force them to add up, you have reinvented story points with an extra step. Size early work with t-shirts for shape, then re-estimate the near-term stories with points and measure velocity from those.
## Related reading
- [Agile estimation techniques compared](/guides/agile-estimation-guide/estimation-techniques/): where t-shirt sizing sits among planning poker, buckets, affinity, and magic estimation.
- [Affinity estimation](/guides/agile-estimation-guide/affinity-estimation/): the other fast, relative technique for sizing a fresh backlog.
- [What are story points?](/guides/agile-estimation-guide/what-are-story-points/): the numbers t-shirt sizes convert into for near-term work.
- [How to run planning poker](/guides/agile-estimation-guide/how-to-run-planning-poker/): the slower, careful technique for stories about to enter a sprint.
- [Free planning poker for agile teams](/free-planning-poker-for-agile-teams/): estimate the points velocity is built from.
---
# Team dynamics: how great teams actually work
URL: https://www.teamretro.com/guides/team-dynamics/
Team dynamics are the forces that decide whether a group of capable people work well together. This guide is the practical version for workplace and remote teams: what shapes those forces, the stages a team moves through, how to warm up a cold or distributed group, how to read the team against [the five dysfunctions](/guides/team-dynamics/five-dysfunctions-of-a-team/), and how to lock in the trust, [working agreements](/guides/team-dynamics/team-norms-and-working-agreements/), and follow-through that make good behavior stick. Start with what team dynamics are, or jump to the chapter that matches the problem in front of you.
---
# Team working agreements: how to create one (+ template)
URL: https://www.teamretro.com/guides/team-dynamics/team-norms-and-working-agreements/
A team working agreement is a short, co-created set of rules for how your team works together: how you communicate, run meetings, make decisions, and give feedback. It is not a poster of values, and it is not the same as a team charter. It is the handful of concrete, agreed behaviors you can point to when something slips. This chapter covers what a working agreement is, how to facilitate one in a single session, examples you can copy and adapt, and how to keep it alive in your retrospectives.
Here is the uncomfortable part. Your team already has norms. Someone always replies within minutes; someone else goes dark for a day. One person's ideas get built on while another's get talked over. Those patterns are your norms, and they formed whether you chose them or not. Working agreements are the version you pick on purpose instead of the version you inherit from whoever talks loudest.
## Values, norms, working agreements, and charters: the difference
These words get thrown around as if they mean the same thing, and they don't. Esther Derby, who co-wrote the book on agile retrospectives, draws the cleanest line between them, and it is worth getting right before you run a session.
| Term | What it is |
|---|---|
| Values | What matters to the team, usually nouns like Respect or Courage. They may guide behavior, but on their own they are not actionable. |
| Norms | The informal, often unspoken standards that emerge from how the group actually behaves. They form whether you shape them or not. |
| Working agreements | Norms made deliberate. Protocols the team develops, agrees to, and writes down. The layer you can act on. |
| Ground rules | Expected behavior for a specific time and place, such as a retro or a planning session. Narrower than a team-level agreement. |
| Team charter | The broader kickoff document: purpose, goals, roles, and how you decide, with the working agreements sitting inside it. |
Derby's point, in [her breakdown of the terms](https://estherderby.com/norms-values-working-agreements-simple-rules/), is that norms are not optional: a group produces them by existing. The only choice is whether you let them congeal by accident or shape them on purpose, and shaping them on purpose is what a working agreement is.
A charter answers why we exist and how we decide, and you tend to set it once at kickoff. Working agreements answer how we behave day to day, and you revisit them constantly. Values without agreements are a poster on the wall. Norms without agreements are whatever happened to settle in during month one. The agreements are the only layer you can point at when something goes wrong. Atlassian keeps the two artifacts separate for the same reason, pairing a [team charter](https://www.atlassian.com/work-management/project-collaboration/team-charter) with a lighter, more frequently revisited working agreements play.
## Why working agreements are worth the hour
Google's re:Work team studied what its strongest teams had in common in Project Aristotle. Two of the factors it surfaced are the ones working agreements speak to directly: structure and clarity, meaning people understand what is expected and how the work gets done, and psychological safety, meaning people feel able to speak up. Aristotle is correlational, so read the [full re:Work guide](https://rework.withgoogle.com/intl/en/guides/understand-team-effectiveness) as a description of what effective teams share, not a recipe that produces one.
Clear agreements do two things at once. They make expectations visible, so nobody has to guess whether interrupting is fine or whether a message sent at 9pm needs an answer tonight. And they give the team something to point at when a line gets crossed, which is what makes it safe to raise the problem at all. Atlassian's Teamwork Lab reports that teams with explicit agreements run fewer and more purposeful meetings and hit fewer misunderstandings.
The safety half of that gets its own chapter in [building trust and psychological safety](/guides/team-dynamics/building-trust-and-psychological-safety/); agreements also sit inside the bigger picture of [what shapes team dynamics](/guides/team-dynamics/what-is-team-dynamics/).
## How to create team working agreements: a 10-step session
You can write a first set in a single 60-to-90-minute session. The order below is the spine; the point of every step is to end up with agreements the team owns rather than rules the facilitator imposed.
1. **Book 60 to 90 minutes with the whole team present.** Attendance is buy-in. An agreement the team did not help write is just a policy, and policies get ignored.
2. **Set the stage.** Say why you are doing this, show two or three example agreements so people know the format, and open with a light [check-in question](/icebreakers/check-in-questions/) to get everyone's voice into the room early. You can run that opener live with something like [icebreaker questions](https://games.teamretro.com/games/icebreaker-questions/).
3. **Gather the inputs first.** Ask each person to share their location, timezone, working hours, and how they like to receive feedback. As facilitator, pre-draft the channel list and an escalation path so the session refines a starting point instead of a blank page. To surface preferences fast, some teams map them on a live [team spectrum](https://games.teamretro.com/games/team-spectrum/): where does each person fall between "reply fast" and "protect focus time"?
4. **Brainstorm silently, then cluster.** Everyone writes proposed agreements on their own before anyone speaks, which stops the loudest voice from setting the agenda. Group the cards across the situations below: communication, meetings, decisions, remote and async work, response times, and conflict.
5. **Rewrite every vague line into a behavior you could film.** "Be respectful" is a value, not an agreement. "We don't interrupt, and we argue with the idea rather than the person" is something you can watch happen or fail to happen.
6. **Decide sync versus async on purpose, and name who decides.** For each topic, agree whether it needs a live conversation or a written thread, and name the person who breaks a tie when consensus stalls.
7. **Confirm commitment out loud.** Use a Fist of Five or a Roman vote (thumb up or down) on each agreement. Silence is not a yes. If someone signals a two, you talk until it becomes a real agreement or you drop it.
8. **Cap the list at five to ten.** A long list is an ignored list. Thirty rules is the same as zero. Pick the few that fix your team's real friction and add more only when a genuine problem shows up.
9. **Post them where the work happens.** Pin them in the team channel, the wiki, or the top of the board, wherever people already look. It is a living document, not a slide deck nobody reopens.
10. **Revisit them on a cadence.** This is the step teams skip. Review the agreements in a retrospective, at quarterly checkpoints, and every time someone joins or leaves. Norms die from neglect, not from disagreement.
If your team runs in sprints, Scrum.org and [Swarmia](https://www.swarmia.com/blog/agile-team-working-agreements/) both describe the same ritual in agile terms, with sprint-context examples you can borrow.
## Team working agreements: 30+ examples to copy
Vague values do not survive contact with a real team. "Be respectful" tells nobody what to do on Monday morning. Start instead from concrete, observable agreements and adapt the specifics to your team. Here is a starter set you can copy today, one for each of the four areas that produce the most friction.
**A starter agreement you can copy**
- **Communication:** "We debate in the open channel, not in DMs, and reply to chat within four working hours."
- **Meetings:** "No agenda in the invite means no meeting. The organizer posts notes and actions the same day."
- **Decisions:** "Reversible decisions don't need a meeting; contested ones name a decider, and we log the outcome within 24 hours."
- **Feedback:** "We disagree with the idea, not the person, and raise a concern directly before escalating it."
Four lines is a working draft, not a finished agreement. Take them into your session as the starting point, change the specifics until they describe your team, and cut anything your team would not actually enforce.
Need more range? The bank below groups concrete agreements by situation. Do not adopt all of them; that would break the five-to-ten rule. Read it as a menu and take the ones that match your friction.
### Communication
- "We debate ideas in the open channel, not in DMs, so the whole team sees the reasoning."
- "We assume positive intent and ask one clarifying question before reacting to a message."
- "If a thread passes ten replies, we move it to a short call and post the summary back."
- "Written status goes up by 10:00 so nobody has to chase an update."
- "Bad news travels first and fast; we would rather hear a problem early than a surprise late."
### Meetings
- "No agenda in the invite means we decline the meeting."
- "We start on time and don't recap for latecomers."
- "Every meeting names the decision it needs to make, or it becomes a written update."
- "The organizer posts notes and actions the same day."
- "Wednesday afternoons are meeting-free for focus work."
- "Anyone can say 'let's take this offline' without it being rude."
### Decisions
- "Reversible, two-way-door decisions don't need a meeting; post the plan and proceed."
- "If we can't reach consensus in ten minutes, [role] decides and the rest of us disagree and commit."
- "Decisions made in a meeting get logged within 24 hours."
- "We name who the decider is at the start of any contested topic."
- "We reopen a logged decision only with new information, not a new mood."
### Remote and async work
- "Core overlap hours are 10:00 to 13:00 [timezone]; we schedule live calls only then."
- "Everyone keeps their working hours and timezone visible on their calendar and status."
- "Async is the default; we book a call only when a written thread has stalled."
- "We write updates so they still make sense to someone reading them eight hours later."
- "Calls that some people can't attend get recorded, so no timezone is penalized."
### Response times
- "Chat gets a reply within four working hours; email within one working day."
- "Nothing is expected outside your posted working hours."
- "Anything urgent goes through a call or the on-call path, not a chat message."
- "Pull requests get a first review within one working day."
- "If you can't answer fully, you acknowledge the message and say when you will."
### Conflict and feedback
- "We disagree with the idea, never the person, and never in DMs."
- "Feedback is specific and about behavior, not about character."
- "We raise a concern with the person directly before escalating it."
- "Saying 'I don't agree' in a meeting is welcome; silence is not agreement."
- "When something festers for more than a week, we escalate to [role] instead of stewing on it."
### Vague agreements are useless
There is one test for whether something belongs on the list. If a stranger watching your team could not tell whether you were following the agreement, it isn't an agreement; it is a wish. These are the usual suspects, and what each becomes when you make it observable.
| Vague (a wish) | Concrete (you could film it) |
|---|---|
| Be respectful | We don't interrupt, and we argue with the idea, not the person |
| Communicate well | Written status by 10:00; chat answered within four working hours |
| Be transparent and honest | Decisions get logged within 24 hours |
| Support each other | Pull requests get a first review within one working day |
| Have fun | Delete it; it is a hope, not an agreement |
## A real working agreement, and how the team keeps it alive
Everything above is advice. Here is what it produced on one of our own teams at TeamRetro, who built their agreement by following the same steps this chapter describes.
The board is called Team agreements and carries one line of context: "These are the things we agree on as a team." Permissions are set so that everyone can propose or add agreements, and the field at the top of the list reads "Propose agreement...". That setting is this chapter's argument in product form. If only the lead can add a line, the list stops being an agreement and starts being a policy.
These are the six agreements the team runs on, word for word:
{/* cspell:ignore finalise -- transcribed verbatim from the screenshot above; must match the image */}
- Our showcase presentations are to get feedback and are short but meaningful
- It's okay to call a "lights out" during hack sessions to work on tasks
- Anyone can run a "Clear the plate" session to finalise tasks.
- We add our blockers to standup - it's okay to get help.
- We ask for progress feedback on projects at the 10%, 70%, 90% mark
- We add reasonable deadlines and due dates for our Linear tasks.
Read them again and notice what is missing. Nothing about respect, nothing about trust, nothing you could print on a mug. Every line names something this team actually does: showcases, hack sessions, standup, the way the work is tracked. They would be close to useless for your team, and that is the point. An agreement is only observable if it describes the real ritual it governs.
The list is six lines long, not thirty. That is the five-to-ten rule applied by a team that had to live with the result.
Three of the six carry a comment thread, and that matters more than the wording does. The agreements sit next to the team's retrospectives, so they get pulled up from time to time as a reference. If a showcase runs long, or if someone is not sure whether calling a lights out is really fine this week, the line is there to point at, and the conversation happens on the agreement itself instead of in a side channel. When the conclusion is that the agreement is wrong, the team edits it. New lines get proposed as the work changes, and lines nobody uses anymore get dropped.
That is the whole lifecycle on one board: write it together, keep it where the team already looks, reference it when something slips, and change it as the team and the work evolve.
## Keeping agreements alive: the wall-art problem
Most working agreements die the same way. The team runs a good session, writes a thoughtful list, pins it somewhere, and never looks at it again. Six months later it is wall art: a brilliant set of ground rules nobody references when they are broken. That is the single most common failure on this topic.
Two things keep agreements alive. The first is teeth: when someone crosses an agreement, somebody points at it, calmly, in the moment. An agreement no one enforces teaches the team that none of them count. The second is revisiting on a schedule. Fold a quick review into your [retrospectives](/retrospectives/), revisit the whole set when the team changes shape, and use a recurring [team health check](/health-checks/) to surface the norm that is quietly slipping before it turns into a fight.
This is a follow-through problem at heart, and follow-through is trackable. When an agreements review becomes an action with an owner and a due date rather than a good intention, it gets done. TeamRetro's own data across a sample of hundreds of thousands of retrospective action items found that about 73% get completed, evidence that commitments a team writes down and returns to do get honored. The agreements that stick are the ones wired into a ritual the team already repeats.
If you have read the [defrosting a cold team](/guides/team-dynamics/how-to-defrost-a-team/) chapter, this is the refreeze step: icebreakers thaw a group, and agreements lock the new warmth into a habit. Because agreements are a social contract the team writes for itself, they hold better than rules handed down, a framing we develop in [creating social contracts with team agreements](/blog/create-social-contracts-with-team-agreements-that-improve-culture/). Remote and distributed teams lean even harder on the written agreement, since the ambient office cues that carry norms are gone; the [remote and distributed dynamics](/guides/team-dynamics/remote-and-distributed-team-dynamics/) chapter goes deeper, and [GitLab's async handbook](https://handbook.gitlab.com/handbook/company/culture/all-remote/non-linear-workday/) is the reference implementation.
## Run your working-agreements session in TeamRetro
A working-agreements session maps almost exactly onto how a retrospective board works, which is why teams often run it in TeamRetro. Everyone adds proposed agreements as cards at the same time, silently, so the quieter people and the person in the awkward timezone get the same airtime as whoever usually fills the silence. You group the similar cards, vote to surface the ten that matter most, and turn the survivors into a shared document the team owns. Start from the examples above as your template: add them as cards, then reword and cut them together until the list is yours. Because it sits next to your retrospectives and health checks, the revisit step stops being a calendar reminder you ignore and becomes part of a ritual you already run.
This chapter is part of our [team dynamics guide](/guides/team-dynamics/). If you are formalizing this at kickoff rather than mid-flight, the working agreements belong inside a wider [team charter](/guides/team-charter/): purpose, goals, roles, and decision rights, with these behaviors as the how. If your team runs agile, the [scrum master's retrospective guide](/guides/scrum-masters-retrospective-guide/) covers where agreements get revisited from sprint to sprint. When you are ready, [start a free TeamRetro trial](https://secure.teamretro.com/login/new) and build your first agreement with the team this week.
## Frequently asked questions
### What is a team working agreement?
A team working agreement is a short, co-created set of rules for how a team works together: how they communicate, run meetings, make decisions, and give feedback. It is deliberate rather than assumed, written down rather than left to habit, and agreed by the whole team rather than handed down by a manager. Most teams keep five to ten and revisit them as the team changes.
### What is the difference between team norms and working agreements?
Team norms are the informal, often unspoken standards that form from how a group behaves. Working agreements are those norms made deliberate: a set the team discusses, writes down, and agrees to follow. Every team has norms; not every team has working agreements. Agreements are the version you chose on purpose.
### What are some examples of team working agreements?
Good agreements are concrete and observable, such as "no agenda in the invite means we decline the meeting," "chat replies within four working hours," "decisions get logged within 24 hours," and "we disagree with the idea, not the person." If a stranger couldn't tell from watching whether you followed it, it isn't an agreement.
### How many working agreements should a team have?
Start with five to ten. A long list is an ignored list. Pick the few agreements that fix your team's real friction, such as meetings, response times, and how decisions get made, and add more only when a genuine problem appears. You can revisit and adjust the list later.
### What is the difference between working agreements and a team charter?
A team charter is the broader kickoff document: why the team exists, its goals, roles, and how it makes decisions, usually set once at the start. Working agreements are the day-to-day behavior rules inside it, and they get revisited far more often. The charter is why and who; the agreements are how.
### How do you make working agreements stick?
Co-write them with the whole team so they are owned rather than imposed, keep the list short, and post them where the work happens. The step teams skip is revisiting them: in retrospectives, at quarterly checkpoints, and whenever someone joins. An agreement nobody references when it is broken is just wall art. Turning the review into a recurring action with an owner is what makes the follow-through actually happen.
---
# The daily standup (daily scrum): the ceremony explained
URL: https://www.teamretro.com/guides/agile-ceremonies-guide/the-daily-standup/
The daily standup, called the **daily scrum** in the Scrum Guide, is a 15-minute, same-time, same-place check-in where the developers re-plan the next 24 hours against the sprint goal. It's a coordination meeting the team runs for itself, not a status report to a manager. Get that one distinction right and most standup problems solve themselves.
This is the ceremony-level summary. For the three questions and the smarter alternatives, a real agenda, facilitation rules, async and remote formats, and the tools, see [the complete guide to daily standups](/guides/daily-standup-guide/).
## Daily scrum or daily standup?
Same event, two names. "Daily scrum" is the current Scrum Guide term; "standup" comes from the practice of holding it standing so nobody gets comfortable and it stays short. Use whichever your team already says. The label is not the thing that makes it work. If the distinction between the two names ever comes up in earnest, [we untangle it here](/guides/daily-standup-guide/daily-scrum-vs-daily-standup/).
## What the fifteen minutes are for
Three jobs, and only three: inspect progress toward the sprint goal, surface anything blocking that progress, and adapt the plan for the day. That's it. The daily scrum is a chance for the people doing the work to synchronize: who's stuck, who can help, what changed since yesterday.
What it is *not* is a lap of individual status updates delivered to the most senior person in the room. That version is [agile theatre](/guides/agile-theatre/performance-agile-theatre/). It looks identical from the outside and is worthless: people perform being busy, blockers get buried in detail, and the fifteen minutes buys nothing. The [most common standup anti-patterns](/guides/daily-standup-guide/standup-anti-patterns/) all trace back to this one confusion about who the meeting is for.
## Two ways to run it
Most teams start with the classic three questions: what did you do yesterday, what will you do today, what's in your way. They're a fine training wheel and a lousy habit: they organize the meeting around *people* reciting activity rather than *work* moving toward the goal.
The alternative is to [walk the board](/guides/daily-standup-guide/daily-standup-agenda/): start at the work closest to done and move right to left, talking about items rather than individuals. It keeps the conversation on flow, surfaces the stuck cards faster, and quietly kills the status-recital habit. Either way, anything that needs real discussion goes to a parking lot after the meeting, with only the people it involves.
## Where it fits, and the product
The daily scrum is the heartbeat between the bookend ceremonies. [Sprint planning](/guides/agile-ceremonies-guide/sprint-planning/) sets the goal it checks against, and the [sprint review](/guides/agile-ceremonies-guide/sprint-review/) inspects the result. Running standups across time zones is its own problem; [TeamRetro's standups](/standups/), with reminders and summaries in [Slack](/integrations/slack/) and [Microsoft Teams](/integrations/microsoft-teams/), exist for exactly the async case the [async and remote chapter](/guides/daily-standup-guide/async-and-remote-standups/) covers.
## Frequently asked questions
### How long should a daily standup be?
Fifteen minutes, timeboxed, and it stays fifteen minutes regardless of how long the sprint is. If it regularly runs longer, the team is problem-solving in the meeting instead of taking the detail offline. Take the deep conversation to a parking lot with only the people it involves.
### Who attends the daily scrum?
The developers own it. It's their meeting to re-plan their day. The product owner and scrum master attend only if they're actively working on sprint backlog items; otherwise they can listen but shouldn't turn it into a status round. The moment managers start collecting updates, it stops being a daily scrum.
### Is the daily scrum the same as a daily standup?
Yes. "Daily scrum" is the term the Scrum Guide uses; "standup" is the older habit of holding the meeting standing so it stays short. They're the same event, and most teams use the words interchangeably.
---
# Void: when the ceremony changes nothing
URL: https://www.teamretro.com/guides/agile-theatre/the-follow-through-void/
The deadliest failure mode isn't a bad ceremony. It's a good one that changes nothing.
A standup can be captured, a planning session can be overloaded, and the team will still feel the friction and push back. The follow-through void is worse because it feels *fine*. The retro runs, people are candid, sticky notes get written, everyone nods. Then the sprint turns over and not one thing is different. Do that a few times and you don't get anger; you get something quieter and more corrosive. As one engineer put it on Hacker News, "retrospectives allow airing concerns, but nothing really ever happens of those concerns in my experience." Another, more bluntly: "I have never seen anything happen besides words." This is the single most-repeated complaint about retrospectives anywhere, and it is not the complaint our industry's advice thinks it is.
## Words, and only words
The standard framing is that teams "forget to write action items," so the standard fix is to write better ones: make them SMART, assign an owner, add them to the board. It misses the actual pathology. The problem is rarely that no action was written; it's that the action was written, added to the backlog, and then sat there forever while the next retro generated three more. "I've repeated the same retrospective items sprint over sprint without them being addressed," runs one resigned account. "This sticky will not be addressed. It's kind of sad." By one commonly-cited survey, only about [a third of teams](https://www.easyagile.com/blog/improve-sprint-retrospective-action-items) consistently complete their retro action items, and the other two-thirds are learning, sprint by sprint, that the ceremony produces words and only words. Treat the folklore with care, though: our own first-party data on [what percentage of retrospective action items actually get done](/guides/follow-through-index/) puts completion nearer three in four, and shows that ownership and cadence, not effort, decide the gap.
The fix that actually holds isn't more actions. It's fewer. Cap it at one. A single improvement the team genuinely commits to, reviewed at the very *top* of the next retro before anything else happens, beats a list of ten that all quietly lapse. This is not new advice: [Johanna Rothman](https://www.jrothman.com/) has recommended a single item, treated as an experiment and built into the team's next block of work, in [_Create Your Successful Agile Project_](https://pragprog.com/titles/jragm/create-your-successful-agile-project/). Make too many action points and half won't get done, and the half that don't teach the team that none of it counts. One item, owned, with a review date, closes the loop that a long list leaves open. Our retro guide's [why retrospectives fail](/guides/scrum-masters-retrospective-guide/why-retrospectives-fail/) chapter covers running that loop from inside the ceremony, and the box-ticking retro in the [Performance](/guides/agile-theatre/performance-agile-theatre/) chapter is what the void looks like before the team gives up entirely.
## The pressure valve
But there's a deeper version of the void, and it's the one our industry's advice gets backwards. Sometimes the actions don't happen because the team was never going to be *able* to make them happen: the real problems are genuinely above the team's pay grade. Budget, headcount, cross-team dependencies, an architecture decision made two levels up, a deadline set by sales. The team can name these all day. It cannot fix any of them. And so the retro becomes a [pressure valve](/guides/agile-theatre/agile-theatre-glossary/#pressure-valve): a place to let off steam so leadership can feel the team has been heard, with no mechanism to change the thing being vented about.
A valve releases just enough steam to change nothing; a radiator pushes the same issue outward to a named owner. The next section turns one into the other.
The sharpest statement of this comes from a developer writing on dev.to, and it's worth quoting in full: "the retrospective became a pressure valve. Appearance of voice without substance of power." The same essay lands the point that should make every coach uncomfortable: "blaming facilitation is like blaming the suggestion box for management not reading the suggestions." You cannot facilitate your way out of a power problem. And on Hacker News, plainly: a retro is "a ceremony without actual purpose because usually the deeper things that people bring up are not within that team's power to control". Worse still: "it gives leadership an excuse for not fixing things."
Here is where most vendor advice does real harm. The standard anti-pattern list tells teams to "stay within your circle of influence" (stop raising things you can't change). Framed as the *team's* discipline problem, that advice is exactly wrong. It tells the team to bury the real blocker and reflect only on the small, safe, team-controllable stuff, which is precisely how a retro turns into comfortable theatre. Staying in your circle of influence is bad advice when the most important thing in the room is outside it.
**A retro that only surfaces problems the team can already fix is a pressure valve, not a retrospective.** If the real blocker is above the team's pay grade, the honest move is to name it, assign who *must* act on it, and escalate it with a date attached, not to coach the team into raising smaller problems. Comfortable and dishonest is worse than uncomfortable and true.
## Radiate outward, don't vent inward
The good news is that the canonical text already wrote the fix, and it's the current edition that did it. The second edition of *Agile Retrospectives* (2024), with David Horowitz joining Esther Derby and Diana Larsen, added [a whole chapter](https://pragprog.com/titles/dlret2/agile-retrospectives-second-edition/) on issues beyond the team's control. The pain got acute enough that the canon caught up. Three of its tools are the antidote to the pressure valve:
- **Circles & Soup**: sort every issue by who owns it, into what the team *controls*, what it can *influence*, and what's in the "soup" it can only respond to. This is triage by ownership, and it replaces "stay in your circle" with "route each issue to whoever can actually act on it."
- **15% Solutions**: for the big, stuck problems, find the slice the team *can* start on now without anyone's permission. Not the whole fix; the 15% of it that's within reach. Momentum on a fraction beats paralysis on the whole.
- **Retrospective Radiators**: make the escalated issues *visible outward*, on a board leadership can see, tracked over time. A radiator is the opposite of a valve: a valve releases pressure and hides it; a radiator broadcasts the unresolved item until someone with the power to fix it does. Escalate the red ones by name.
That's the hard line the research points to, and it's canon-backed: triage by ownership, escalate red items by name and date, radiate rather than vent. A retro that does this is honest about power. A retro that skips it is a pressure valve with a facilitator.
## Learning is the point, not the to-do list
The last reframe closes the loop on the whole mode. The second edition also shifts the *success criterion* itself, from action items to **learning**. Its position (and it's a relief to hear it from the canon) is that a retro without an action item isn't a failure if the team learned something. The unit of change becomes an **experiment**: a hypothesis you test with a review date, rather than a to-do that rots in the backlog. "We think pairing on the deploy will cut our rollback rate; we'll try it for two sprints and check" is an experiment. "Improve deploys" is a sticky note that dies.
An action item like "improve deploys" rots unowned in the backlog; the same intent framed as an experiment (a hypothesis with a review date) is a change the team is actually running.
It also dignifies a cost that never makes it onto anti-pattern lists: the emotional tax of the pure venting session. As one participant put it, a retro can be "an hour plus of sitting there mostly listening to other people complain about stuff, which bums me out." A venting-only retro doesn't just fail to fix things. It taxes the people who absorb the complaints. The fix isn't to ban feelings; it's to give them an exit: convert the red items into owned, dated, radiated experiments, and the hour stops being a place where frustration just circulates.
That's the way out of the void, and out of the guide. Run the loop small enough to close it, triage honestly enough to escalate what the team can't fix, and measure learning rather than counting actions, because [candor that changes nothing](/guides/scrum-masters-retrospective-guide/how-to-build-a-psychologically-safe-space/) eventually stops being candor. The four modes ([Performance](/guides/agile-theatre/performance-agile-theatre/), [Power](/guides/agile-theatre/power-agile-theatre/), [Overload](/guides/agile-theatre/ceremony-overload/) and the Void) are, in the end, the same question asked four ways: *is this ceremony doing its job, or just performing it?*
## Frequently asked questions
### What do you do when the same issues come up every single retro?
Diagnose why they recur, because two different failures look identical from the inside. If the action was written but never owned, it rots in the backlog while the next retro adds three more. Cap it at one owned item with a review date, and open the next retro by checking it. If the issue keeps coming back because it is genuinely outside the team's control, re-listing it will never work: triage it by who owns it and escalate it upward by name and date instead of venting again.
### What do you do when the real problem is out of the team's control?
Don't coach the team into raising smaller problems. That's how a retro becomes theatre. Triage every issue by who actually owns it, then escalate the red ones upward with a name and a date attached, and make them visible on a retrospective radiator so they can't be quietly dropped. Staying inside your circle of influence is bad advice when it means burying the real blocker.
### How do we get retrospective action items to actually get done?
Cap it at one. A single improvement the team genuinely commits to, reviewed at the very top of the next retro before anything else, beats a list of ten that all quietly lapse. Give it an owner and a review date, and treat it as an experiment with a hypothesis rather than a chore on a list.
### Does a retrospective need an action item?
No, and insisting it does is part of the problem. The second edition of Agile Retrospectives reframes the success criterion as learning, not action items: a retro where the team genuinely understood something new isn't a failure just because it didn't generate a to-do. Run experiments you can learn from, not tasks you'll feel guilty about.
## Related reading
- [Power: when authority captures the ceremony](/guides/agile-theatre/power-agile-theatre/). Why the problems worth raising are so often above the team's pay grade.
- [Performance: the ceremony you run for the audience](/guides/agile-theatre/performance-agile-theatre/). The box-ticking retro, before the team gives up on it.
- [How to build a psychologically safe space](/guides/scrum-masters-retrospective-guide/how-to-build-a-psychologically-safe-space/). Candor that has somewhere to go.
- [The retrospective Prime Directive](/guides/scrum-masters-retrospective-guide/what-is-the-retrospective-prime-directive/). The norm that keeps the room honest.
- [The sprint retrospective (the ceremony)](/guides/agile-ceremonies-guide/sprint-retrospective/). Where the retro sits in the cycle, and the loop it exists to close.
- [Agile Theatre glossary](/guides/agile-theatre/agile-theatre-glossary/). The four coined failure modes, defined.
---
# The report exists. The room doesn't.
URL: https://www.teamretro.com/guides/ai-agent-retrospectives/the-report-exists/
**A discussion paper.** We're interested in every continuous-improvement cycle: removing friction from how teams work is our standing subject. One of the newer areas we think about is AI-assisted work, and we've been thinking it through the lens we know best: the retrospective. These are working positions, not conclusions; we'd genuinely like to be argued with: [ai-discussion@teamretro.com](mailto:ai-discussion@teamretro.com).
Recently, an AI agent filed six items on [our own retro board](/blog/our-ai-teammates-joined-our-retro/).
The first one read: *"Start verifying before acting — agent execution error is 38% of friction (2× the next cause); the recurring cost is asserting a cause, pushing, or retargeting before checking live code, data, or branch state."* Behind it sat the pattern evidence: git/branch-state errors under concurrent-agent work across eight sessions and two repos; partial pre-push checks that broke CI in four sessions, twice in one repo on the same day; a test-mocking gap that a session had flagged the day before, with the note that the fix doc *was never written*.
Two things about that board are worth staring at. First, no single work session would have ranked any of this as its top problem: each instance was a shrug, a few lost minutes, an annoyance someone worked around. The ranking only exists in aggregate, across sessions and people. Second, and more uncomfortable: the most damning items weren't about the agent or the code at all. They were about *us*: fixes we'd agreed to and not adopted, the same stall recurring with "no standing fix shipped between them."
An automated report can tell you all of this. What it can't do is get the people who own the process, the docs, the tooling budget, and the priorities to sit down and decide what to do about it. The report exists. The room doesn't. This paper is about the room.
## Everyone built the loop
By mid-2026, "capture what went wrong in AI-assisted work and feed it back" is consensus practice. It exists under at least six names, and they're all good. Rahul Garg's [Feedback Flywheel](https://martinfowler.com/articles/reduce-friction-ai/feedback-flywheel.html) harvests session friction into priming docs and guardrails. Every's [Compound Engineering](https://every.to/source-code/compound-engineering-the-definitive-guide) makes each unit of work teach the next. Thoughtworks instruments agents with [sensors](https://www.thoughtworks.com/en-us/insights/blog/generative-ai/harness-engineering-agent-feedback-exploring-ai-coding-sensors); Addy Osmani calls the discipline [Loop Engineering](https://addyosmani.com/blog/loop-engineering/). The platform vendors close the loop at fleet scale: [OpenAI's memory "dreaming"](https://openai.com/index/chatgpt-memory-dreaming/), [Anthropic's context curation](https://www.zenml.io/llmops-database/context-engineering-and-memory-management-for-production-agent-systems), [Factory Signals](https://factory.ai/news/factory-signals) auto-filing tickets. GitHub's open-source [`gh-aw`](https://github.com/github/gh-aw), a framework for agentic workflows written in natural-language markdown, goes furthest toward our subject: its session-insights workflows already generate automated session-analysis reports. [One public example](https://github.com/github/gh-aw/discussions/15173), a single day's automated analysis of 50 sessions, flags a 24% skip rate and a 33% executor-success rate as "Failure Signals."
If you use any of these: keep using them. This paper proposes replacing none of them. But sort [the loops](/guides/ai-agent-retrospectives/agent-feedback-loops/) by the level they run at and read the pattern:
**One** practitioner's playbook. **One** session's config. **One** platform's memory. **One** observability stack. **One** vendor's fleet.
Nearly every loop today is solo: a person and their agent, or a vendor and its fleet. The team layer, where the fix-owners compare notes together, is the piece nobody has built.
Nearly every loop in the field is a solo cycle: a person and their agent, or a vendor and its fleet. Garg's flywheel is the one design that reaches for shared team artifacts, and his cadence list includes a line almost nobody has operationalized: *"At the retrospective: an agenda item in the existing sprint retrospective: what worked with AI this sprint?"* He names the venue and moves on. GitHub's dogfooding, meanwhile, produces exactly the friction report a team ceremony would want as its *input*, and positions it as engineering observability, full stop.
The nearest thing to an exception comes from Scrum.org, whose hybrid-team series includes [How to Run the Sprint Retrospective When Half of Your Team is AI Agents](https://www.scrum.org/resources/blog/how-run-sprint-retrospective-when-half-your-team-ai-agents). It's worth reading, because it takes the venue question seriously and answers it differently than we do: their retro becomes a data-driven debugging session over agent metrics (prompt-rewrite frequency, deviation rates, token burn). That's a useful lens, and a team could run both. But it reviews the *agents*; the loop this paper is about reviews the *collaboration*: causes rather than symptoms, fixes routed to whatever level they belong (the brief, the docs, the process, the material), with the agents contributing their own account of the work rather than appearing as a dashboard.
The gap isn't technology. Every piece (capture, aggregation, reporting) ships today. The gap is a practice: **almost nobody has said what the team does, together, when the report arrives.**
## What actually needs a room
The instinct here is to automate harder: better clustering, auto-filed fixes, a dashboard. For a large class of findings that's correct, and the pipelines above do it well. But list the decisions the report actually raises and notice their shape:
- **Keep or kill.** Which recurring friction is waste, and which is deliberate control? The review gate that slows the agent down might be the leash someone chose ([a recap of Armin Ronacher's AIE Europe talk](https://www.youtube.com/watch?v=_Zcw_sVF6hU): "friction is what's necessary… to steer"); Thoughtworks' Radar now warns about the [cognitive debt](https://www.thoughtworks.com/about-us/news/2026/combat-ai-cognitive-debt-radar-v34) of removing too much. Deleting a control point changes everyone's risk. That's a team decision by definition.
- **Where the fix lands.** A recurring friction pattern gets fixed at some [*altitude*](/guides/ai-agent-retrospectives/where-should-the-fix-land/): a personal note, a prompt or skill, environment config, the docs, the work material itself, the process, or upstream with a vendor. Those artifacts have owners, and the owners are different people.
- **Priority under aggregation.** Five shrugged-off minutes per person per session is invisible to each person and a top team cost in the sum. Acting on it (rewrite the shared template, change the intake process, escalate to the vendor) takes a decision ceiling no individual has.
- **The adoption check.** Did last cycle's fix actually get adopted, and did the friction stop? Our own board's most valuable line was exactly this: *flagged yesterday, never written.* A loop without this check is a flywheel spinning in the air.
None of these is a computation. All of them are negotiations between people who own different pieces of how the team works. Solo practitioners legitimately fold these calls in by feel; fleet pipelines legitimately make the machine-legible subset at machine speed. The team-scale versions need people in a room with shared vocabulary and the authority to reallocate attention. That's not a pipeline. That's a ceremony.
## Why the retro, or your ceremony of equivalent shape
Full disclosure before the argument: **we sell retrospective software.** That's precisely why this section argues from properties rather than from the brand: discount our conclusion accordingly and check the properties yourself.
The properties the decision set needs: a venue that is **recurring** (chronic minor friction never triggers an episodic meeting), **blameless by norm**, **cross-owner** (the people who own process, docs, tooling, and priorities are present), and **evidence-fed**. For most teams, the [sprint retrospective](/retrospectives/) is where those four properties already live: no new meeting to defend in a calendar war, and a blameless convention that matters more than it looks, because the tempting failure mode here is the *agent-blame postmortem*, and the harness-engineering school explicitly rejects that default: the engineer blames the model and files it under "wait for the next version"; fix the harness instead ([Osmani, *Agent Harness Engineering*](https://addyosmani.com/blog/agent-harness-engineering/)).
But the honest form of the claim prices the rivals rather than declaring a winner:
- **Sprint planning** has the most authority in the room, but its agenda is forward-looking and chronically full; retrospective triage in a planning slot reliably starves. Planning is where accepted actions get *scheduled*, not where patterns get read.
- **The blameless postmortem** has exactly the right norms and the wrong trigger: it convenes for the big episodic failure, never for the five-minutes-eight-people-every-sprint pattern, which is precisely the pattern only aggregation can see.
- **Async (a report plus a tracker)** is the cheapest venue and, for the routine majority of items, enough. What it can't do is the judgment set: keep-or-kill is a negotiation, altitude disputes cross ownership lines, and reprioritizing needs the owners in the same conversation.
- **The null alternative (just talk about AI in the retro, no records, no labels)** is free, fits today, and for a small team with light agent use may genuinely be enough. Start there. What it can't produce is comparability across sessions, trends, or the adoption check: a conversation that starts from zero every time. The practice below is what you add *when that conversation keeps repeating itself*.
So the claim, honestly sized: **the retro, or your existing ceremony of equivalent shape.** A media team's monthly campaign review and a support team's triage review are the same ceremony wearing different names, and nothing in this practice assumes code: the friction log of a tangled ads account or an inconsistent template library reads exactly like the friction log of a legacy repo.
## The agent in the room: participant, never facilitator
If the evidence comes from agents, should the agent run the item? No, and not primarily for the reason you'd guess.
The reason that decays: today's models are unreliable at exactly this kind of judgment: LLM verdicts flip on identical inputs [~13.6% of the time](https://arxiv.org/abs/2606.13685), and in one eight-week production study [~70% of silent agent failures were first caught by a person](https://arxiv.org/abs/2606.14589), not by tests or monitoring. True today; models improve.
The reason that doesn't decay: facilitation and adjudication *allocate a team's attention* and change artifacts the team owns and answers for. That authority doesn't transfer to the most capable model in the room, any more than it transfers to the most capable engineer in the room. It's an organizational fact, not a capability gap.
So the agent participates the way the best-informed contributor does. It **brings evidence**: its [session records](/guides/ai-agent-retrospectives/ai-friction-records/), labeled and cost-noted. It **answers questions**: "what did you actually try before the workaround?" has a transcript-backed answer. It **drafts, never decides**: proposed fixes arrive with suggested altitudes; the room amends, reprioritizes, or kills them. And it **takes accepted actions back** (the doc edit, the config change), executing them after the ceremony under ordinary review. Research practice has a name for this division: in the ACE framework the agent is the [Reflector and a Curator consolidates](https://arxiv.org/abs/2510.04618) what enters the playbook. We make one deliberate adaptation: in ACE the curator is a deterministic component; here the curators are the team.
One asymmetry is load-bearing. Everything the agent brings *into* the room should be ungated, because an agent that needs permission to report friction under-reports. Everything that leaves the room *into what agents later rely on* (memory, context files, config) goes through ordinary review, because that write-path is a recognized poisoning-and-drift surface ([OWASP Agentic Top 10, ASI06](https://genai.owasp.org/)). The ceremony sits exactly at that boundary: ungated evidence in, gated writes out.
The ceremony sits on a boundary: evidence flows in ungated (an agent that needs permission to report under-reports) while what leaves, into the memory, docs, and config agents later rely on, passes ordinary review.
## The fifteen minutes
What we're actually proposing a team try, this sprint, with every loop it already runs intact:
1. **Per session**, the agent writes a short retrospective entry of its own work: what went well, each friction item with a root-cause label and what it cost, a proposed ticket-sized fix and the altitude it targets. Committed with the work, ungated.
2. **Before the retro**, the entries since last time are synthesized into a one-page brief: recurring themes with prevalence, which root-cause group dominates, whether past fixes were adopted, top-3 recommended actions. The brief feeds the conversation; it doesn't replace it.
3. **In the retro** (an agenda item, not a new meeting): fifteen minutes on "what worked with AI this cycle, and what kept hurting?" The humans triage: keep or kill, confirm or re-route the altitudes, assign owners to the top three.
4. **Next cycle**, the brief's adoption check reports whether the friction actually dropped. That check is what turns the report into a loop. It's also where our own board caught us.
Failure modes, named so you can defend against them: *retro theatre* ([the ceremony you run for the audience](/guides/agile-theatre/performance-agile-theatre/): brief read, heads nod, nothing decided; the top-3-with-owners rule exists for this); *agent-blame* (treating "the agent erred" as the explanation rather than the residual; most failures trace to the harness and the inputs, [not model reasoning](https://cobusgreyling.substack.com/p/the-four-layer-agent-failure-taxonomy)); *wishlist sprawl* (twenty actions, no owners); and *the loop never closing* ([the follow-through void](/guides/agile-theatre/the-follow-through-void/): fixes land, nobody checks the trend). We've written a whole [field guide to how ceremonies fail](/guides/agile-theatre/); every mode in it applies here too.
## What we're not claiming
Not a replacement for any vendor loop: their outputs are this ceremony's inputs. Not a new meeting. Not an AI-run ceremony; from a company whose product is retrospectives, the guardrail is deliberate. Not necessary for a solo practitioner, whose loops close fine by feel. And not friction-zero as the goal: some friction is the control surface, and the agenda item exists to *choose*, not to eliminate on sight.
## What would change our minds
This is a discussion paper, so here is the falsifiable part. If the vendor loops grow genuine cross-tool, cross-person judgment, not just fleet-wide memory writes, the room shrinks to an audit function. If teams that run the brief-only async version show the same friction-reduction trend as teams that run the agenda item, the fifteen minutes is theatre and we'll say so. And our own labeled-vocabulary claim rests on an inter-rater reliability experiment we are currently running on real entries rather than asserting in advance. We'd rather publish the numbers than the confidence.
If your team runs any version of this (the agenda item, the async brief, or a ceremony we haven't thought of), we want to hear what happened: [ai-discussion@teamretro.com](mailto:ai-discussion@teamretro.com).
---
**Next chapter:** [Running the AI collaboration retro](/guides/ai-agent-retrospectives/running-the-ai-collaboration-retro/). The facilitator's guide to the fifteen minutes: the template, the entry format, and the prompt cards. Part of the [AI agent retrospectives guide](/guides/ai-agent-retrospectives/).
---
# User story examples: 16 annotated stories, good and bad
URL: https://www.teamretro.com/guides/agile-estimation-guide/user-story-examples/
Sixteen user story examples, drawn from the domains teams actually work in: authentication, e-commerce, mobile, APIs, bugs, and internal tools. Each one is annotated: not just *what* the story says, but why the role and benefit clauses earn their keep. Four are deliberately bad, shown next to their rewrites, because the fastest way to learn the format is to watch it fail.
If the format itself is new to you, start with [what is a user story?](/guides/agile-estimation-guide/what-is-a-user-story/). The short version is that every story here follows *"As a [role], I want [goal], so that [benefit]"*, and every good one could go straight into refinement and a round of [planning poker](/guides/agile-estimation-guide/how-to-run-planning-poker/).
## Authentication and accounts
**1. Sign-in**
> As a returning customer, I want to sign in with my email and password, so that I can see my order history.
**Why it works:** the role is specific. "Returning customer" tells you this person has an account, has ordered before, and has a reason to come back: three facts a designer and a tester can use. "As a user" would have carried none of them.
**2. Password reset**
> As a locked-out user, I want to reset my password from the sign-in screen, so that I can get back into my account without contacting support.
**Why it works:** the benefit clause names a real cost. Every reset that goes through support is measurable money, so this story can be prioritized against others on evidence rather than vibes. Note what the sentence *doesn't* carry: token expiry, rate limits, the email template. That detail belongs in the [acceptance criteria](/guides/agile-estimation-guide/acceptance-criteria/), written when the team refines it:
- A reset email arrives within two minutes of the request.
- The reset link expires after one hour and can be used once.
- The form gives the same response whether or not the email exists (no account enumeration).
**3. The circular story**
> As a user, I want to log in, so that I can access the app.
**Why it fails:** every slot is filled and nothing is said. The role is nobody in particular, and the benefit restates the goal, so the "so that" clause could be deleted without losing information. A story like this passes the format check while skipping all the thinking the format exists to force.
**The rewrite:**
> As a project member returning mid-sprint, I want to land on the board I last viewed after signing in, so that I don't re-navigate there every morning.
Now there's a person, a moment, and a benefit someone could weigh against other work.
## E-commerce
**4. Cart persistence**
> As a shopper browsing on my lunch break, I want my cart to keep its items when I come back tonight, so that I don't have to find everything again.
**Why it works:** the role carries a scenario. "Browsing on my lunch break" explains *why* carts get abandoned mid-flow, which tells the team the persistence window that matters is hours, not seconds. A well-chosen role smuggles context into one clause.
**5. Guest checkout**
> As a first-time buyer, I want to check out without creating an account, so that I can finish my purchase before I change my mind.
**Why it works:** it takes a product position (accounts are optional) and states the honest benefit: hesitation kills first purchases. Stories this clear also expose disagreement early: if the business wants every buyer to have an account, that fight happens in refinement, not in the pull request.
**6. The metric wearing a story costume**
> As a shopper, I want a faster, cleaner checkout, so that conversion improves.
**Why it fails:** twice over. "Faster, cleaner" isn't a capability anyone can build or test, and "conversion improves" is the business's benefit, not the shopper's. No shopper wants conversion. This is a quarter's worth of work compressed into a sentence, which makes it an [epic](/guides/agile-estimation-guide/epic-vs-story-vs-task/), not a story.
**The rewrite** (one slice of it):
> As a buyer on my phone, I want my shipping address autofilled from my postcode, so that I can complete checkout one-handed.
The epic becomes a backlog of slices like this, each one testable and small enough to size.
## Mobile
**7. Offline mode**
> As a field technician, I want today's job sheet to load without a connection, so that I can keep working in basements and dead zones.
**Why it works:** the role selects the requirement. Office staff never notice offline support; field technicians live in it. When someone asks "how offline is offline?" in refinement, the role has already answered: wherever the job takes them.
**8. Notification preferences**
> As a subscriber getting three pushes a day, I want to choose which alert types send notifications, so that I stop muting the whole app.
**Why it works:** the benefit names the failure mode the story prevents. Users don't complain about notification volume; they mute the app and quietly leave. A story that names the silent behavior it's defending against is a story the team can argue about honestly.
## APIs and technical work
**9. Pagination**
> As an integration developer, I want paginated responses on the /events endpoint, so that my nightly sync doesn't time out on large accounts.
**Why it works:** this is the legitimate technical user story: the developer is a real, external user with their own goals, not the team writing itself into the sentence. API consumers, plugin authors, and on-call operators all pass that test.
**10. Rate limiting**
> As an API consumer, I want a 429 response with a Retry-After header when I hit the rate limit, so that my client can back off instead of failing the whole job.
**Why it works:** the goal is precise enough to be its own first acceptance criterion, and it's still a *what*, not a *how*: nothing here dictates the limiter's implementation.
**11. The refactor in disguise**
> As a developer, I want to refactor the payments module, so that the code is cleaner.
**Why it fails:** the role is the team, the goal is an activity rather than an outcome, and "cleaner" can't be tested. This is the story format applied to work it wasn't designed for, a case covered in [when user stories are the wrong tool](/guides/agile-estimation-guide/what-is-a-user-story/).
**The rewrite** (not a user story, on purpose):
> Reduce the payments module's provider-coupling so a new payment provider can be added without touching core checkout. Done when: the provider interface is extracted, the two existing providers run behind it, and the integration test suite passes unchanged.
A plain technical item with a named outcome beats a costumed story every time.
## Bug or story?
**12. The bug that is a story**
> As a customer on an annual plan, I want my invoice to show the discount I was quoted, so that finance can reconcile it without a support ticket.
**Why it works:** the cause is known and the fix has clear scope, so this behaves like any other story: it gets criteria, a size, and a slot in the sprint. Pointing bug work keeps [velocity](/guides/agile-estimation-guide/velocity/) honest about where capacity actually goes; the [story points chapter](/guides/agile-estimation-guide/what-are-story-points/) makes that argument in full.
**13. The bug that isn't**
> Customers intermittently report being charged twice. No reliable reproduction.
**Why it's not a story:** there is no scope to promise. A role-goal-benefit sentence ("As a customer, I want to not be charged twice…") would be true and useless, and any estimate would measure hope. The right move is a time-boxed [spike](/guides/agile-estimation-guide/splitting-user-stories/): investigate for two days, deliver what was learned, then write the real story for the fix.
## Internal tools and reporting
**14. Support tooling**
> As a support agent on a live chat, I want to see the customer's last five sign-in attempts, so that I can tell a forgotten password from a locked account in one look.
**Why it works:** internal users are still users. The benefit is measured in seconds-per-ticket, which is exactly the kind of concrete stake that lets this story compete with customer-facing work for a sprint slot instead of losing by default.
**15. Exports**
> As a team lead, I want to export the sprint report as CSV, so that I can share results with stakeholders who don't have accounts.
**Why it works:** the "so that" clause quietly scopes the work. Sharing *outside the tool* is the job, which rules out solutions like in-app dashboards and rules in boring, portable CSV. A good benefit clause does design work for free.
**16. The visibility epic**
> As a manager, I want a dashboard of everything the team is doing, so that I have visibility.
**Why it fails:** "everything" is not a scope and "visibility" is not an outcome: nothing here can be built, tested, or sized. Underneath a story like this is a real question the manager hasn't been asked yet.
**The rewrite:**
> As a delivery manager preparing the Monday status call, I want each team's sprint goal and its red/amber/green state on one page, so that I can flag blocked work without pinging every lead.
Same person, same instinct, but now it fits a sprint and a tester knows when it's done.
## What the good ones share
Look back across the twelve that work. Each names a person specific enough to have an opinion, states a goal that person would recognize, and carries a benefit that survives one honest "why?". None of them contain implementation, and none of them try to be complete. That's what [acceptance criteria](/guides/agile-estimation-guide/user-story-template/) and the refinement conversation are for.
The bad four fail in exactly two ways, which is encouraging: either the benefit is circular (nobody checked why) or the scope is an epic (nobody checked how big). Both failures surface the moment your team tries to estimate the story, which is why sizing sessions catch bad stories faster than any writing guideline: a wide vote spread is the format's error message. Write your next batch against the [template](/guides/agile-estimation-guide/user-story-template/), then put them in front of the team with [planning poker](/free-planning-poker-for-agile-teams/) and see which ones converge.
## Frequently asked questions
### What is an example of a user story?
"As a returning customer, I want to sign in with my email and password, so that I can see my order history." It names a specific person, a capability in that person's terms, and the reason the work is worth scheduling. That three-part shape (role, goal, benefit) is the classic user story format.
### How do you write a good user story?
Name a specific role rather than "a user", state the goal as something the person does rather than something the system contains, and finish the "so that" clause with a benefit that would survive one honest "why?". Then attach acceptance criteria, because the story sentence is a conversation starter, not the requirement.
### Can technical work be written as a user story?
Sometimes. If the "user" is real (an integration developer consuming your API, an operator on call), the format works as written. If the only honest role is "the team", drop the costume and write a plain technical item with a named outcome and acceptance criteria. The discipline transfers; the sentence shape doesn't have to.
### Should bugs be written as user stories?
A bug with a known cause and a clear fix can be, and pointing it keeps velocity honest. A bug nobody can reproduce cannot: there is no scope to promise, so a story would just be a guess with a benefit clause. Time-box an investigation first, then write the real story for whatever it finds.
### How detailed should a user story be?
One sentence of story, then three to five acceptance criteria. The sentence earns the conversation; the criteria capture what the conversation decided. If the criteria list keeps growing past five, the story is several stories, and the criteria are showing you where to split it.
## Related reading
- [Agile estimation: the complete guide](/guides/agile-estimation-guide/). The hub for everything here.
- [What is a user story?](/guides/agile-estimation-guide/what-is-a-user-story/). The format, the three Cs, and the INVEST checklist behind every example above.
- [User story template and acceptance criteria](/guides/agile-estimation-guide/user-story-template/). A copy-paste template and a worked example through to estimation.
- [Splitting user stories](/guides/agile-estimation-guide/splitting-user-stories/). What to do with the epics hiding in examples 6 and 16.
- [Agile estimation examples](/guides/agile-estimation-examples/). The companion series: what sizing these stories actually sounds like in the room.
---
# User story template and acceptance criteria
URL: https://www.teamretro.com/guides/agile-estimation-guide/user-story-template/
The user story template is one sentence with three blanks:
> As a **[role]**, I want **[goal]**, so that **[benefit]**.
Copy it, use it, but know what it's for: the template is a prompt for a conversation, not a form to complete. A filled-in sentence is where refinement *starts*. What makes the story workable is what gets attached next: the acceptance criteria that turn an agreed intention into a pass/fail test, and the estimate that turns it into plannable work. This chapter carries one story through all three.
## Filling the blanks without faking them
Each slot has a common misfire, and each misfire is checkable:
- **[role]**: a specific person, never "a user." If you couldn't pick this person out of your analytics or your support queue, the role is decoration. *Test: could a designer make one decision differently because of the role you chose?*
- **[goal]**: what the person does, in their vocabulary. "I want to reset my password" belongs to the user; "I want a password-reset microservice" belongs to the architecture diagram. *Test: would the person actually say this sentence?*
- **[benefit]**: the argument for scheduling the work. *Test: delete the clause. If nothing is lost, the benefit hasn't been found yet.*
The full reasoning behind the format (including the three Cs and the INVEST checklist a finished story should pass) is in [what is a user story?](/guides/agile-estimation-guide/what-is-a-user-story/). Sixteen worked instances, good and bad, are in [user story examples](/guides/agile-estimation-guide/user-story-examples/).
## A copy-paste story card
The sentence alone is not enough to take into a sprint. Here is the full card shape worth standardizing on, with story, criteria, boundaries, and a size added last:
```text
Story
As a [role], I want [goal], so that [benefit].
Acceptance criteria (3–5, each pass/fail)
- [ ] …
- [ ] …
- [ ] …
Out of scope
- What this story deliberately does NOT cover.
Notes & dependencies
- Designs, decisions, other teams, open questions.
Size: [added by the team, after the conversation — never before]
```
Two deliberate choices in that card. **"Out of scope" is load-bearing:** most estimation arguments are two people sizing different scopes, and one line here prevents them. **The size comes last:** a number written on the card before the team discusses it becomes an anchor, which is the first of the classic [planning poker mistakes](/guides/agile-estimation-guide/planning-poker-mistakes/).
## Template variants
The classic template is the right default, and it isn't the only shape that works.
| Variant | Shape | Reach for it when |
|---|---|---|
| Classic (Connextra) | As a [role], I want [goal], so that [benefit] | The default for user-facing work |
| Job story | When [situation], I want to [motivation], so I can [outcome] | The triggering moment explains more than the persona (the same person on a train wants different things than at a desk) |
| Benefit-first | In order to [benefit], as a [role], I want [goal] | The team keeps writing circular benefits; putting the clause first makes it impossible to skip |
| Plain problem statement | One sentence of problem, one of outcome, plus "done when" criteria | Platform and technical work where the only honest persona would be the team itself |
The last row matters more than it looks. Some backlog items have no user in the sentence, and pretending otherwise produces filler like "as a developer, I want the framework upgraded." The template's discipline (a stated reason plus testable criteria) transfers to that work; the sentence costume doesn't need to.
## Acceptance criteria: the confirmation on the card
Acceptance criteria are the story's pass/fail conditions, written before work starts. On the card they do two jobs: they capture what the refinement conversation actually agreed, and they define the finish line the estimate will be sizing toward. Two formats cover nearly every story:
**A plain checklist**, for independent conditions:
- Cart contents persist across sessions for 30 days.
- A returning shopper sees the cart from any signed-in device.
- An emptied cart stays empty (no resurrection of removed items).
**Given/When/Then**, for behavior that depends on state:
- **Given** a shopper with a saved cart, **When** an item goes out of stock, **Then** the cart shows the item grayed out with an "out of stock" label rather than silently removing it.
Default to the checklist; reach for Given/When/Then when the precondition is doing real work. Keep the list to three to five entries. A longer list usually means the story should [split](/guides/agile-estimation-guide/splitting-user-stories/), and the criteria are showing you the cut lines. For the full treatment (criteria vs requirements, criteria vs definition of done, who writes them), see the [acceptance criteria chapter](/guides/agile-estimation-guide/acceptance-criteria/).
## Worked example: one story, template to estimate
Here is the path a real story takes, using the card above.
Criteria before points. A card with a clear role, a falsifiable benefit and three to five criteria converges in a vote or two; a vague one produces a spread nobody can resolve.
**Step 1: the story.** The product owner writes:
> As a first-time buyer, I want to check out without creating an account, so that I can finish my purchase before I change my mind.
**Step 2: the conversation, captured as criteria.** In [backlog refinement](/guides/agile-ceremonies-guide/backlog-refinement/) the team surfaces the edges the sentence doesn't carry, and writes them down:
- [ ] A buyer can complete checkout with only email and shipping details, no password.
- [ ] The order confirmation email offers account creation with one click (order already attached).
- [ ] A guest order is findable by support via the order number plus email.
- [ ] Guest checkout respects the same fraud checks as account checkout.
**Out of scope:** converting historical guest orders when an account is created later.
**Step 3: the readiness check.** Four criteria, one named exclusion, no unconfirmed dependencies: the story passes the [definition of ready](/guides/agile-estimation-guide/definition-of-ready/) and goes to the team for sizing.
**Step 4: the estimate.** The team votes in a round of [planning poker](/guides/agile-estimation-guide/how-to-run-planning-poker/). Cards come up 3, 5, 5, 8. The 8 explains: the fraud-check criterion means touching the payments provider integration, which nobody else had priced in. That's the criteria doing their real job: the discussion is about scope, not about whose number is right. The team re-votes and converges on 5.
Notice the direction of travel: criteria first, then points. A story estimated before its criteria exist produces the wide, unresolvable spreads that stall sizing sessions. The team ends up voting on different stories that happen to share a title.
**The template's payoff is measured in the sizing session.** A story with a specific role, a falsifiable benefit and three to five criteria converges in one or two votes. A vague one burns ten minutes and converges on a guess. If your planning poker sessions run long, the fix is usually upstream, on the card. Try it: take your next story through this card, then [run the vote](/free-planning-poker-for-agile-teams/) and watch the spread.
## Frequently asked questions
### What is the user story template?
"As a [role], I want [goal], so that [benefit]." The role names who gets the value, the goal names the capability in that person's terms, and the benefit is the reason the work deserves a place in the backlog. The template is a prompt for a conversation, not a form to complete. Filling in the blanks is where refinement starts.
### How do you write acceptance criteria for a user story?
Write three to five testable conditions that say, pass or fail, whether the story delivered what was agreed. Use a plain checklist when the conditions are independent, and Given/When/Then when the behavior depends on state. Each criterion should be checkable by a tester who never attended the refinement conversation.
### Should acceptance criteria use Given/When/Then or a checklist?
Match the format to the behavior. Given/When/Then earns its keep when the outcome depends on a starting state, because it forces you to name the precondition, the trigger and the result. A checklist is faster to read and harder to pad when the story is simply "these four things must be true." Most stories need only the checklist.
### What is a job story?
A variant that replaces the persona with a situation: "When [situation], I want to [motivation], so I can [outcome]." Job stories come from the jobs-to-be-done school and work well when the triggering moment explains the requirement better than a persona does. The same person wants different things at their desk and on a train.
### Does every backlog item need the user story template?
No. The template describes user-facing value, and forcing it onto platform work, known bugs or research spikes produces sentences that add ceremony without information. Keep the two disciplines that always transfer (a stated reason and testable acceptance criteria), and let the sentence shape fit the work.
## Related reading
- [Agile estimation: the complete guide](/guides/agile-estimation-guide/): the hub for everything here.
- [What is a user story?](/guides/agile-estimation-guide/what-is-a-user-story/): the reasoning behind the template, the three Cs and INVEST.
- [User story examples](/guides/agile-estimation-guide/user-story-examples/): sixteen annotated stories to calibrate against.
- [Acceptance criteria: how to write them](/guides/agile-estimation-guide/acceptance-criteria/): the full chapter on the confirmation step.
- [Definition of ready](/guides/agile-estimation-guide/definition-of-ready/): the gate a templated story clears on its way into the sprint.
- [What are story points?](/guides/agile-estimation-guide/what-are-story-points/): the unit the finished card gets sized in.
---
# Team velocity in agile: how to measure and use it (+ free calculator)
URL: https://www.teamretro.com/guides/agile-estimation-guide/velocity/
Team velocity is a forecast input, not a KPI. The moment you measure teams on it, it inflates.
Velocity is the average number of story points a team completes per sprint, taken over the last few sprints. That is the whole definition. It exists for one job: projecting how many sprints a backlog will take to ship, given the team's actual rate of delivery. Sum the points remaining, divide by velocity, and you have a forecast. That is the only thing it does honestly.
Every other use breaks it. "Why was velocity lower this sprint?" turns each retrospective into a defense of the number. "Team A has a higher velocity than Team B" treats two teams' independent calibrations as comparable when they are not. "We need to increase velocity by 20% this quarter" tells the team to make the number go up, and the team will, by sizing the same work bigger rather than doing more of it. That is Goodhart's law running on a two-week cycle.
One honest caveat before the how-to: the Scrum Guide does not mention velocity. It is a common practice layered on top of Scrum, not a rule of it, which is exactly why it is worth being deliberate about what you use it for.
## Free velocity calculator
Here is the fastest way to see velocity in action. Enter the points your team completed in each recent sprint, and, if you want the forecast, the points left in the backlog. The calculator averages your recent sprints and returns a sprint-count forecast, all on this page. No sign-up.
Three sprints of 21, 34 and 26 average to a velocity of 27. Divide the points remaining by 27 to forecast the sprints left.
Read the range, not just the average. Your next sprint lands somewhere between your best recent sprint and your worst, so a forecast quoted as a single number carries more certainty than the data does. "Eight to ten sprints" is an honest answer. "8.7 sprints" is false precision wearing a decimal point.
## How to calculate team velocity
Take the points completed in each of the last three to five sprints. Average them. That is your velocity.
A worked example, over three sprints:
| Sprint | Story points completed |
|---|---|
| Sprint 7 | 21 |
| Sprint 8 | 34 |
| Sprint 9 | 26 |
Velocity = (21 + 34 + 26) divided by 3 = 27 points per sprint.
If the backlog has 210 points remaining, the forecast is 210 divided by 27, which is about 8 sprints. Because the inputs ranged from 21 to 34, the honest version is "seven to ten sprints", not "7.8 sprints". Or skip the arithmetic and let the calculator above run it for you.
The rules that keep the number honest: do not adjust for "exceptional" sprints, because the exceptional sprints are part of the signal you are trying to smooth out. Do not count carried-over work twice, and do not count partially completed stories at all. They count in the sprint they actually finish. The simpler the calculation, the harder it is to game.
Velocity stabilizes after a team has been running together for three or four sprints. A new team, a new reference story, or a major personnel change are all reasons to throw out the prior number and rebuild from scratch. The number is not a property of the technique. It is a property of this team in this period of time. A team that lost two members yesterday has yesterday's velocity for a different team.
## Using velocity to plan the next sprint
Velocity earns its keep in sprint planning, and the method is short:
1. Start from the rolling average of the last three to five sprints, never a single sprint's number, and never your best sprint.
2. Adjust for known capacity changes. Two people on leave next sprint? A public holiday? Scale the target down proportionally before planning, not apologetically afterwards. Velocity assumes the team that produced it, and next sprint's team is sometimes smaller.
3. Commit below the average, about 80 to 90 percent of it. Pick stories until they sum to roughly that, and leave the slack for the unplanned work that arrives every sprint whether you plan for it or not.
4. Forecast in ranges. For anything beyond the next sprint, quote your best and worst recent sprints as the bounds. Stakeholders can plan around "seven to ten sprints". They cannot plan around a precise number that turns out to be wrong.
Use velocity to do three things, and only three: project a date for a known scope (scope divided by velocity gives a sprint count), decide what fits in the next sprint, and spot when something has changed (a 30 percent drop is signal worth a retrospective conversation). What you cannot do with it: compare it to another team's number, use it to grade the team, or convert it to "expected hours per developer per day". Each of those is the same mistake wearing a different hat.
## How many story points per sprint?
Searching "how many story points per sprint" is a category error. There is no industry number, no "good" number, no per-developer-per-day rate. Velocity is the team's measured throughput, and the only useful version is the rolling average over the team's own last few sprints. Fifteen points, forty points, a hundred points, none is right or wrong. They are calibrated to the team's reference story.
The two easy sprints pull the average above the team's sustainable rate. Plan to the typical sprint, not the mean.
## The big mistake: velocity as a performance score
The single most common failure mode: a manager reads a velocity number as "how productive is this team?" It gets quoted in status meetings, then compared across teams, then targeted. Within two sprints the team has rebased its sizing to make the number go up, every story now sizes 30% bigger than it used to, and velocity has stopped meaning what it used to. The forecast it was supposed to produce is now wrong.
The second: comparing teams. Two teams sizing the same backlog produce different velocity numbers because they use different reference stories, which is the whole point of relative estimation. Comparing them is like comparing two thermometers with different zero points. The numbers do not mean the same thing, and treating them as if they did corrupts both teams' calibration.
**If a manager outside the team is asking "is your velocity good?", the fix is upstream, not the velocity number.** The honest answer to "what are you actually trying to measure?" is almost never a point count.
Want the arithmetic done for you? Jump back to the [free velocity calculator](#free-velocity-calculator) and run your own sprints through it.
## When to re-estimate
Re-estimating completed work breaks velocity. Re-estimating carried-over work is the only honest case.
The question comes up every quarter: "we sized this as a 5, it was actually a 13, should we update it?" The instinct that says yes is the same instinct that wants every number to be retroactively correct, and it's wrong. Velocity is the rate at which the team, at the calibration it had *at the time*, completed work. Going back and rewriting the points rewrites the calibration too, and the forecast that used to work stops working. "The team got faster, so old stories should be smaller" removes the only signal that the team improved. "This 5 turned out to be a 13" is a refinement signal for sizing the *next* story like it, not a license to rewrite this one's history.
The one case where you should re-estimate is carry-over. A story didn't finish, the sprint is closing, the remaining work moves into next sprint's commitment. That remaining work is materially different from what was sized at the start: the team has done some of it, found at least one unknown, and has a clearer view of what's left. Vote it again as if it were new, using the original estimate as a sanity check rather than a constraint.
## Normalizing velocity across teams
Normalization is mostly a SAFe ritual to make a portfolio dashboard add up. Resist it unless someone above you genuinely needs that dashboard.
Normalization gets two or more teams to agree on a shared reference story, usually something like "one person-day of work for an average engineer", so a 5 on Team A means the same thing as a 5 on Team B, and their velocities can be summed. The technique works: a normalized 5 really does mean the same across the teams that agreed to it. The problem is what you traded for it. You've swapped each team's relative-estimation property for an absolute one, which is [estimating duration in disguise](/guides/agile-estimation-guide/story-points-vs-hours/), just so a number can be averaged across teams that don't share a codebase, a stack or a domain.
If a portfolio-level forecast genuinely funds work (not just compares teams), do the normalization at the rollup layer: have program management keep a per-team points multiplier, calibrated once and revisited rarely, and apply it when the numbers roll up. Each team still estimates against its own reference story; the multiplier turns team velocity into the portfolio's currency, and refinement meetings never see it. What to push back on: normalization that starts inside a single team, and normalization done to make team comparison easier. That second one isn't a use case, it's an anti-pattern with a polished name.
## Velocity and AI coding tools
Copilot, Cursor, Claude Code. The points don't change. Velocity does, and only after the fact.
The question shows up in every team that's used an AI coding assistant for a few months: we're shipping faster, should we re-size the backlog? Should last quarter's 3 be this quarter's 5? The answer is no, because story points were never measuring the thing that changed. Points measure relative complexity and uncertainty; the assistant reduces the keyboard time on a story, sometimes dramatically, but the complexity is unchanged, the unknowns are unchanged, the integration risk and edge cases are unchanged. Re-point a 5 to a 3 because the tool wrote the boilerplate and you're estimating in hours again.
What changes is velocity. The same team shipping the same kind of work with an assistant ships more points per sprint than it did six months ago, not because the points got smaller, but because the team got faster at turning points into shipped code. That's the number doing exactly its job, and it [rebases naturally](/guides/agile-estimation-guide/what-are-story-points/) over three or four sprints. Keep the team's reference story recent, one they shipped *with the tools they use now*, and the calibration already accounts for whatever speed-up exists.
Two things to push back on. "Velocity is up 30%, let's commit to 30% more" double-counts the improvement: the recent average already includes the AI effect, so don't scale it again. "Everything got smaller, let's re-estimate the backlog" is the re-estimation trap above: the stories didn't shrink, the team got faster, and the forecast already reflects it. Uncertainty is where the tools help least: an assistant speeds up parts of a [spike's](/guides/agile-estimation-guide/splitting-user-stories/) investigation, but the thing the spike is trying to learn hasn't gotten any smaller.
## Estimate together in TeamRetro
Velocity is only as good as the estimates behind it. TeamRetro [Estimations](/estimations/) runs planning poker with your team, live or async, so the points you feed this calculator come from the whole team's judgement, not one person's guess. Try TeamRetro Estimations, or start with the [free planning poker tool](/free-planning-poker-for-agile-teams/).
## Frequently asked questions
### What is team velocity in agile?
Team velocity is the average number of story points a team completes per sprint, usually measured over the last three to five sprints. It is a planning input, used to forecast how much fits in the next sprint and how long a backlog will take, not a measure of how good the team is.
### How do you calculate team velocity?
Add up the story points completed in each of the last three to five sprints and take the average. If your last three sprints completed 21, 34 and 26 points, your velocity is 27. Count only finished stories, in the sprint they finished, or use the free calculator on this page to run the numbers.
### What is a good team velocity?
A stable one. There is no benchmark, because every team's points are calibrated to its own reference story, so 15, 40 and 100 can all be healthy. A good velocity is one you can plan against, not a number that keeps climbing.
### Should you compare velocity across teams?
No. Different teams calibrate points against different reference stories, so their velocities are not in the same units. Comparing them is like comparing two thermometers with different zero points. Cross-team comparison also pressures teams to inflate estimates, which corrupts the forecasts velocity exists to produce.
### What if we don't estimate in points, for example we use t-shirt sizing?
You can still track a rough throughput, but you cannot get a true velocity number straight from t-shirt sizes, because sizes do not add up. Two options. Map the sizes to a simple point scale first (for example XS=1, S=2, M=3, L=5, XL=8), total the completed items each sprint, and treat the result as a coarse trend rather than a precise figure. Or, if your items are usually similar in size, count throughput instead: the number of items finished per sprint. Both are rougher than points-based velocity, so read them as direction, not decimals. When you need a real forecast, re-estimate the near-term work in points. See our guide to [t-shirt sizing](/guides/agile-estimation-guide/t-shirt-sizing/) for the size-to-points bridge.
### How do we account for work that isn't recorded as sized items?
Velocity only reflects the work you actually size and track. Support tickets, meetings, interruptions and un-pointed bug fixes still consume capacity, so if a lot of that work is invisible, your velocity will look lower than the team's real effort and your forecasts will run optimistic. Two honest fixes. Capture the recurring unplanned work as sized items so it enters velocity like everything else. Or reserve capacity for it openly, by committing to about 80 to 90 percent of your average and leaving the rest as slack. Do not back-fill points onto invisible work just to make the number look bigger, because that breaks the calibration velocity depends on.
### How do you treat re-work in velocity?
Re-work is real effort, but re-pointing a story that was already counted as done breaks velocity. Treat re-work as new work: create a new item, size it, and count it in the sprint it is completed. Do not reopen the original story and re-estimate it. If re-work keeps showing up, that is a quality signal worth a retrospective conversation, not a velocity adjustment. The forecast stays honest only if each point is counted once, in the sprint the work actually finished.
### How many story points per sprint is normal?
There is no industry number. Velocity is your team's measured throughput, the rolling average of points completed over the last few sprints. Fifteen, forty, a hundred: none are right or wrong, because each is calibrated to a different reference story.
### How many story points per sprint per developer?
Don't compute one. A per-developer rate turns story points back into disguised hours and invites the cross-person comparison the technique is designed to avoid. Velocity is a team number, not a sum of individual quotas.
### How many story points are in a two-week sprint?
However many your team has historically completed in a two-week sprint. Measure it, do not target it. Pick stories until they sum to roughly 80 to 90 percent of your recent average, and leave room for the unplanned.
### What is a good velocity for a scrum team?
A stable one. "Is our velocity good?" is the question that breaks the system. The moment velocity is graded, points inflate and nothing actually ships faster. A good velocity is one you can plan against, not a number that keeps climbing.
## Related reading
- [Story points vs hours](/guides/agile-estimation-guide/story-points-vs-hours/): why the points-to-hours conversion is the failure mode velocity replaces.
- [Velocity and capacity planning](/guides/sprint-planning-guide/velocity-and-capacity/): using velocity to size a realistic sprint commitment.
- [What is a burndown chart?](/guides/agile-metrics/burndown-chart/): how teams track the points they committed to within a sprint.
- [Agile estimation techniques](/guides/agile-estimation-guide/estimation-techniques/): where velocity fits among planning poker, story points and the rest, and which to use when.
- [Agile estimation guide](/guides/agile-estimation-guide/): the full estimation cluster.
- [Free planning poker for agile teams](/free-planning-poker-for-agile-teams/): estimate the points velocity is built from.
---
# Velocity and capacity planning
URL: https://www.teamretro.com/guides/sprint-planning-guide/velocity-and-capacity/
Velocity and capacity are the two numbers that keep a sprint honest, and teams that conflate them overcommit sprint after sprint. **Velocity** is how much work you have historically finished per sprint. **Capacity** is how much time you actually have this sprint. They answer different questions, and when they disagree, the smaller one is usually right.
## The distinction that gets missed
Velocity is backward-looking: average the story points your team completed over the last few sprints and you have a reasonable expectation for a *normal* sprint. It smooths out the noise of any single sprint into a planning baseline. Those points come out of estimation, so if your numbers wobble, tightening how you [estimate as a team](/estimations/) steadies the velocity average that planning leans on.
Capacity is forward-looking and specific to the sprint in front of you. Two developers on leave, a public holiday, a heavy on-call week, the all-hands on Thursday: none of that shows up in your velocity average, but all of it eats the sprint you are about to plan.
So velocity tells you what a typical sprint looks like. Capacity tells you whether *this* sprint is typical. Plan on velocity alone and every holiday-shortened or leave-heavy sprint blows up. Plan on capacity alone and you lose the calibration that stops you from wildly over- or under-loading a normal sprint. You need both, and where they conflict, trust capacity. It knows something the average does not.
Velocity is the historical average; capacity is what this sprint actually holds. When a holiday or heavy support week shrinks capacity below velocity, plan to the smaller number. The average does not know about the holiday.
## Calculating capacity you can trust
Capacity is simple arithmetic that teams routinely get wrong by being optimistic. Start high and subtract honestly:
1. **Working days in the sprint × people.** Your gross starting figure.
2. **Subtract planned time off**: leave, public holidays, part-time schedules.
3. **Subtract standing commitments**: the ceremonies themselves, recurring meetings, 1:1s.
4. **Subtract the support and interrupt load**: on-call, production issues, "quick questions" that are never quick. If you run a support rotation, that person is not available for sprint work, so do not count them.
5. **Keep a buffer for the unplanned.** Something always lands. A team that plans to 100% of its remaining time has planned to fail the first time reality intrudes.
What remains is capacity. The most common error is skipping steps 4 and 5. The interrupt tax is real, and a sprint planned as if it will not happen is a sprint planned for a team that does not exist.
**Pro tip:** track planned capacity against what actually got done, sprint over sprint. After a handful of sprints the gap between the two tells you your team's real interrupt tax, and you can bake it into the buffer instead of rediscovering it every fortnight. Your [retrospective](/guides/scrum-masters-retrospective-guide/) is the place to look at that gap together.
## Velocity is a planning aid, not a scoreboard
This is the point where velocity gets ruined. Velocity works for exactly one purpose: helping a single team forecast its own future sprints. The moment it becomes a target to grow, or a stick to compare teams with, it stops measuring anything, because the easiest way to raise your velocity is to inflate your estimates, and everyone quietly does.
Story points are relative to one team's shared sense of size. They do not transfer. Team A's 8 is not Team B's 8, so "Team A did 60 points and Team B did 40" is a comparison of two different rulers. Velocity is a planning aid, not a scoreboard. Respect that boundary and it stays useful.
For how velocity is actually calculated, how many sprints to average, and how to handle a brand-new team with no history, see the [velocity chapter in the estimation guide](/guides/agile-estimation-guide/velocity/). It goes deep on the mechanics so this chapter can stay focused on planning. And if the estimates feeding your velocity are shaky, that is an [estimation](/guides/agile-estimation-guide/) problem to fix in refinement, not in planning.
## Putting both to work in planning
In the meeting, the two numbers play distinct roles. Capacity sets the ceiling: pull work until the estimate total reaches your calculated capacity for *this* sprint, then stop. Velocity is the sanity check: if your capacity-based selection is wildly above or below your normal velocity, something is off (either your capacity maths or your estimates) and it is worth a second look before you commit.
Practically: work out capacity first, use it as the hard limit during [selection](/guides/sprint-planning-guide/sprint-planning-meeting/), and glance at velocity to check the result is not surprising. When capacity and velocity disagree because the sprint is short-staffed or holiday-shortened, take the smaller number and move on. Under-committing costs you a little slack; over-committing costs you the sprint goal.
## Frequently asked questions
### What is the difference between velocity and capacity?
Velocity is how much work a team has historically completed per sprint, measured in story points: a backward-looking average. Capacity is how much time the team actually has this sprint, after leave, meetings, and support load. Velocity tells you a normal sprint; capacity tells you whether this sprint is normal. You need both.
### How do you calculate team capacity for a sprint?
Start from the working days in the sprint, multiply by the number of people, then subtract the honest deductions: planned leave, public holidays, standing meetings and ceremonies, support or on-call rotations, and a buffer for the unplanned. What remains is capacity. Most teams overstate it by forgetting the interrupt tax.
### Should you plan to your full velocity?
No. Velocity is an average, so planning to it means overcommitting half the time by definition. Plan to your capacity for this specific sprint, sanity-checked against velocity. When the two disagree (a holiday-shortened sprint, say), trust capacity and take the smaller number.
### Is velocity a measure of productivity?
No, and treating it as one breaks it. Velocity is a planning aid for one team's own forecasting. The moment it becomes a target or a cross-team comparison, teams inflate estimates and the number stops measuring anything. Points do not transfer between teams.
---
# What are story points? Estimating effort, not time
URL: https://www.teamretro.com/guides/agile-estimation-guide/what-are-story-points/
Story points measure the **relative effort** of a piece of work (its size, complexity and uncertainty rolled into one number), not the hours it will take. You size a backlog item against a reference story the team already shipped ("this is about twice that one") instead of guessing a duration. That single shift is what lets the estimate survive contact with reality.
## Why measure effort, not time
A team that estimates in hours is really carrying two estimates: the one the senior engineer believes, and the one the junior engineer writes down after rounding up to look responsible. People are unreliable at "how long will this take" and surprisingly good at "is this bigger than the thing we finished last sprint." Story points lean on the second.
[Relative sizing](/guides/agile-estimation-guide/relative-vs-absolute-estimation/) lets the team agree that one item is larger than another without anyone committing to a number of hours, which sidesteps the anchoring and seniority bias that hour estimates invite. The number that comes out isn't a duration; it's a position on a shared scale.
Sizing in effort rather than hours sidesteps three problems that dog hour-based estimates:
- **An estimate is not a commitment.** Hours invite stakeholders to treat "8 hours" as a promise; points keep the estimate a forecast.
- **The same task takes different people different times.** A point reflects the work, not the person.
- **Duration ignores risk.** A short but uncertain task can be riskier than a long, well-understood one, so points fold that uncertainty in.
## How story point estimation works
Most teams vote on a [Fibonacci-style scale](/guides/agile-estimation-guide/why-fibonacci/), 1, 2, 3, 5, 8, 13, in a round of [planning poker](/guides/agile-estimation-guide/how-to-run-planning-poker/). The gaps widen on purpose: the bigger the work, the less anyone really knows, so the scale stops pretending you can tell a 9 from a 10. Add up the points a team finishes each sprint and you get [velocity](/guides/agile-estimation-guide/velocity/), the one forecasting input points are actually meant to produce.
The scale is fine-grained where teams can tell items apart and coarse where they can't. A 5 versus an 8 is a real argument; a 19 versus a 20 is noise.
If an item comes out larger than about a 13, that is usually the scale telling you to [split it](/guides/agile-estimation-guide/splitting-user-stories/) into pieces the team can understand and finish inside a single sprint.
For a faster, rougher first pass, some teams size the whole backlog in [t-shirt sizes](/guides/agile-estimation-guide/t-shirt-sizing/) and convert only the near-term work to points once it is refined. Sizing a whole backlog at once? Start with [affinity estimation](/guides/agile-estimation-guide/affinity-estimation/) and label the groups with points at the end.
In a round of planning poker, everyone reveals their card at the same time, so nobody anchors on the loudest or most senior voice. Where the high and low estimates diverge, those two people explain their reasoning, and that conversation, which surfaces the assumptions and hidden complexity behind the number, is usually worth more than the number itself. The [full planning poker walkthrough](/guides/agile-estimation-guide/how-to-run-planning-poker/) covers the mechanics.
The single biggest failure mode is the team that starts [converting points back into hours](/guides/agile-estimation-guide/story-points-vs-hours/). The moment that conversion table goes on the wiki, every estimation conversation collapses into a duration argument and the relative-effort property is gone.
**Points don't have units.** If someone can convert a story's points into hours, the team is estimating hours with extra steps. When a stakeholder needs a date, project it from velocity, never from a per-story points-to-hours rate.
## Which work should you point?
Two questions come up in every refinement meeting: does this even get points, and if so, how many. The "how many" is what the scale is for. The "does it" has a rule of thumb: point anything the team ships as part of its committed work, so the velocity signal reflects where capacity actually goes.
### Bugs
A bug with a known cause and a clear fix is a story. It has acceptance criteria ("the form no longer accepts negative quantities"), a defined scope and a reasonable size, so vote it like any other story. Bug work and feature work compete for the same capacity, and velocity should show that.
The exception is the bug whose nature is "we don't know what's in there yet": *investigate the data corruption*, *figure out why p99 doubled*, *customers keep reporting it and we can't reproduce it.* The fix isn't sized because the cause isn't known, so a story-point vote just measures what the team hopes to find. Put those on a time-boxed investigation track: spend a day or two looking, then come back with a real story for whatever you found.
**Be wary of a "no points for bugs" policy.** Velocity isn't a grade, it's a planning signal. If a third of capacity goes to bug work, you want that in the number, not hidden. And the moment "no points for bugs" becomes policy, teams quietly start re-classifying small features as bugs.
### Testing and QA
Story points size the work between "story enters the sprint" and "story is shippable", which includes whatever QA the team does as part of done: automated tests, manual verification, accessibility checks, security review. The story isn't done when the PR merges; it's done when it meets the [definition of done](/guides/agile-estimation-guide/definition-of-done/).
Teams that point dev-only work and bolt QA on separately overcommit every sprint, because QA is the bottleneck nobody sized. If a separate QA team owns the testing, the story still carries the dev-side cost of working with them: preparing the build, writing the test plan, fielding questions. That part isn't free, so it stays in the estimate.
## Why you rarely want a 1-point story
Points are relative, so a 1 is only meaningful next to a 2, a 3, an 8. When a team has a steady stream of 1-point stories, that gradient is gone: everything tiny is a 1, everything bigger is a 2 or 3, and the scale has collapsed to a coin flip.
The fix isn't to ban 1s (that's the cargo-cult version of the rule). It's to ask why so much work is sizing at the bottom. Usually the [reference story has drifted](/guides/agile-estimation-guide/velocity/): the team got faster, and the original "1" is now smaller than anything they ship, so pick a newer reference the team remembers and re-anchor. Sometimes the team is over-decomposing in refinement, pulling every acceptance criterion out as its own story: "update the button text" isn't a [story](/guides/agile-estimation-guide/what-is-a-user-story/), it's an [acceptance criterion](/guides/agile-estimation-guide/acceptance-criteria/) on a bigger one. And sometimes the work genuinely is small (a maintenance quarter, a copy change that needs legal review, a config tweak that touches production), in which case points are doing their job and there's nothing to fix.
The signal to watch isn't "no 1s ever." It's 1s making up most of the backlog. One or two per sprint is fine. Every other story a 1 means the calibration question hasn't been asked in too long.
## Story points and the retrospective
Estimation is one of the most common things a team inspects in its [sprint retrospective](/guides/scrum-masters-retrospective-guide/what-is-a-sprint-retrospective/). When items are routinely under- or over-estimated, when velocity swings wildly, or when "done" work keeps reopening, the retrospective is where the team recalibrates its shared sense of size and tightens how it slices work. Estimation accuracy improves through that feedback loop, not by trying harder up front.
## Frequently asked questions
### What are story points in agile?
Story points are a unit of relative estimation: one number that captures how big a piece of work is (its effort, complexity and uncertainty together) compared with a reference story the team has already delivered. They are deliberately not a measure of time. The team sizes each item against the others rather than against the clock.
### Why use story points instead of hours?
People are poor at estimating absolute time but good at judging whether one thing is bigger than another, and story points lean on that strength. They also avoid the trap of treating an estimate as a commitment, account for the fact that the same task takes different people different amounts of time, and fold in complexity and risk, not just duration. Over a few sprints, a team's velocity in points becomes a more reliable forecast than summing hour estimates.
### How do you estimate story points?
Most teams use planning poker. Someone explains a backlog item, the team discusses it, and everyone privately picks a value from a shared scale, usually a Fibonacci-like sequence (1, 2, 3, 5, 8, 13). Everyone reveals at once; where estimates differ widely, the high and low voters explain their thinking and the team re-votes until it converges. The discussion that surfaces hidden complexity is often more valuable than the number itself.
### Should bugs have story points?
Yes, when the bug has a known cause and a clear fix: it is a story like any other, and pointing it keeps velocity honest about where capacity goes. The exception is the exploratory bug you cannot yet scope; put that on a time-boxed investigation track and size the real fix once you know the cause.
### Do story points include testing?
Yes. Points size everything between a story entering the sprint and it being shippable, which includes the testing and QA the team does as part of its definition of done. Point dev-only work and the sprint overruns every time, because QA is the bottleneck no one accounted for.
### Why should you avoid 1-point stories?
A few are fine. But if most of the backlog is 1s, the team's reference story has drifted and the scale has collapsed, so everything reads as tiny-or-bigger. Recalibrate against a recent reference story rather than shrinking the scale.
### Can you compare story points between teams?
No. A story point is calibrated to one team's own sense of relative size, so one team's 5 is not another team's 5. Comparing velocity or point totals across teams is meaningless and, used as a target, actively harmful: it pushes teams to inflate estimates. Story points are a planning tool for a single team's own forecasting, not a productivity metric for comparison.
## Related reading
- [Why story points use the Fibonacci sequence](/guides/agile-estimation-guide/why-fibonacci/): why the gaps widen as the numbers grow.
- [Story points vs hours](/guides/agile-estimation-guide/story-points-vs-hours/): the conversion trap, and what to do when someone needs a date.
- [Velocity](/guides/agile-estimation-guide/velocity/): turning points into a forecast without breaking them.
- [Agile estimation techniques](/guides/agile-estimation-guide/estimation-techniques/): which method to use when, and how each one fails.
- [Sprint retrospective](/guides/scrum-masters-retrospective-guide/what-is-a-sprint-retrospective/): where teams recalibrate estimates that keep missing.
- [Agile estimation guide](/guides/agile-estimation-guide/): the full cluster, from planning poker to splitting stories.
- [Free planning poker for agile teams](/free-planning-poker-for-agile-teams/): size your backlog together in real time.
---
# What is a sprint retrospective? Definition, stages & examples
URL: https://www.teamretro.com/guides/scrum-masters-retrospective-guide/what-is-a-sprint-retrospective/
A sprint retrospective is the recurring Scrum meeting, held at the end of every sprint, where the team reflects on how it worked and agrees concrete improvements for the next sprint. It is the team's main opportunity to inspect and adapt the way it works, and it is the last of the four Scrum ceremonies in each sprint.
Most teams can run a sprint retrospective. Far fewer run one that changes the next sprint, and that is the only test that really matters. If your retros have started to feel like a meeting nobody fights for, you are not alone. The format goes stale, the same two people talk, and action items get logged then quietly forgotten. The mechanics usually are not the problem. Follow-through is — and [our data on how often retro actions actually get done](/guides/follow-through-index/) shows what separates the teams who manage it from the teams who don't.
This chapter covers what a sprint retrospective is, how it differs from the sprint review, the five stages that give the meeting its shape, and the part most guides skip: how to make the actions actually land. The "retro," as it is commonly known, is also called a scrum retrospective or an agile retrospective. Whatever you call it, the goal is the same: improve how the team works going forward, based on what it learned from the sprint just gone. For the broader picture beyond Scrum, see [running effective retrospectives](/guides/running-effective-retrospectives/), which covers the practice for any team that finishes work in cycles.
Done well, the retrospective is the highest-leverage hour in your sprint cycle. The team shares what went well and what did not, looks for common themes, votes on what matters most, and agrees a short set of actions to carry forward. Those actions are what let the team continuously inspect and adapt, and improve both the quality and the pace of its work.
## Sprint retrospective vs sprint review
These two ceremonies get conflated constantly, and that mix-up is the single most common reason a retrospective drifts into a status update.
Per the [Scrum Guide](https://scrumguides.org), the sprint review inspects the *product*: what got built, whether it meets the goal, and what stakeholders think of it. The sprint retrospective inspects the *process*: how the team collaborated, what tools helped or slowed it down, and what it should try differently. One looks outward at the output. The other looks inward at the way the work got done.
Keep that line clear. The moment a retrospective becomes a rundown of tickets closed, you have lost the meeting that is meant to be about the team, not the backlog. For a full side-by-side, see [sprint review vs sprint retrospective](/guides/scrum-masters-retrospective-guide/sprint-review-vs-retrospective/).
## What questions does a sprint retrospective ask?
The key areas for the team to explore are:
1. What went well?
2. What did not go well?
3. What ideas do we have going forward?
4. How do we put those actions into practice?
5. Who should we acknowledge, and what do we need?
The exact question set can come from a theme in a one-on-one, from team feedback, or from a data source such as your sprint metrics. It helps to vary the questions every few sprints so they stay relevant and current, and to keep meeting fatigue at bay.
## Who joins the sprint retrospective?
The sprint retrospective is a Scrum Team meeting. Depending on the team, it can involve some or all of the following:
- The Scrum Master, who usually facilitates
- The whole development or Scrum Team
- The Product Owner
- An agile coach
- An observer
Stakeholders are generally left out so the team can talk openly about how it works, rather than performing for an audience.
## How long should a sprint retrospective run?
This is usually based on the length of your sprint cycle. As a rough guide:
- **Two-week sprint:** about 90 minutes
- **One-month sprint:** about 3 hours
- **End of a longer iteration:** up to a day
The shorter the sprint, the shorter the retro. What matters is that it is long enough to reach concrete, agreed actions, and short enough that the energy holds. Tight [timeboxing keeps a retrospective moving](/blog/timeboxing-for-scrum-teams-and-successful-retrospectives/) and stops one topic eating the whole hour.
## The five stages of an effective retrospective
The structure that holds up, sprint after sprint, comes from Esther Derby and Diana Larsen's book *Agile Retrospectives: Making Good Teams Great*. Their five-stage model gives each part of the meeting a specific job, which is exactly what keeps a retro from turning into an unstructured gripe session. The Scrum Master guides the team through all five.
1. **Set the stage.** Get people oriented and willing to speak. A quick check-in question does more work here than people expect, and it is also where you [choose the retrospective template](/guides/scrum-masters-retrospective-guide/retrospective-templates/) that frames the session.
2. **Gather data.** Collect what actually happened, not opinions about it yet. A timeline review, [sprint metrics](/guides/agile-metrics/scrum-metrics/), or a simple round of "what did you notice" all work. This is where the Scrum Master steps fully into the facilitator role.
3. **Generate insights.** Look for patterns and connections across the data. Why did the same blocker show up three sprints running? Group similar ideas, vote on what matters most, and discuss the top-ranked items in depth.
4. **Decide what to do.** Turn insight into a short list of specific, ownable changes. Not ten. Two or three. This is the stage that separates a retrospective from a chat.
5. **Close the retrospective.** Confirm what was agreed, make sure every action has an owner, thank the team, and end on time.
Skip "set the stage" and a quiet team stays quiet. Skip "decide what to do" and you get a feelings dump with no owner attached. Each stage covers for a specific failure mode, which is why cutting corners here shows up in your outcomes later, not in the room.
Every stage maps to a ready-to-run [retrospective template in TeamRetro](/retrospective-templates/), so the structure, timer, and voting are already set up before anyone joins.
## Make your action items actually stick
Here is the part most guides skip, and it is the one that decides whether your retrospective was worth the hour: what happens to the actions after everyone logs off. Retros rarely fail for lack of ideas. They fail because the ideas never turn into a change anyone can point to.
The fix is almost boringly specific:
- **One owner per action.** Not "the team." A name.
- **One sprint.** If it cannot happen before the next retro, it is too big. Break it down.
- **Reviewed first, next retro.** Before you gather any new data, check the last set of commitments. Did they happen? If not, why not?
That third point is the one teams drop first, and it is the one that makes the other two mean anything. An action item that is never revisited is just a sticky note with extra steps. For more on this, see [what percentage of action items actually get done](/guides/follow-through-index/), and [why retrospectives fail](/guides/scrum-masters-retrospective-guide/why-retrospectives-fail/) for the deeper pattern behind it.
## Getting a quiet team to talk
Every team has a version of the same problem: two people talk, the rest nod. It is rarely disengagement. More often, trust has not been earned yet, especially on newer or distributed teams. A few things move the needle: set the norm that retros improve the system rather than score points on individuals, let people enter ideas anonymously so the unpopular thought still gets said, and rotate facilitation so the room is not always performing for the same person.
None of this is complicated. It just has to be deliberate, because a quiet retro does not announce itself as a trust problem. It just looks like a short meeting. For the full playbook, see [how to build a psychologically safe retrospective](/guides/scrum-masters-retrospective-guide/how-to-build-a-psychologically-safe-space/).
## Keep retros from going stale
Even a well-run retrospective goes flat if it looks identical every sprint. The five stages do not change, but the format wrapped around them should, every few sprints, on purpose. The signs are easy to spot: people answer on autopilot, the same sticky notes show up in different words, or someone sighs when the calendar invite pops up. That does not mean retros have stopped working. It means this particular shape of retro has worn out its welcome.
Rotating through a small handful of formats keeps the structure fresh without losing the discipline behind it. Our posts on [avoiding retrospective anti-patterns](/blog/avoid-these-retrospective-anti-patterns/) and [overcoming recency bias](/blog/tips-to-overcome-recency-bias-in-your-retrospectives/) go deeper on keeping retros from calcifying into ritual.
## Run your sprint retrospective in TeamRetro
A sprint retrospective only earns its place on the calendar if it changes what happens next sprint. That means keeping the review and the retro distinct, giving each of the five stages room to do its job, making it safe for quieter voices to speak up, and treating action items as commitments rather than notes.
The follow-through is the hard part, and a better meeting format alone does not fix it. [Run your next retrospective in TeamRetro](/retrospectives/features/) and the structure, timer, and action tracking are built in, with last sprint's actions carried forward automatically, so chasing commitments is no longer a manual job. Browse the [retrospective template library](/retrospective-templates/) to pick a starting point.
## Frequently asked questions
### What is a sprint retrospective?
A sprint retrospective is a recurring Scrum meeting held at the end of every sprint where the team reflects on how it worked and agrees on concrete improvements for the next sprint. It is the team's main opportunity to inspect and adapt the way it works, and it is the last of the four Scrum ceremonies in each sprint.
### Who attends a sprint retrospective?
The sprint retrospective is a Scrum Team meeting, so it involves the Developers, the Product Owner, and the Scrum Master. The Scrum Master usually facilitates. Stakeholders are generally not included, so the team can speak openly about how it works; an agile coach or observer may occasionally attend to support the team.
### How long should a sprint retrospective be?
Timebox the retrospective to the length of the sprint. A common guide is about 90 minutes for a two-week sprint and up to about three hours for a one-month sprint. The shorter the sprint, the shorter the retrospective, and what matters is that it is long enough to reach concrete, agreed actions.
### What are the five stages of a sprint retrospective?
Esther Derby and Diana Larsen describe five stages: set the stage, gather data, generate insights, decide what to do, and close the retrospective. The Scrum Master guides the team through each stage so reflection turns into a short, owned list of improvements for the next sprint.
### What is the difference between a sprint retrospective and a sprint review?
The sprint review inspects the product, so the team shows completed work to stakeholders and gathers feedback. The sprint retrospective inspects the process, so the team reflects on how it worked and agrees improvements. The review faces outward to stakeholders; the retrospective faces inward to the team. See our chapter on [sprint review vs retrospective](/guides/scrum-masters-retrospective-guide/sprint-review-vs-retrospective/) for a full comparison.
---
# What is a standup meeting? Purpose, history and the 15-minute rule
URL: https://www.teamretro.com/guides/daily-standup-guide/what-is-a-standup-meeting/
A standup meeting is a short, daily synchronization, usually fifteen minutes and usually held standing, where a team shares progress, surfaces blockers, and re-plans the next day together. It is a meeting the team runs *for itself*: a coordination checkpoint, not a status report to a manager. That one distinction decides whether the fifteen minutes are worth it.
Most teams run a standup. Far fewer run one worth the time, and the difference is almost never the format. It's whether the meeting coordinates the team or just audits it.
## Why it's called a standup
The name is the constraint. You stand because standing gets uncomfortable, and the discomfort does a job: it caps the meeting before it sprawls into design debate. Take away the chairs and you take away the incentive to ramble.
The format predates Scrum. It comes from [Extreme Programming](https://en.wikipedia.org/wiki/Stand-up_meeting) in the late 1990s, where the daily standup was one of the original team practices, and it was later folded into Scrum as the *Daily Scrum*. If you want the terminology untangled (daily scrum, daily standup, daily huddle), see [daily scrum vs daily standup](/guides/daily-standup-guide/daily-scrum-vs-daily-standup/). For this chapter, treat them as the same event.
## What a daily standup is for
Strip it back and a standup does three things:
- **Builds a shared picture of progress** toward the sprint goal: not a task-by-task audit, but enough for everyone to know where the work stands.
- **Surfaces blockers early**, while they still cost an hour instead of a day. A blocker named on Tuesday morning is a blocker someone can clear by Tuesday afternoon, and one that isn't cleared comes back the next morning in a [daily standup tool](/standups/) that carries open blockers forward.
- **Lets the team re-plan** the next day around each other: who pairs with whom, what gets picked up, what waits.
None of that is reporting. The failure mode is a room of people taking turns narrating yesterday to a manager while everyone else waits for their turn and tunes out. That is a status meeting wearing a standup's clothes, and teams can feel the difference. It's the version people quietly start skipping.
## The fifteen-minute rule
Fifteen minutes is the ceiling, not the target. For a team of five or six, a good standup is often done in eight.
The timebox is a container, not a countdown. Anything that needs longer than the box leaves the box. It goes to the parking lot, not the whole team's fifteen minutes.
The rule that makes the timebox real is simple: **you may raise a problem in the standup, but you may not solve it there.** The second two people start debugging, everyone else is paying rent on a conversation they aren't in. Note it, name who needs to follow up, and take it offline the moment the standup ends: the "parking lot." A fifteen-minute meeting that spawns three five-minute follow-ups with the right two people is working exactly as intended.
**Pro tip:** hold it at the same time and place every working day. The predictability is what lets people build their morning around it instead of context-switching for it. A standup nobody has to be reminded about is one nobody resents.
## Who should be there
The people doing the work, and few others. A delivery team of four to nine is the sweet spot; past that, the round-robin alone eats the timebox and you should split the team or the standup.
Managers are the recurring tension. There is nothing wrong with a manager or product owner attending, but they attend to coordinate their *own* work, not to receive a report. The instant the meeting is performed *at* someone, people start describing effort instead of naming problems, and the honest material ("I'm stuck, I've been stuck since yesterday, I don't know who to ask") is exactly what stops getting said. If you're wondering whether your standup has tipped into surveillance, that question has its own chapter: [why your standup is broken](/guides/daily-standup-guide/standup-anti-patterns/).
## Where the standup fits
The daily standup is one of a handful of recurring agile meetings: planning at the start of the sprint, the standup every day, a review and a retrospective at the end. It's the only one that happens daily, which makes it the heartbeat of the sprint and also the one most easily hollowed out by habit. For how the whole set fits together, see the [agile ceremonies guide](/guides/agile-ceremonies-guide/); for the sprint's opening move, see [sprint planning](/guides/sprint-planning-guide/).
Once you're clear on what a standup is *for*, the rest of [this guide](/guides/daily-standup-guide/) is the practical how, starting with [what to actually say](/guides/daily-standup-guide/daily-standup-questions/) and [how to facilitate it](/guides/daily-standup-guide/how-to-run-a-daily-standup/) so it stays fifteen minutes.
## Frequently asked questions
### What is the purpose of a daily standup?
To coordinate, not to report. A daily standup gives the team a shared picture of progress toward the sprint goal, surfaces blockers while they are still cheap to fix, and lets people re-plan the next day around each other. The moment it becomes a status update read out to a manager, it has stopped doing its job.
### How long should a daily standup be?
Fifteen minutes, timeboxed, and most teams can do it in less. If it regularly runs longer, the team is problem-solving in the meeting instead of after it. End on time even mid-sentence. The overrun is the signal, and protecting the timebox is what keeps people showing up.
### Why is it called a standup?
Because you hold it standing up. The physical discomfort is deliberate: standing makes a long meeting unpleasant to sustain, so it caps the length without anyone having to police it. The name predates Scrum (it comes from Extreme Programming), and the constraint is the point of the format.
### Who should attend a daily standup?
The people doing the work. Keep it to the delivery team: the developers, testers, and designers actually moving items this sprint. A product owner or Scrum Master can attend, but as participants coordinating their own work, not as an audience being reported to. Once managers turn up to listen, the honest material dries up.
---
# What is a user story?
URL: https://www.teamretro.com/guides/agile-estimation-guide/what-is-a-user-story/
A user story is a short, plain-language description of a change, told from the perspective of the person who benefits from it: *"As a returning customer, I want to sign in with my email, so that I can see my order history."* It is deliberately not a specification. The card holds a promise to have a conversation, and the detail arrives when the team refines the story, writes its [acceptance criteria](/guides/agile-estimation-guide/acceptance-criteria/), and sizes it.
Everything else in this guide operates on stories. They are what [planning poker](/guides/agile-estimation-guide/what-is-planning-poker/) sizes, what [story points](/guides/agile-estimation-guide/what-are-story-points/) attach to, and what gets [split](/guides/agile-estimation-guide/splitting-user-stories/) when the estimate won't converge. A team that writes bad stories will estimate badly no matter how well it runs the session, because the inputs are where the trouble starts.
## The format: role, goal, benefit
The classic shape dates to Connextra, a London XP team, around 2001:
> As a **[role]**, I want **[goal]**, so that **[benefit]**.
Three slots, three jobs. Fill all three honestly and the card earns its place in the backlog; drop the benefit and it's just a task in disguise.
Three slots, and each one is doing a job.
- **The role** names who gets the value. "As a user" is the format's most common failure: a story that could be about anyone is a story nobody actually checked with. Name the specific person: the returning customer, the integration developer.
- **The goal** is the capability in the user's terms, describing what the person does rather than how the system is built. "I want to reset my password" is a goal. "I want a password-reset microservice" is a design decision wearing the format.
- **The benefit** is the clause teams drop first, and it is the one that earns the card its place in the backlog. The "so that" is the story's argument for being scheduled. If nobody can finish it, the work has no case, and writing the clause down is how you find that out before the sprint starts instead of after.
**Watch for the circular benefit.** "As a user, I want to log in, so that I can log in" passes the format check and says nothing. If deleting the "so that" clause loses no information, the benefit hasn't been found yet. Keep asking why until it names something the person outside the building would recognize as valuable.
## Card, conversation, confirmation
Ron Jeffries condensed how stories work into three Cs, and the ordering matters.
The card is deliberately too small to hold the requirement, which is exactly what forces the conversation, and then the confirmation that says whether the work is done.
**The card** is a token: a sentence or two, small on purpose. Its size is a feature: it physically cannot hold a full requirement, which forces the next C to happen.
**The conversation** is where the requirement actually lives. The team and the product owner talk the story through in [backlog refinement](/guides/agile-ceremonies-guide/backlog-refinement/): the edge cases, and what's explicitly out of scope. Teams that skip this and treat the card as the requirement get the worst of both worlds: a document too thin to build from, and no conversation because "it's already written down."
**The confirmation** is the acceptance criteria: the pass/fail conditions that say whether the finished work delivers what the conversation agreed. The [user story template chapter](/guides/agile-estimation-guide/user-story-template/) shows the two formats that work, and the [acceptance criteria chapter](/guides/agile-estimation-guide/acceptance-criteria/) covers writing them in depth.
## The INVEST checklist
Bill Wake's 2003 checklist is still the fastest way to test whether a story is ready to work on. A good story is:
- **Independent**: schedulable on its own, without dragging three other stories into the sprint with it.
- **Negotiable**: the card invites a conversation; scope can still move. A story with every detail fixed is a requirement wearing a story's clothes.
- **Valuable**: the "so that" clause holds up under one honest "why?".
- **Estimable**: the team can put a number on it. A story nobody can size is carrying an unknown; run a [spike](/guides/agile-estimation-guide/splitting-user-stories/) to find it.
- **Small**: fits in a sprint with room to spare. If it doesn't, [split it](/guides/agile-estimation-guide/splitting-user-stories/).
- **Testable**: you can write acceptance criteria that pass or fail. "The page feels faster" fails this; "results load in under a second" passes.
Estimable and small are where stories meet the rest of this guide. A wide vote spread in planning poker is usually an INVEST failure surfacing late: the story was negotiable in ways nobody negotiated, or too big for anyone to see all of it.
## What a user story is not
**Not a task.** A story delivers something a user can see; a task is a step the team takes to get there. "Sign in with email" is a story. "Set up the session store" is one of its tasks. The [epic vs story vs task chapter](/guides/agile-estimation-guide/epic-vs-story-vs-task/) covers the hierarchy, and why points belong at the story tier only.
**Not a requirement document.** A requirement aims to be complete before work starts. A story aims to be *sufficient to start the conversation* and no more. Judging stories by requirement standards ("it's too vague!") misses the design: the vagueness is a reserved seat for the team's judgment.
**Not a promise of implementation.** The story fixes the outcome; the team owns the how. When a story arrives with the solution pre-decided, the negotiable part of INVEST is already gone.
## When user stories are the wrong tool
The format has limits, and pretending otherwise costs credibility with the people who have to write the awkward ones. Some work has no user in the sentence:
- **Deep platform work.** "As a developer, I want to upgrade the framework, so that the framework is upgraded" says nothing the ticket title didn't. Write it as plain technical work with a named outcome: what breaks or slows down if this doesn't happen, and what gets easier when it does.
- **Bugs with a known cause.** A defect report (expected behavior, actual behavior, steps to reproduce) is a better native shape than a retrofitted story. The [story points chapter](/guides/agile-estimation-guide/what-are-story-points/) covers when bugs get pointed.
- **Research spikes.** A spike is a question plus a time-box, and its output is knowledge. Forcing it into role-goal-benefit obscures the one thing that matters: what the team needs to learn.
- **Compliance work.** You cannot negotiate scope with a regulator. The requirement is the requirement; write it down as one.
What transfers to all of these is the discipline, not the sentence shape: a stated reason the work matters, and a testable definition of finished. Keep those and the format has done its job even where it doesn't apply.
## Where stories meet estimation
A story is the unit of estimation. Once it's written, the path runs through this guide: the team discusses it, sizes it in [story points](/guides/agile-estimation-guide/what-are-story-points/) with [planning poker](/guides/agile-estimation-guide/how-to-run-planning-poker/), checks it against the [definition of ready](/guides/agile-estimation-guide/definition-of-ready/), and splits it if the vote won't converge. A well-formed story makes every one of those steps faster, which is the practical reason to care about the format at all.
To see the format applied, the [user story examples chapter](/guides/agile-estimation-guide/user-story-examples/) walks through sixteen annotated stories, good and bad. To write your own, start from the [template](/guides/agile-estimation-guide/user-story-template/).
## Frequently asked questions
### What is a user story?
A user story is a short, plain-language description of a change, told from the perspective of the person who benefits: "As a returning customer, I want to sign in with my email, so that I can see my order history." It is deliberately not a specification. The card is a placeholder for a conversation, and the detail arrives when the team refines and sizes the work.
### What is the user story format?
The classic format is role-goal-benefit: "As a [role], I want [goal], so that [benefit]." The role names who gets the value, the goal names the capability in the user's terms, and the benefit is the argument for scheduling the work at all. If nobody can finish the "so that" clause, the story has no case for being in the backlog.
### What are the three Cs of user stories?
Card, conversation, confirmation. The card is a reminder, deliberately too small to hold the requirement. The conversation is where the requirement actually lives, in refinement with the team. The confirmation is the acceptance criteria that say, pass or fail, whether the finished work delivers what was discussed.
### What does INVEST stand for?
Independent, negotiable, valuable, estimable, small, testable. It is Bill Wake's checklist for whether a story is ready to work on. The last three carry the most weight in practice: a story the team cannot estimate, that will not fit a sprint, or that no test can confirm is a story that is not ready yet.
### When should you not use user stories?
When the format adds ceremony instead of clarity. Deep platform work, bug fixes with a known cause, compliance requirements, and research spikes all have better native shapes. Keep the benefit clause and the acceptance criteria; skip the "as a developer, I want" costume when there is no user in the sentence.
## Related reading
- [Agile estimation: the complete guide](/guides/agile-estimation-guide/). The hub for everything here.
- [User story examples](/guides/agile-estimation-guide/user-story-examples/): sixteen annotated stories, including the ones that fail and why.
- [User story template and acceptance criteria](/guides/agile-estimation-guide/user-story-template/): the template, its variants, and a worked example through to estimation.
- [Epic vs story vs task](/guides/agile-estimation-guide/epic-vs-story-vs-task/): where the story sits in the hierarchy, and which tier gets pointed.
- [Splitting user stories](/guides/agile-estimation-guide/splitting-user-stories/): what to do when a story fails the small test.
---
# What is planning poker?
URL: https://www.teamretro.com/guides/agile-estimation-guide/what-is-planning-poker/
Planning poker is a consensus-based estimation technique: the team sizes a piece of work by voting privately, revealing every card at once, and discussing the disagreement the reveal exposes. When the cards converge, that number is your estimate.
It sounds almost too simple to matter, and the simplicity is the point. Because the vote is private and everyone reveals at the same moment, nobody anchors on the first number said aloud, and any real disagreement about the size of the work actually surfaces, instead of being quietly smoothed into the loudest person's guess.
## How a round works
A round has four beats. The facilitator reads the item and the team asks clarifying questions. Everyone plays a card at the same time, face-down in the room or hidden automatically in a tool. The cards flip together. If they disagree by more than a step, the highest and lowest cards explain their reasoning, and the team re-votes. Most items settle inside two votes; the full [facilitator's loop](/guides/agile-estimation-guide/how-to-run-planning-poker/) is its own chapter.
**Rule of thumb:** when two cards land more than one step apart, that gap isn't a number to average. It's a conversation you haven't had yet. Averaging a 3 and a 13 to 8 doesn't resolve the disagreement; it hides it.
## Where planning poker came from
James Grenning wrote it up in 2002, looking for something quicker than Wideband Delphi, a structured estimation process descended from 1940s RAND work and about as ceremonial as that sounds. Mike Cohn's 2005 book *Agile Estimating and Planning* put it in front of the wider Scrum world, and it has been standard kit ever since. The name is literal: estimators play numbered cards like a hand, face-down, and turn them over together. Teams write it a few ways, [poker planning](/free-planning-poker-for-agile-teams/), scrum poker, [pointing poker](/pointing-poker/), and all of them mean this same round of cards.
## Why the cards use the Fibonacci sequence
Most decks run a Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) and the gaps widen on purpose. The bigger the work, the less anyone actually knows about it, so the options spread apart to match. You end up choosing between an 8 and a 13 instead of arguing over whether something is a 9 or a 10. That argument was never going to be accurate; the scale simply stops you having it. There's a [whole chapter on why Fibonacci](/guides/agile-estimation-guide/why-fibonacci/) if you want the reasoning in full.
## What you're estimating: effort, not time
Planning poker sizes *relative effort*, not hours. A [story point](/guides/agile-estimation-guide/what-are-story-points/) bundles three things (complexity, uncertainty, and sheer amount of work) into one number. A 5 is roughly five times the effort of a 1, even when nobody in the room can tell you how many hours either one takes.
That's the point, not a limitation. People are unreliable at predicting clock time and surprisingly good at saying *this is bigger than that*. Planning poker leans on the judgment teams are actually good at and ignores the one they're not. (When someone asks you to convert the points back into hours, read [story points vs hours](/guides/agile-estimation-guide/story-points-vs-hours/) before you agree to it.)
## Why teams use it
A few things fall out of the private-vote mechanic that are hard to get any other way:
- **It surfaces disagreement instead of hiding it.** When one engineer plays a 2 and another plays a 13, you've found a gap in shared understanding. An average would have buried it at 8 and shipped the confusion into the sprint.
- **It prices the whole cost of shipping.** Designers, QA, and engineers all vote, so the estimate reflects testing, edge cases, and design work, not just the coding.
- **It flattens seniority at the vote.** A junior's hidden card counts exactly as much as the lead's. Seniority earns its keep in the discussion after the reveal, which is where it belongs.
- **It's quick.** A focused team sizes ten to fifteen refined stories in half an hour, and the numbers tend to be more honest than the ones people give under social pressure.
## When planning poker is the wrong tool
Planning poker is the right call when you need shared understanding, not just a number, for a focused backlog of stories the team is about to commit to. It's the wrong call when you have hundreds of items and need rough sizing fast; reach for [bucket sizing, affinity mapping, or T-shirts](/guides/agile-estimation-guide/estimation-techniques/) instead. And if your stories are already small and uniformly understood, you may not need to estimate them at all. Plenty of mature teams drift toward simply counting stories once their refinement is sharp. Planning poker is a tool for a specific job, not a ritual to perform every sprint regardless.
When you're ready to run a round, [TeamRetro's free planning poker](/free-planning-poker-for-agile-teams/) keeps every vote hidden until the reveal, so the mechanic works the same for a distributed team as it does around a table. New to facilitating one? Start with [how to run a session](/guides/agile-estimation-guide/how-to-run-planning-poker/).
## Frequently asked questions
### How does planning poker work?
The team sizes one item at a time. The facilitator reads it, everyone votes privately with a numbered card, and all the cards are revealed at once. If they disagree, the highest and lowest estimators explain their reasoning and the team re-votes. When the cards land within a step of each other, that number is the estimate, usually within two rounds.
### What is the Fibonacci sequence used in planning poker?
Most decks use 1, 2, 3, 5, 8, 13, 21 and up. The gaps widen on purpose: the larger the work, the less precisely anyone can size it, so the scale offers fewer, wider choices at the top and removes the false-precision argument about whether something is a 9 or a 10.
### When should a team use planning poker?
Use it for a focused set of well-refined stories the team is about to commit to, where shared understanding matters as much as the number. For sizing a large backlog quickly, a faster technique such as bucket sizing or affinity mapping fits better. Planning poker trades speed for the conversation it forces.
### Does planning poker actually work?
It works when the stories are refined and someone protects the mechanic: private votes, a real discussion on wide spreads, and no averaging. It fails quietly when teams estimate vague stories or convert the points straight back into hours. The technique is robust, but it is not automatic; see [planning poker mistakes](/guides/agile-estimation-guide/planning-poker-mistakes/) for the ways it goes wrong.
---
# Team dynamics: definition, examples, and what makes them work
URL: https://www.teamretro.com/guides/team-dynamics/what-is-team-dynamics/
Team dynamics are the psychological and behavioral forces that shape how a group of interdependent, mutually accountable people work together and perform. Those forces include roles, norms, trust, communication patterns, leadership, and team size. Get them right and capable individuals become a team; get them wrong and the same people underdeliver.
Most writing on this topic dissolves into slogans. There is no "i" in team. Communication is key. Hire for culture fit. None of it survives a real team under a real deadline. The useful version starts with where the idea came from and what the evidence supports, then gets specific about what to change on Monday.
One disambiguation first. In clinical training, "effective team dynamics" refers to CPR and ACLS resuscitation teamwork — closed-loop orders, the resuscitation triangle, a clear code leader. This guide is about workplace and remote teams, not the code cart.
## Where the idea comes from: group dynamics and Kurt Lewin
The phrase "team dynamics" is a workplace narrowing of a much older idea. The psychologist [Kurt Lewin](https://www.britannica.com/biography/Kurt-Lewin) coined "group dynamics" in the 1940s and founded MIT's Research Center for Group Dynamics in 1945 to study the positive and negative forces that operate within and between groups. His central claim was that behavior is a product of the person and their environment together, so if you want to change how people act, you change the field around them instead of lecturing the individuals.
Group dynamics is the parent field. It covers any set of people who influence one another, from a jury to a committee to a group of friends. Team dynamics is that field applied to task teams: a group with a shared goal and shared accountability. We cover the broader field, its forces, and its uglier failure modes in the sibling chapter on [group dynamics](/guides/team-dynamics/group-dynamics/). This chapter stays on workplace teams.
## A working team is not a working group
Before you diagnose your team's dynamics, check that you have a team. In their 1993 *Harvard Business Review* piece [The Discipline of Teams](https://hbr.org/1993/03/the-discipline-of-teams-2), Jon Katzenbach and Douglas Smith drew a hard line between a working group and a real team. A working group is the sum of individual bests: people share information and make decisions so each person performs better in their own lane. A team produces joint work-products, and in their words is "a small number of people with complementary skills who are committed to a common purpose, set of performance goals, and approach for which they hold themselves mutually accountable."
That distinction matters because a lot of "team dynamics" problems are working-group problems wearing a disguise. Where there is no shared work-product and no mutual accountability, no amount of trust-building will make the group cohere, because there is nothing to cohere around. Katzenbach and Smith mapped this as a performance curve that runs from working group to pseudo-team to potential team to real team to high-performing team, with the steepest gain sitting between potential and real. Dynamics also shift as a team matures, and the chapter on the [stages of team development](/guides/team-dynamics/stages-of-team-development/) walks that arc from forming to performing.
A quick test tells you which one you have. If everyone went on leave and their work paused in its own lane, you have a working group and probably do not need to fuss over its dynamics. If the work would stall because the pieces only add up when people build on each other, you have a team, and how those people interact is worth real attention.
## What shapes team dynamics: five forces that move the needle
So what do effective team dynamics look like in practice? The most credible answer comes from Google's [Project Aristotle](https://rework.withgoogle.com/intl/en/guides/understand-team-effectiveness), which studied a large sample of its own teams to work out why some outperformed others with similar talent on paper. The headline finding was blunt: "what really mattered was less about who is on the team, and more about how the team worked together." Raw ability mattered less than five conditions, in rough rank order.
1. **Psychological safety.** Can people take an interpersonal risk (admit a mistake, ask an obvious question, push back on the lead) without fear of looking incompetent or getting punished for it? This was Aristotle's top predictor by a wide margin. In practice it looks like an engineer saying "I don't follow this spec" in standup and getting a straight answer rather than a sigh. The term is Amy Edmondson's, from her [1999 study](https://journals.sagepub.com/doi/10.2307/2666999) defining it as "a shared belief held by members of a team that the team is safe for interpersonal risk taking." Her data came from 51 teams in a single manufacturing firm, so read it as a strong foundation, not a universal law.
2. **Dependability.** Members reliably do what they said they would, to a decent standard, on time. It sounds mundane, and it is the whole difference between a plan and a wish. When the design lands on the day it was promised, testing does not get crushed into a weekend.
3. **Structure and clarity.** People know the goals, know who owns which decision, and know what "done" means. A one-line decision rule or a simple ownership map heads off the classic failure where two people quietly assume they own the same thing and neither ships it.
4. **Meaning.** The work matters to the people doing it, for whatever reason is personal to them: the craft, the customer, the paycheck, the teammates they don't want to let down.
5. **Impact.** People can see that their work changes something. A team that ships into a void loses steam; a team that watches a real number move keeps going.
Those five are the closest thing we have to a validated picture of effective team dynamics, and the useful part is that each one is a behavior you can watch for rather than a personality you have to hire. One caution: Google never published clean public effect sizes for Aristotle, so treat the ranking as strong signal, not a formula you can optimize to three decimal places.
The through-line is what Julia Rozovsky, who led the research, put plainly: "Who is on a team matters less than how the team members interact, structure their work, and view their contributions." That is the whole reason dynamics are worth managing. You rarely get to swap out your people, but you can almost always change the way they work together.
Two older frameworks give you extra vocabulary for the same territory. Patrick Lencioni's [Five Dysfunctions of a Team](/guides/team-dynamics/five-dysfunctions-of-a-team/) stacks the failure modes as a pyramid: absence of trust feeds fear of conflict, which feeds lack of commitment, then avoidance of accountability, then inattention to results. Read from the bottom up it is a decent order-of-operations for what to fix first. Meredith [Belbin's nine team roles](https://www.belbin.com/about/belbin-team-roles) (the Plant, the Completer-Finisher, and seven others) give a team shared language for the jobs a balanced group needs covered. Use both as lenses, not law. Belbin's self-perception inventory has mixed psychometric support, and no role chart survives a reorg.
Two structural forces sit underneath all of this. Size is one: as a group grows, coordination cost climbs and social loafing gets easier to hide, which is part of why durable teams tend to stay small. Distance is the other. A distributed team carries every one of these forces and then adds the friction of timezones and thin, text-only signals, so the warmth a co-located team gets almost for free has to be built on purpose.
## What breaks team dynamics
Left to run on their own, group forces drift toward two well-documented failure modes. The first is [groupthink](https://www.britannica.com/science/groupthink), named by Irving Janis in 1972 and defined as "a mode of thinking that people engage in when they are deeply involved in a cohesive in-group, when the members' strivings for unanimity override their motivation to realistically appraise alternative courses of action." Its tells are an illusion of invulnerability, quiet self-censorship by anyone with doubts, and self-appointed "mindguards" who shield the group from inconvenient information. The uncomfortable part is that the friendlier and more cohesive a team feels, the more exposed to it they are.
The second is [social loafing](https://www.simplypsychology.org/social-loafing.html), the tendency for individual effort to fall as a group grows. Max Ringelmann measured it around 1913 when he found people pulled less hard on a rope in a group than they did alone. Add members without adding clear individual ownership and total output can drop. Both of these, along with conformity pressure, get the full treatment in the [group dynamics chapter](/guides/team-dynamics/group-dynamics/). For the pillar, the takeaway is simple: harmony is not the same as health, and a team that never disagrees is usually quiet rather than safe.
## How to measure and improve team dynamics
You cannot improve what you never surface, and dynamics are easy to leave unspoken until they curdle. Three practices do most of the work.
- **Measure it with a team health check.** A structured [team health check](/health-checks/) asks everyone to rate the same dimensions anonymously, then shows where people quietly disagree. The disagreement is the signal. Run it every quarter and a vague conversation about "morale" becomes a trend line you can act on. Our [team health check guide](/guides/team-health-check/) covers choosing dimensions, the questions to ask, and how to run the session.
- **Write the norms down.** Implicit norms are still norms; the only difference is that nobody chose them. A [team charter](/guides/team-charter/) or a set of working agreements makes expectations explicit: how you make decisions, how fast you reply, how you handle disagreement. The sibling chapter on [team norms and working agreements](/guides/team-dynamics/team-norms-and-working-agreements/) has a copy-pasteable library to start from.
- **Build the safety on purpose.** Since psychological safety is the top predictor, treat it as a practice rather than a lucky personality mix. The [scrum master's guide to building a psychologically safe space](/guides/scrum-masters-retrospective-guide/how-to-build-a-psychologically-safe-space/) and the sibling chapter on [building trust and psychological safety](/guides/team-dynamics/building-trust-and-psychological-safety/) get concrete about the behaviors. Our blog also has a plain-language read on [how to tell if your team feels psychologically safe](/blog/how-to-tell-if-your-team-feels-psychologically-safe/).
Surfacing the problem is only half the job. The other half is following through on what you decide, and that is where most teams quietly leak. TeamRetro's own data across a sample of hundreds of thousands of retrospective action items found that about 73 percent get completed. That is far better than the folklore that only a third of team actions ever happen, but it still leaves nearly a quarter of good intentions evaporating between meetings. Dynamics improve when the loop closes: you surface an issue, agree an owner and a date, and check on it next time.
None of this needs a heavy program. A lot of it starts with lighter, more regular contact between people. If your team is new or freshly reshuffled, you can run a quick round of [This or That](https://games.teamretro.com/games/this-or-that/) or [Two Truths and a Lie](https://games.teamretro.com/games/two-truths-and-a-lie/) live with your team to lower the temperature before the real work begins. The value is in the recurring low-stakes contact, not the game itself.
## The honest version
Team dynamics is not a switch you flip in a workshop. It is the accumulated residue of how people treat one another under pressure, and it drifts back to old habits the moment attention moves elsewhere. No model on this page is proven the way a law of physics is proven: Tuckman's stages describe more than they predict, Aristotle came with no effect sizes, and every role inventory ships with caveats. What holds up is the direction of travel. Make it safe to speak, be clear about who does what, keep the promises you make to each other, and check honestly and often whether it is working. The rituals in this guide turn those four things into a habit instead of a hope.
## Frequently asked questions
### What are examples of effective team dynamics?
Effective team dynamics show up as concrete behaviors, not vibes. People admit mistakes and ask questions without fear (psychological safety), reliably deliver what they promised (dependability), know who owns which decision (structure and clarity), find the work meaningful, and can see the impact of what they ship. Google's Project Aristotle found these five conditions predicted a team's performance better than who was on the team.
### What is the difference between team dynamics and group dynamics?
Group dynamics is the broader field, coined by Kurt Lewin in the 1940s, that studies the forces within and between any set of people who influence one another. Team dynamics is that field applied to a task team: a small group with a shared goal and mutual accountability. Every team has group dynamics; not every group is a team.
### What are the signs of poor team dynamics?
Common signs include meetings where nobody disagrees, decisions that get quietly re-litigated afterward, work that stalls with no clear owner, and a few people carrying the load while others coast. Silence is often the loudest signal: if raising a problem feels risky, you have a psychological-safety problem, not a personality one.
### What are the five keys to effective team dynamics?
Google's Project Aristotle identified five, in rough rank order: psychological safety (by far the most important), dependability, structure and clarity, meaning, and impact. Its headline was that how a team works together matters more than who is on it. Google published no public effect sizes, so treat the five as strong signal, not a formula.
### How do you improve team dynamics?
Surface the current state with an anonymous team health check, write your norms down in a team charter so expectations are explicit, and build psychological safety deliberately. Then close the loop: agree an owner and a date for every action, and review it next time. TeamRetro's data on a sample of hundreds of thousands of retrospective action items found about 73 percent get done, so following through is where most of the gains hide.
---
# The Retrospective Prime Directive
URL: https://www.teamretro.com/guides/scrum-masters-retrospective-guide/what-is-the-retrospective-prime-directive/
The Retrospective Prime Directive is a short statement, written by Norm Kerth, that asks everyone to assume their teammates did the best job they could with what they knew at the time. It sets a blameless tone so the team can focus on improving the way they work rather than finding fault.
> "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
> — Norm Kerth, Project Retrospectives: A Handbook for Team Review
This mindset aims to create a culture and communication style at the retro. Rather than judgment, blame, and shaming, the retrospective prime directive seeks to create a collaborative way of thinking. Each person in the team shows respect, understanding, and curiosity in order to learn and grow together. The Prime Directive forms the basis of the way a retrospective itself should be run.
There are a few key notable points about this prime directive. It assumes that people are genuine and have the best interests of the team and product in mind. It encourages a safer space for people to understand that there is not just one perfect or ideal solution and that experimenting, growth, and adaptation are more important. The information a person has at any given point has informed and guided them to a decision, and the way to improve and learn is through collaboration and information sharing.
This ensures that the framing of what happens in the retrospective is not aimed at a particular person or area, but about how the team overall can improve their overall outcomes.
This is just one of the reasons we have this as the default text in the Context and Agenda of your retrospective meetings. As a new team, it's important to run through this as a starting point, or to tailor it based on your team dynamics.
This helps everyone behave and act in an agreed and productive way at your meeting.
---
# Where should the fix land?
URL: https://www.teamretro.com/guides/ai-agent-retrospectives/where-should-the-fix-land/
**A discussion paper** on routing agent-encountered friction to the right level of fix. We're interested in all continuous-improvement cycles; AI-assisted work is a new area we're thinking through via our retrospective lens. These are working positions, and we'd genuinely like to be argued with: [ai-discussion@teamretro.com](mailto:ai-discussion@teamretro.com).
## Two teams, same friction, different quarter
Two teams both start [logging the friction their AI agents hit](/guides/ai-agent-retrospectives/ai-friction-records/): the ambiguous asks, the stale docs, the flaky tools, the reruns.
The first team fixes everything at the level nearest to hand. Every recurring annoyance becomes a prompt tweak or a memory note; anything bigger becomes another paragraph in the context file. Three months later their agents run on bloated instructions nobody reads end to end, and the friction that mattered (the brief template that leaves scope undefined, the ad account whose structure fights every session) is still there, because no prompt tweak can reach it.
The second team asks one extra question per pattern: *where does this fix actually belong?* The "agents keep guessing our audience" cluster becomes a change to how work is briefed: a process fix, agreed in a team session. The stale-runbook cluster becomes a documentation fix with an owner. The one-off quirk becomes a memory note and nothing more. Three months later their instruction files are shorter than when they started, and the friction categories they fixed are trending down.
The difference is not logging discipline. Both teams logged. The difference is a routing question the first team never asked.
## The core move: friction points at an altitude
When an AI-assisted session hits friction, the root cause points at a *level* where the durable fix lives. We call it the fix's **altitude**; the available altitudes run from ephemeral to structural:
**memory → skill/prompt → environment & config → documentation → the work material itself → process/workflow → upstream product or vendor**
Naming the altitude turns a complaint into a routable fix. "The agent got the bid strategy wrong again" is a complaint. "The bid-strategy decision was never written down anywhere the agent could find it: a documentation fix, and here's the runbook it belongs in" is a work item with an address.
Getting the altitude wrong fails in two directions. **Under-targeting**, a private memory note for what's really a missing team doc, means the friction recurs for everyone who isn't you: a recurrence tax on the rest of the team. Notes already stranded that way can be recovered with a [memory harvest across the team](/blog/claude-md-for-teams/). **Over-targeting** (a new skill for a one-off, another paragraph in an already-bloated context file) is a maintenance tax on the artifact; the field has named the anti-patterns precisely: skill sprawl ([16→48 skills in 15 days](https://dev.to/shimo4228/15-days-of-skill-sprawl-in-claude-code-lessons-from-3-audits-27em): *"Adding skills is easy. … Management is the hard part."*) and context-file bloat (*"a memory file that has stopped being read"*, per this [field note](https://www.digitalapplied.com/blog/claude-code-anti-patterns-team-adoption-failure-modes-2026)). The vendors have converged on the same gradient from the other end: demote ephemeral memory, promote durable learning to version control: Windsurf/Devin (*"write it as a Rule or add it to AGENTS.md… rather than relying on auto-generated Memories"*, [docs](https://docs.devin.ai/desktop/cascade/memories)), OpenAI Codex (*"when Codex makes the same mistake twice, ask it for a retrospective and update AGENTS.md"*, [best practices](https://learn.chatgpt.com/guides/best-practices)), Copilot memory's deliberate [28-day expiry](https://github.blog/changelog/2026-03-04-copilot-memory-now-on-by-default-for-pro-and-pro-users-in-public-preview/).
Seven rungs from memory to upstream. A fix pinned too low (a private memory note for what's really a team-wide gap) recurs for everyone who isn't you; one pinned too high bloats an artifact until it stops being read.
So the field knows both failure modes. What's been missing is a routing instrument.
## A fixed vocabulary that routes
Our working proposal: label each friction finding with exactly one root cause from a fixed vocabulary of ten labels in five groups: small enough to hold in your head, cause-shaped rather than symptom-shaped, and deliberately tool- and discipline-agnostic:
- **Briefing**: `ambiguous-instruction`, `missing-context`, `incorrect-context`, `changed-requirements`
- **Documentation**: `missing-documentation`, `incorrect-documentation`
- **Work material**: `work-material-friction`
- **Tooling**: `missing-access-or-tool`, `environment-friction`
- **Agent**: `agent-error`
The group is the routing key. The moment a finding is labeled, it's half-routed:
| Group dominant | The fix usually lives at | Typical artifacts |
|---|---|---|
| **Briefing** | process (how work is briefed) or a persisted memory | brief template, kickoff checklist, memory file |
| **Documentation** | docs | README, runbook/SOP, context file, spec |
| **Work material** | the material itself | code: the refactor the friction keeps pointing at; non-code: the account, board, or template restructure |
| **Tooling** | environment/config, or upstream | settings, MCP config, access grant, vendor ticket |
| **Agent** | prompt, skill, or guardrail | skill edit, hook, eval |
One honesty note up front: the groups are *named for* their fix destinations, so "the label half-routes the fix" is true by construction, a design choice rather than an empirical discovery. The empirical claim underneath is that capture-time labels are *accurate and consistent*, which is exactly what we haven't yet measured (more below).
The table gives a fix its first address, and recurrence can move it. When friction comes back after a documentation or context-file fix, the prose probably isn't working. Move the fix to a guardrail: a hook or a CI check, which holds whether anyone reads it or not. It's the same reasoning as [choosing a capture trigger](/guides/ai-agent-retrospectives/ai-friction-records/): a convention line depends on someone remembering it, and a hook doesn't.
Note what `work-material-friction` covers, because it's where the vocabulary earns its discipline-agnostic claim. In code, it's tech debt: the module every session trips over. Outside code, it's just as real. Picture a marketing team whose agent audits a Google Ads account grown by accretion: three generations of naming conventions, paused campaigns nobody dares delete, keywords duplicated across overlapping ad groups. Every session, the agent burns its first stretch reconstructing which campaign owns what, and every recommendation carries a caveat. No prompt fix touches this; no memory note fixes it for the next person. The label is `work-material-friction`, always paired with the concrete material named (this account), and the altitude is the material itself: the restructure the friction keeps pointing at. The same pattern lives in tangled spreadsheets, CMS template messes, and support-macro libraries; a coding-agent-shaped loop has nowhere to put these.
**Why fixed rather than emergent?** Because for a team, the taxonomy is a coordination instrument, not a classification exercise. "The same friction across eight sessions is a process problem" only computes if all eight sessions labeled it the same way; distribution claims need a stable denominator; and trend lines ("is briefing friction down since we fixed the brief template?") survive only if a label means the same thing in March and July. Emergent categories, each person coding their own, are the right call solo, but across a team they drift per person, and nothing aggregates without a reconciliation step nobody owns. We keep the emergent engine running in two places: an evidence-cited note beneath every label, and a periodic vocabulary review where the accumulated notes pressure-test the labels. The vocabulary is versioned; it is designed to change under evidence, not to be defended.
## What already exists, honestly compared
We didn't invent failure taxonomies, and the existing ones are good at what they're for.
**MAST** ([arXiv 2503.13657](https://arxiv.org/abs/2503.13657)) is the reference fixed taxonomy: 14 failure modes in 3 categories, derived from 150 expert-examined traces and validated against a 1600+ corpus, with strong inter-annotator agreement (κ = 0.88). It classifies how multi-agent *systems* fail, built for research and benchmarking, closest to ours in discipline, different in object: we classify why human–agent *collaboration* friction happened.
**The error-analysis school**, Husain & Shankar's evals methodology ([evals FAQ, Jan 2026](https://hamel.dev/blog/posts/evals-faq/)), argues the opposite of a fixed list: categories *"should emerge from observed failure patterns… not predetermined query classifications,"* and open-ended reading of your own traces is *"the most important activity in evals."* We think they're right at solo scale and that the trade flips at team scale, for the aggregation reasons above. Their reading discipline is load-bearing in our proposal either way; it's what the evidence notes are.
Around these poles: the [Four-Layer taxonomy](https://cobusgreyling.substack.com/p/the-four-layer-agent-failure-taxonomy) (Greyling, May 2026) classifies which *layer* of the stack failed, attributing only ~9.9% of failures to model reasoning: most failures are harness problems (the harness is the scaffolding around the model), which is why our `agent-error` label is a residual, used only when the inputs were adequate (the harness-engineering school explicitly rejects the agent-blame default, fixing the harness rather than the agent: [Osmani, *Agent Harness Engineering*](https://addyosmani.com/blog/agent-harness-engineering/)). [TraceProbe](https://arxiv.org/abs/2607.06184) classifies error-handling *actions* in traces. [Garg's Feedback Flywheel](https://martinfowler.com/articles/reduce-friction-ai/feedback-flywheel.html) harvests four signal *types* into team artifacts, the framework ours sits inside: his context ≈ our briefing + documentation groups; his failure arm is what our taxonomy decomposes. [Factory Signals](https://factory.ai/news/factory-signals) classifies session *symptoms* into auto-filed tickets; [Braintrust Topics](https://www.braintrust.dev/articles/what-are-topics-in-braintrust-2026) is the emergent school productized, re-clustering your traces daily.
Two honest readings of that comparison. First, most of these classify symptoms, layers, or destinations; ours classifies *causes*, which is what makes the label a routing key, and it's the actual novelty claim, such as it is. Second, and more important: **MAST has measured labeling reliability and we have not.** Inter-rater reliability on our ten labels is unmeasured, and we treat that as a prerequisite, not a footnote: the experiment (independent raters blind-labeling the same real entries, agreement reported whatever it says) is underway against entries from our own live trial, with MAST's κ = 0.88 as the bar. Until it reports, this taxonomy is a working proposal with versioned labels, not a validated instrument. We'd rather tell you that than have you discover it.
We're also supportive of [every loop already running](/guides/ai-agent-retrospectives/agent-feedback-loops/): [Loop Engineering](https://addyosmani.com/blog/loop-engineering/), [Compound Engineering](https://every.to/source-code/compound-engineering-the-definitive-guide), [agent-retro](https://github.com/giannimassi/agent-retro), AGENTS.md retrospectives, vendor memory systems, automated session reports. Keep them all; nothing here replaces them.
## Why altitude is a team question
Here's the gap those existing loops share: almost all of them are solo (one developer and their agent, or one vendor and its fleet). And the field's own numbers say the expensive step isn't watching: ~90% of teams instrument agent traces, but only ~37–52% systematically evaluate them ([LangChain State of Agent Engineering, Jun 2026](https://www.langchain.com/state-of-agent-engineering)). The unclaimed layer is team-level synthesis, and that's precisely where altitude starts to matter, for two reasons.
**Aggregation reweights priorities.** One person's ten-minute annoyance is noise; nobody rationally fixes it. The same label across eight sessions and five people is one of the team's largest costs, and only the aggregate view can see it. Aggregation is also what the fixed vocabulary buys: the counts only add up if everyone used the same labels.
**The highest altitudes are team-owned.** An individual can fix their own memory, prompts, and config. But process changes, cross-tool judgment calls, budget for tooling, upstream escalations, the altitudes where the biggest recurring friction usually points, are decisions no individual can make alone. This is also why we think a human seat at synthesis persists however good models get: the fixes land in artifacts humans own and answer for: briefs, processes, budgets, team agreements. That's a claim about organizational authority, not model capability. And it's a seat in the loop, not a gate on the pipeline: agents should detect, record, cluster, and draft freely; humans add the routing judgment and carry the accountability.
Reading across people and repos also turns up lessons that contradict each other. Supersede rather than overwrite: the new lesson goes in as a dated entry that references the old one, and the old one stays readable, so nobody quietly re-derives the wrong belief later. To choose between them, check provenance first (first-hand evidence beats a lesson that has only been repeated), then recency, reading the actual timestamps. If neither settles it, flag the pair as unresolved rather than forcing a winner. Check scope too. One of our repos had a lesson saying never symlink a worktree's `node_modules`; another said you must symlink it or the build fails. Each was true in its own repo. A later shared fix, a hard-linked copy, worked in both, so the symlink lesson was superseded.
If your team already runs a continuous-improvement ceremony, this slots into it: the aggregate friction picture arrives, the team asks "where does each fix land?", and each pattern leaves with an altitude and an owner. Not a new ritual, just a [retrospective](/retrospectives/) with better inputs. ML engineers call the reading error analysis; teams call the venue a retro.
## What would change our minds
This is a discussion paper, so here is what we're genuinely unsure about:
- **Reliability.** If the inter-rater experiment reports poor agreement, the boundary rules (or the labels themselves) are wrong, and we'll revise them under the version stamp rather than defend them.
- **Size.** Ten labels is inherited, not derived. MAST runs 14; Four-Layer runs 4. Our label distribution after a quarter of real entries is the evidence that keeps or reshapes it.
- **Missing modes.** Inter-agent friction (subagent handoff loss, orchestration failures) currently files under `environment-friction`; real occurrences may demand a label of its own.
- **Non-code review scope.** We scope reviews by where fixes would land: the repo for most dev work; "account," "workspace," or "engagement" outside it. Those non-code boundaries are proposals we want tested against real teams.
- **Capture-time feasibility.** Can busy teams label causes in the moment, or must labeling happen at review? Teams who try it would settle this faster than our theorizing.
If you run any version of this loop (emergent categories, a vendor pipeline, a plain spreadsheet), we'd like to hear where the routing table breaks. Especially if you can show us a friction pattern that doesn't point at an altitude at all: [ai-discussion@teamretro.com](mailto:ai-discussion@teamretro.com).
---
**Next chapter:** [The report exists. The room doesn't.](/guides/ai-agent-retrospectives/the-report-exists/): why routing the fixes is a team decision, and what the team does when the friction report arrives. Part of the [AI agent retrospectives guide](/guides/ai-agent-retrospectives/).
---
# Why story points use the Fibonacci sequence
URL: https://www.teamretro.com/guides/agile-estimation-guide/why-fibonacci/
The gaps grow because uncertainty grows. A scale that lets you say "7" is a scale that lets you pretend.
Fibonacci (1, 2, 3, 5, 8, 13, 21) spaces the numbers further apart as they get bigger. That spacing isn't decorative. It encodes the one thing every estimate is really about: how confident you are. Telling a 2 from a 3 is a real distinction your team can argue and resolve. Telling a 21 from a 22 is theatre. The sequence widens the gaps so the scale stops offering a precision it can't deliver.
The gap between a 5 and an 8 is a real argument. The gap between a 21 and a 22 is noise, so the scale doesn't offer it.
## Why not 1 to 10?
Because a linear scale promises distinctions that don't exist. Give a team ten buckets and someone will spend ten minutes arguing 6 versus 7, a difference that evaporates the moment anyone opens the codebase. Fibonacci gives you roughly six usable buckets and forces the decision: this is a 5 or it's an 8. There's no 6 or 7 to hide in, so the conversation moves to what actually matters: what makes this bigger than the reference story.
## Why 1, 2, 3, 5, 8?
Some decks drop a number or two; the classic planning poker deck is 1, 2, 3, 5, 8, 13, 21. The exact membership matters far less than the shape. What every variant shares is the widening gap: each step is roughly the sum of the two before it, so the jumps get bigger exactly where your ability to estimate gets worse. Pick a deck and keep it; don't let the team renegotiate the scale every sprint, or you reset everyone's calibration for no gain.
## Modified Fibonacci, and powers of two
Most [planning poker](/free-planning-poker-for-agile-teams/) tools ship a *modified* Fibonacci deck (½, 1, 2, 3, 5, 8, 13, 20, 40, 100) that rounds the top end. Nobody distinguishes a 34 from a 21 at that size, so the deck rounds to 20, 40, 100 and stops pretending. Powers of two (1, 2, 4, 8, 16) work for the same reason: exponential spacing. Pick Fibonacci unless your team is already fluent in doubling. The difference is cosmetic, and switching decks mid-stream just resets everyone's calibration.
## When the scale is the wrong fix
If every story comes back an 8 or a 13, the scale isn't the problem: the stories are too big. [Split them](/guides/agile-estimation-guide/splitting-user-stories/); don't reach for a 34. And if you find yourself wanting a 6, you've started [estimating in hours with extra steps](/guides/agile-estimation-guide/story-points-vs-hours/). The missing 6 is a feature.
Use Fibonacci because uncertainty isn't linear. The numbers spread out because your confidence does the opposite.
## Frequently asked questions
### Why are story points 1, 2, 3, 5, 8?
Because the gaps mirror how uncertainty grows with size. The difference between a 2 and a 3 is real and arguable; the difference between a 21 and a 22 is noise. Fibonacci widens the gaps as the numbers grow, so the scale stops offering precision it can't deliver.
### Why use Fibonacci instead of a 1-to-10 scale?
A linear 1–10 scale invites arguments over 6 versus 7, a distinction that won't survive contact with the work. Fibonacci gives you about six usable buckets and forces a decision: it's a 5 or an 8, with nothing in between to hide in.
### What is the modified Fibonacci sequence?
A rounded version (½, 1, 2, 3, 5, 8, 13, 20, 40, 100) used by many planning poker decks. It rounds the large numbers because no team meaningfully distinguishes a 34 from a 21 up there. The rounding just admits it.
### Why does planning poker use the Fibonacci sequence?
So the cards force a choice the moment estimates get fuzzy. Because the gaps widen as the numbers grow, there's no middle value to hedge on. You commit to a 5 or an 8, and the discussion moves to why.
## Related reading
- [What are story points?](/guides/agile-estimation-guide/what-are-story-points/): the concept the scale measures, and why 1-point stories are a warning sign.
- [Story points vs hours](/guides/agile-estimation-guide/story-points-vs-hours/): the conversion trap the missing numbers protect against.
- [Agile estimation guide](/guides/agile-estimation-guide/): the full estimation cluster.
- [Free planning poker for agile teams](/free-planning-poker-for-agile-teams/): Fibonacci, modified-Fibonacci and powers-of-two decks, ready to vote.
---
# Why remote retrospectives are key in agile
URL: https://www.teamretro.com/guides/scrum-masters-retrospective-guide/why-remote-retrospectives-are-key/
Being remote means your retrospectives become even more vital as an agile ceremony. This is a time for the team to come together to share learnings, celebrate, and decide what is happening next. Any connection lost in the absence of face-to-face meetings is rebuilt through this touchpoint.
Even if you have some of the team in the same room, being able to incorporate everyone in the team wherever they may be, opens up the possibility of more diverse ideas, creating a sense of team, and starts building relationships that can't form on a day-to-day basis in a traditional office environment. Using video during a remote retrospective can give you a glimpse into the personality and lives of your teammates.
It can also help maintain accountability in the team while working from home. Being able to come up with action items at your remote retrospective and people seeing the impact can boost team morale and create more energy for the next retrospective.
---
# Why retrospectives matter
URL: https://www.teamretro.com/guides/scrum-masters-retrospective-guide/why-retrospectives-a-useful-agile-tool/
Retrospectives matter because they give agile teams a regular, focused way to inspect how they work and adapt before small problems become big ones. A well-run retro turns reflection into tracked actions that lift morale, surface impediments early, and build a culture of continuous improvement.
> At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
> — Agile Manifesto Principle
Agile teams regularly inspect and adapt, reflect and improve, in a collaborative way, supported by relevant goals. Retrospectives are a critical tool for scrum masters, development teams, and product owners to work collaboratively in a focused and time-boxed way as a way of instilling a culture of continuous improvement.
The main purpose of the retrospective is for the team to come together and share what might be slowing things down and what changes can be made to improve outcomes. It means:
1. Teams have a way to suggest improvements
2. Challenges and issues can be addressed anonymously if need be
3. Team morale and engagement can be improved
4. Impediments can be identified and addressed early to increase velocity
5. Mistakes and lessons learned are shared to avoid them being repeated
The caveat is that the retro must be run with intention and focus. It should be engaging as well as being time efficient.
Bain & Company studied the time budget of 17 large corporations. It showed that up to 15% of a team's time is spent in meetings, yet up to 71% of people in those meetings are disengaged, distracted, multitasking, or checked out.
Often cited causes are the lack of agenda, time budget, purpose, and decision process which drastically reduces the return on time invested. Larger and more recent surveys reach the same conclusion: our roundup of [what meetings cost teams](/guides/agile-statistics/#meetings-and-the-cost-of-collaboration) gives each figure with its sample and its source.
On the other hand, if you never run a retrospective, this could result in:
- Issues not being identified and discussed early
- Tension and anxiety build up, killing productivity and morale
- No opportunity to suggest new ideas and improve things as a team
- A top-down approach that does not empower the team
- A scrum master does not know what is motivating or demotivating the team
A well-run retrospective offers a defined purpose, a clear repeatable process, facilitated group decision making, and actions that can be created and tracked. Holding them on a regular basis further increases accountability and discipline.
Time boxing the retrospective provides momentum, and having the right template means people have a structure for providing thoughts easily.
They are also a forum for Agile Values, the Manifesto, and Principles to be demonstrated, practiced, and applied.
**PRO TIP:** Remind your team every so often of the purpose and value of a retrospective to help keep it at the top of mind, and re-engage them to participate in the process.
With [online retrospective tools](/retrospective-tool/), like TeamRetro, you can make the retro semi or fully anonymous, increasing psychological safety. Everyone has an equal opportunity to participate in the discussions and decision-making process allowing you to identify where there is resistance or energy and therefore increase buy-in. By giving the team a role in the process, they are more likely to support any changes in the next iteration.
---
# Why retrospectives fail (and how to make yours matter)
URL: https://www.teamretro.com/guides/scrum-masters-retrospective-guide/why-retrospectives-fail/
Your team runs a retro every sprint. People show up, post their stickies, nod at two or three action items, and leave. Then nothing about how the work actually happens changes. Do that forty times a year and you haven't built a habit of improvement. You've built a habit of *talking about* improvement. That is the failure mode almost nobody names: not a bad format, but a ritual that reliably produces words and only words.
The standard advice treats a failing retro as a facilitation problem: rotate the format, write SMARTer actions, add an icebreaker. Sometimes that's the issue. Usually it isn't. We've cataloged the ten common [retrospective anti-patterns](/blog/avoid-these-retrospective-anti-patterns/) elsewhere, and they're worth fixing. This chapter goes after the two failures that list politely steps around, because they are the ones that make experienced engineers call retros a waste of time: a **power** problem and a **follow-through** problem. No icebreaker touches either. If facilitation is genuinely your problem, the fix lives in [running effective retrospectives](/guides/running-effective-retrospectives/), not here.
## The retro that changes nothing because the team can't
Here is the deepest critique of retrospectives, and the one our own anti-patterns post gets backwards. When a developer says "nothing ever happens," they usually don't mean the team forgot to write action items. They mean the problems worth raising (headcount, cross-team dependencies, a deployment pipeline that takes forty minutes, a deadline set three levels up) are *genuinely* outside the team's authority to fix. As one engineer put it plainly on Hacker News, a retro can become "a ceremony without actual purpose because usually the deeper things that people bring up are not within that team's power to control." Another, in the same thread: "It gives leadership an excuse for not fixing things or listening because retro is supposed to be the outlet for gripes."
That's the trap. The retro turns into a [pressure valve](/guides/agile-theatre/agile-theatre-glossary/#pressure-valve): the team gets to speak, precisely so that nothing has to change. People vent, leadership feels the box is ticked, and the underlying cause survives untouched. Blaming the facilitator for this is, as one developer's essay put it, "like blaming the suggestion box for management not reading the suggestions." No amount of sailboat-versus-starfish will give a team the authority to solve a problem it was never given authority to solve.
Our old advice ("stop focusing on things outside your circle of influence") quietly sides with the system here. It tells the team to bury the real blocker to keep the conversation comfortable. Take the harder line instead. Sort every issue by who actually owns it: what the team **controls**, what it can **influence**, and what it can only **suffer**. That's the Circles and Soup activity from Esther Derby and Diana Larsen's [_Agile Retrospectives_ (2nd ed.)](https://pragprog.com/titles/dlret2/agile-retrospectives-second-edition/). The point of the outer ring is not "ignore these." It's the input to an escalation.
Triage every issue by who owns it (control, influence, or the outer "soup" you can only respond to), then lift the red ones out to a named owner with a date instead of re-listing them.
**Escalate red items by name.** An issue the team can't fix doesn't disappear because you moved on from it. It just goes unowned. Turn each out-of-scope blocker into a visible request: name the problem, quantify the impact ("this cost us two days this sprint"), and name who needs to act and by when. The 2nd edition calls this a Retrospective Radiator: the retro radiates its findings outward instead of absorbing them. A team that escalates on the record is doing a retrospective. A team that only lists problems it can already solve is running a support group.
Not everything escalates, and not everything is hopeless. [15% Solutions](https://www.liberatingstructures.com/15-percent-solutions), the Liberating Structures technique of finding the smallest change the team *can* make without anyone's permission, keeps momentum on the influence ring while the big blockers work their way up. But the honest retro refuses to pretend the outer ring is the team's fault.
## The feedback that gets banked and used against you
Now the part no vendor writes about. People stay quiet in retros for a reason more concrete than shyness: being honest can be career-negative. The fear is specific and it shows up in real stories. One developer described retro feedback resurfacing "in my yearly evaluation where it was pointed out that I 'complain too much'." Another, more cynically: "they bank all these complaints for withdrawal at your annual bonus review."
The mechanism that keeps people quiet: candor offered in the retro is deposited, held, and withdrawn months later as a line in a performance review.
That's [feedback banking](/guides/agile-theatre/agile-theatre-glossary/#feedback-banking): honest input stored up and withdrawn against you later, and the fastest way to kill a retro dead. The Scrum Guide describes the Sprint Retrospective as the [Scrum Team inspecting *itself*](https://scrumguides.org/). Read that literally: the team, inspecting itself. So why is the person who signs your performance review sitting in the room taking notes? Their silence is enough. Nobody who controls your promotion has to say a word to make you soften what you'd have said otherwise. Google's Project Aristotle found psychological safety the single biggest predictor of team effectiveness; a manager's mere presence is often enough to remove it. (We cover the mechanics in the chapter on [building a psychologically safe space](/guides/scrum-masters-retrospective-guide/how-to-build-a-psychologically-safe-space/).)
So name the fear and design against it:
- **Keep promotion authority out of the room.** Share the agreed *actions* upward, not seats. A team blocked by a manager's presence cannot hold a transparent retrospective, and no facilitation trick recovers it.
- **Agree what's said stays in the room.** Only the actions the team chooses to publish leave it. This is what lets people speak in the first place.
- **Make anonymity an option per idea, not a permanent mode.** Anonymity levels power dynamics and surfaces the sensitive stuff; used as a permanent crutch it erodes the trust you're trying to build. Let people choose it for the item that needs it.
- **Be careful bringing metrics in.** Objective data (velocity, cycle time) belongs in a retro, but the moment velocity becomes a target the team is measured against, you've built a [velocity ratchet](/guides/agile-theatre/agile-theatre-glossary/#velocity-ratchet), and people optimize the number instead of telling the truth. This is the [power failure mode](/guides/agile-theatre/power-agile-theatre/) that turns candor into performance.
## The follow-through void, and the reframe that fixes it
Assume the power and safety problems are handled. Retros still fail on the most-repeated complaint in the entire discourse: "Retrospectives allow airing concerns, but nothing really ever happens of those concerns." Or, more bluntly: "I have never seen anything happen besides words." The resigned sound of it ("this sticky will not be addressed") is what groundhog-day retros feel like from the inside. It's not imagination: the number everyone repeats, a commonly cited figure that only about a third of teams consistently complete their retro action items, turns out to oversell the doom. We measured [how many retrospective action items actually get done](/guides/follow-through-index/) across hundreds of thousands of real actions: completion is closer to three in four, and cadence and ownership decide which side of that gap a team lands on. What the folklore gets right is the shape of the failure. An action nobody owns, on no date, in a team with no rhythm, is the one that gets written on a whiteboard and erased.
Two fixes, and the second is the important one.
First, stop trying to fix everything. The longer the list, the worse each item on it does: in our data retros that leave with ten or more actions complete about 56% of them, against about 79% for retros that leave with one to three. Cap it at **one** improvement the team genuinely commits to, write it into the next sprint's work rather than leaving it on the board, and open every retro by reviewing last time's one thing before generating anything new. If it wasn't done, that's the most useful conversation in the room. Reaching for a new format is the first thing teams try and the least likely to help: swapping Mad/Sad/Glad for a sailboat is lipstick if follow-through is broken.
Second, stop treating the *action item* as the point. This is the reframe from the [_Agile Retrospectives_ 2nd edition](https://pragprog.com/titles/dlret2/agile-retrospectives-second-edition/) that the whole category is moving toward. Derby, Larsen and David Horowitz's key shift is that **learning**, not a completed to-do, is the success criterion. Replace the action item with an **experiment**: a hypothesis you test ("if we pair on the risky story, we'll cut rework"), a date to review it, and an honest look at what actually happened. A retro that produced no checkbox action but genuinely taught the team something is not a failed retro. That single move dissolves the "nothing changes" complaint, because the goal stops being a completed chore and becomes a change you're actually running. [Johanna Rothman](https://www.jrothman.com/) had been making the same substitution well before it reached the retrospective canon, in [_Create Your Successful Agile Project_](https://pragprog.com/titles/jragm/create-your-successful-agile-project/): one item, run as an experiment, with the team's next block of work framed to include it.
## Silence isn't apathy: it's a signal
A quieter failure: the retro where two of eight people talk for five minutes and the rest is dead air, and every format and pre-filled board you try changes nothing. It's easy to read that as a disengaged team. It usually isn't. Silence in a retro is a signal, not the problem itself: it points at missing trust, unclear purpose, or a leadership issue people won't name out loud. Remote makes it worse: cameras off, mics muted, energy flat.
Don't fill the silence with more prompts. Change who talks first. Run a silent, solo brainstorm before any discussion so people write before they speak, which protects the introverts and the people who don't want to be the one who says it aloud. Collect input async ahead of time. Let people contribute a sticky without having to defend it in front of the room. The goal isn't a lively meeting; it's honest data, and honest data often arrives quietly.
## The meeting tax is a real cost, not an excuse
Finally, the critique the "never skip the retro" crowd waves away too fast: retros cost something. "It's another meeting on my calendar potentially interrupting whatever deep focus I was in," one developer wrote. That is stacked on standup, planning, review, and refinement. On short cadences the math gets brutal: teams on one-week sprints describe planning and retro every week as "a burden," and they're right. Fifty retros a year on a mature team is not a virtue. The same complaint shows up at organizational scale in [the research on meeting load](/guides/agile-statistics/#meetings-and-the-cost-of-collaboration), where the share of meetings people say they could have skipped is measured rather than guessed at.
The answer isn't to skip retros; it's to right-size them. A newly formed team under stress benefits from a retro every sprint. A stable team that keeps having the same thin conversation is telling you the cadence is wrong, not that reflection is worthless. Move to bi-weekly, or trigger retros by *events* (after a release, after an outage, after a rough sprint) when there's genuinely something to inspect. Cadence is a dial, not a commandment. (The same overload logic runs through every ceremony: see [standup anti-patterns](/guides/daily-standup-guide/standup-anti-patterns/) and the [follow-through void](/guides/agile-theatre/the-follow-through-void/) in our Agile Theatre field guide.)
Fix the power problem, protect the honesty, follow through on one real thing, and right-size the cadence, and the retro stops being a pressure valve. It becomes the one hour a sprint where the team actually changes how it works, which was always the point. An [online retrospective tool](/retrospectives/) helps in one specific way: it carries each agreed change forward as a tracked action, so the follow-through survives the week after the meeting.
## Frequently asked questions
### Why does nothing ever change after our retrospectives?
Usually because the issues that matter most are outside the team's authority, and the retro has no route to send them anywhere. The board fills with problems the team cannot fix alone (headcount, dependencies, a broken deployment pipeline), and everyone leaves having described the weather rather than changed it. The fix is to triage every item by who actually owns it, keep a single team-controlled improvement to work on, and escalate the out-of-scope items upward by name with an owner and a date instead of quietly dropping them.
### What do you do when the real problem is outside the team's control?
You escalate it, on the record. Sort issues into what the team controls, what it can influence, and what it can only suffer (the Circles and Soup activity from _Agile Retrospectives_). The generic advice says to ignore the outer ring and stay in your circle of influence. That is how a retro becomes theatre. Instead, turn the outer-ring items into a visible request (a Retrospective Radiator) that names the blocker, the impact, and who needs to act, and put it in front of the people who can move it. A retro that only surfaces problems the team can already fix is comfortable and dishonest.
### Is it safe to be honest in a retrospective?
Only if honesty carries no career cost. Developers routinely report retro feedback resurfacing in a performance review as evidence they "complain too much." If the person who signs off on promotions is in the room, or if what's said gets banked for later, people go quiet and say everything is fine. Protect candor deliberately. Keep line managers who own promotions out of the session, agree that what's discussed stays in the room and only agreed actions leave it, and make anonymity available per idea rather than as an all-or-nothing mode.
### Are retrospectives a waste of time?
They are when the only success test is a completed action item, because most sprints don't hand you a tidy one. Reframe the goal. A retrospective succeeds when the team learns something it will carry into the next sprint, even without a checkbox action, and when it runs one honest experiment rather than ten abandoned to-dos. Retros also do quieter work (surfacing tension early, keeping a team cohesive) that never shows up as an action item but is real. Judged as a learning ritual instead of a task factory, they earn their place.
---
# Responsible AI
URL: https://www.teamretro.com/security/responsible-ai/
## Responsible AI
#### At TeamRetro, we believe that artificial intelligence should enhance teamwork, decision-making, and collaboration while keeping people, ethics, and trust at the heart of every interaction. Our commitment to responsible AI ensures that the tools we build are transparent, fair, and aligned with these values.
#### TeamRetro does not use your data to build or train AI models.
All content generated using TeamRetro’s AI tools is subject to our platform’s overall [security](/security/), [privacy](/privacy/), and [terms of use](/terms-of-service/).
## TeamRetro AI capabilities
TeamRetro integrates generative AI into various features to enhance retrospectives, health checks, estimations, and standups. These AI features streamline your experience by answering questions through our AI Assistant (trAI), generating templates, health models, icebreakers, suggesting groupings, actions, providing summaries and insights, and tracking team sentiment and topics over time.
| Capability | Provider | Model |
| :-- | :-- | :-- |
| Retrospective template, icebreaker question, health model generation | Open AI | ChatGPT 5.x |
| AI Assistant (trAI) | AWS Bedrock | Claude Sonnet 5.x |
| Meeting summarization | AWS Bedrock | Claude Sonnet 5.x |
| Meeting suggested titles | AWS Bedrock | Claude Haiku 5.x |
| Insights topic, sentiment, keyword annotations. Theme identification. | AWS Bedrock | Claude Sonnet 5.x |
| Automated grouping, group title suggestions | AWS Bedrock | Claude Sonnet 5.x Claude Haiku 5.x |
| Action suggestions | AWS Bedrock | Claude Sonnet 5.x |
| Search embeddings | AWS Bedrock | Titan Text Embeddings v2 Cohere Embed Model 3 |
| AI image generation for cover and topic images | fal – Features & Labels, Inc. | Image-generation models hosted on fal.ai |
| Moderation of typed themes and image descriptions | Open AI | omni-moderation-latest |
*Learn more about our [AI-powered features](https://help.teamretro.com/article/445-ai-features). Learn more about our [sub-processors](/security/subprocessors/).*
## Our principles
We are committed to responsible AI governance. Our AI use must:
- Be fair, transparent, and accountable.
- Avoid bias and discrimination.
- Use data ethically and lawfully.
- Be explainable to users, with clear documentation of decision-making processes.
- Comply with our SOC 2 Type 2, GDPR and other privacy rules.
## Our commitment to safety
Principles are important, but so are practices. To make sure our AI stays aligned with your needs, we actively monitor, moderate, and restrict AI use where appropriate. These include, but are not limited to:
- The AI Assistant (trAI), summaries and suggestions run on AWS Bedrock under AWS Bedrock Guardrails. The guardrail blocks attempts to override our instructions (prompt attacks).
- The guardrail also screens AI output for violent, sexual, hateful, insulting or criminal content.
- The theme or image description you type for generated templates, health models, icebreaker questions and images is checked by OpenAI's moderation model before anything is generated. Flagged requests are refused.
These safeguards cover TeamRetro's own AI features. If you connect your own AI assistant, such as Claude, through our MCP server, it can read and change only what you can in TeamRetro. Your AI provider's terms apply to the data it receives. Account administrators can turn off MCP connections for the whole account.
## AI regulation and the EU AI Act
TeamRetro does not develop or train AI models, so the conformity assessments and conformance testing the EU AI Act requires of model providers do not apply to us. The models behind our features are built and operated by our providers: OpenAI, Anthropic and Amazon (via AWS Bedrock), Cohere, and fal.ai, who carry the model-level obligations, including those for general-purpose AI models.
Our own use of AI is assistive. Features like summaries, suggested groupings, and action suggestions support your team’s discussion, and a person reviews the output and decides what to keep. The AI Assistant (trAI) can also create and change items in a meeting, but only when a user asks it to, only within that user’s own permissions, and its changes stay visible and editable like any other. TeamRetro’s AI features do not make automated decisions about individuals, and based on our assessment they are not high-risk AI systems under the EU AI Act, so no conformity assessment is required for them either.
We monitor the EU AI Act and related regulation as obligations come into force, and we will update this page if our position changes.
## Reporting and feedback
Responsible AI is not a one-time promise; it’s an ongoing journey. We continuously review, refine, and update our practices as technology evolves, ensuring our solutions remain aligned with the highest ethical standards.
If you encounter inappropriate, inaccurate, or unexpected AI content, or believe a prompt or output was incorrectly flagged, please contact our support team so we can investigate at [info@teamretro.com](mailto:info@teamretro.com).
## Frequently asked questions
---
# Responsible Disclosure
URL: https://www.teamretro.com/security/responsible-disclosure/
## Responsible Disclosure
## Our customers trust us to keep their data secure and confidential. We take security seriously and work constantly to ensure that trust is well-founded. Have something to report? Please reach out to us at security@groupmap.com
## Responsible disclosure
We encourage everyone that practices responsible disclosure and complies with our policies and terms of service to participate in our vulnerability disclosure program. Please avoid automated testing and only perform security testing with your own data. Please do not disclose any information regarding the vulnerabilities until we fix them. We may, at our sole discretion, offer recognition for high-quality, impactful reports that demonstrate a genuine security risk.
You can report vulnerabilities by contacting [security@groupmap.com](mailto:security@groupmap.com). Please include a proof of concept. We will respond as quickly as possible to your submission and won’t take legal actions if you follow the rules.
***Coverage:***
- secure.teamretro.com
***Exclusions:***
- \*.eu.teamretro.com
- ww1.teamretro.com
- ww2.teamretro.com
- ww3.teamretro.com
- www.teamretro.com
- at.teamretro.com
- help.teamretro.com
- feedback.teamretro.com
- mail.teamretro.com
- status.teamretro.com
- track.teamretro.com
- games.teamretro.com
- icebreaker.teamretro.com
- ideas.teamretro.com
- planning-poker.teamretro.com
- www-assets.teamretro.com
***Accepted vulnerabilities are the following:***
- Cross-Site Scripting (XSS)
- Open redirect
- Cross-site Request Forgery (CSRF)
- Command/File/URL inclusion
- Authentication issues
- Code execution
- Code or database injections
***This vulnerability disclosure program does NOT include:***
- Account/email enumerations
- Denial of Service (DoS)
- Attacks that could harm the reliability/integrity of our business
- Spam attacks
- Clickjacking on pages without authentication and/or sensitive state changes
- Mixed content warnings
- Lack of DNSSEC
- Content spoofing / text injection
- Timing attacks
- Social engineering
- Phishing
- Insecure cookies for non-sensitive cookies or 3rd party cookies
- Vulnerabilities requiring exceedingly unlikely user interaction
- Exploits that require physical access to a user’s machine
- Missing security headers which do not lead directly to a vulnerability
- Missing best practices (we require evidence of a security vulnerability)
- Reports generated by automated scanners without demonstrated impact
- Missing security headers without a demonstrated exploit
- SSL/TLS configuration issues without a demonstrated exploit
- Missing rate limiting
- Self-XSS (requires victim to paste code into their own console)
- Login/logout CSRF
- Vulnerabilities requiring outdated or unsupported browsers
- Duplicate reports or previously known issues
### Submission requirements
***All reports must include the following or they will not be reviewed:***
- Affected URL or endpoint
- Step-by-step reproduction instructions
- Proof of concept (screenshots, video, or code)
- Description of the security impact
Automated scanning is not permitted without prior written approval. All testing must be performed manually and all vulnerability disclosure program details must remain confidential.
#### Our thanks go to the following security researchers:
- Abin Joseph
- daniel\_v
- Ananda Dhakal
- Luiz Viana
- Aman Gupta
- Vipul Sahu
- Hsu Myat Noe
- Tomasz Bartoszewski
- Harry Gertos
- Sathwik Veeramaneni
- Yassine Nafiai
- SIDN SOC
- Burhan Chhotaudepur
- Faizan Nehal
- Aaditya Kumar Sharma
- Syed Ahsan Raza
- Mohammed Eldawody
- Yaniv Shoshani
- Lucas Werkmeister
- Ankit Rathva
---
# TeamRetro Subprocessors
URL: https://www.teamretro.com/security/subprocessors/
## TeamRetro third-party subprocessors
TeamRetro uses the third-party entities in the table below to perform limited activities in connection with the provision of its services. Customers whose enterprise agreement or data processing agreement requires it are told before we add a new subprocessor.
*Last updated: October 9, 2026.*
## TeamRetro core product subprocessors
Subprocessors in this section apply to the use of the TeamRetro product.
| Entity | Task | Entity Country | Processing Country | More Info |
| :-- | :-- | :-- | :-- | :-- |
| [Amazon Web Services](https://www.aboutamazon.eu/) 38 Avenue John F. Kennedy, L-1855, Luxembourg | **TeamRetro EU Region** Hosting services for the core TeamRetro application EU environment (VPC, ALB, WAF, ECR, ECS, RDS, Elasticache, Backup), content storage and distribution (S3, CloudFront), infrastructure security and management (CloudWatch, CloudTrail, GuardDuty, SecurityHub). | Luxembourg | Germany | [Privacy](https://aws.amazon.com/privacy/) [Security](https://aws.amazon.com/security/) [Status](https://health.aws.amazon.com/health/status) |
| [Amazon Web Services](https://aws.amazon.com/) 410 Terry Ave N, Seattle, Washington 98019 United States | **TeamRetro US Region** Hosting services for the core TeamRetro application (VPC, ALB, WAF, ECR, ECS, RDS, Elasticache, Backup), content storage and distribution (S3, CloudFront), infrastructure security and management (CloudWatch, CloudTrail, GuardDuty, SecurityHub). | United States | United States | [Privacy](https://aws.amazon.com/privacy/) [Security](https://aws.amazon.com/security/) [Status](https://health.aws.amazon.com/health/status) |
| [Ably Realtime Ltd.](https://ably.com/) Scale Space, 58 Wood Lane London W12 7RZ United Kingdom | **TeamRetro EU Region** Real-time data synchronization via Websockets | United Kingdom | Cross-border (Ireland, Germany, United Kingdom, France, Sweden) | [Privacy](https://ably.com/privacy) [Security](https://ably.com/security-and-compliance) [Status](https://status.ably.com/) |
| [Ably Realtime, Inc.](https://ably.com/) 2100 Geng Road, Suite 210 Palo Alto, CA 94303 United States | **TeamRetro US Region** Real-time data synchronization via Websockets | United States | United States | [Privacy](https://ably.com/privacy) [Security](https://ably.com/security-and-compliance) [Status](https://status.ably.com/) |
| [Twilio Inc.](https://www.twilio.com/en-us) 101 Spear St 5th floor, San Francisco, CA 94105, United States | Processes and delivers transactional emails (SendGrid) | United States | United States | [Privacy](https://sendgrid.com/privacy/) [Security](https://sendgrid.com/security/) [Status](https://sendgrid.statuspage.io/) |
| [PayPal](https://www.paypal.com/) 2211 N First St, San Jose, CA 95131, United States | Payment processing for online self-subscriptions (Braintree Payments). | United States | United States | [Privacy](https://www.paypal.com/us/legalhub/paypal/privacy-full) [Security](https://www.paypal.com/us/security) [Status](https://www.paypal-status.com/product/production) |
| [Rollbar, Inc.](https://rollbar.com/) 548 Market St #60587, San Francisco, CA 94104, United States | Error logging | United States | United States | [Privacy](https://docs.rollbar.com/docs/privacy-policy) [Security](https://docs.rollbar.com/docs/security) [Status](https://status.rollbar.com/) |
| [Better Stack, Inc.](https://betterstack.com/) Rybna 716/24, 11000 Prague, Czech Republic | **TeamRetro EU Region** Application logging and uptime monitoring. | Czech Republic | Germany | [Privacy](https://betterstack.com/privacy) [Security](https://betterstack.com/security) [Status](https://status.betterstack.com/) |
| [Better Stack, Inc.](https://betterstack.com/) 9450 SW Gemini Drive PMB 98229 Beaverton, Oregon 97008-7105 | **TeamRetro US Region** Application logging and uptime monitoring. | United States | United States | [Privacy](https://betterstack.com/privacy) [Security](https://betterstack.com/security) [Status](https://status.betterstack.com/) |
| [Datadog, Inc.](https://www.datadoghq.com/) 620 8th Ave 45th Floor, New York Times Bldg, New York, NY 10018, USA | Application monitoring, telemetry, and metric services. | United States | United States | [Privacy](https://www.datadoghq.com/legal/privacy/) [Security](https://docs.datadoghq.com/security/) [Status](https://status.datadoghq.com/) |
## TeamRetro AI synthesis subprocessors
Subprocessors in this section are engaged by TeamRetro’s AI synthesis features, such as suggested grouping, retrospective, health check and standup meeting summaries and health check response summaries. These features can be disabled at the account level at any time.
| Entity | Task | Entity Country | Processing Country | More Info |
| :-- | :-- | :-- | :-- | :-- |
| [Amazon Web Services](https://www.aboutamazon.eu/) 38 Avenue John F. Kennedy, L-1855, Luxembourg | **TeamRetro EU Region** Optional. AI Assistant (trAI), suggested grouping, retrospective, health check and standup meeting summaries and health check response summaries powered by [AWS Bedrock](https://aws.amazon.com/bedrock/?gclid=Cj0KCQjw8pKxBhD_ARIsAPrG45kPMSUGI5Jexo7YnQ3ma92h2Lql3xApMg2rKESuKct-dwe-LOWKD70aAoyOEALw_wcB&trk=1325fdf1-f38b-4c89-8bf9-dc39eeb87ff8&sc_channel=ps&ef_id=Cj0KCQjw8pKxBhD_ARIsAPrG45kPMSUGI5Jexo7YnQ3ma92h2Lql3xApMg2rKESuKct-dwe-LOWKD70aAoyOEALw_wcB:G:s&s_kwcid=AL!4422!3!692062112141!e!!g!!aws%20bedrock!21054970946!157173566817). *AWS Bedrock does not log, store, or use your content for any other purposes.* | Luxembourg | France, Germany, Ireland | [Privacy](https://aws.amazon.com/privacy/) [Security](https://aws.amazon.com/security/) [Status](https://health.aws.amazon.com/health/status) |
| [Amazon Web Services](https://aws.amazon.com/) 410 Terry Ave N, Seattle, Washington 98019 United States | **TeamRetro US Region** Optional. AI Assistant (trAI), suggested grouping, retrospective, health check and standup meeting summaries and health check response summaries powered by [AWS Bedrock](https://aws.amazon.com/bedrock/?gclid=Cj0KCQjw8pKxBhD_ARIsAPrG45kPMSUGI5Jexo7YnQ3ma92h2Lql3xApMg2rKESuKct-dwe-LOWKD70aAoyOEALw_wcB&trk=1325fdf1-f38b-4c89-8bf9-dc39eeb87ff8&sc_channel=ps&ef_id=Cj0KCQjw8pKxBhD_ARIsAPrG45kPMSUGI5Jexo7YnQ3ma92h2Lql3xApMg2rKESuKct-dwe-LOWKD70aAoyOEALw_wcB:G:s&s_kwcid=AL!4422!3!692062112141!e!!g!!aws%20bedrock!21054970946!157173566817). *AWS Bedrock does not log, store, or use your content for any other purposes.* | United States | United States | [Privacy](https://aws.amazon.com/privacy/) [Security](https://aws.amazon.com/security/) [Status](https://health.aws.amazon.com/health/status) |
## TeamRetro AI content generation subprocessors
Subprocessors in this section are optionally engaged when you make use of TeamRetro’s Generative AI features such as AI-generated retrospective templates, health models and icebreaker questions. These features can be disabled at the account level at any time. Only the details you enter for the generation, such as the theme, team type and language, are sent. We treat them as customer data.
| Entity | Task | Entity Country | Processing Country | More Info |
| :-- | :-- | :-- | :-- | :-- |
| [OpenAI LLC](https://openai.com/) Pioneer building 3180 18th St, San Francisco, CA 94110, USA | Optional. OpenAI generative AI is used for AI content generation (retrospective templates, health models, icebreaker questions). OpenAI's moderation model also checks the themes and image descriptions you type before anything is generated. | United States | United States | [Privacy](https://openai.com/policies/row-privacy-policy/) [Security](https://openai.com/security-and-privacy/) [Status](https://status.openai.com/) |
## TeamRetro AI image generation subprocessors
Subprocessors in this section are optionally engaged when you make use of TeamRetro’s AI image generation features, such as cover and topic images. These features can be disabled at the account level at any time. Only the image description you enter is sent. We treat it as customer data.
| Entity | Task | Entity Country | Processing Country | More Info |
| :-- | :-- | :-- | :-- | :-- |
| [fal – Features & Labels, Inc.](https://fal.ai) 2261 Market St., Suite 10467, San Francisco, CA 94114 | Optional. fal.ai generative AI is used for AI image generation | United States | United States | [Privacy](https://fal.ai/legal/privacy-policy) [Security](https://trust.fal.ai/) [Status](https://status.fal.ai) |
| [OpenAI LLC](https://openai.com/) Pioneer building 3180 18th St, San Francisco, CA 94110, USA | Optional. OpenAI's moderation model checks each image description before it is sent to fal.ai | United States | United States | [Privacy](https://openai.com/policies/row-privacy-policy/) [Security](https://openai.com/security-and-privacy/) [Status](https://status.openai.com/) |
## GroupMap Technology Pty Ltd business operations subprocessors
Subprocessors included in this section apply when you engage with GroupMap Technology Pty Ltd as an organization and purchase or use any of our offerings.
| Entity | Task | Entity Country | Processing Country | More Info |
| :-- | :-- | :-- | :-- | :-- |
| [Google LLC](https://workspace.google.com/intl/en_au/) 1600 Amphitheater Parkway, Mountain View, California, 94043, USA | Google Workspace processes email messages. Customer content may be processed by Google Workspace but only if customer chooses to provide customer content in email interactions with GroupMap staff. | United States | United States | [Privacy](https://policies.google.com/privacy) [Security](https://safety.google/security-privacy/) [Status](https://www.google.com/appsstatus/dashboard/) |
| [Salesforce, Inc.](https://www.salesforce.com/ap/?ir=1) ([Slack](https://slack.com/)) 415 Mission Street, San Francisco, California, USA | Internal team communication tool, which may include customer support or technical incident response information. | United States | United States | [Privacy](https://slack.com/trust/privacy/privacy-policy) [Security](https://slack.com/security-practices) [Status](https://slack-status.com/) |
| [Xero](https://www.xero.com/au/) 19–23 Taranaki Street Te Aro, Wellington 6011 New Zealand | Enterprise invoicing and financial accounting. | New Zealand | United States | [Privacy](https://www.xero.com/legal/privacy/) [Security](https://www.xero.com/security/) [Status](https://status.xero.com/) |
| [PayPal](https://www.paypal.com/) 2211 N First St, San Jose, CA 95131, United States | Enterprise invoice payment processing | United States | United States | [Privacy](https://www.paypal.com/us/legalhub/paypal/privacy-full) [Security](https://www.paypal.com/us/security) [Status](https://www.paypal-status.com/product/production) |
| [Skcript Technologies Pvt. Ltd](https://www.skcript.com/) ([FeatureOS](https://featureos.app/)) L3, VR Mall, The Hive, Madras House, near Madras House, Anna Nagar, Chennai, Tamil Nadu 600040, India | Feature suggestions | India | United States | [Privacy](https://featureos.app/legal/privacy) [Security](https://featureos.app/legal/security) [Status](https://status.featureos.app/) |
| [HelpScout](https://www.helpscout.com) Boston, Massachusetts, United States | Sales & support ticketing system, including HelpScout's AI Answers in our support chat | United States | United States | [Privacy](https://www.helpscout.com/company/legal/privacy/) [Security](https://www.helpscout.com/company/legal/security/) [Status](https://status.helpscout.com/) |
| [Linear Orbit, Inc (Linear)](https://linear.app) 440 Barranca Ave #4242, Covina, CA 91723, United States | Feature backlog, task and client management | United States | United States | [Privacy](https://linear.app/privacy) [Security](https://linear.app/security) [Status](https://linearstatus.com/) |
| [GitHub, Inc.](https://github.com/) 88 Colin P Kelly Jr St, San Francisco, CA 94107, United States | Source code management and CI/CD | United States | United States | [Privacy](https://docs.github.com/en/site-policy/privacy-policies/github-general-privacy-statement) [Security](https://github.com/security) [Status](https://www.githubstatus.com/) |
---
# Cookie Policy
URL: https://www.teamretro.com/cookies/
This is the Cookie Policy for TeamRetro, accessible from teamretro.com
## 1. What are cookies
As is common practice with almost all websites and software-as-a-service products, TeamRetro uses cookies, which are tiny files that are downloaded to your computer, to improve your experience. This page describes what information they gather, how we use it and why we sometimes need to store these cookies. We will also share how you can prevent these cookies from being stored however this may downgrade or ‘break’ certain elements of TeamRetro functionality.
For more general information on cookies see the Wikipedia article on [HTTP Cookies](https://en.wikipedia.org/wiki/HTTP_cookie).
## 2. How we use cookies
We use cookies for a variety of reasons detailed below. Unfortunately in most cases there are no industry standard options for disabling cookies without completely disabling the functionality and features they add to this site. It is recommended that you leave on all cookies if you are not sure whether you need them or not in case they are used to provide a service that you use.
## 3. Disabling cookies
You can prevent the setting of cookies by adjusting the settings on your browser (see your browser help for how to do this). Be aware that disabling cookies will affect the functionality of this and many other websites that you visit. Disabling cookies will usually result in also disabling certain functionality and features of this site. Therefore it is recommended that you do not disable cookies.
## 4. The cookies we set
### Account related cookies
If you create an account with us then we will use cookies for the management of the signup process and general administration.
| **Cookie Name** | **Description** | **Retention** |
| :-- | :-- | :-- |
| teamretro-production.defaultRegion | Captures the TeamRetro region the user has most recently signed into, United States or European Union. | 1000 days |
### Login related cookies
We use cookies when you are logged in so that we can remember this fact. This prevents you from having to log in every single time you visit a new page. These cookies are typically removed or cleared when you log out to ensure that you can only access restricted features and areas when logged in.
| **Cookie Name** | **Description** | **Retention** |
| :-- | :-- | :-- |
| teamretro-us-production.session teamretro-eu-production.session | A random token identifying the active user login session. | 16 hours |
### Site preferences cookies
In order to provide you with a great experience on this site, we provide the functionality to set your preferences for how this site runs when you use it. In order to remember your preferences we need to set cookies so that this information can be called whenever you interact with a page that is affected by your preferences.
| **Cookie Name** | **Description** | **Retention** |
| :-- | :-- | :-- |
| teamretro-website.preferredLocale | Remembers the language you last viewed this website in, so we never switch it on you automatically. | 180 days |
| teamretro-website.geoRedirected | Records that we just switched you to a local language, so we can offer you the way back to English. | 2 minutes |
### Third Party Cookies
We do not use any third party tracking cookies.
## 5. More information
Hopefully that has clarified things for you and as was previously mentioned if there is something that you aren’t sure whether you need or not it’s usually safer to leave cookies enabled in case it does interact with one of the features you use on our site.
However if you are still looking for more information then you can contact us at [privacy@teamretro.com](mailto:privacy@teamretro.com)
---
# GDPR Compliance
URL: https://www.teamretro.com/gdpr/
## Your privacy rights under the GDPR
At TeamRetro, we prioritize your privacy and data protection. If you are a resident of the **European Economic Area (EEA)**, **United Kingdom (UK)**, or **Switzerland**, the **General Data Protection Regulation (GDPR)** provides you with specific rights concerning your personal data.
## Your GDPR rights
As an EEA/UK/Swiss resident, you have the following rights regarding your personal data:
### 1. Right to access
You have the right to request access to the personal data we hold about you and obtain a copy of it.
### 2. Right to rectification
If your personal data is inaccurate or incomplete, you have the right to request correction.
### 3. Right to erasure (“Right to be forgotten”)
You can request the deletion of your personal data where:
- It is no longer necessary for the purpose collected.
- You withdraw consent (where applicable).
- You object to the processing and there are no overriding legitimate grounds.
- Your data has been unlawfully processed.
### 4. Right to restrict processing
You may request to restrict the processing of your data in certain circumstances, such as when you contest its accuracy or object to its processing.
### 5. Right to data portability
You have the right to receive your personal data in a structured, commonly used, and machine-readable format and to transfer it to another service provider.
### 6. Right to object
You can object to processing based on legitimate interests, direct marketing, or automated decision-making.
### 7. Right to withdraw consent
If we process your data based on consent, you may withdraw it at any time without affecting the lawfulness of prior processing.
### 8. Right to complain
If you believe we have not handled your data in accordance with the UK or EU GDPR, you have the right to complain to us directly. Email us at [privacy@teamretro.com](mailto:privacy@teamretro.com), or use the complaint form provided by our representative, Prighter. We will acknowledge your complaint within 30 days of receiving it, investigate it without undue delay, and inform you of the outcome.
You also have the right to lodge a complaint with a supervisory authority — the Information Commissioner's Office (ICO) in the UK, or your local **Data Protection Authority (DPA)** in the EU — particularly if you are not satisfied with our response.
## How to exercise your rights
To exercise any of these rights, please contact us at:
- **Email**: [privacy@teamretro.com](mailto:privacy@teamretro.com)
- **Mailing Address**: Chief Privacy Officer
GroupMap Technology Pty. Ltd.
Level 1/931 Albany Highway
East Victoria Park WA 6100
Australia
For security purposes, we may request proof of identity before processing your request.
## Legal basis for processing your data
We process your data based on the following lawful grounds:
- **Contract**: To fulfill agreements with you.
- **Legitimate Interest**: To provide, secure, and improve our services.
- **Consent**: Where required, such as for marketing communications.
- **Legal Obligation**: To comply with laws and regulations.
## International data transfers
Your data may be processed in the **United States (US)** or **European Union (EU)** depending on your selected region. We use Standard **Contractual Clauses (SCCs)** and other safeguards to ensure compliance with GDPR when transferring data outside the EEA.
## Data retention
We retain personal data only as long as necessary for the purposes stated or as required by law. Retention periods include:
- **User-Generated Content**: Stored until deleted by you or your administrator.
- **Trial Accounts**: Deleted 365 days after the trial ends.
- **Canceled Paid Accounts**: Deleted 365 days after cancellation.
- **Billing Information**: Retained for up to 7 years for compliance purposes.
- **Backups**: Retained for up to 30 days.
## Security measures
We implement appropriate technical and organizational security measures, including **encryption (SSL/TLS)**, **secure hosting**, and **access controls**. While we strive to protect your data, no system is 100% secure.
For more details, visit our [Privacy Policy](/privacy/).
## Updates to this notice
We may update this GDPR notice periodically to reflect regulatory changes or operational updates. The “Last Updated” date at the top indicates the latest revision.
***TeamRetro remains committed to protecting your privacy.
If you have any concerns, feel free to reach out at [privacy@teamretro.com](mailto:privacy@teamretro.com).***
## Request a Data Processing Agreement (DPA)
If your organization requires a Data Processing Agreement (DPA), send us the details
below and our privacy team will email your DPA. You can also request a copy directly at
[privacy@teamretro.com](mailto:privacy@teamretro.com).
---
# Privacy Policy
URL: https://www.teamretro.com/privacy/
## INTRODUCTION
GroupMap Technology Pty Ltd ("the Company") operates TeamRetro, an online agile retrospective and health check tool for remote teams. We are committed to respecting your privacy. This privacy policy explains how we collect, use, and protect your personal information.
Our core data protection principles:
- **Security**: We keep your data safe and secure.
- **Stewardship:** We accept responsibility for handling personal data.
- **Transparency:** We communicate openly about how we process data.
- **Legal Compliance:** We meet all relevant privacy laws and regulations.
**Definitions**
- "**Site**" refers to our website at [https://www.teamretro.com](https://www.teamretro.com/).
- "**Service**" refers to any services provided through the Site, including TeamRetro.
- "**We**," "**us**," "**our**" refer to GroupMap Technology Pty Ltd.
- "**You**" refers to you, our user (individual or corporate client).
By using our Service, you agree to this privacy policy and our [terms of service](/terms-of-service/), and you consent to the ways we collect, store, use, and disclose your personal information.
## Information we collect
### a) Personal information you provide
We collect personal information you choose to give us, such as:
- **Name and contact details**: Your name, email address, billing address, and similar information.
- **Login credentials**: Passwords (stored in a cryptographically hashed and salted form) and related data for account access.
- **Social media login data**: If you choose to register or sign in via Google, Facebook, LinkedIn, etc. we collect the relevant profile info they share with us.
- **Payment data**: Payment details like credit card numbers and security codes. (Stored by our payment processor; please check their privacy policy).
### How and when we collect it:
- During registration
- When you use the Service or express interest in our products
- When you contact us or participate in our online sessions
### Legal Bases for Processing (where applicable):
- **Contract**: To fulfill the agreement we have with you.
- **Legitimate interests**: For our lawful business purposes (unless overridden by your rights).
- **Legal obligation**: To comply with legal or regulatory requirements.
- **Consent**: Where you've specifically agreed to certain uses.
Please ensure the information you provide is accurate and up to date. Please note that certain personal data (e.g. your email) is necessary for account creation and basic functionality. If you choose not to provide or later withdraw consent to process this data, we may be unable to continue offering you some or all of our services.
### b) User-generated content
This is the information you add in collaborative spaces — like ideas, comments, or feedback within retrospectives or workshops. It may include personal details only if you choose to include them.
- **Our use**: We only store and process this content to provide our Service.
- **Visibility**: It's visible to you and other invited participants.
- **No sale or ads**: We do not sell or use your User-Generated Content for advertising.
### c) Information collected automatically
We automatically collect certain data when you interact with our site or service, such as:
- IP address, browser type, device information
- Usage details (e.g. features used, time spent on pages)
This helps us secure the Service, analyze usage, and improve performance. It typically does not identify you personally.
## How we use your information
We use your personal information for purposes based on our legitimate business interests, our contract with you, compliance with legal obligations, or your consent.
Key uses include:
- **Processing user-generated content**: Facilitating retrospectives, collaboration, and related features.
- **Account creation & login**: Including social logins (Google, Facebook, LinkedIn).
- **Marketing & promotions**: Sending promotional messages if you've consented (you can opt out anytime).
- **Administrative communications**: Sending product updates, policy changes, or other important notices.
- **Order fulfillment**: Managing payments, returns, and other transaction-related items.
- **Testimonials**: Publishing your testimonial with your consent (you can request updates or removal).
- **Feedback requests**: Asking you for feedback on our Site or Service.
- **Protecting our service**: For fraud monitoring and security.
- **Collaborations between users**: Enabling shared workspaces and user-to-user interactions (with each user's consent).
- **Enforcing terms & legal requests**: Investigating and acting on potential legal issues or violations.
- **Other business purposes**: Such as data analysis, usage trends, and improving our offerings.
## Cookies and other tracking technologies
We use **essential** and **referral** cookies to operate our Site. We do **not** use third-party analytics or advertising cookies.
- **Essential cookies**:
- **Account-related**: Manage signup and administration.
- **Login-related**: Remember you're logged in.
- **Site preferences**: Store your preferences (e.g. language).
- **Referral cookies**: Track if you arrived via a partner site for referral purposes.
## Children's privacy
Our service is not intended for users under 18 (or the legal minimum age in your region). If we discover we've collected information from a child under 18, we'll delete it promptly. If you believe we hold data for someone under 18, please email us at [privacy@teamretro.com](mailto:privacy@teamretro.com).
## Social logins
You can register or log in with a social media account (like Google, Facebook, LinkedIn). In doing so, we may receive basic profile info (name, email, profile picture) from them. How they use your info is governed by their own privacy policies.
## Information sharing and disclosure
We **do not sell** your information to third parties. We only share data:
- **With your consent**
- **To comply with laws**
- **To protect rights and safety** (e.g. investigate fraud, address security or technical issues)
- **To enforce our terms**
- **With service providers** (e.g. payment processors, hosting partners) who follow our strict data protection rules
- **During a business transfer** (merger, acquisition, etc. with appropriate notice to you)
Any content you share in collaborative workspaces is visible to other invited participants.
## Email communications and marketing
We may email you to:
- Respond to questions or requests
- Share product or service updates
- Provide subscription info
We follow relevant laws (like the Australian Spam Act 2003 and US CAN-SPAM Act). We **do not** use false or misleading subjects, and we always include an easy way to unsubscribe. If you wish to stop receiving marketing emails, use the unsubscribe link in our messages or contact us at [info@teamretro.com](mailto:info@teamretro.com).
## Data retention
We keep your personal information only as long as needed to provide our service or as required by law.
- **User-generated content** stays until you or your administrator delete it, or until your account is deleted.
- **Expired trial accounts** are automatically deleted 365 days after the trial ends.
- **Canceled paid accounts** are automatically deleted 365 days after cancellation.
- **Transactional or billing data** may be retained for up to 7 years (to meet legal requirements).
### How and when we delete your data
You can request deletion of your account or data at any time — from within the application, or by emailing [info@teamretro.com](mailto:info@teamretro.com). Here's exactly what happens:
1. **Within 30 days of your request**, we delete your data from our live systems.
2. **For up to a further 30 days**, copies may remain in our encrypted backups, which exist only for disaster recovery. They are automatically overwritten on our normal backup cycle and are never used for any other purpose.
So in the worst case, your data is fully removed — including from backups — **within 60 days** of your request. Expired trials and canceled accounts follow the same process automatically once their 365-day retention period ends.
## Data security
We protect your data with technical and organizational measures, including encryption (SSL/TLS) and secure hosting. We use Amazon Web Services (AWS) for data hosting, with US and EU environments. Although we work hard to protect your data, the internet is never 100% secure.
For more on AWS's GDPR compliance, visit [AWS GDPR Center](https://aws.amazon.com/compliance/gdpr-center/).
For details on our security measures, see [TeamRetro Security](/security/).
## International data transfers
We operate separate server environments in the United States (US) and the European Union (EU). Generally, if you (or your organization) choose our **US region**, your information will be stored and processed on servers in the US. If you choose our **EU region**, your information will be stored and processed on servers in the EU. However, we may still transfer your data to other countries if it is necessary for providing our services (for example, when engaging certain service providers).
For users located in the European Economic Area (EEA), any transfer of personal data outside the EEA is protected by appropriate safeguards, such as **Standard Contractual Clauses**. You may request a copy of our Data Processing Agreement, which includes these clauses and explains how we protect your data during international transfers, by contacting us at [privacy@teamretro.com](mailto:privacy@teamretro.com).
## Third-party websites
Our Site may link to external websites or applications. We're not responsible for how these third parties handle your data. This privacy policy applies only to data we collect. Review the privacy policies of any external sites you visit.
## Your privacy rights
### General
You can review, change, or delete your account information anytime by:
- Logging into your account and updating settings
- Contacting us at [info@teamretro.com](mailto:info@teamretro.com)
If you unsubscribe from marketing emails, we may still send you essential account-related emails.
If you have any privacy-related concerns, please contact our Data Protection Officer at [privacy@teamretro.com](mailto:privacy@teamretro.com). We'll investigate and respond in a timely manner.
### EU/UK residents
Under the General Data Protection Regulation (GDPR) and UK GDPR, you may have the right to:
- **Access** your personal information
- **Request correction** of inaccuracies
- **Request deletion** of your data
- **Restrict or object** to certain processing
- **Data portability** (receive a copy in a portable format)
We value your privacy and your rights as a data subject and have therefore appointed Prighter Group with its local partners as our privacy representative and your point of contact for the following regions:
- United Kingdom (UK)
- European Union (EU)
Prighter gives you an easy way to exercise your privacy-related rights (e.g. requests to access or erase personal data). To contact us through our representative, Prighter, or to exercise your data subject rights, visit [prighter.com](https://app.prighter.com/portal/11059092).
**Making a complaint to us.** If you are unhappy with how we have handled your personal data, you have the right to complain to us directly. Email our Data Protection Officer at [privacy@teamretro.com](mailto:privacy@teamretro.com), or use the complaint form provided by our privacy representative, Prighter, at [prighter.com](https://app.prighter.com/portal/11059092). We will acknowledge your complaint within 30 days of receiving it, investigate it without undue delay, and inform you of the outcome.
You can also lodge a complaint with a supervisory authority at any time — in the UK, the Information Commissioner's Office (ICO); in the EU, your local Data Protection Authority — particularly if you are not satisfied with how we have dealt with your complaint.
### Australian residents
We comply with the Australian Privacy Principles. You can request:
- **Access** to personal information we hold
- **Corrections** if data is incorrect
If you have any complaints about our handling of your data, contact us or the Office of the Australian Information Commissioner (OAIC).
### California residents
You have rights under the California Consumer Privacy Act (CCPA) and California Privacy Rights Act (CPRA), such as:
- **Right to know/access**
- **Right to delete**
- **Right to correct**
- **Right to opt out of sharing/sale** of personal information
- **Right to limit use of sensitive personal information**
- **Right to non-discrimination** for exercising your privacy rights
You can exercise these rights by emailing [info@teamretro.com](mailto:info@teamretro.com). If you use an authorized agent, we may require proof of authorization.
## Updates to this policy
We may update this privacy policy from time to time. The "last revised" date at the top tells you when changes were made. If changes are significant, we may notify you via email or by posting a notice on our site. We recommend reviewing this policy periodically.
**June 2026** – Added the right to complain to us directly about how we handle your personal data, in line with the UK Data (Use and Access) Act 2025. Updated revision date.
**February 2026** – Updated minimum age requirement to 18 years for consistency across our terms. Updated revision date.
## Contact Us
If you have questions about this privacy policy or wish to submit a request, please contact:
Chief Privacy Officer
GroupMap Technology Pty. Ltd.
Level 1/931 Albany Highway
East Victoria Park WA 6100
Australia
[privacy@teamretro.com](mailto:privacy@teamretro.com)
For general inquiries about TeamRetro, email us at [info@teamretro.com](mailto:info@teamretro.com) or write to the address above.
Thank you for trusting TeamRetro. We appreciate your confidence and take every step to safeguard your privacy.
---
# U.S. State Privacy Notice
URL: https://www.teamretro.com/privacy/us-state-privacy/
## Your Privacy Rights as a U.S. Resident
At TeamRetro, we respect your privacy and are committed to transparency in how we handle your personal data. A growing number of U.S. states have enacted consumer privacy laws that give their residents specific rights over their personal information. This notice explains those rights and how to exercise them. It supplements our full [Privacy Policy](/privacy/).
If your state is not listed below, you still have the protections described in our [Privacy Policy](/privacy/), and you are welcome to contact us with any privacy request.
## California (CCPA / CPRA)
If you are a California resident, you have specific rights under the **California Consumer Privacy Act (CCPA)** as amended by the **California Privacy Rights Act (CPRA)**.
### 1. Right to Know / Access
You have the right to request details about the personal information we have collected, including:
- Categories of personal information we collect
- Specific pieces of personal information we hold about you
- Sources from which we collect personal information
- Business or commercial purposes for collecting personal information
- Categories of third parties with whom we share your personal information
### 2. Right to Delete
You may request the deletion of personal information we have collected, subject to certain legal and operational exceptions.
### 3. Right to Correct
You have the right to request corrections to inaccurate personal information we maintain about you.
### 4. Right to Opt Out of Sale or Sharing
TeamRetro **does not sell** your personal information. However, you may opt out of any data-sharing practices that could be considered a “sale” under CCPA.
### 5. Right to Limit Use of Sensitive Personal Information
If we process sensitive personal information, you can request to limit its use to what is necessary to provide our services.
### 6. Right to Non-Discrimination
You have the right not to receive discriminatory treatment for exercising any of your privacy rights. This means we will not deny you services, charge you different prices, or provide a different level of service based on your privacy choices.
## Other U.S. States
Residents of certain other states have comparable rights under their own consumer privacy laws — including **Virginia** (VCDPA), **Colorado** (CPA), **Connecticut** (CTDPA), **Utah** (UCPA), **Texas** (TDPSA), **Oregon** (OCPA), and **Montana** (MCDPA), among others taking effect over time. While the details differ by state, these laws generally give you the right to:
- **Access / confirm** whether we process your personal information and obtain a copy of it
- **Correct** inaccuracies in the personal information we hold about you
- **Delete** personal information we have collected about you, subject to legal exceptions
- **Opt out** of the sale of personal information and of targeted advertising or profiling, where applicable
- **Appeal** a decision we make about a privacy request (in states that provide an appeal right)
- **Non-discrimination** for exercising any of these rights
As noted above, TeamRetro **does not sell** your personal information and does not use it for targeted advertising or for profiling that produces legal or similarly significant effects.
### State rights at a glance
| State | Law | Access | Correct | Delete | Opt out of sale / targeted ads | Appeal |
| :-- | :-- | :--: | :--: | :--: | :--: | :--: |
| California | CCPA / CPRA | Yes | Yes | Yes | Yes | — |
| Virginia | VCDPA | Yes | Yes | Yes | Yes | Yes |
| Colorado | CPA | Yes | Yes | Yes | Yes | Yes |
| Connecticut | CTDPA | Yes | Yes | Yes | Yes | Yes |
| Utah | UCPA | Yes | — | Yes | Yes | — |
| Texas | TDPSA | Yes | Yes | Yes | Yes | Yes |
| Oregon | OCPA | Yes | Yes | Yes | Yes | Yes |
| Montana | MCDPA | Yes | Yes | Yes | Yes | Yes |
This table is a summary; the exact scope of each right is governed by the applicable state law.
## How to Exercise Your Rights
To make a request related to your personal information, please contact us:
- **Email**: [privacy@teamretro.com](mailto:privacy@teamretro.com)
- **Mailing Address**: Chief Privacy Officer
GroupMap Technology Pty. Ltd.
Level 1/931 Albany Highway
East Victoria Park WA 6100
Australia
If you submit a request, we may need to verify your identity before processing it. This is to ensure that your personal information is protected and that requests are valid. We may require:
- A government-issued ID or other proof of identity
- A signed declaration verifying your request
- If using an authorized agent, written proof of their authority
If we decline your request, you may — in states that provide an appeal right — ask us to reconsider by replying to our response or contacting us at the address above.
## Data Categories We Collect
Below are the categories of personal information we collect, as defined by these laws:
| Category | Examples | Collected? |
| :-- | :-- | :-- |
| Identifiers | Name, email, IP address | Yes |
| Commercial Info | Payment details, purchase history | Yes |
| Internet Activity | Interactions with our site | Yes |
| Geolocation Data | IP-based location | Yes |
| Professional Data | Employment details (if provided) | Yes |
| Sensitive Data | Not actively collected unless user-provided | No |
## Updates to This Notice
We may update this notice as needed to reflect changes in our data practices or in applicable state privacy laws. The “Last revised” date at the top of this page indicates when this notice was last revised.
For more information about our overall data practices, please review our full [Privacy Policy](/privacy/).
**TeamRetro is committed to protecting your privacy and ensuring you have control over your personal data. If you have any questions, feel free to reach out to us at [privacy@teamretro.com](mailto:privacy@teamretro.com).**
---
# Terms of Service
URL: https://www.teamretro.com/terms-of-service/
## 1. Introduction
Thank you for visiting TeamRetro. We are a service enabling team agile retrospectives, health checks, estimations, action planning, and improving meeting outcomes.
This agreement below refers to all online subscriptions only. Please [contact us](/contact-us/) if your organization requires an enterprise agreement, service level agreement or Data Processing Agreement (DPA) instead.
Please read this agreement carefully — you must agree to all terms completely (as well as our other legal documents such as our [privacy policy](/privacy/) and [responsible use of AI](/responsible-ai/)) as they constitute a contract between you and us GroupMap Technology Pty Ltd, the company behind TeamRetro, which you agree to be bound by as a condition of accessing our site and service. For information relating to our security policies and procedures, please visit [www.teamretro.com/security](/security/).
## 2. Definitions
Throughout this agreement, we may use certain words or phrases, and it is important that you understand the meaning of them. This list isn't comprehensive, but it is helpful:
- Agreement means these terms of service.
- GroupMap, us, we, our refers to our company, [GroupMap Technology Pty Ltd.](https://www.groupmap.com/)
- The site refers to our website, [teamretro.com](https://www.teamretro.com/).
- TeamRetro, service refers to our site and any services we provide through our site, including our meeting software and any other software we may provide.
- User refers to anyone who trials or purchases our service and general visitors to our site.
- You, your refers to you, the person entering into this agreement with us, and includes the organization, if any, that you are signing up to TeamRetro.
## 3. What is TeamRetro?
TeamRetro is a SaaS (software-as-a-service) tool for facilitating online retrospective meetings, health checks, estimations and tracking the resulting team actions and meeting outcomes. Our service guides you and your team through the process of brainstorming, grouping, voting and actioning ideas; then provides ongoing tracking of the agreed actions and team agreements.
## 4. Eligibility
To use our service, you must meet a number of conditions, including but not limited to:
- You must not violate any embargoes, export controls, or other laws of Australia or other countries having jurisdiction over this agreement, GroupMap Technology Pty Ltd, and yourself. Please visit the website of the Australian government's [Department of Foreign Affairs and International Trade](https://www.dfat.gov.au/international-relations/security/sanctions) for more information.
- You must be the minimum age required to enter into a contract in the area where you reside and, in any event, must be at least 18 years of age.
- You must, if signing up on behalf of an organization, be authorized by that organization to create a TeamRetro account (usually, the person(s) who exercise(s) the executive functions of an organization will have this authority, but you must verify it with your appropriate superiors, if any).
- You must provide us with personal information, payment information, and other information that we deem necessary to provide you with our service.
## 5. Nature of service
TeamRetro is an intermediary designed to bring you and your team members together. We do not make any representations about the effectiveness of our service or any ideas produced within TeamRetro by the mere fact that they arose from using TeamRetro. You agree that you are solely responsible for the use of any ideas or discussions, regardless of whether they occurred within TeamRetro or elsewhere.
## 6. License to use
Once you have signed up to TeamRetro, additional rules govern the use of our service. You must NOT:
- Violate the laws of Australia, its states or territories, or any foreign political entity having jurisdiction over this agreement, whether or not the foreign political entity is a country or a subdivision (such as a state or province) or municipality (such as a city, town, county, or region) of a foreign country.
- Post or send anything violent, threatening, pornographic, racist, hateful, or otherwise objectionable according to the opinion of GroupMap Technology Pty Ltd or our delegates.
- Be fraudulent or negligent in your representations to us, our delegates, or any other third party.
- Infringe on anyone's intellectual property rights, defame anyone, impersonate anyone, or otherwise violate the rights of a third party.
- Hack, crack, phish, SQL inject, or otherwise compromise the security or integrity of our service or its users' computers.
- Do anything else which, at our sole discretion, may bring TeamRetro or us into disrepute.
- Establish false/fake accounts or create multiple accounts.
- Share your login and account details with others, or permit others without licenses to use your account.
- Create shared email administration accounts with multiple people within an organization.
- Sub-license, sell the right to use or create maps for the use of others who do not have an active subscription or license.
## 7. Payments, billing & refunds
Certain portions of TeamRetro's service require a subscription to be paid in advance to access those portions. Payment for TeamRetro's service may be made by credit card or electronic funds transfer.
Pricing and terms for various services shall be made available on our site. Where pricing and terms conflict between our site, this agreement, and some other information we provided, the pricing and terms most favorable to us shall take precedence.
Subscriptions will be renewed at the beginning of each billing period and may be canceled at any time before the commencement of the next billing period to avoid a recurring payment. Should you cancel within a current period, your account will remain active until the end of the billing period paid for. If you decide to upgrade your subscription plan, we will credit the unused portion of your current month on a pro-rata basis, though we will not do the same if you downgrade.
We do not provide refunds on prepaid subscription plans where the billing period has passed. We are entitled to recover any loss amounts if there are any chargebacks due to client error or not providing the correct credit card details.
Where applicable, Goods and Services Tax (GST) or equivalent taxes are determined based on the billing address and information provided by the customer at the time of signup or as subsequently updated.
## 8. Discounts
We may, but are not obligated to, provide discounts for any reason. The discounts provided will be made according to the information published on our site. If any information conflicts, the terms most beneficial to us shall take effect.
We may refuse to provide such discounts for any reason including, but not limited to, fraud, mistake on the part of our publication of information, actual or expected financial hardship, sale of all or part of our business, or any other reason.
## 9. Chargebacks, credit card cancellations, and similar actions
When you provide payment to us, and that amount of money is subsequently taken from us due to a chargeback, credit card cancellation, or other action that is your fault, we are entitled to recover that amount from you. In the event of such payment reversals, the onus will be on you to prove the event was not your fault.
## 10. Interruptions possible
Our service may be interrupted at any time for server maintenance, security purposes, business purposes, or any other reason we deem advisable. If we have advance notice of such downtime, we will usually attempt to notify you, but we make no promises that we will do so as it may sometimes be necessary to not notify users (such as for security purposes), or be unreasonably burdensome upon us to do so. You therefore acknowledge and agree that our service may not always be available and that this will not impose any liability on us for refunds for non-delivery of our service if it occurs for less than twelve consecutive hours. For any greater loss of service time, we may refund subscriptions for non-provided days on a pro-rata basis.
## 11. Our copyright
Our copyright is important to us, as is our server bandwidth. You agree not to copy, distribute, display, disseminate, or otherwise reproduce any of the information on the site without receiving our prior written permission, even if it would otherwise constitute fair use or be otherwise legally permissible (you may, of course, copy such legal material if you get it from another source than our server). Material that arises from discussions or other brainstorming activities using our service is permitted to be reproduced elsewhere as long as the authors or other owners of such material have authorized you to reproduce it, and you are not otherwise barred by law from doing so.
## 12. Your copyright
We must be assured that it has the right to use the content posted to our site by its users. Such content may include but is not limited to, photographs, videos, text, audio, and other materials. By submitting content to the service, you grant GroupMap Technology Pty Ltd a non-exclusive, worldwide license to use, store, and process your content solely for the purpose of providing, maintaining, and improving the service. This license terminates when your content is deleted from the service, subject to the backup retention period described in the [privacy policy](/privacy/) (deletion from live systems within 30 days of a request, with copies remaining in backups for up to a further 30 days). You warrant to us that you have the right to grant us this license over the content, that you will indemnify us for any loss resulting from a breach of this warranty, and defend us against claims regarding the same.
## 13. Trademarks
"TeamRetro" and "GroupMap" are trademarks used by us, GroupMap Technology Pty Ltd, to uniquely identify our site, service, and businesses. You agree not to use this phrase anywhere without our prior written consent. Additionally, you agree not to use our trademark or copy the look and feel of our website or its design without our prior written consent. You agree that this paragraph goes beyond the governing law on intellectual property law and includes prohibitions on any competition that violates the provisions of this paragraph, including starting your own business, which competes directly or indirectly with us.
## 14. Revocation of consent
We may revoke our consent for your use of our intellectual property or any other permission granted under this agreement at any time. You agree that if we so request, you must take immediate action to remove any usage of our intellectual property that you may have engaged in, even if it would cause a loss to you.
## 15. Copyright & trademark infringement
Users must not post any information that infringes on anyone's copyright, but it may happen. We take copyright infringement very seriously, and although we do not concede that we are subject to the jurisdiction of the United States courts, we have registered a Copyright Agent with the United States Copyright Office to provide us with an additional safe harbor for attempted copyright actions in that country, as it limits our liability under the Digital Millennium Copyright Act. If you believe that your copyright has been infringed, please send us a message which contains:
- Your name.
- The name of the party whose copyright has been infringed, if different from your name.
- The name and description of the work that is being infringed.
- The location on our site of the infringing work.
- A statement that you have a good faith belief that the use of the copyrighted work described above is not authorized by the copyright owner (or by a third party who is legally entitled to do so on behalf of the copyright owner) and is not otherwise permitted by law.
- A statement that you swear, under penalty of perjury, that the information contained in this notification is accurate and that you are the copyright owner or have an exclusive right in law to bring infringement proceedings with respect to its use.
- You must sign this notification and send it to us at [info@teamretro.com](mailto:info@teamretro.com). Since we prefer that you send the notification by email, an electronic signature is acceptable. We recommend that you send us similar information to that above in regard to any allegation of trademark infringement, and we will address it as soon as practicable. By submitting a takedown notice which follows the above DMCA format, you agree to hold us harmless for any damages for intellectual property infringement against you that may have been committed by a third party on our site or service, regardless of in which court you may have brought suit against us.
If you do not use the above DMCA format, you agree to submit irrevocably and exclusively to the jurisdiction of Australia's courts and laws by sending us a takedown notice in any form, in relation to the subject matter of that takedown notice.
## 16. Representations & warranties
We make no representations or warranties as to the merchantability of our service or fitness for any particular purpose. You agree that you are releasing us from any liability that we may otherwise have to you in relation to or arising from this agreement or our services for reasons including, but not limited to, failure of our service, negligence, or any other tort. To the extent that applicable law restricts this release of liability, you agree that we are only liable to you for the minimum amount of damages that the law restricts our liability to if such a minimum exists.
We are not responsible in any way for damages caused by third parties who may use our services, including but not limited to people who commit intellectual property infringement, defamation, tortious interference with economic relations, or any other actionable conduct towards you.
We are not responsible for any use of the information generated or disseminated using our services, nor are we liable for any damages which arise from the proper or improper use of our service, including any altered version of our service.
We are not responsible for any failure on the part of a payment processor, including the credit company or bank that you use, to direct payments to the correct destination or any actions on their part in placing a hold on your funds.
We are not responsible for any failure on your part to provide a computer system adequate for the purpose of running our software. Please ensure you have up-to-date software and hardware before purchasing our service.
We are not liable for any failure of the services of our company or a third party, including any failures or disruptions, untimely delivery, scheduled or unscheduled, intentional or unintentional, on our site which prevents access to our site temporarily or permanently.
The provision of our service to you is contingent on your agreement with this and all other sections. Nothing in the provisions of this "Representation and Warranties" section shall be construed to limit the generality of the first paragraph of this section.
For jurisdictions that do not allow us to limit our liability: Notwithstanding any provision of this agreement, if your jurisdiction has provisions specific to waiver or liability that conflict with the above, then our liability is limited to the smallest extent possible by law. Specifically, in those jurisdictions not allowed, we do not disclaim liability for:
1. Death or personal injury caused by its negligence or that of any of its officers, employees or agents.
2. Fraudulent misrepresentation.
3. Any liability that is not lawful to exclude now or in the future.
## 17. Indemnity
You agree to indemnify and hold us harmless for any claims by you or any third party which may arise from or relates to this agreement or the provision of our service to you, including any damages caused by your use of our website or acceptance of the offers contained on it. You also agree that you have a duty to defend us against such claims, and we may require you to pay for an attorney(s) of our choice in such cases. You agree that this indemnity requires you to pay for our reasonable attorneys' fees, court costs, and disbursements. In the event of a claim such as the one described in this paragraph, we may elect to settle with the party/parties making a claim, and you shall be liable for the damages as though we had proceeded with a trial. If you and a third party (such as another user) both incur the kinds of claims mentioned in this paragraph against us through a combination of your activities (such as while both brainstorming together on TeamRetro), you agree that you shall be jointly and severally liable for the kind of indemnity mentioned herein.
## 18. Choice of law
This agreement, and any disputes relating to TeamRetro or GroupMap in general, shall be governed by the laws in force in the Commonwealth of Australia. The offer and acceptance of this contract are deemed to have occurred in the Commonwealth of Australia.
## 19. Forum of dispute
You agree that any dispute arising from or relating to this agreement, TeamRetro, or GroupMap will be heard solely by a court of competent jurisdiction in the Commonwealth of Australia. Specifically, where the subject matter of a dispute is eligible, you agree that any disputes shall be held solely within the lowest court that has the authority to hear your claim ("Small Claims Court"). Depending on your jurisdiction, this will often be handled by a lower level of the "Civil and Administrative Tribunal." Where you do not otherwise have any nexus to an Australian state or territory, you agree that any disputes will be brought within Western Australia.
If a dispute claims multiple claims and one or more of those claims would be eligible to be heard by the Small Claims Court, you agree not to bring the other claims against us and to proceed instead within the Small Claims Court.
If you would be entitled in a dispute to an amount exceeding the monetary jurisdiction of the Small Claims Court, you agree to waive your right to collect any damages in excess of the monetary jurisdiction and instead still bring your claim within the Small Claims Court. In other words, if you believe we owe you $15,000, but the state or territorial Small Claims Court that has jurisdiction has a limit of $10,000, you would only sue us for $10,000 and waive the extra $5,000.
You agree that if a dispute is eligible to be heard in Small Claims Court but you would be entitled to an additional or alternative remedy in a higher court, such as injunctive relief, you will waive your right to that remedy and still bring the dispute within the Small Claims Court.
If you bring a dispute in a manner other than in accordance with this section, you agree that we may move to have it dismissed and that you will be responsible for our reasonable attorneys' fees, court costs, and disbursements in doing so.
Except for the case envisioned in the above paragraph (where you bring a dispute in violation of this agreement), you agree that the attorneys' fees, court costs, and disbursements relating to a case will be awarded according to the rules of the court in which the case is brought.
## 20. Force majeure
You agree that we are not responsible to you for anything that we may otherwise be responsible for if it is the result of events beyond our control, including, but not limited to, acts of God, war, insurrection, riots, terrorism, crime, labor shortages (including lawful and unlawful strikes), embargoes, postal disruption, communication disruption, unavailability of payment processors, failure or shortage of infrastructure, shortage of materials, or any other event beyond our control.
## 21. Severability
In the event that a provision of this agreement is found to be unlawful, conflicting with another provision of the agreement, or otherwise unenforceable, the agreement will remain in force as though it had been entered into without that unenforceable provision being included in it.
If two or more provisions of this agreement are deemed to conflict with each other's operation, we shall have the sole right to elect which provision remains in force.
## 22. Non-waiver
We reserve all rights afforded to us under this agreement and the provisions of any applicable law. Our non-enforcement of any particular provision or provisions of this agreement or any applicable law should not be construed as our waiver of the right to enforce that same provision under the same or different circumstances at any time in the future.
For example, if someone violates our rules, and you hear that we didn't do anything about it, this does not mean you can violate our rules, too. Also, if you violate our rules and we don't do anything about it, it doesn't mean we can't take action against you the next time you do it (or within the limitation period that applies to the first time you did it, but a bit later on).
The above being said, it is important to abide by this agreement at all times, regardless of how we may choose to enforce it.
## 23. Termination & cancellation
We may terminate your account or access as well as access to our site and service to you at our discretion without explanation, though we will strive to provide a timely explanation in most cases. Our liability for refunding you, if you have paid anything to us, will be limited to the amount you paid for goods or services which have not yet been and will not be delivered, except in cases where the termination or cancellation was due to your breach of this agreement, in which case you agree that we are not required to provide any refund or other compensation whatsoever.
Under no circumstances, including termination or cancellation of our service to you, will we be liable for any losses related to actions of other users, such as conduct which occurs during brainstorming sessions.
If your account is canceled or your trial expires, your account and its data are automatically deleted 365 days later. You can also request earlier deletion at any time — see the [privacy policy](/privacy/) for the exact deletion timelines.
Please note that although we may terminate the provision of our service to you, this agreement will still remain in effect. For example, you will stop paying for our service and receiving the ability to access our service, but you will still be responsible for indemnifying us for any claims which might have arisen from your activities while you were using our service.
## 24. Assignment of rights
You may not assign your rights and/or obligations under this agreement to any other party without our prior written consent. We may assign our rights and/or obligations under this agreement to any other party at our discretion.
## 25. Amendments
We may amend this agreement from time to time. We will notify you of a significant change when we amend this agreement. If you do not agree to the changes, you must cease using our site and service immediately and inform us of your non-agreement with sufficient information to identify your account at [info@teamretro.com](mailto:info@teamretro.com) so we may disable your account.
## 26. Australian consumer law
In addition to complying with Californian consumer laws, our service also complies with Australian Consumer Law. You may read more about your rights when purchasing and using our service by visiting [www.consumerlaw.gov.au](https://www.consumerlaw.gov.au/). If you have any questions or concerns about our service, you may contact us at [info@teamretro.com](mailto:info@teamretro.com).
## 27. Corporate information
GroupMap Technology Pty Ltd is a proprietary limited company domiciled in the State of Western Australia and doing business under Australian Business Number 95 160 220 520. For our detailed corporate contact information or to confirm that we are in good standing, please look us up on the [Australian Business Register](https://abr.business.gov.au/ABN/View?abn=95160220520).
## 28. Confidentiality obligations
**Definitions.** "confidential information" means information designated by the party disclosing such information ("disclosing party") as "confidential" or "proprietary" or that a reasonable person would understand to be confidential given the nature of the information and the circumstances of the disclosure. Your confidential information includes any information uploaded to the site. Our confidential information includes any information related to the site's performance, functionality, and reliability.
Confidential information does not include information that:
1. Is or becomes generally known to the public through no fault of the party that receives such information from the disclosing party ("receiving party");
2. Is in the receiving party's possession prior to receipt from the disclosing party;
3. Is acquired by the receiving party from a third-party without breach of any confidentiality obligation to disclosing party; or
4. Is independently developed by receiving party without reference to the disclosing party's confidential information.
**Obligations**. Confidential information is and will remain the exclusive property of the disclosing party. The receiving party will:
1. Use disclosing party's confidential information solely for the performance of the activities contemplated by these terms of service;
2. Disclose such information only to its employees, agents, and contractors who are bound by obligations of confidentiality at least as strict as those contained in this section
3. Protect disclosing party's confidential information against unauthorized use or disclosure using the same degree of care it uses for its own confidential information, which in no event will be less than reasonable care; and
4. Upon written request, return or destroy all copies of the disclosing party's confidential information in its possession or control.
## 29. Customer support and hours of service
We are here to help you where we can in using our service. You can email us at anytime at [info@teamretro.com](mailto:info@teamretro.com). We will aim to respond to you within 8 hours or less. Our general support hours for online subscriptions are 7 days a week from 9AM to 9PM WST. You can also access our [help and support articles](https://help.teamretro.com/) at any time or schedule a meeting as needed.
## History of changes
**April 2023** – Simplifying sentences and clarification of customer support and hours of service.
**February 2026** – Added clarification on GST determination based on billing address. Updated link to security page and expanded definition of services provided. Clarified that the license you grant us to your content is limited to providing and maintaining the Service. Updated terminology references for consistency with our privacy policy.
---
# EasyRetro alternative: TeamRetro vs Easy Retro compared
URL: https://www.teamretro.com/compare/easyretro-alternative/
An EasyRetro alternative comparison: what Easy Retro does better, what TeamRetro adds, and who should stay put. Sources checked September 2026.
---
# Echometer Alternative: Scheduled Retros
URL: https://www.teamretro.com/compare/echometer-alternative/
Echometer's retros still start manually and it isn't SOC 2 certified. TeamRetro adds recurring retro scheduling, 275+ templates, planning poker and SOC 2 Type 2 security. Try it free.
---
# GoRetro Alternative: Team Health Checks
URL: https://www.teamretro.com/compare/goretro-alternative/
GoRetro tracks team happiness but skips structured health checks. TeamRetro adds health-check models, scheduled retros, AI summaries and integrations.
---
# Ideaboardz Alternative with Health Checks
URL: https://www.teamretro.com/compare/ideaboardz-alternative/
Ideaboardz is free but stops at basic boards with no integrations or security. TeamRetro adds health checks, scheduled retros, AI summaries and SOC 2 hosting.
---
# Compare Retrospective Tools | TeamRetro
URL: https://www.teamretro.com/compare/
## What to weigh when you compare retrospective tools
The right retrospective tool depends on how your team actually runs its retros.
A few things are worth comparing side by side before you commit:
- **Templates and facilitation**: enough formats to keep retros from going stale,
with guided steps so anyone on the team can run one.
- **Anonymity and voting**: honest input depends on people feeling safe. Check
whether anonymity and independent voting come on every plan or only higher tiers.
- **Health checks**: tracking team health over time is what separates a
continuous-improvement tool from a retro board you fill in once a sprint.
- **Integrations**: Jira, Slack and Teams, so the actions you agree on land where
the work actually happens.
- **Pricing model**: per team versus per user changes the cost a lot as you grow.
- **Security and privacy**: one team doing client work has as much to protect as fifty.
Look for SSO and a choice of hosting region on the plan you'd buy, backed by a SOC 2
audit.
Each comparison above puts TeamRetro next to a specific tool on these points (feature
tables, pricing and what teams say) so you can decide with the detail in front of you
rather than a marketing claim.
Not sure which pair to open first? Start with what separates
[retrospective tools](/retrospective-tool/) from each other, then come back for the
head-to-head.
Want a broader view first? See our roundup of [the best retrospective tools for agile
teams](/blog/best-retrospective-tools/).
---
# Kollabe Alternative with Health Checks
URL: https://www.teamretro.com/compare/kollabe-alternative/
Kollabe has no health-check model or SOC 2 certification. TeamRetro adds team health checks, 275+ templates and SOC 2 security.
---
# Miro Alternative for Retrospectives
URL: https://www.teamretro.com/compare/miro-alternative/
Miro is a general whiteboard, not built for retros. TeamRetro has structured retrospectives, health checks, scheduled retros, AI grouping and SOC 2 certification.
---
# Mural Alternative for Retrospectives
URL: https://www.teamretro.com/compare/mural-alternative/
Mural is a general whiteboard, not built for retros. TeamRetro adds guided retrospectives, health checks, scheduled retros, AI grouping and SOC 2 certification.
---
# Neatro Alternative: Scheduled Retros & AI
URL: https://www.teamretro.com/compare/neatro-alternative/
Neatro has no scheduled retros, AI summaries or SOC 2 certification. TeamRetro adds scheduling, AI grouping and summaries, presentation mode and SOC 2 security.
---
# NimbleRetro Alternative — 275+ Templates
URL: https://www.teamretro.com/compare/nimbleretro-alternative/
NimbleRetro ships just four templates and charges per user. TeamRetro adds 275+ templates, health checks, AI insights and SOC 2 Type 2 security with unlimited users.
---
# Parabol Alternative: Priced Per Team
URL: https://www.teamretro.com/compare/parabol-alternative/
Parabol bills per user and its free tier limits teams fast. TeamRetro charges per team for unlimited users, with health-check trends, scheduled retros and 275+ templates.
---
# Reetro Alternative: Anonymity on Every Plan
URL: https://www.teamretro.com/compare/reetro-alternative/
Reetro keeps anonymous input on paid plans and isn't SOC 2 certified itself. TeamRetro gives anonymity on every plan, plus health checks, radars and SOC 2 security.
---
# Retrium Alternative with AI Grouping
URL: https://www.teamretro.com/compare/retrium-alternative/
Retrium's paid plans have no AI. TeamRetro offers 275+ templates, AI grouping and summaries, health checks and scheduled retros for less. Try it free.
---
# Retrospected Alternative with AI Grouping
URL: https://www.teamretro.com/compare/retrospected-alternative/
Switch from Retrospected to TeamRetro for 275+ templates, automated grouping, health checks, action tracking and SOC 2 Type 2 security on every plan. Try it free.
---
# Retros.work Alternative: SSO & Health Checks
URL: https://www.teamretro.com/compare/retroswork-online-retrospective-tool-alternative/
Switch from Retros.work to TeamRetro for 275+ retrospective templates, team health checks, AI grouping, SSO on every plan and SOC 2 Type 2 security. Try it free.
---
# RetroTeam is winding down. Here's the alternative
URL: https://www.teamretro.com/compare/retroteam-alternative/
RetroTeam has said it is winding down and moving on from retrospectives. Your retros, actions and agreements need somewhere settled to land: TeamRetro has 275+ templates, team health checks and SOC 2 Type 2.
---
# RetroTime Alternative with Health Checks
URL: https://www.teamretro.com/compare/retrotime-alternative/
Switch from RetroTime to TeamRetro for 275+ retrospective templates, health checks, automated grouping, action tracking and SOC 2 Type 2 security. Try it free.
---
# RetroTool Alternative for Jira, Slack & Teams
URL: https://www.teamretro.com/compare/retrotool-alternative/
RetroTool has no integrations, health checks or SOC 2. TeamRetro adds Jira, Slack and Teams integrations, health checks, AI grouping and SOC 2 Type 2 security.
---
# Reviews & Ratings from Agile Teams
URL: https://www.teamretro.com/compare/reviews/
[](https://reviews.capterra.com/products/new/35062843-3dc8-4bef-a877-2c34e0b8c9ff/)
[Capterra](https://reviews.capterra.com/products/new/35062843-3dc8-4bef-a877-2c34e0b8c9ff/)
[](https://crozdesk.com/software/teamretro/reviews/new)
[Crozdesk](https://crozdesk.com/software/teamretro/reviews/new)
[](https://www.g2.com/products/teamretro/review_modalities/new?source_type=stale_reviews_callout)
[G2](https://www.g2.com/products/teamretro/review_modalities/new?source_type=stale_reviews_callout)
[](https://g.page/r/Cf7vvNYpylIBEAI/review)
[Google](https://g.page/r/Cf7vvNYpylIBEAI/review)
[](https://slashdot.org/software/p/TeamRetro/reviews/new)
[Slashdot](https://slashdot.org/software/p/TeamRetro/reviews/new)
[](https://sourceforge.net/software/product/TeamRetro/reviews/new)
[SourceForge](https://sourceforge.net/software/product/TeamRetro/reviews/new)
[](https://www.trustpilot.com/review/www.teamretro.com)
[TrustPilot](https://www.trustpilot.com/review/www.teamretro.com)
---
# ScatterSpoke Alternative: Health Checks
URL: https://www.teamretro.com/compare/scatterspoke-alternative/
ScatterSpoke has no team health checks or radars. TeamRetro adds health-check models, radars, 275+ templates, AI grouping and SOC 2 Type 2 security on every plan.
---
# Metro Retro is now Spreo. Here is the alternative
URL: https://www.teamretro.com/compare/spreo-alternative/
Metro Retro became Ludi, then Spreo, and now sells itself as whiteboard software. TeamRetro is still built for retrospectives: guided stages, health checks, action carry-over.
---
# Sprintlio Alternative: Health Checks
URL: https://www.teamretro.com/compare/sprintlio/
Sprintlio has no free plan, health checks or scheduling. TeamRetro adds health-check models, scheduled retros, 275+ templates, AI grouping and SOC 2 Type 2 security.
---
# TeamRetro vs Sticky Notes: When Paper Retros Stop Scaling
URL: https://www.teamretro.com/compare/sticky-notes-alternative/
Sticky notes earned their place. Cheap, tactile, satisfying to peel, and they survive a power outage. We're not here to argue with that.
But somewhere between hybrid teams, action items that quietly vanish, and that one teammate whose handwriting nobody can read, a lot of retros have outgrown the wall. Here's what changes when yours moves into TeamRetro, and how the two compare, point for point.
---
# TeamRetro vs Parabol vs Retrium: which fits your team
URL: https://www.teamretro.com/compare/teamretro-vs-parabol-vs-retrium/
**The short answer:** all three run a solid online retrospective, and they differ most on pricing model, health checks and security. **Parabol** is open source, has a free tier and bills per active user. **Retrium** is retro-only, bills per room, and has no AI in its paid plans (a separate free AI rebuild, Retrium Next, is in open beta). **TeamRetro** is built around health checks you can trend over time and, on Enterprise, across teams, action follow-through and security on every plan: SOC 2 Type 2 and SAML SSO, at per-team pricing.
We're one of the three, so a note on method: every claim on this page comes from each vendor's public pricing and feature pages, checked in September 2026, with Parabol rechecked in October 2026.
## The three tools at a glance
From each vendor's public pricing and feature pages. Pricing examples assume three teams of about eight people.
| Features | TeamRetro | Parabol | Retrium |
| --- | --- | --- | --- |
| **Free option** | 30-day trial, no credit card | Free tier: 2 teams, 10 meetings/month, 30-day history | 30-day trial |
| **Pricing model** | Per team, no per-user fees, from $25/month | Per active user, from $8/user/month | Per team room, unlimited members, from $39/month |
| **Cost for 3 teams of 8** | $50/month (annual Small Organization plan) | ~$192/month | ~$117/month |
| **Retro templates** | Customizable, as many as you need | 40+ | 10+ (plus custom) |
| **Health checks** | First-class: custom models, radars, trends; cross-team reporting on Enterprise | Recurring check, 5 Likert questions per check across 5 fixed categories, five-check trend line; paid plans only | Team Radar with custom spokes |
| **AI features** | Grouping, summaries, suggested actions, sentiment | Grouping, summaries, discussion prompts, insights | None in the paid product; AI co-facilitator in the separate Retrium Next beta |
| **In-meeting AI assistant** | trAI, in the meeting side panel | Not offered | Only in the Retrium Next beta |
| **Action follow-through** | Action dashboard, carryover, propose-and-agree actions | Kanban task board, carryover, backlog write-back | Team-room action plan, carries forward |
| **Planning poker** | Included, plus a [free standalone tool](/free-planning-poker-for-agile-teams/) | Included (Sprint Poker) | Not offered |
| **Integrations** | Jira, Azure DevOps, GitHub, Linear, Trello, Confluence, Slack, Teams and more | Jira, GitHub, GitLab, Azure DevOps, Linear, Slack, Teams | Jira Cloud; Slack (beta) |
| **SAML SSO** | Every plan | Enterprise tier only | Business and Enterprise plans |
| **SOC 2** | Type 2, held directly | Yes | Yes |
| **Self-hosting** | No | Yes, open source (AGPL-3.0) | No |
## How the three differ
### Parabol
The only one of the three with an ongoing free tier, and the only one you can self-host, because it's open source under AGPL-3.0. It writes back to Jira, GitHub, GitLab, Azure DevOps and Linear, and offers AI summaries and grouping. Sprint Poker and async standups round out the ceremony stack.
Team Health, generally available since September 2026, is a recurring check built on five research-backed categories, with 10 question packs including Gallup Q12 and the Spotify squad model, and findings sync to the backlog as tasks.
The trade-offs: each check asks five Likert questions across the same five categories, it is English only, and organization-wide reporting is still listed as coming soon. Team Health is also paid-plans-only, so it is not part of the free tier. SAML SSO and SCIM sit on the Enterprise tier only, and per-user pricing grows with every person you add.
### Retrium
A library of retro techniques with an opinionated five-phase flow, built around the facilitator. Team Radar is its health check, with customizable spokes including psychological safety. Per-room pricing means unlimited users on every plan, and the persistent action plan carries between retros. Retrium Next, a free open beta, is its AI rebuild, separate from the paid product.
The trade-offs: no free tier, no AI in its paid plans, and integrations stop at Jira Cloud plus a beta Slack app. It's retro-only, with no planning poker or estimation, and its release notes stop at 2024.
### TeamRetro
Health checks are a first-class module: pick from 45+ models or build your own, then read the results as a radar, a trend line per dimension and, on Enterprise, a cross-team rollup. Actions get a dashboard, carryover and propose-and-agree flow so follow-through is visible. SOC 2 Type 2 and SAML SSO come on every plan, with audit logs and US/EU hosting. Customizable templates, AI grouping and summaries, planning poker and async daily standups included.
The trade-offs: no free tier, just a 30-day trial and then a paid plan. No self-hosted option, and SCIM plus the full account-level API are Enterprise-only.
## Which should your team pick?
**Parabol** is the only one of the three with a free tier and a self-hosted option. It bills per active user, so the cost grows with headcount, SAML SSO and SCIM sit on the Enterprise tier, and team health is paid-plans-only. See the deeper two-way look at [TeamRetro vs Parabol](/compare/parabol-alternative/).
**Retrium** is retro-only, with per-room pricing and no free tier. Its paid plans have no AI and no estimation, its integrations stop at Jira Cloud plus a beta Slack app, and its release notes stop at 2024. See the deeper two-way look at [TeamRetro vs Retrium](/compare/retrium-alternative/).
**Choose TeamRetro if** retrospectives are part of a wider improvement practice. If you're tracking [team health](/health-checks/) over time, need action items to actually get done between sprints, or have a security review to pass (SOC 2 Type 2, SAML SSO on every plan, audit logs) TeamRetro covers all three in one per-team price with no per-user fees. [Plans start at $25/month per team](/pricing/), with a 30-day trial and no credit card required.
---
# TeleRetro Alternative — Health-Check Radars
URL: https://www.teamretro.com/compare/teleretro-alternative/
TeleRetro offers pulse surveys but no team radars or SOC 2. TeamRetro adds health-check models and radars, AI grouping, 275+ templates and SOC 2 Type 2 security.
---
# Agile Coach Solution
URL: https://www.teamretro.com/solutions/agile-coach-solution/
## Engage with people, not tools
As an Agile Coach, your priority is guiding teams toward agile excellence, not wrangling with tools. TeamRetro simplifies the retrospective process so you can dedicate more time to coaching, mentoring, and facilitating meaningful conversations.
With automated processes and an intuitive interface, you can set up and manage retrospectives seamlessly, allowing you to invest your energy where it matters most: helping teams grow and succeed.
## Transform your retrospectives
Say goodbye to boring, repetitive, uneventful retrospectives. From a huge range of templates from our AI retro-verse and dynamic brainstorming sessions to simple but effective engagement tools to keep people focused, you’ll be taking your retros to the next level.
Check-in and check-out questions provide instant feedback, while team sentiment analysis helps you explore the mood and feelings shared during retrospectives based on the topics and ideas shared.
## Use AI to get fresh perspectives
With TeamRetro’s AI-powered features, retrospectives become smarter and more insightful.
Get automatic suggestions for discussion topics, data-driven summaries, and even new ideas to improve team dynamics.
Analyze feedback, highlight recurring themes, and present different perspectives, helping teams uncover blind spots and discover innovative solutions for ongoing challenges.
## Build team culture and safety
TeamRetro equips Agile Coaches with powerful tools to build team culture and psychological safety.
Anonymous feedback encourages open conversations, while team agreements ensure alignment and shared values.
Team health checks monitor well-being, and structured retrospectives provide a safe space for reflection. Play the observer role and provide neutral feedback to support team dynamics.
## Amazing features designed for Professional Agile Coach
Guide your teams to meaningful change with TeamRetro — turn retrospectives into actionable insights and build a culture of accountability. Coaching several teams at once? Ask [trAI](/ai/), the in-meeting assistant, to compare this session with the last one or pull up what a team said about a recurring theme, without breaking the conversation you're holding.
### Better agile meetings
Empower agile teams to collaborate in real-time, face to face, or remote.
### Guided facilitation process
Guide teams through structured and customizable templates.
### Observer role
Allow stakeholders to observe without direct participation.
### Track actions & agreements
Unite the team around shared goals. Visualize progress over time and keep accountability high.
### Team health & sentiment
Measure and track team health and sentiment trends over time to create happy productive teams.
### Cross-team insights
Compare data across teams to see where support is most needed and where they are thriving.
---
# Agile Transformation Solutions
URL: https://www.teamretro.com/solutions/agile-transformation-solution/
## Built in agile practices
With industry templates, guided facilitation, and built-in support, TeamRetro empowers teams to confidently run retrospectives and health checks.
Its simple UI and workflow help teams move from ideas to action, providing a consistent, time-efficient method that keeps everyone focused on continuous improvement.
## Align agile with business goals
Empower teams to connect their work directly to business goals, ensuring their energy and focus drive common delivery outcomes.
Effortlessly scale standardized, repeatable practices that accelerate delivery and enhance product quality.
## Drive continuous improvement
Efficient retrospectives and health checks enable teams and their supporters to quickly identify areas for improvement, implement changes, and measure success, fostering a culture of continuous learning.
Streamlined, standardized processes ensure teams follow a common structure, making it easier to compare results, share insights, and scale best practices across the organization.
## Get teams engaged and onboard
Create a safe space where everyone feels comfortable sharing their ideas with icebreakers, check-in and check-out questions, and built-in anonymity options.
Real-time meeting feedback, emojis, and reactions, along with the ability to suggest actions for improvement, keeps people engaged.
Plus, you can easily measure participation and engagement rates to pinpoint which teams are thriving and where additional support is needed.
## Get data-driven insights
Leverage data and insights to drive evidence-based discussions. From tracking actions and team health to improving meeting cadence and outcomes, you’ll get insight into how your team is progressing.
## Powerful features designed for Agile Transformation
Accelerate your Agile transformation with TeamRetro and improve collaboration, efficiency, and accountability across your teams.
### Organization-wide templates
Standardize templates across all teams for consistency.
### Meeting cadence
See how frequently teams are running their meetings.
### Action tracking
Track and manage progress on action items from retrospectives.
### Team health & sentiment
Measure and track team health and sentiment trends over time.
### Seamless integrations
Easily publish actions to your workflow tools and share outcomes. [More integrations.](/integrations/)
### High level security
Data protection and privacy with SOC 2 Type 2 and GDPR compliance.
---
# Engineering Managers Solution
URL: https://www.teamretro.com/solutions/engineering-managers-solution/
## Tailored templates for teams
TeamRetro offers a wide range of retrospective templates tailored to engineering teams. Customize topics, design and workflow to fit your teams.
Whether focusing on code quality, sprint reviews, or process improvements, you can select or create templates that fit your team’s specific needs, helping identify technical debt, bottlenecks, and areas for improvement.
## Cross-team collaboration
Engineering teams often need to collaborate across multiple functions or departments. TeamRetro makes it easy to coordinate retrospectives across different teams, fostering knowledge sharing, improving workflows, and ensuring alignment with larger engineering goals.
With engaging interfaces, open team transparency and the ability to create programs with multiple teams, you’ll enable easy cross-team collaboration.
## Create actionable outcomes
Turn discussions into results with action items that are tracked and prioritized within TeamRetro. Assign tasks directly from the retrospective and set clear due dates, ensuring accountability and follow-through on key improvements that will drive your team forward.
Whether you are integrating actions with your engineering tools like Jira or Github, or reviewing open actions from meeting to meeting, you will be giving people the chance to make real changes.
## Data-driven insights
From tracking action item completion rates to visualizing recurring issues, TeamRetro helps you turn qualitative feedback into actionable data, the why behind your [DORA metrics](/guides/agile-metrics/dora-metrics/).
View trends across multiple retrospectives, compare team progress, and align outcomes with project objectives. By using this data and your wider [agile metrics](/guides/agile-metrics/) to inform decisions, you can continuously fine-tune your processes and ensure your teams are always improving.
## Amazing features designed for Engineering Managers
Go beyond online whiteboards and physical sticky notes to real time collaborative retrospectives that will level up your team meetings.
### Organization-wide templates
Standardize templates across all teams for consistency.
### Power up with AI
Boost efficiency with suggested actions and instant meeting summaries.
### Team health and sentiment
Measure and track team health and sentiment trends over time.
### Track actions and agreements
Unite the team around shared goals, with retro and [daily standup](/standups/) actions on one list. Visualize progress over time.
### Explore word clouds
Discover common themes or recurring points of discussion across your teams meetings.
### Data driven insights
Identify patterns for continuous improvement and use metrics to optimize team effectiveness.
---
# Solutions for every team
URL: https://www.teamretro.com/solutions/
TeamRetro adapts to the way your team works. Whether you facilitate sprint retrospectives, coach across an organization, or lead projects, find the playbook that fits your role.
---
# Marketing, HR, Sales and Finance Solutions
URL: https://www.teamretro.com/solutions/marketing-hr-sales-and-finance-solutions/
## Agile marketing
Marketing teams worldwide have realized true benefits from the implementation of agile methods. TeamRetro helps agile marketing teams streamline retrospectives, optimize processes, and deliver stronger campaigns.
Whether you’re planning a product launch, reworking brand strategy, or optimizing lead generation, TeamRetro provides the tools you need to succeed.
## Agile HR
With customizable retrospective templates, feedback loops, and actionable insights, TeamRetro helps Agile HR teams continuously improve processes like recruitment, onboarding, and employee engagement.
Foster a culture of trust and psychological safety by using regular retrospectives and health checks to reflect, adapt, and evolve based on real-time feedback.
## Increase team engagement
Keep things fresh, novel and avoid meeting fatigue to keep engagement high. Create an engaging and collaborative space that allows everyone to contribute.
Build a psychologically safe space for open, honest communication and have your finger on the pulse of the team with real time feedback.
## Agile sales
Transform your sales team into an agile powerhouse with TeamRetro. Using customizable retrospectives, dynamic feedback tools, and actionable insights, TeamRetro helps Agile sales teams continuously refine their strategies, improve workflows, and boost performance.
By regularly reflecting on sales processes, team collaboration, and customer engagement, your team can adapt quickly and close more deals.
## Agile finance
Elevate your finance team with the power of agile retrospectives using TeamRetro. Tailored templates, real-time feedback, and actionable insights help Agile finance teams continuously improve financial planning, budgeting, and reporting processes.
Regular retrospectives enable your team to reflect, adapt, and streamline workflows to improve efficiency and accuracy.
## Save time and stress
When time is such a precious commodity, TeamRetro helps you make the most of this resource.
From guided facilitation to automated grouping and meeting summaries, the ability to customize steps and timers, you’ll be making the most of your time together.
## Amazing features designed for Marketing, HR, Sales and Finance teams
Equip cross-functional teams with TeamRetro to foster collaboration, unify goals, and propel agile success across your organization.
### Range of custom templates
Explore a wide variety of templates that are designed for your team.
### Collaborate in real time
Capture and discuss your team's ideas in real time, face to face or remotely.
### Make it anonymous
Promote psychological safety and engagement with anonymity options.
### Engage the team
Bring your meetings to life with Icebreakers, live reactions and check in questions.
### Track actions and agreements
Unite the team around shared goals. Visualize progress over time.
### Shareable summaries
Share customizable and AI-generated summaries with stakeholders so everyone stays in the loop.
---
# Project Managers Solution
URL: https://www.teamretro.com/solutions/project-managers-solution/
## Manage people, not tools
TeamRetro is designed to simplify the retrospective process, allowing you to focus on coaching your team and driving meaningful discussions.
With intuitive, user-friendly features, you can set up retrospectives quickly, automate reports, and dive straight into valuable conversations. The result? Less time on logistics and more time on fostering team success.
## Empower teams and build buy in
Want to build ownership and create engagement? TeamRetro encourages every team member to contribute ideas, raise concerns, and share insights in an inclusive environment.
Coordinate retrospectives across multiple teams or departments. Whether you manage one team or several, TeamRetro allows for seamless collaboration, encouraging knowledge sharing and cross-team alignment.
## Create actionable outcomes
Track and prioritize action items directly within TeamRetro. With seamless integration into your project management workflow, you can assign tasks, set due dates, and ensure accountability.
Use interactive features like anonymous feedback, polls, and brainstorming sessions to ensure everyone has a voice. When your team feels heard and engaged, they take greater ownership of outcomes, building trust and driving continuous improvement across every project phase.
## Get data-driven insights
From tracking action item completion rates to visualizing recurring issues, TeamRetro helps you turn qualitative feedback into actionable data.
View trends across multiple retrospectives, compare team progress, and align outcomes with project objectives. By using data to inform decisions, you can continuously fine-tune your processes and ensure your teams are always improving.
## Amazing features designed for Project Managers
Transform your project meetings into dynamic, collaborative sessions that inspire action. Achieve results with agility and confidence.
### Customizable templates
A range of ready to use customizable templates to help facilitate project discussions.
### Real-time collaboration
Save precious time. Capture and discuss your team’s ideas in real time.
### Track actions & agreements
Unite the team around shared goals. Visualize progress over time.
### Power up with AI
Boost efficiency with suggested actions and instant meeting summaries.
### Seamless integrations
Easily publish actions to your workflow tools and share outcomes. [More integrations.](/integrations/)
### Measure team and project health
Track team well-being early to boost performance and avoid risks.
---
# Scrum masters solution
URL: https://www.teamretro.com/solutions/scrum-masters-solution/
## Streamline your retrospectives
Easy planning and better facilitation saves you time and improves focus, honing in on what is important. Lead your team from thought to action with confidence.
Give your teams the chance to reflect on both positives and challenges and foster a balanced and constructive approach to improvement.
## Increase team engagement
Keep things fresh, novel and avoid meeting fatigue to keep engagement high. Create an engaging and collaborative space that allows everyone to contribute.
Build a psychologically safe space for open, honest communication and have your finger on the pulse of the team with real time feedback.
## Create actionable outcomes
Facilitate continuous improvement and guide the team to identify areas for improvement, with optional AI suggested actions.
Keep the team aligned and moving forward. Build buy-in for actions that drive change. Create accountability, ownership and reinforce a cycle of learning and growth.
## Save time and stress
When time is such a precious commodity, TeamRetro helps you make the most of this resource.
From guided facilitation to automated grouping and meeting summaries, the ability to customize steps and timers, you’ll be making the most of your time together.
## Get data-driven insights
Leverage data and insights to drive evidence based discussions. From tracking actions and team health to improving meeting cadence and outcomes, you’ll get insight into how your team is progressing.
## Amazing features designed for Professional Scrum Masters
Go beyond online whiteboards and physical sticky notes to real time collaborative retrospectives that will level up your team meetings. And when you'd rather facilitate than take notes, ask [trAI](/ai/), the in-meeting assistant, to summarize the themes so far or capture the action the team just agreed on.
### The perfect retro
Built-in templates, AI suggestions and community templates you can customize any way you like.
### Quickly group ideas
Get grouping suggestions for the team to review with just a click. (Powered by AI)
### Private Voting
Independent, unbiased voting to filter out the best ideas in the room, free from ego.
### Build your process
Go fast and furious, or deep dive with time-boxed activities you can customize.
### Integrations
Easily publish actions to your workflow tools and share outcomes. [More integrations.](/integrations/)
### AI Summaries and Actions
Create your own meeting summaries and get action ideas. (Powered by AI)
See all features
---
# Asana Integration
URL: https://www.teamretro.com/integrations/asana/
### Publish your TeamRetro retrospective action items as Asana tasks
Make sure your actions don’t fall by the wayside by publishing them directly to your teams’ existing [Asana](https://www.asana.com/) projects.
---
# Azure DevOps Integration
URL: https://www.teamretro.com/integrations/azure-devops/
### Publish your TeamRetro retrospective action items as Azure DevOps action items
Make sure your actions don’t fall by the wayside by publishing them directly to your teams’ existing [Azure DevOps](https://azure.microsoft.com/en-us/products/devops) projects.
### Estimate Azure DevOps work items as a team
Import the work items you’re planning into an [estimation session](/estimations/), run planning poker so every vote stays independent, and sync the agreed story points back to the work item. Azure DevOps holds the number the team actually agreed on, with no copy-paste and no separate spreadsheet.
---
# Basecamp Integration
URL: https://www.teamretro.com/integrations/basecamp/
### Publish your TeamRetro retrospective action items as Basecamp tasks in your To-do’s
Make sure your actions don’t fall by the wayside by publishing them directly to your teams’ existing [Basecamp](https://basecamp.com/) projects.
---
# ClickUp Integration
URL: https://www.teamretro.com/integrations/clickup/
### Publish your TeamRetro retrospective action items as ClickUp tasks
Make sure your actions don’t fall by the wayside by publishing them directly to your teams’ existing [ClickUp](https://clickup.com/) projects.
---
# Confluence Integration
URL: https://www.teamretro.com/integrations/confluence/
### Publish your TeamRetro retrospective and health check reports to Confluence
Make sure your actions don’t fall by the wayside by publishing them directly to your teams’ [Atlassian Confluence](https://www.atlassian.com/software/confluence) space.
---
# GitHub Integration
URL: https://www.teamretro.com/integrations/github/
### Publish your TeamRetro retrospective action items as GitHub issues
Make sure your actions don’t fall by the wayside by publishing them directly to your teams’ existing [GitHub](https://www.github.com/) repositories.
### Estimate GitHub issues as a team
Import the GitHub issues you’re planning into an [estimation session](/estimations/), run planning poker so every vote stays independent, and sync the agreed estimate back to the issue. GitHub holds the number the team actually agreed on, with no copy-paste and no separate spreadsheet.
---
# GitLab Integration
URL: https://www.teamretro.com/integrations/gitlab/
### Publish your TeamRetro retrospective action items as GitLab issues
Make sure your actions don’t fall by the wayside by publishing them directly to your teams’ existing [GitLab](https://about.gitlab.com/) repositories.
---
# Seamless Integrations for Agile Teams
URL: https://www.teamretro.com/integrations/
TeamRetro integrates with the tools your team already uses, so it's easy to run a retrospective, health check, estimation, or standup session and act on the outcomes. Create action items with owners and due dates, sync estimates to your trackers, then publish to your existing task management and communication tools, quickly and securely.
Want to know more, or want to integrate your organization's workflow tool? Feel free to [get in touch](/contact-us/).
---
# Jira Integration
URL: https://www.teamretro.com/integrations/jira/
### Keep your retrospectives, health checks, and estimation aligned with Jira
Connect TeamRetro to your teams’ existing [Atlassian Jira](https://www.atlassian.com/software/jira) projects so decisions made in a session don’t get stranded there.
### Publish retrospective action items as Jira issues
Make sure your actions don’t fall by the wayside by publishing them directly to your teams’ existing Jira projects, so follow-ups live in the same backlog your team already works from.
### Planning poker for Jira
Estimate without leaving your backlog behind. Jira planning poker in TeamRetro runs like this: import the Jira issues you’re planning into an [estimation session](/estimations/), run planning poker so every vote stays independent, and sync the agreed story points back to the Jira issues. The estimate stays a team decision, everyone votes privately, the reveal happens together, and Jira holds the number the team actually agreed on.
New to the technique, or just want to try it first? [Run a free planning poker session](/free-planning-poker-for-agile-teams/) in your browser, no account needed.
---
# Linear Integration
URL: https://www.teamretro.com/integrations/linear/
### Publish your TeamRetro action items as Linear issues
Make sure your action items and stories are in sync by publishing them directly into your chosen Linear Team.
Make sure your actions don’t fall by the wayside by publishing them directly to your teams’ existing [Linear](https://linear.app/) projects.
---
# Microsoft Teams Integration
URL: https://www.teamretro.com/integrations/microsoft-teams/
### Invite your team via your Microsoft Teams channel
Get your retrospective or team health check quickly underway by posting an invite to [Microsoft Teams](https://teams.microsoft.com/).
### Post your team action items to your Microsoft Teams channel
Keep on top of your retrospective or health check action items – post them to your Microsoft Teams channel!
### Daily standup reminders and summaries in Microsoft Teams
The same connection works for your [daily standup](/standups/). TeamRetro reminds the team in your Microsoft Teams channel when it's time to post, with a button that opens the standup in TeamRetro, where everyone posts their update. When the standup closes, it posts a digest back to your channel with an AI summary, each person's update and the actions agreed, so a team spread across time zones stays in sync without a meeting that suits nobody's morning.
Add an action for a blocker, give it an owner, and it joins the same action list as your retrospectives and health checks, so it gets followed up instead of forgotten.
---
# Monday.com Integration
URL: https://www.teamretro.com/integrations/monday-com/
### Publish your TeamRetro retrospective action items as Monday.com tasks
Make sure your actions don’t fall by the wayside by publishing them directly to your teams’ existing [Monday.com](https://monday.com/) projects.
---
# n8n Integration
URL: https://www.teamretro.com/integrations/n8n/
## How it works
{/* Step numerals come from the Walkthrough counter; never hand-number the headings. */}
### Install the TeamRetro node
Search "TeamRetro" in n8n's nodes panel (Cloud), or go to *Settings* > *Community nodes* > *Install* and enter `n8n-nodes-teamretro` (self-hosted).
### Connect your TeamRetro account
Create an API key in TeamRetro under *Account* > *Settings* > *API & SCIM*, paste it into a new TeamRetro credential in n8n, and pick your region (**US** or **EU**). Click Test to confirm the connection.
### Listen for events in real time
Add the **TeamRetro Trigger** node, register its webhook URL in TeamRetro, and events arrive the moment they happen: signed, verified, and with no polling.
## Hook TeamRetro into everything else
Your retrospectives, health checks and estimation sessions produce moments worth acting on. Connect TeamRetro to [n8n](https://n8n.io/) and those moments become workflows across 1,000+ tools, with real-time triggers and no polling. The decisions a team makes in a session flow to where the work actually happens, so nothing is stranded in a meeting no one revisits.
{/* IMAGE SLOT (hero, 16:9): n8n canvas showing the TeamRetro Trigger node fanning out to Google Sheets, an AI node and Gmail. Real product screenshot. */}
{/* The three ready-made workflows read as parallel recipes, so they render as a
card trio (the about-page pattern), not stacked prose. Card titles are h3s;
the "Works with" line closes each card. TEMPLATE LINKs go inside their card
once the n8n template library URLs exist. */}
### Put your team health data where your metrics live
Health checks are a signal, but they're most powerful next to your other engineering metrics. When a health check completes, this workflow writes every dimension score to Google Sheets or Postgres, ready for the dashboard you already have. Add the optional alert branch and get pinged when a dimension drops sprint-over-sprint.
**Works with:** Google Sheets, Postgres, and anywhere your BI reads from.
{/* IMAGE SLOT (3:2): TeamRetro health radar on the left, trend chart in a BI dashboard on the right. */}
{/* TEMPLATE LINK: "Health check scores → your dashboard": n8n template library URL once published. */}
### Walk into your retro with the board already full
The sprint's real talking points already happened: in standups, in incident calls, in that meeting where everything went sideways. This workflow takes a meeting transcript from Zoom (or Fathom, Grain, Otter), asks AI to pull out the themes, and pre-seeds your next retrospective with ideas ready to discuss. Facilitators start the session with substance, not silence.
**Works with:** Zoom, Fathom, Grain, Otter, and your AI provider of choice.
{/* IMAGE SLOT (3:2): TeamRetro retro board with ideas already populated; inset of a transcript snippet showing the source. */}
{/* TEMPLATE LINK: "Meeting transcript → pre-seeded retro". */}
### Turn incidents into learning, automatically
The moment a Sev-1 is resolved in PagerDuty or Sentry, this workflow creates a blameless postmortem retrospective seeded with the incident facts as discussion points. Nothing depends on someone remembering to schedule it. The retro exists before the adrenaline wears off.
**Works with:** PagerDuty, Sentry.
{/* IMAGE SLOT (3:2): PagerDuty resolved notification flowing into a TeamRetro retro card titled "Postmortem: API outage". */}
{/* TEMPLATE LINK: "Incident resolved → postmortem retro". */}
### …or build your own
The node covers the full TeamRetro API (88 operations across retrospectives, health checks, estimations, actions, agreements, insights and reports) plus the **TeamRetro Trigger** node for 19 real-time events. If you can describe the workflow, you can build it. It pairs well with n8n's AI agent nodes too: give your agent TeamRetro as a tool and ask it questions about your teams.
**Good to know:** The TeamRetro API allows 60 requests per minute per key, and some operations depend on your plan or on an account-scoped key. Retro summaries and reports are also generated with AI. As with all AI-generated content, review a summary before you act on it. Learn more [about our responsible use of AI →](/responsible-ai/)
---
# Notion Integration
URL: https://www.teamretro.com/integrations/notion/
### Sync your TeamRetro action items seamlessly with Notion
Keep your team accountable by publishing TeamRetro action items directly to your existing [Notion](https://www.notion.com/) databases or project pages.
---
# Shortcut Integration
URL: https://www.teamretro.com/integrations/shortcut/
### Publish your TeamRetro action items as Shortcut stories
Make sure your action items and stories are in sync by publishing them directly into your chosen Shortcut Project.
Make sure your actions don’t fall by the wayside by publishing them directly to your teams’ existing [Shortcut](https://shortcut.com/) projects.
---
# Slack Integration
URL: https://www.teamretro.com/integrations/slack/
{/* Step numerals come from the Walkthrough counter; never hand-number the headings. */}
### Link your TeamRetro team with your Slack channel
Find **Slack** under *Team* > *Settings* > *Integrations*.
### Invite your team to join retrospectives or health checks
Click “Post to #channel” in the invitation dialog.
### Run your retrospective or health check
Easily run your online retrospectives or health check meetings with guided facilitation techniques, whether for face-to-face or remote teams. Avoid group-think and bias. Our time-saving features mean everyone gets more time to discuss what matters.
### Publish action items to your Slack channel
Keep on top of your retrospective action items: post them to your Slack channel!
Actions are tracked from one meeting to the next. Click “*Publish to Slack*” after your meeting.
### Daily standup reminders and summaries in Slack
The same connection works for your [daily standup](/standups/). TeamRetro reminds the team in your Slack channel when it's time to post, with a button that opens the standup in TeamRetro, where everyone posts their update. When the standup closes, it posts a digest back to your channel with an AI summary, each person's update and the actions agreed, so nobody has to piece the day together from a scattered thread.
Add an action for a blocker, give it an owner, and it joins the same action list as your retrospectives and health checks, so it gets followed up instead of lost in the scroll.
**Disclaimer:** TeamRetro uses AI to generate meeting summaries, suggest actions, group ideas, and surface team insights directly within your Slack workflow. As with all AI-generated content, outputs may occasionally be inaccurate or incomplete — we recommend reviewing suggestions before acting on them.
Learn more [about our responsible use of AI →](/responsible-ai/)
---
# Trello Integration
URL: https://www.teamretro.com/integrations/trello/
### Publish your TeamRetro retrospective action items as Trello cards
Make sure your actions don’t fall by the wayside by publishing them directly to your teams’ existing [Trello](https://www.trello.com/) boards.
---
# Zapier Integration
URL: https://www.teamretro.com/integrations/zapier/
## How it works
{/* Step numerals come from the Walkthrough counter; never hand-number the headings. */}
### Connect your TeamRetro account
Create an API key in TeamRetro under *Account* > *Settings* > *API & SCIM*, add TeamRetro to a Zap, then paste the key and pick your region (**US** or **EU**).
### Pick a trigger
Retrospective completed, health check completed, action item created or reassigned, kudos given, and more. Every one fires in real time.
### Add your actions
Send the outcome on to any of Zapier's 8,000+ apps: email, spreadsheets, support desks, chat. Turn the Zap on and you're done.
### Connect TeamRetro to 8,000+ apps, no code required
The moment a retrospective wraps, a health check completes or kudos is given, [Zapier](https://zapier.com/) carries it into the tools your team already uses. Every TeamRetro trigger is real-time, with no waiting on polling, and building a Zap takes minutes, not sprints.
{/* IMAGE SLOT (hero, 16:9): Zapier editor showing a two-step Zap: TeamRetro "Retrospective Completed" → Gmail "Send Email". Real UI screenshot. */}
#### Catch up the people who missed the retro
Not everyone makes every session. This Zap emails a recap (what was discussed, what was agreed) the moment a retrospective completes. Stakeholders stay in the loop without another meeting.
**Works with:** Gmail, Outlook.
{/* IMAGE SLOT (3:2, card media slot): Gmail message titled "Retro recap: Sprint 42 (Team Phoenix)". */}
{/* ZAP TEMPLATE LINK: "Email a recap when a retrospective completes". Add once the app is public and templates are approved. */}
#### Never lose a "we should talk about this in retro" moment
The best retro topics show up mid-week, in a support ticket or a bug report, and are forgotten by Friday. Tag a ticket `retro` in Zendesk or Intercom and this Zap parks it in TeamRetro automatically. Your next retro agenda builds itself.
**Works with:** Zendesk, Intercom.
{/* IMAGE SLOT (3:2, card media slot): Zendesk ticket with a "retro" tag on the left, TeamRetro parking lot showing the same item on the right. */}
{/* ZAP TEMPLATE LINK: "Send tagged tickets to your retro parking lot". */}
#### Give kudos a bigger audience
Recognition shouldn't stay locked in the session. When someone gives kudos in TeamRetro, this Zap shares it to Google Chat, or logs it to a recognition sheet so nothing gets lost come review season.
**Works with:** Google Chat, Google Sheets.
{/* IMAGE SLOT (3:2, card media slot): Google Chat message with a kudos card: "🎉 Kudos to Sam from Alex for unblocking the release". */}
{/* ZAP TEMPLATE LINK: "Share kudos beyond the retro". */}
### Keep your favourite tools in the loop
Already use our native [Jira](/integrations/jira/), [Slack](/integrations/slack/) or [Microsoft Teams](/integrations/microsoft-teams/) integrations? Keep them, they go deeper. Zapier shines for everything else: email, spreadsheets, support desks, calendars, CRMs, and the long tail of tools that make your team yours. Every TeamRetro trigger (real-time, webhook-based) is available to build with, plus actions and searches for multi-step Zaps.
Estimation is **outbound only**: a completed session hands your Zap the agreed results to send onward. Casting votes or creating estimates stays inside TeamRetro.
**Good to know:** The TeamRetro API allows 60 requests per minute per key, and some operations depend on your plan or on an account-scoped key. Retro summaries and reports are also generated with AI; as with all AI-generated content, review a summary before you act on it. Learn more [about our responsible use of AI →](/responsible-ai/)
---
# About TeamRetro
URL: https://www.teamretro.com/about/
{/* The company story: narrow reading column. */}
## The company behind TeamRetro
TeamRetro is made by GroupMap Technology Pty Ltd, an independent software company that has been building collaboration tools since 2012. We launched TeamRetro in 2018 to do one thing properly: help teams run retrospectives that lead to real change, not just another meeting.
We are privately held and profitable, with no outside investors and no exit timeline. That is a deliberate choice. It means the roadmap answers to the teams who use TeamRetro every week, not to a board chasing the next funding round or an acquisition.
When you pick a tool for something your team repeats every sprint, the real question is whether it will still be here in a few years, and still getting better. We have been building this category since before it was crowded, and we plan to keep doing it.
{/* The people: one flat grid of the team building TeamRetro. */}
## The people building TeamRetro
A small, focused team: the same people who answer your support tickets, ship the roadmap, and keep the lights on.
{/* What we believe: three principles, the "confidence" pillars stated about us. */}
## How we work
### Independent and profitable
No investors and no exit timeline. We grow at the pace our customers need, and every roadmap decision answers to them.
### Focused on one thing
Retrospectives, team health checks, agile estimation, and standups. Built properly, not bolted onto something else as a side feature.
### Built to last
SOC 2 Type 2, independently audited every year, with a public SOC 3 report and a status page anyone can check.
{/* Stability proof: the verifiable facts, stated plainly. */}
## A vendor you can build on
### Since 2012
Building collaboration software, with TeamRetro shipping since 2018.
### 12,700+ paid teams
Run retrospectives and health checks with TeamRetro, from startups to Fortune 500s.
### SOC 2 Type 2
Independently audited every year, plus a public SOC 3 report and GDPR compliance.
### 99.99% uptime
On a status page anyone can check, any time.
{/* Trusted-by logo wall: the shared customer marquee. */}
## Trusted by teams in every industry
From fast-growing startups to established names like Herman Miller, Culture Amp, and Eurowings Digital, teams use TeamRetro to make retrospectives count and track team health over time.
{/* Security proof band. */}
{/* Closing CTA: the shared trust + start-free block. */}
---
# Meet trAI, your in-meeting AI assistant
URL: https://www.teamretro.com/ai/
## The team's intelligence, in the room with you
trAI sits in the side panel while you facilitate, ready when you need more than what's on the board. Ask it to make sense of where the discussion has landed, to sharpen the action the team just agreed on, or to surface what they said about this three retros ago. It's recall no one in the room has.
It works in retrospectives, health checks, estimation sessions and standups, and acts only when you ask it to.
## What can your AI meeting assistant do in TeamRetro?
### Generates new formats
Get fresh new ideas for retro formats, health checks and icebreakers.
### Summarizes as you go
Surface key themes during or at the end of meetings for you and the team.
### Gives clever suggestions
trAI proposes unbiased actions, suggests next steps, and flags what you’ve missed.
### Acts on your instruction
Use natural language instructions for trAI to act on your behalf, saving you time.
### Recalls past outcomes
trAI helps your team with follow through without having to dive into the archives.
### Spots the patterns
Get more insights beyond the meeting to track hot topics, themes and team sentiment over time.
## trAI and the MCP server
Two doors, and the difference is where you're standing when you ask.
### trAI inside the meeting
For the person facilitating right now. It lives in the side panel of a retro, standup, health check or estimation session, and works on the meeting in front of you.
### MCP outside the meeting
For the rest of your week. The [TeamRetro MCP server](/mcp/) connects Claude, ChatGPT, Copilot or Gemini, so you can ask from the assistant you already work in.
Most teams end up using both: trAI while the meeting is running, [MCP](/mcp/) for everything between meetings.
## Three things to try this week
### In a retrospective
Reads the board as it stands and hands back the shape of the discussion, so you can check the team agrees before moving on.
### In a health check
Puts this session next to the previous one and points at what moved, while the radar is still on screen.
### In an estimation session
Looks up comparable past sessions, so a contested estimate has some history behind it rather than just opinions.
## Frequently asked questions
---
# Automate retros, health checks and actions with the TeamRetro API
URL: https://www.teamretro.com/api/
## One REST API across retros, health checks, actions and teams
Pull retro summaries into your reports, sync actions with your tracker, provision teams from your HR system, whatever your workflow needs. Authenticate with a bearer token and you're away:
```bash
curl https://developer.teamretro.com/api/v1/actions \
-H "Authorization: Bearer $TEAMRETRO_API_KEY"
```
## What you can build
### Teams & people
List and manage teams, members and roles. Provision users from your own systems.
### Actions & agreements
Create, update and close actions; read and maintain working agreements.
### Meetings & health
Read retrospective, health-check, estimation and standup metadata, plus health models, to feed your reporting.
### Report exports
Download CSV exports for team activity, action activity, retro and health-check activity, team health and users.
## Authentication & access
### Bearer keys, scoped
Create keys under **Settings → API & SCIM** with **Read**, **Write** or **SCIM** scope. Send them as `Authorization: Bearer `. Revoke any key the moment you need to.
### Team-level on every plan
Team-scoped keys work on **all plans**. **Enterprise** unlocks account-wide, **cross-team** keys plus **SCIM** provisioning, the same line we draw for cross-team insights over MCP. Organization owners can disable API & MCP access for the whole account at any time.
## Webhooks: know the moment it happens
Don't poll. Point TeamRetro at an endpoint and we'll push a signed event as soon as something changes: a retro or health check completes, an action is created, reassigned or closed, an agreement changes, a member joins, or someone is @mentioned.
```json
{
"event": "action.completed",
"timestamp": "2026-06-09T10:30:00.000Z",
"data": { "action": { "id": "…", "title": "Fix flaky CI", "team": "Mobile" } }
}
```
### Per-team, self-serve
Configure under **Team → Settings → Integrations**. Choose the events, set your endpoint, get an auto-generated signing secret and send a test event.
### Signed & verifiable
Every delivery carries an `X-TeamRetro-Signature` (HMAC-SHA256) and a unique delivery id, so you can verify authenticity and de-duplicate.
### Reliable delivery
HTTPS only, 30-second timeout, and automatic retries (immediate, then 1m, 5m, 30m and 2h) before a failing endpoint is paused.
## Built for AI agents, too
The same data is one step away from your AI assistant. The [**TeamRetro MCP server**](/mcp/) connects Claude, ChatGPT, Microsoft Copilot, Gemini and others so an agent can pick up where the meeting left off in natural language: summarize, chase actions, park topics. The API and webhooks are how you build it into your own systems; MCP is how your team works with it in chat.
## Quickstart
List a team's open actions, then close one:
```bash
# Find open actions for a team
curl "https://developer.teamretro.com/api/v1/actions?status=open" \
-H "Authorization: Bearer $TEAMRETRO_API_KEY"
# Mark an action complete
curl -X PATCH https://developer.teamretro.com/api/v1/actions/$ACTION_ID \
-H "Authorization: Bearer $TEAMRETRO_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "status": "completed" }'
```
The full reference, covering every resource, filter and field, is at [developer.teamretro.com/docs](https://developer.teamretro.com/docs).
## Frequently asked questions
---
# Ball Point Game
URL: https://www.teamretro.com/ball-point-game/
## Experiment and play in multiple teams while learning about continuous improvement
The Ball Point game helps a Scrum team experience agile delivery first-hand. By
running the production process themselves, the team feels why self-organization,
flow and iterative working matter, and why a short retrospective between
iterations changes the result.
### Learning goals
The agile production process and iterative working.
### Time and format
About 60 minutes, in person or virtual.
### What you need
4+ players and a set of ping pong balls (multicolored works best).
## How the game works
The objective of Ball Point is to get as many balls through the system as possible
in a fixed number of iterations. Teams estimate how many they can move, run a timed
round, hold a quick retrospective, then try to beat their own score. It is the same loop
agile teams use to improve sprint over sprint.
## Agile ball game rules
- There are 3 minutes per iteration and 5 iterations.
- In between, there is a 1-minute retrospective.
- The ball needs to start and end with the same person.
- The ball must have passed through everyone in the team.
- The ball must have air time.
- It can't be passed to the person next to them.
- If the ball is dropped, it does not count.
### How to facilitate
1. Gather the team and explain the goal and the rules.
2. Ask the team to estimate how many balls they will move in an iteration.
3. Start the timer and run the iteration.
4. Record the score after each round.
5. Hold a timed retrospective so the team can adjust its strategy.
6. Repeat for all five iterations.
## Debrief questions
Run the debrief [as a retrospective in TeamRetro](https://secure.teamretro.com/demo/retrospectives) so everyone can add their own
perspective anonymously before you discuss as a group.
- What was your experience like in the game?
- How did the iterations differ?
- What changes did you make, and what effect did they have?
- How important were the retrospectives?
- How different was the last iteration from the first?
- Did you experience the concept of flow?
- Which iteration stood out?
- How did you feel working as a team?
- Did leadership change during the iterations?
- What did you learn from playing this game?
## Variations
- Split a large group into smaller teams, each working in its own zone.
- Add rules around the color or numbered sequence of the balls.
- Introduce chaos by calling out position switches mid-iteration.
Capture the debrief as a retrospective in TeamRetro so the lessons turn into
tracked action items, not just a good conversation.
## Other agile games
- [Paper Airplane Game](/paper-airplane-game/): waste and rework on a production line the team keeps re-tuning.
- [Coin Game](/coin-game/): batch size and flow on a kanban, with coins moving between stations.
- [Chocolate Bar Game](/chocolate-bar-game/): product ownership and customer feedback rather than flow.
---
# Chocolate Bar Game
URL: https://www.teamretro.com/chocolate-bar-game/
## Become a product owner and get feedback on your ultimate chocolate bar
The Chocolate Bar game is a short scrum simulation about product ownership. Teams
design a chocolate bar their customers will love, gather feedback each round, and
decide what to change next, feeling first-hand how iterative feedback shapes a
product.
### Learning goals
Product ownership, iterative feedback and customer value.
### Time and format
About 60 minutes, in person or virtual.
### What you need
3+ people and recycled or scrap paper.
## How the game works
The goal is a scrum simulation where you create the chocolate bar that is most
attractive to your customers within a set of constraints. Each phase pairs a short
design round with a feedback round, so the team learns to listen, prioritize and
improve rather than guess.
## Agile Chocolate Bar game rules
- For each team there should be a designated Product Owner. In a small group, each person is their own product owner.
- Each phase has an iteration round (3 minutes) and a feedback round (1 minute).
- There are at least 3 phases.
### How to facilitate
1. Split into teams and choose a Product Owner for each (or have everyone own their own design).
2. Run a 3-minute design round where the team builds or improves its chocolate bar.
3. Run a 1-minute feedback round where customers respond to the design.
4. Repeat for at least three phases.
5. Have teams present their final designs for the group to critique.
## Debrief questions
Run the debrief [as a retrospective in TeamRetro](https://secure.teamretro.com/demo/retrospectives) so everyone can add their own
perspective before you discuss as a group.
- How did you decide how to design your chocolate bar in each phase?
- How useful was the feedback from customers, and how did you improve the feedback you asked for each round?
- How did you measure the value of the chocolate bar to the customer each time to make improvements?
- If you didn't measure customer value, why not?
- How did the feedback you received influence the design of the chocolate bar?
- What trade-offs did you have to make in the design?
- What proportion of the customers did you satisfy at the end?
- Would you have personally bought this chocolate bar?
- Were there any features that were added that did not come from customer feedback?
- Were any agile processes applied in the game, such as a backlog, dot voting or prototyping?
- What else did you learn from this activity that you wanted to share?
## Variations
- Add a score from each customer each round on how likely they are to buy the chocolate bar.
- Allow or restrict who hears the feedback (for example, only the Product Owner attends the feedback sessions).
- Add constraints to the design, such as the materials or the size of the bar.
Capture the debrief as a retrospective in TeamRetro so lessons about customer
value and product ownership turn into tracked action items.
## Other agile games
- [Ball Point Game](/ball-point-game/): self-organization and flow, with one ball passed through the whole team.
- [Paper Airplane Game](/paper-airplane-game/): waste and rework on a production line the team keeps re-tuning.
- [Coin Game](/coin-game/): batch size and flow on a kanban, with coins moving between stations.
---
# Coin Game
URL: https://www.teamretro.com/coin-game/
## Get flipping with a kanban workflow challenge that will help teams stay active
The Coin Game brings the first principle of the Agile Manifesto to life: satisfy
the customer through early and continuous delivery of value. Teams race to find the
fastest way to move coins down the value chain, and discover why large batches slow
everyone down.
### Learning goals
Continuous delivery and the cost of large batch sizes.
### Time and format
About 15 minutes, in person or virtual.
### What you need
3+ people and 20 coins.
## How the game works
The goal of this game is to work out the fastest way to deliver value to the customer
as a team. A coin is only "delivered" once everyone in the value chain has flipped it,
so the team has to decide how to batch and hand off work, then prove it against the
clock across several timed iterations.
## The Coin Game rules
- There is a set number of coins representing value to the customer.
- Each coin needs to be flipped by each person along the value chain before it is given to the customer.
- The process is timed to see how long it takes to deliver value to the customer.
- There will be 3+ iterations that are timed.
### How to facilitate
1. Gather the team and explain the goal and the rules.
2. Separate people into teams of five or six, each representing a different role.
3. Give the team a minute to decide the fastest way to flip and stack the coins.
4. Start the timer and run the iteration.
5. Hold a one-minute retrospective so the team can rethink its approach.
6. Re-run and record the time for each iteration.
## Debrief questions
Run the debrief [as a retrospective in TeamRetro](https://secure.teamretro.com/demo/retrospectives) so everyone can add their own
perspective before you discuss as a group.
- Which batch sizes did the best in terms of time? Why do you think that is?
- Was there anything that surprised you in the game?
- How do you think it would change if the distance between people were increased?
- How do you think things would change if you had to wait 10 seconds each time there was a handover of coins?
- If you introduced a change request during the game, how did that impact the process?
- If you had compared it to the traditional waterfall approach, what differences did you notice?
- How good were the team's time estimates?
- What else did you learn from this activity that you wanted to share?
## Variations
- Have the teams start by completing the task in a traditional waterfall approach, where every coin is flipped by one person before it is moved to the next person. This acts as a baseline.
- Introduce one or more change requests to the process, such as "I only want $2 coins" or "coins with a picture of an animal".
- Have teams estimate how long it would take to complete the task at different batch sizes.
Capture the debrief as a retrospective in TeamRetro so insights about batch size
and flow turn into tracked action items the team can act on.
## Other agile games
- [Ball Point Game](/ball-point-game/): self-organization and flow, with one ball passed through the whole team.
- [Paper Airplane Game](/paper-airplane-game/): waste and rework on a production line the team keeps re-tuning.
- [Chocolate Bar Game](/chocolate-bar-game/): product ownership and customer feedback rather than flow.
---
# Contact us
URL: https://www.teamretro.com/contact-us/
## We'd love to hear from you
Whether you have a question about features, pricing or your account, our team
is here to help. Reach out and we'll usually get back to you within one
business day.
### GroupMap Technology Pty Ltd
ABN 95 160 220 520
#### Address
Level 1/931 Albany Hwy
East Victoria Park WA 6101
Australia
#### Email
[info@teamretro.com](mailto:info@teamretro.com)
#### Website
[www.teamretro.com](/)
## Other ways to get help
Already using TeamRetro and need a hand? The [TeamRetro help center](https://help.teamretro.com)
covers setup, integrations, billing, and security, and is the fastest route to an
answer for most account questions.
Weighing TeamRetro up for your team and want to see it in action? You can
[book a demo](https://calendly.com/groupmap/teamretro-demo) and a member of our team
will walk you through retrospectives, team health checks, agile estimation and standups, and
answer anything specific to how your team works.
For procurement, security reviews, or rolling TeamRetro out across several teams, the
[rollout checklist](/roll-out-checklist/) walks through plans, onboarding, and the
documentation IT usually asks for, and you're welcome to email
[info@teamretro.com](mailto:info@teamretro.com) directly.
---
# Enterprise-ready tool for agile teams
URL: https://www.teamretro.com/enterprise/
{/* Role icons: inline SVG (?raw) so `fill="currentColor"` is recolored from var(--marker). */}
{/* Product screenshot (the brand PageHeader above carries the H1 + lead + the
email-capture/Request-a-demo hero CTA via heroEmailCapture). */}
{/* Trusted-by logo wall: the shared customer marquee. */}
## Cross-team reporting & insights
Get organization-wide clarity and uncover trends, spot risks, and drive strategic improvements.
### Track key metrics and actions
Get perspective from meeting cadence to tracking actions.
### Boost productivity with TeamRetro AI
Let AI suggest themes, actions, and meeting summaries.
### Uncover recurring challenges
Explore shared themes and blockers to focus on what matters most.
### Monitor sentiment trends
Spot early signs of disengagement or misalignment.
### Visualize team health
Monitor team happiness, engagement and maturity.
### Measure ROTI on retros
Give feedback to boost meeting outcomes and decision quality.
## Collaborate at scale with smart role management
The same roles govern AI, and on Enterprise you decide when it starts. The [trAI assistant](/ai/) is **off by default on Enterprise accounts**, so your organization reviews it before rolling it out — account owners and admins hold that switch under **Settings → AI & Features → AI Assistant**, and team administrators choose which roles may use it under **Team Settings → Roles & Permissions → Use the AI assistant**. Guests never get access. trAI acts as the person using it, with exactly their permissions, so switching it on never widens what anyone can reach — and it can't reveal who wrote an anonymous idea, comment or survey response. See [responsible AI](/responsible-ai/) for the data handling behind it.
### Guest Access
### Observer Role
### Facilitator Only Role
### Role-Based Permissions
### No Extra Seats Needed
{/* Support-team avatars centred above the heading (the live dark support band). */}
## Enterprise support that has your back
With TeamRetro, you get more than a platform. You receive dedicated support tailored to your organization.
{/* A checkmark list (matching live's dark support band); prose text reads white on
the dark tint, so Card's own surface would render dark-on-dark and be unreadable. */}
Enterprise Agreements and SLA
DPA (Data Processing Agreements)
Custom Onboarding and Roll Out
Security Questionnaires
Dedicated Account Manager
Vendor Onboarding and Purchase Orders
## Predictable pricing that scales with you
From 5 to 5,000+ teams, our pricing adapts to your growth.
Volume-Based Pricing
DPA (Data Processing Agreements)
Custom Onboarding and Roll Out
Multi-Year Discounts
Multiple Currency Options
Vendor Onboarding and Purchase Orders
Let us tailor a plan that fits your needs.
Request a quoteSee plans
## Why choose TeamRetro?
See why enterprises are choosing TeamRetro over other retro tools.
Feature area
Other tools
Security
SOC 2 Type 2, GDPR Compliant, SSO, SCIM, IP whitelisting
Basic security, limited compliance
Insights and analytics
Key agile metrics, team sentiment, action tracking, word clouds, heat maps
Manual collation or tagging, limited insights or drill down
Flexibility
Customizable templates and workflows at team and organization level
Limited workflow customization
Facilitation tools
Guided facilitation, ice breakers, check in / check out questions, live reactions, presentation mode and quick polling
Limited or restrictive workflow and facilitation tools
AI capability
Inbuilt, context driven AI capability to boost productivity
## What teams are saying
Trusted by enterprise teams to turn retrospectives into meaningful insights and actions at scale.
Client StoriesHow Big Give runs smarter, more impactful retrospectives with TeamRetro
At Big Give, small means mighty. Big Give is the UK's largest match funding platform, helping thousands of UK-registered charities…
Client StoriesHow Culture Amp uses TeamRetro to unify agile feedback and boost visibility
At Culture Amp, building a better world of work starts from within. Culture Amp is a leading employee experience platform…
Client StoriesHelping nonprofits thrive through agile grant writing
Beth Archer wears two hats at DH Leonard Consulting & Grant Writing Services, LLC, as both a Registered Scrum Master and grant writer…
{/* Closing band: the enterprise overview deck + the "start scaling" CTA, merged
into one brand section (the live layout; previously two stacked sections that
read as broken). */}
## Start scaling best practices across your organization
Security, scale, and smarter collaboration tailored for enterprise teams. Want the full picture? Talk with our team for a guided overview of TeamRetro for enterprise.
Request a demoTalk with us
---
# Improve your sprint planning with agile estimation poker
URL: https://www.teamretro.com/estimations/
## Align fast with clearer estimates
Say goodbye to manual calculations and messy tallies. TeamRetro's agile estimation helps teams find common ground, fast.
It's a sprint planning tool built around how agile teams really estimate: run story point estimation as a team, use planning poker so every vote stays independent, and land on a number everyone stands behind, without spreadsheets or anchoring on the first guess.
### Create alignment
Get everyone on the same page before work starts, with structured rounds and reveals.
### Build delivery confidence
Turn "I think" into shared clarity, so your plan matches reality more often.
### Reduce uncertainty
Surface assumptions, risks, and unknowns early so you avoid surprises mid-sprint.
## Start estimating and agile planning in minutes
Transform your sprint planning and backlog grooming sessions with guided facilitation, anonymous estimates and easy team engagement.
### Create a clean, focused list easily
Pull items from retros, health checks, or your backlog (or import straight from TeamRetro, Jira, Azure DevOps, GitHub, or Linear) and keep everything in sync with your source of truth.
### Invite your team into a safe, secure space
Bring everyone into the same agile estimation flow, instantly. Everyone sees the same estimation items in real time. Flexible anonymity options let you build safety or accountability.
### Discuss each item to gain more data
Ensure everyone understands the requirements, scope, and acceptance criteria. Run polls, give kudos and use live reactions for real-time feedback. Keep discussions focused by parking items or creating follow-up actions and team agreements.
### Estimate privately, free from bias
Cards remain hidden until everyone is done to prevent anchoring bias. Choose from a library of estimation decks that fit your team's style or life cycle.
### Reveal results and agree on a final score
View all estimates at once to spot alignment or gaps. Surface risks, clarify requirements, and uncover assumptions. Then re-vote to reach consensus and lock in the final story points together.
### Share results and sync with workflow tools
Get a complete summary of final estimates for sprint planning and backlog prioritization. Sync agreed estimates back to Jira, Azure DevOps, GitHub, and Linear, and export meeting notes to Confluence, Slack, and more, so everyone stays aligned.
### Engage more with the team
Throw in an icebreaker to kick things off, a check-out question to get feedback on delivery confidence, or run quick polls.
## Choose the estimation deck that drives better planning outcomes
Select from our library of proven estimation decks.
### Scrum
The classic scrum deck with story points including half values, perfect for standard agile estimation.
### Fibonacci
Based on the fibonacci sequence, ideal for highlighting the uncertainty in larger estimates.
### Sequential
Simple sequential numbers for teams who prefer straightforward linear estimation.
### Half card
Granular half-point increments for teams that need more precision in their estimates.
### Power of two
Exponential growth pattern, great for technical teams estimating complexity and effort.
### Modified fibonacci
A refined fibonacci deck with smoother jumps, great for teams balancing speed, clarity, and estimation confidence.
### Five fingers
An easy-to-use deck based on the five fingers on your hand for when teams want simplicity.
### T-shirt sizes
Relative sizing with familiar clothing sizes, perfect for high-level backlog estimation.
*…or build your own.*
### Animal estimation deck
Set a deck up once and reuse it across all your sessions.
## Planning poker for Jira
If your backlog lives in Jira, you don't have to choose between estimating well and keeping Jira up to date. Pull the issues you're planning straight from Jira into a TeamRetro estimation session, run planning poker so every vote stays independent, and write the agreed story points back to the Jira issues. No copy-paste, no second spreadsheet.
The estimation itself stays a team conversation rather than a field one person fills in later: everyone votes privately, the reveal happens together, and where votes split you talk through why before the number is locked. Jira ends up holding the point the team actually agreed on, with the reasoning still fresh.
See the [Jira integration](/integrations/jira/) for setup, or [try planning poker free](/free-planning-poker-for-agile-teams/) in your browser first. No account needed.
## Frequently asked questions
New to estimating as a team? Our [agile estimation guide](/guides/agile-estimation-guide/) works through story points, planning poker, and [velocity in depth](/guides/agile-estimation-guide/velocity/) (including [which estimation technique to use when](/guides/agile-estimation-guide/estimation-techniques/) and a free velocity calculator), and our roundup of the [best planning poker tools](/blog/best-planning-poker-tools-for-agile-teams/) compares the options. You can also [try planning poker free](/free-planning-poker-for-agile-teams/) in your browser, no sign-up needed.
---
# Free Planning Poker by TeamRetro
URL: https://www.teamretro.com/free-planning-poker-for-agile-teams/
## Built with care by TeamRetro
TeamRetro helps scrum masters, product owners, and development teams run better retrospectives, health checks, and estimations, with ready-to-use templates, action tracking, and continuous improvement built in for remote, hybrid, and in-person teams.
## Simple, easy estimations for better sprint planning
Keep everyone aligned, reduce anchoring bias, and get to consensus faster.
Teams write the name a few ways, poker planning, scrum poker, [pointing poker](/pointing-poker/), and every one of them describes the round below.
### Add items for discussion
Discuss the items to be estimated and let people ask questions before estimating.
### Estimate items privately
Each player selects a hidden value card. Cards stay hidden until revealed, so no one anchors on someone else's number.
### Reach a shared decision
All cards are revealed with a tally and team average. Discuss, re-vote, or agree on a final estimate.
## Ready-to-go estimation card decks
Choose the scale that works best for your team: classic Fibonacci, simple [t-shirt sizing](/guides/agile-estimation-guide/t-shirt-sizing/), or anything in between.
### Scrum
### Fibonacci
### Sequential
### Half card
### Power of two
### T-shirt size
## Learn how to run better estimation sessions
Planning poker is easy to start and surprisingly easy to get wrong. For a big backlog, try [affinity estimation](/guides/agile-estimation-guide/affinity-estimation/) instead of pointing each item. These free, practical guides, from the team behind TeamRetro, go deeper than the basics, written for the scrum masters and engineers who actually run the sessions:
What is planning poker?
The technique, where it came from, and when it's the wrong tool.
How to run a planning poker session
The facilitator's playbook: ground rules, the four phases of a round, ruthless time-boxing, and which card deck to use.
Story points and estimation
What story points really measure, and the points-to-hours trap that quietly breaks velocity.
Agile estimation techniques
Planning poker compared with t-shirt sizing, affinity mapping, and bucket sizing.
Team velocity
After the estimate: turn story points into a forecast, with a free velocity calculator.
Worked estimation examples
Real stories (login, payments, migrations) walked through the conversations they need.
Common planning poker mistakes
The recurring ways sessions fall apart, and how to pull them back.
## When your team outgrows the free tool
The free planning poker room is yours to use for as long as you like, with no account and no limits on estimating together. When you want estimates to live alongside the rest of your team's work, [TeamRetro's estimation](/estimations/) brings it into one place: run your retrospectives, health checks, and estimation together, reuse your own decks, and sync final story points to Jira, Azure DevOps, GitHub, and Linear, with a record every session builds on.
## Frequently asked questions
Everything you need to know about planning poker.
---
# Agile team health checks and radars
URL: https://www.teamretro.com/health-checks/
## Build high-performing teams
TeamRetro is team health check software that shows how your team rates their performance and satisfaction across the dimensions that matter. Create your own health models or start from a template, then turn the results into a continuous improvement habit. New to running one? Our [team health check guide](/guides/team-health-check/) covers choosing dimensions, the questions to ask, and how to facilitate the session.
### Custom Health checks
Create your own health models or use a template.
### Visualize team health
Evaluate health dimensions over time.
### Find the gaps
Address issues early and improve productivity.
### Create actions for change
Propose and track actions that create happier teams.
## Team health check methods and formats
Out of the box, TeamRetro has industry-based health checks to choose from, including the [Spotify squad health check model](/health-check-templates/squad-health-check/) ready to run. Customize an existing model or use our AI-generated suggestions to create the ideal fit for your team. [Browse health check templates](/health-check-templates/) to find a starting point that fits your team.
### Numeric
### Happiness Scale
### Matrix Model
### Likert Scale
## Run better team health checks
Survey the team and capture comments with ease, free from bias. Run open surveys or facilitate in-person meetings. Device friendly and no downloads required.
## Data-driven discussions
Real-time results plot every dimension on a team radar, so you see the overall picture and how it moves over time at a glance. Prioritize discussions by focusing on what is most important to you. Dive into individual results or statistics like standard deviation, range and mean.
## Present, discuss and create actions
Use presentation mode to sync screens and facilitate discussions. Propose and create actions that drive change.
## Review your action plan
Assign due dates and owners and check things off. Actions are tracked from meeting to meeting with gentle reminders when things are due.
## Create summaries in seconds
Generate summaries of comments for each health dimension and the overall health check, ready to share.
## Go further with maturity models
Organize health dimensions into categories to reveal deeper insights across your agile journey.
Learn more about maturity models
## Enterprise insights
Managing multiple teams? Get cross-team reporting across your portfolio with our enterprise plan, and a sense of what teams are talking about.
### Word clouds
Get a sense of what the teams are talking about.
### Timelines
See how individual health dimensions move over time.
See all health check features
## You're in good company
## Frequently asked questions
---
# Agile maturity assessment
URL: https://www.teamretro.com/health-checks/agile-maturity-assessment/
## Accelerate continuous improvement with agile maturity assessments
Regular assessments are the foundation of continuous improvement. Here's why leading teams choose TeamRetro.
### Custom maturity models
Create your own model or start from a proven template.
### Visualize trends over time
Track maturity by dimension and spot patterns early.
### Find the highest-impact gaps
Focus discussion on what will move outcomes, not vanity scores.
### Turn insights into actions
Create accountable action items and follow through.
## Choose your agile maturity assessment template
Select from our library of curated agile maturity models designed for each area of agile transformation.
### Agile delivery
Planning & prioritization · Delivery flow · Team collaboration · Continuous feedback & improvement
### Agile teams
Teamwork & collaboration · Agile ways of working · Planning & prioritization · Technical excellence & quality · Product delivery & customer value · Agile mindset, culture & continuous improvement
### Customer support
Support operations · Customer success outcomes · Knowledge & enablement · Voice of customer (VOC)
### Data & analytics
Data quality & governance · Reporting & insight · Infrastructure & accessibility · Experimentation & optimization · Data literacy & culture
### DevOps & continuous delivery
CI/CD pipeline · Release & deployment · Reliability & operations · Security & compliance automation · Platform & infrastructure
### Engineering excellence
Code quality & standards · Architecture & scalability · Technical debt management · Engineering collaboration & enablement
### Finance
Financial planning & forecasting · Financial control & compliance · Cash flow & financial health
### Leadership
Vision & strategic alignment · Communication & influence · Team development & support · Adaptability & innovation
### Marketing
Strategy & positioning · Content & messaging · Campaign execution · Analytics & performance
### People operations
Hiring & onboarding · Performance & growth · Culture & engagement · People operations excellence · Workforce planning & capability
### Product discovery
Customer understanding · Experimentation & validation · Research practices · Lifecycle learning
### Product management
Vision & strategy · Roadmapping & prioritization · Execution & collaboration · Data & customer insight · Market & stakeholder alignment
### Product strategy & customer value
Product strategy & customer value · Discovery, innovation & experimentation · Engineering excellence & platform · Customer success & market performance · Data, measurement & enterprise operations
### SaaS growth & lifecycle
Acquisition & activation · Engagement & retention · Monetization & billing · Analytics & lifecycle optimization · Growth strategy & market fit
Browse health check templatesLearn about health checks
## Run your agile maturity assessment in TeamRetro
Run a quick assessment, gather honest input, and turn results into a shared improvement plan.
## Capture feedback privately
Create categories and clearly defined dimensions. Design the model for your organization that fits best.
## Data-driven discussions
Real-time, visual results show you the overall picture and trends over time. Prioritize discussions by focusing on what is most important to you. Dive into individual results or statistics like standard deviation, range and mean.
## Present, discuss and create actions
Use presentation mode to sync screens and facilitate discussions. Propose and create actions that drive change.
## Review your action plan
Assign due dates and owners and check things off. Actions are tracked from meeting to meeting with gentle reminders when things are due.
## Create summaries in seconds
Generate summaries of comments for each health dimension and the overall health check which can be shared.
## Enterprise insights
Standardize maturity models across teams, compare trends, and identify systemic blockers with cross-team reporting.
### Detect key topics and themes
Get a sense of what the teams are talking about.
### Trends over time
See how individual health dimensions move over time.
## You're in good company
---
# All the features you need for insightful agile team health checks
URL: https://www.teamretro.com/health-checks/features/
{/* Section illustrations. */}
{/* Survey-style rating scales. */}
{/* Feature-item images (one per item, mirroring the live page). */}
{/* Capability icons (inline SVG ?raw → recolored from --marker). */}
## Create meaningful health checks
Choose a template, customize your health check and define the dimensions that matter to your team.
### Dark mode
### Responsive
### 29 Languages
### 45+ health check models
Used by top agile teams around the world. [Browse the template library →](/health-check-templates/)
### …plus AI-generated suggestions
Pick a focus for your team and explore the possibilities.
## Choose from a range of survey styles
Pick the rating style that fits your team and the question you're asking.
### Numeric
Rate each dimension on a simple numeric scale.
### Happiness Scale
Capture sentiment with an expressive happiness scale.
### Matrix Model
Plot responses across two dimensions with a matrix.
### Likert Scale
Measure agreement across a familiar Likert scale.
## Easily survey the team, free from bias
Capture private ratings and comments without bias. Choose how people participate and customize your process for in-person or asynchronous surveys.
### Timer
### Music
### Team chat
### Team roles
### Fully anonymous meetings
Choose between anonymous, aliases and named.
### …or give participants a choice
Optional anonymity for individual comments or ideas.
### Customize your process
Design your health check for in-person or asynchronous surveys.
### Check-in questions
Focus the team before starting a survey.
### Open with an icebreaker question
Choose a question, create your own, or get an AI suggestion.
### …or choose from a library of activities and games
Your icebreaker becomes a game the whole team plays together.
### Review open actions
Create accountability and recognize success.
### Whiteboards
Sketch diagrams, map frameworks, and collaborate visually.
### Kudos & shoutouts
Celebrate wins, big or small, with quick appreciation.
## Lead team discussions with visual radars
Real-time radars make the overall picture clear, with customizable steps to guide the conversation.
### Easily sort results
From most positive to most negative to most mixed responses.
### Get data happy
Drill down into a range of statistics, or see individual results.
### Spot the trend
Compare past trends and get AI summaries of comments.
### Capture team agreements
Improve the way the team works and how they collaborate.
## Focus your conversation with Presentation Mode
Sync screens and talk through one dimension at a time with live meeting feedback polls.
### Live reactions
### Quick poll
### Meeting feedback
### Deepen discussions
Capture comments, reactions and replies on ratings.
### Parking lot
Move items to the parking lot for follow up and keep things moving.
## Capture actions for continuous improvement
Turn discussion into change: capture actions and AI summaries, and push them into the tools your team already uses.
### Use check-out questions
Get quick feedback on your health checks.
### Generate summaries
Easily create, publish and share with AI summaries.
### Integrate actions into your workflow
Publish actions into your workflow tools at the touch of a button.
### Personal dashboard
Each person can see their actions, open meetings and teams.
### Get suggested actions
Harness the power of AI to suggest actions based on your meeting.
## Data-driven insights to help you level up
See the bigger picture across health checks — meeting effectiveness, health dimension trends and your team's pulse over time.
### Return on time invested
Assess how effective your meeting was.
### Timelines
See how individual health dimensions shift over time.
### Track check-in/out trends
Get the pulse of your team over time.
### Explore common themes
Drill down into your word clouds.
## Frequently asked questions
---
# Ask your AI assistant about your teams
URL: https://www.teamretro.com/mcp/
## Your retros, health checks and actions — now a question away
TeamRetro speaks MCP, so the assistant you already work in can read your retros, summarize meetings, chase actions and keep working agreements current. No new dashboard to open, no context-switch.
Inside a meeting you don't need any of this: [trAI](/ai/) is already in the side panel. MCP is for the rest of your week.
## With TeamRetro MCP you can…
### See across every team
Ask which teams need attention and get overdue retros, slipping health scores and stalled actions, already flagged. _Cross-team views are an [Enterprise](/enterprise/) capability._
### Run your rituals from chat
Spin up a retro, health check or planning poker session using the same template as last time, ready to join.
### Set up estimation from your backlog
Hand the assistant this sprint's stories and have it open a planning poker session, ready for the team to vote.
### Never lose a follow-up
Check what's on your plate, mark actions done and push due dates. Add an idea to the retro the moment it comes up, and it's parked automatically if no retro is open.
### Participate, not just observe
Cast votes, rate health-check dimensions and leave feedback as yourself. Every contribution respects your team's anonymity settings.
### Connect it to everything else
Pull incidents from Slack into the retro, post summaries to your channel, cross-check actions against the Jira tickets they reference.
## Three prompts your team will run every week
### Summarize our last retro
Runs `list_retrospectives` → `get_retrospective` and hands back the summary with owners and due dates.
### Start the next one
Sets up the meeting, ready to share. No template hunting.
### Add an idea while it's fresh
Runs `create_retrospective_idea`. If a retro is open it lands on the board; if not, it's parked for the next one.
## Prompts for every role
### Engineering managers & coaches Enterprise
### Scrum masters & facilitators
### Team members
### Working agreements
## Bring the signal in, push the outcomes out
Your other tools hold the raw signal; TeamRetro is where the team acts on it. Pull incidents from Slack and park the themes. Turn a postmortem's commitments into actions with owners and due dates. Post Friday's retro summary to your channel, or open a Jira ticket for every open action, linked back to the meeting.
## Connect in about five minutes
Add the TeamRetro MCP server in your assistant, sign in to TeamRetro in the browser, and start asking. Use the endpoint for your region:
```text
US https://mcp.teamretro.com/mcp
EU https://mcp.eu.teamretro.com/mcp
```
Or follow a step-by-step guide for your assistant:
Working in Cursor, Windsurf, Zed or VS Code instead? Add a new MCP server with the URL above and the **Streamable HTTP** transport, then approve the OAuth sign-in.
## What it can do today
### Read
List teams and members
Summarize and compare retrospectives, health checks and estimation sessions
List and filter actions
Read working agreements
Track health-check trends over time
### Do
Start retros, health checks and planning poker sessions
Add ideas to a retro, or park them for the next one
Create and update actions
Keep working agreements current
As yourself, vote and add health-check feedback
Write actions respect your permissions and anonymity settings.
## Built on permissions you already trust
You connect with **OAuth 2.1**: a browser sign-in, no API key to copy. The connection is **account-level** (one TeamRetro account per connection; add it more than once for multiple accounts). The assistant only ever sees what your account can see: on standard plans, the teams you belong to; **cross-team, organization-wide insights are an [Enterprise](/enterprise/) capability.** Revoke any connection at any time, and **organization admins can turn API & MCP access off for the whole account** whenever they need to. Included on all paid plans.
## Frequently asked questions
---
# Connect TeamRetro to ChatGPT
URL: https://www.teamretro.com/mcp/chatgpt/
## Bring your retros into ChatGPT
Add the TeamRetro connector and ChatGPT can recap meetings, surface open actions and track team health without leaving the chat.
## What you can do in ChatGPT
## Set up in ChatGPT
OpenAI updates this surface often. If the menus look different, follow the [TeamRetro MCP help article](https://help.teamretro.com/article/535-mcp) for the current steps. You'll also need a TeamRetro plan with **API & MCP access**.
## First prompts to try
## Permissions & access
ChatGPT only sees what your account can see. On standard plans that's the teams **you belong to**; **cross-team, organization-wide insights are an [Enterprise](/enterprise/) capability.** Every action respects your team's anonymity settings, and you can revoke the connector at any time. **Organization admins can turn API & MCP access off for the whole account** whenever they need to.
## Set up another assistant
## Frequently asked questions
---
# Connect TeamRetro to Claude
URL: https://www.teamretro.com/mcp/claude/
## Run your retros from Claude
Connect once and Claude can summarize meetings, chase actions and track team health, all from the chat you already work in.
## What you can do in Claude
## Set up in Claude
You'll need a TeamRetro plan with **API & MCP access** and account-admin permission to approve the connected app. Connecting signs you in with OAuth 2.1; there's no API key to copy.
## First prompts to try
## Permissions & access
Claude only sees what your account can see. On standard plans that's the teams **you belong to**; **cross-team, organization-wide insights are an [Enterprise](/enterprise/) capability.** Anything Claude does on your behalf respects your team's anonymity settings, and you can revoke the connection at any time. **Organization admins can turn API & MCP access off for the whole account** whenever they need to.
## Set up another assistant
## Frequently asked questions
---
# Connect TeamRetro to Microsoft Copilot
URL: https://www.teamretro.com/mcp/copilot/
## Ask Microsoft Copilot about your teams
Connect the MCP server and Copilot can summarize retros, chase actions and track team health, right alongside the Microsoft 365 tools your team already uses.
## What you can do in Microsoft Copilot
## Set up in Microsoft Copilot
You'll need a TeamRetro plan with **API & MCP access**. Connecting signs you in with OAuth 2.1; there's no API key to copy. Microsoft updates this surface often; for the latest steps, see the [TeamRetro MCP help article](https://help.teamretro.com/article/535-mcp).
## First prompts to try
## Permissions & access
Copilot only sees what your account can see. On standard plans that's the teams **you belong to**; **cross-team, organization-wide insights are an [Enterprise](/enterprise/) capability.** Every action respects your team's anonymity settings, and you can revoke the connection at any time. **Organization admins can turn API & MCP access off for the whole account** whenever they need to.
## Set up another assistant
## Frequently asked questions
---
# Connect TeamRetro to Gemini
URL: https://www.teamretro.com/mcp/gemini/
## Ask Gemini about your teams, from the terminal
Connect the MCP server to the Gemini CLI and ask about retros, health checks and actions straight from your terminal.
## What you can do in Gemini
## Set up with the Gemini CLI
You'll need a TeamRetro plan with **API & MCP access**. Connecting signs you in with OAuth 2.1, so there's no API key to copy. For the latest steps, see the [TeamRetro MCP help article](https://help.teamretro.com/article/535-mcp).
## First prompts to try
## Permissions & access
Gemini only sees what your account can see. On standard plans that's the teams **you belong to**; **cross-team, organization-wide insights are an [Enterprise](/enterprise/) capability.** Every action respects your team's anonymity settings, and you can revoke the connection at any time. **Organization admins can turn API & MCP access off for the whole account** whenever they need to.
## Set up another assistant
## Frequently asked questions
---
# Paper Airplane Game
URL: https://www.teamretro.com/paper-airplane-game/
## A good game that explores continuous improvement and lean workflow
The Paper Airplane game is a hands-on way to see lean workflow in action. Teams fold
as many quality airplanes as they can, but only one person can fold at a time, so
bottlenecks, waste and handovers show up fast, and the team improves the process
between rounds.
### Learning goals
Lean workflow, value stream mapping and continuous improvement.
### Time and format
About 60 minutes, in person or virtual.
### What you need
4+ players and recycled or scrap paper.
## How the game works
The objective is to fold as many airplanes as possible in a given timeframe, with one
constraint: only one person can make a fold at a time. The team runs timed iterations
with a short retrospective between each one, so they can spot waste and improve the
flow round after round.
## Paper Airplane game rules
- There are 3 minutes per iteration and 5 iterations.
- In between, there is a 1-minute retrospective.
- Every airplane must meet the same design and quality standard.
- Only one person can fold at any one time; the rest of the team supports as needed.
- The team agrees on the airplane design before they start, simple enough to fly about a meter.
- After each round, count only the airplanes that meet the quality standard.
### How to facilitate
1. Gather the team and agree on a single airplane design and quality standard.
2. Start the timer and run the iteration, with one fold at a time.
3. Count the airplanes that meet the standard and record the score.
4. Hold a 1-minute retrospective so the team can adjust its approach and re-estimate.
5. Repeat for all five iterations.
## Debrief questions
Run the debrief [as a retrospective in TeamRetro](https://secure.teamretro.com/demo/retrospectives) so everyone can add their own
perspective before you discuss as a group.
- Where did you notice you were waiting (waste)?
- How often was everyone engaged?
- What changes were made, and how did they affect the production process?
- What design aspects could make the flow slower or faster?
- How would this game differ if played virtually versus in person?
- How did quality controls play a part in this process?
- Did you experience the concept of flow?
- Which iteration stood out?
- How did you feel working as a team?
- Did leadership change during the iterations?
- What did you learn from playing this game?
## Variations
- Measure the time required to produce a set number of airplanes, rather than counting output in a fixed time.
- Adjust the complexity of the airplane design up or down.
- Introduce a quality check midway through, rather than only at the end.
- Raise the difficulty: for example, require each plane to fly at least two meters.
Capture the debrief as a retrospective in TeamRetro so lessons about waste and flow
turn into tracked action items the team can follow through on.
## Other agile games
- [Ball Point Game](/ball-point-game/): self-organization and flow, with one ball passed through the whole team.
- [Coin Game](/coin-game/): batch size and flow on a kanban, with coins moving between stations.
- [Chocolate Bar Game](/chocolate-bar-game/): product ownership and customer feedback rather than flow.
---
# Pointing poker for agile teams
URL: https://www.teamretro.com/pointing-poker/
## Pointing poker is planning poker
Same round, different name. Pointing poker gets its name from the story point on the card: the team sizes an item, everyone plays a card privately, and the cards turn over together so nobody anchors on the loudest number. You will also see it written as poker planning or scrum poker, and [planning poker](/free-planning-poker-for-agile-teams/) is the name the technique was published under in 2002.
If you are new to it, the guide chapter on [what planning poker is](/guides/agile-estimation-guide/what-is-planning-poker/) covers where it came from and when it is the wrong tool. For what the numbers actually mean, read [what story points are](/guides/agile-estimation-guide/what-are-story-points/).
## How a pointing poker round runs
Three beats, repeated per item. The value is in the second and third.
### Review the item
Read the story, check the acceptance criteria, and ask the questions that would change your number.
### Point it privately
Everyone picks a card from the agreed scale. Cards stay hidden until the last person has voted.
### Reveal and agree
All cards flip at once with a tally. Where the high and low cards disagree, that gap is the conversation worth having before you re-vote.
## When the estimate needs to outlive the session
The free room is enough to point a backlog today. When you want the number to stay useful, [TeamRetro's estimation](/estimations/) keeps it with the work: pull items straight from your backlog, pick the deck your team already uses, and sync the agreed story points back to [Jira](/integrations/jira/), Azure DevOps, GitHub or Linear. Retrospectives, health checks and estimation sit in one place, so the sprint you plan and the sprint you review are the same record.
## Frequently asked questions
---
# Pricing and plans
URL: https://www.teamretro.com/pricing/
## Our plans and features
## Frequently asked questions
---
# Report abuse
URL: https://www.teamretro.com/report-abuse/
## Tell us what you saw
Someone may have used TeamRetro to send you an email you didn't expect, or to share
a link that looks unsafe. Use this form to report it. We read every report.
### Keep yourself safe
Don't click links in an email you weren't expecting.
If you typed a password into a page you reached from one of these emails, change
that password now and tell your IT team.
TeamRetro will never ask for your password by email.
#### Prefer email?
Forward the email to [security@teamretro.com](mailto:security@teamretro.com).
---
# Pick a retrospective tool you will still be using in a year
URL: https://www.teamretro.com/retrospective-tool/
## Four things to check before you commit
Retrospective tools look much the same in a demo. The differences show up in month three, when the novelty has worn off and someone still has to run the meeting.
### Formats you can rotate
Teams tire of the same three columns by the fourth sprint. Look for a library you pull from, not a blank board you redesign every time.
### Anonymity on every plan
Check whether private brainstorming and independent voting come as standard or sit behind an upgrade. A team that has to pay more to be honest will not be.
### Actions that outlive the board
Capturing a good idea is the easy part. Carrying it into the next retro, with an owner and a date, is what decides whether anything changes.
### One place, not three
Retros, team health and estimation in separate tools means three logins and no shared history. Ask what you would have to stitch together later.
## The actions are the product
Every retrospective tool gives you a board. TeamRetro turns each agreed change into a tracked action with an owner and a date, then puts the open ones back on screen before the team adds a single new note. That one habit is the difference between a meeting that vents and a meeting that ships. In our own data, [about 73% of retrospective action items get done](/guides/follow-through-index/), and ownership is what moves the number.
## Honest input, not polite input
Everyone writes at the same time, privately, so nobody anchors on the loudest first idea. Voting is independent and stays hidden until the reveal, which keeps the team's real priorities from collapsing onto whatever the senior person liked. Anonymity is a per retro setting on every plan, including the trial.
## Anyone on the team can run it
Guided facilitation walks the group through each phase on a timer, and presentation mode keeps everyone on the same idea instead of scrolling ahead. The retro stops depending on the one person who remembers how the format works, which is what makes it survive a holiday, a handover or a new scrum master. New to running them? Start with our guide to [running effective retrospectives](/guides/running-effective-retrospectives/).
## You will want the trend, not the snapshot
One retro tells you about one sprint. Insights track sentiment, participation and recurring themes across months, and [team health checks](/health-checks/) ask the same questions on a cadence, which is how you tell a rough fortnight from a pattern worth acting on. Summaries publish into Slack, Microsoft Teams or Confluence for the people who were not in the room.
## Priced per team, not per seat
A single team plan starts at $250 per team per year for up to 25 members, so inviting a contractor, a stakeholder or a new hire to one retro does not change the bill. Most whiteboard-first tools charge per user instead, which is cheaper for three people and steadily worse after that. There is no free forever plan here. The 30 day trial carries every feature, health checks and estimation included, and does not ask for a card.
## Still comparing?
We would rather you chose deliberately than switched again in six months. Competitor facts on each page are checked against that vendor's own site.
The best retrospective tools in 2026
Sixteen tools compared on pricing model, free plans, anonymity and health checks, with a clear best-for verdict on each.
TeamRetro versus the alternatives
Side by side breakdowns against EasyRetro, Retrium, Parabol, Neatro, Miro and the rest of the field.
Every retrospective feature
The full list, from brainstorm styles and kudos to action tracking, reporting and integrations.
## You are in good company
Teams at Fortune 500 companies, banks, government agencies and early stage startups run their retros here.
## Frequently asked questions
---
# Run agile retrospectives that lead to action
URL: https://www.teamretro.com/retrospectives/
### Save time, create value
with more efficient, focused and worthwhile retros.
### Drive continuous improvement
by getting buy in on actions and creating accountability.
### Build happier teams
with easy, engaging and empowered meetings.
## Make every sprint count
TeamRetro is an online retro tool that gives everyone a safe space to share ideas, foster collaboration and drive continuous improvement, face to face or fully remote. Run your sprint retro in retrospective software built for the job: create shared understanding, capture actions for positive change and improve outcomes. New to facilitating retros? Learn [how to run a retrospective](/guides/running-effective-retrospectives/) step by step, or go deeper with our [Scrum Master's retrospective guide](/guides/scrum-masters-retrospective-guide/) on the formats, stages and psychological safety that make them work.
### Create the perfect retro
Ready to go templates you can adapt to your specific project, sprint or goals.
### Easy to use, anywhere
Guided step by step facilitation keeps everyone on the same page and moving forward.
### Data driven insights
Discover and share meeting summaries, key metrics, and track outcomes.
### Harness the power of AI
Get template and icebreaker suggestions, automated grouping and meeting summaries (if enabled).
## Facilitate effective retros with confidence
Start your retro off with an icebreaker game the whole team plays together — or a quick check-in question — and boost the mood. Set the context of the retro, review open actions and get everyone moving in the right direction.
## Brainstorm and vote privately
Avoid bias and fear by having people brainstorm anonymously and privately. Multiple voting options let the team prioritize items for discussion and focus on what really matters.
## Effortlessly group ideas
Use our AI to automatically suggest groups or manually group ideas. Quickly identify common themes and focus your discussions, saving you time (if enabled).
## Power up your facilitation
Control the flow with guided facilitation and live meeting feedback. Use presentation mode to sync everyone up and talk through one idea at a time. Easily capture ideas, actions and team agreements.
## Create actions and track progress
Empower teams to propose and agree on actions. Assign dates and owners for accountability. Effortlessly track open actions to eliminate barriers and integrate them with your workflow tools. In our own data, [about 73% of retrospective action items get done](/guides/follow-through-index/), and ownership is what moves the number.
## Generate summaries in seconds
Create summaries of the meeting with key metrics, action outcomes and key highlights. Share them easily or publish them into your workflow tools (if enabled).
## Discover insights and share outcomes
From meeting summaries and team sentiment to pivotal themes and emerging trends, you'll gain useful insights from your retrospectives, all easily shared.
See all retrospective features
## See a retrospective board in action
Start from a ready-made template like the classic retrospective, then make it your own.
Explore retro templates
## You're in good company
Thousands of teams from Fortune 500 companies, banks, government, and innovative startups use TeamRetro to make their good teams great!
## Frequently asked questions
---
# All the features you need for effective, fun and easy retrospectives
URL: https://www.teamretro.com/retrospectives/features/
{/* Card banner images (one per feature card, mirroring the live page). */}
{/* At-a-glance feature icons (inline SVG ?raw → recolored from --marker, like enterprise roles). */}
## Create the perfect retrospective for your team
Build a retro that fits the way your team works: customizable steps, free idea input, fun GIFs, and a clear panel for actions and agreements, all designed for agile teams.
### Dark mode
### Responsive
### 29 Languages
### 275+ retrospective templates
Used by the top agile teams around the world. [Browse the template library →](/retrospective-templates/)
### …plus unlimited AI-generated possibilities
Pick a theme for your team and let AI do the rest.
## Rich facilitation at your fingertips
Guide the conversation with confidence. Built-in timers, chat, a parking lot and team roles keep the meeting flowing while you stay focused on the team.
### Comment
### Timer
### Chat
### Team roles
### Parking lot
### Fully anonymous meetings
Choose between anonymous, aliases and named.
### …or give participants a choice
Optional anonymity for individual comments or ideas.
### Customize your process
From a short and sharp meeting to a team think tank.
### Review open actions
Create accountability and recognize success.
### Choose your brainstorm style
Add ideas alone or together.
### Automated grouping
Save time with automated suggestions or group manually.
## Engage your team, build participation
Open with an icebreaker question or a game the team plays together, then keep everyone involved with roles, private voting and visual collaboration.
### Music
### Mentions
### Live reactions
### Quick poll
### Meeting feedback
### Start with an icebreaker question
Choose a question, create your own, or get an AI suggestion.
### …or choose from a library of activities and games
Your icebreaker becomes a game the whole team plays together.
### Check-in questions
Increase focus as you start the meeting.
### Assign meeting roles
Invite co-facilitators, guests and observers.
### Independent voting
Vote privately and without bias across topics, or abstain.
### Whiteboards
Sketch diagrams, map frameworks, and collaborate visually.
### Kudos & shoutouts
Celebrate wins, big or small, with quick appreciation.
### Check-out questions
Get quick feedback from the meeting.
## Focus the conversation
Sync everyone's screen with presentation mode to talk through one idea at a time, or share the screen, but not your input, so people can participate freely.
### Presentation mode
Sync everyone's screen to facilitate discussion.
### Share screen mode
Share the screen, but not your input, and participate freely.
## Capture actions for continuous improvement
Turn discussion into change: propose and agree on actions, get AI suggestions, and push them into the tools your team already uses.
### Propose actions
Propose and create actions for continuous improvement.
### Get suggested actions
Harness the power of AI to suggest actions based on your meeting.
### Integrate actions into workflow
Push actions straight into your workflow tools.
### Personal dashboards
Each person can see their actions, open meetings and teams.
### Meeting summaries
Easily create, publish and share with AI summaries.
### Capture team agreements
Create team culture and expectations to improve teamwork.
## Data-driven insights to help you level up
See the bigger picture across retros — meeting cadence, team health, action tracking, the themes that keep coming back, and how the team actually felt about each one.
### Meeting cadence
Track meeting frequency and activity over time.
### Track team health
Run health checks to measure and track team happiness.
### Action tracking
Monitor and track actions to create progress.
### Explore common themes
Drill down into your word clouds to see what keeps coming back.
### AI sentiment analysis
[Track sentiment by topic, retro after retro](/blog/ai-sentiment-analysis-in-retrospectives/).
---
# TeamRetro Roll-out Checklist
URL: https://www.teamretro.com/roll-out-checklist/
{/* The brand PageHeader above carries the H1 + the intro question (description). */}
Here's a list to help you prepare the necessary steps to roll out TeamRetro to
your teams. Tick off each step as you go. Your progress is saved on this device.
---
# Scrum Master Self-Assessment Quiz
URL: https://www.teamretro.com/scrum-master-self-assessment-quiz/
---
# Security
URL: https://www.teamretro.com/security/
Our customers trust us to keep their data secure and confidential. We take security seriously and work constantly to ensure that trust is well-founded. Have questions? Feel free to reach out to us at [security@teamretro.com](mailto:security@teamretro.com).
TeamRetro holds a SOC 2 Type 2 report covering security, availability, confidentiality and privacy. An independent auditor (Sensiba) examined the controls across our policies, product, platform and infrastructure under AICPA attestation standards, and found them effective.
## Secure platform
#### Secure infrastructure
Our services are hosted on [Amazon Web Services](https://aws.amazon.com/) (AWS) infrastructure. We don’t host or run our own routers, load balancers, DNS servers or physical servers. Amazon data-centers feature 24-hour manned security, biometric access control, video surveillance, and physical locks. All systems, networked devices, and circuits are constantly monitored. AWS facilities are accredited under [ISO 27001](https://aws.amazon.com/compliance/iso-certified/), [SOC 1 and SOC 2](https://aws.amazon.com/compliance/soc-faqs/)/SSAE 16/ISAE 3402 (Previously SAS 70 Type II), PCI Level 1, FISMA Moderate and Sarbanes-Oxley (SOX). Learn more about [AWS security](https://aws.amazon.com/security/).
#### USA or EU hosted – your choice
**United States** – served by US-located data-centers and subprocessors, with our primary services hosted in Northern Virginia; and the **European Union** – served by EU data-centers, with our primary services hosted in Frankfurt, Germany. Some subprocessors, such as those for email delivery, payments, error logging, application monitoring and optional AI content and image generation, process data outside the EU. Our [subprocessor page](/security/subprocessors/) lists each one and where it processes data.
#### Always encrypted
*Encryption in transit –* All data sent to or from our infrastructure is encrypted in transit via industry best-practices using Transport Layer Security (TLS 1.2 or 1.3). Our SSL configuration receives an A+ security grade from [Qualys SSL Labs](https://www.ssllabs.com/ssltest/analyze.html?d=secure.teamretro.com&hideResults=on&latest).
*Encryption at rest –* All our user data is encrypted using the battle-proofed AES256 encryption algorithm in our databases.
#### Secure payments
We aren’t in the business of handling or storing credit card numbers – your card details are directly captured and stored securely by [Braintree](https://www.braintreepayments.com/) (a PayPal company), our payments provider. Braintree is certified as PCI Level 1 compliant, and listed as a Visa® Global Compliant Provider and MasterCard® Compliant Provider (SDP). We complete an annual PCI DSS self-assessment with Braintree. Learn more about [Braintree security and compliance](https://www.braintreepayments.com/products-and-features/data-security).
#### Application security monitoring
- We use a security monitoring solution to get visibility into our application security, identify attacks and respond quickly to a data breach.
- We use technologies to monitor exceptions, logs and detect anomalies in our applications.
- We collect and store comprehensive logs to provide an audit trail of our applications activity. Our logs feed automated alerts, which our team investigates.
- Security events are logged and notifications are sent in case of critical attacks to allow for fast remediation.
#### Application security protection
- We use Amazon [Web Application Firewall](https://aws.amazon.com/waf/) to protect our users from a wide variety of vulnerabilities. AWS WAF integrates protections against the most critical attack categories like SQL injections and cross-site scripting. It blocks attacks in real-time and warns us when attackers start stressing our applications.
- Our website forms use [Cloudflare Turnstile](https://www.cloudflare.com/products/turnstile/) to block bots.
- We use security headers to protect our users from attacks. Our services have received an A+ grade from [SecurityHeaders.io](https://securityheaders.com/?q=secure.teamretro.com&followRedirects=on).
#### Incident management
Suspected security incidents, including any logical and physical security breaches are ticketed, tracked and resolved following our Incident Management Policy and procedures. Where required by applicable law, including the EU Cyber Resilience Act, we notify relevant authorities (such as ENISA) of significant security incidents within mandated timeframes. If a personal data breach affects your data, we will tell affected customers without undue delay, and within 48 hours of confirming it. We notify regulators and affected individuals as the law requires. If you have any questions or suspect an incident may have occurred, please contact [security@groupmap.com](mailto:security@groupmap.com).
#### Downtime reporting
We post incidents that affect availability on our [status page](https://status.teamretro.com/) as soon as we confirm them. For a High or Critical incident (as rated under our Incident Management Policy), we also email enterprise customers’ nominated contacts. Our hosting platform usually obviates the need for downtime when we make changes to our services. We schedule planned maintenance to keep disruption low and post it on our status page.
#### Your privacy, protected
Your data remains owned by you; and only accessible to those whom you choose to share. TeamRetro (and the GroupMap Technology team) may only access your data in limited circumstances such as when required by law or to provide technical support. Full details can be found in the TeamRetro [Privacy Policy](/privacy/).
#### Data retention and removal
We retain our users' data for a period of 365 days after their trial or subscription ends. All data is then completely removed from the application. Users can request the removal of data at any time by deleting their account or contacting TeamRetro support. Read more about our privacy settings in our [Privacy Policy.](/privacy/)
#### Business continuity and disaster recovery
We back up all our critical assets and regularly attempt to restore the backup to guarantee a fast recovery in case of disaster. We capture a full backup of customer data every 24 hours. Backups are securely encrypted and stored for 30 days, at which point they are securely destroyed. We have established Business Continuity and Disaster Recovery plans and review them annually.
{/* `section-figure` centres the seal: the base reset makes images block-level, so a
bare Markdown image ignores the wide-section `text-align: center` and hugs the
left edge of the (centred) prose column. */}
## User protection
#### Single sign-on
Single sign-on (SSO) via your SAML Identity Provider (IdP) is available for all TeamRetro customers.
#### Passwords – protected
TeamRetro passwords are stored salted and cryptographically hashed using the scrypt algorithm. TeamRetro enforces a minimum password complexity requirement using Dropbox’s ZXCVBN library, ensuring passwords are safely unguessable and unbreakable.
#### Account verification
Users are required to verify their ownership of an email address via a link provided in an automated email prior to using for a TeamRetro account. All users must be authenticated prior to gaining access to customer data.
#### Account takeover protection
We protect our users against data breaches by monitoring and blocking brute force attacks.
#### 2-factor authentication
We allow for 2-factor authentication via Google or your SAML IdP to protect against account takeover attacks.
#### Role-based access control
Advanced role-based access control (RBAC) is offered on all accounts.
#### IP whitelisting
Once configured and enforced, anyone attempting to access the account from outside the permitted ranges will be blocked. This gives organizations tighter control over how and where their teams access TeamRetro.
#### Suspicious user behavior monitoring
We use [Datadog](https://www.datadoghq.com/) to monitor suspicious behaviors and react fast in case of account takeovers. It also protects customers against data theft by blocking credential stuffing or brute force attacks.
## Security practices
#### Secure coding
Our developers are required to follow our formally documented Application Security Policy, and follow security best practices and frameworks (OWASP Top 10, SANS Top 25). We use the following best practices to ensure the highest level of security in our software:
- Developers participate in regular security training to learn about common vulnerabilities and threats
- Every change is peer reviewed, including for security vulnerabilities: before it merges where possible, and otherwise afterwards, in a monthly review of every change merged without approval. Production releases also need approval before they deploy.
- We regularly update our dependencies and make sure none of them has known vulnerabilities
- We use Static Application Security Testing (SAST) to detect basic security vulnerabilities in our codebase
- We use Dynamic Application Security Testing (DAST) to scan our applications
- By using [Datadog](https://www.datadoghq.com/) we can more efficiently remediate vulnerabilities that were triggered by security tests, audits or vulnerability disclosure program. Every production release is scanned for components with known vulnerabilities, and Dependabot proposes dependency updates every week.
#### Vulnerability scanning
TeamRetro is scanned on a monthly basis, and after significant releases, by [intruder.io](https://www.intruder.io/) to identify potential infrastructure, platform and application vulnerabilities. Any identified vulnerabilities are triaged and mitigated in accordance with our application security policies.
#### Penetration testing
We periodically commission independent penetration testing, validating the security of the TeamRetro platform. We fix all critical issues within 48 hours and high-severity issues within 7 days.
#### Risk assessments
An annual risk assessment is conducted to identify threats and vulnerabilities for TeamRetro systems. Mitigation strategies are developed based on the results of the risk assessment.
#### System hardening
***SERVER CONTAINERIZATION*** – TeamRetro uses OS containerization via AWS Fargate to ensure that access to TeamRetro data and code is properly restricted. All TeamRetro services run on dedicated compute resources isolated in their own virtual network.
***SERVER EPHEMERAL FILESYSTEMS*** – TeamRetro servers operate on an ephemeral filesystem, restored to a fresh copy of the most recently deployed code at minimum once per day, or every time a new version is deployed.
***SYSTEM PATCHING*** – Platform-level patching (operating system, system libraries, and services) of TeamRetro application and database servers is performed on an ongoing basis.
***APPLICATION PATCHING*** – Application patching (application libraries etc) is performed by TeamRetro on an ongoing basis.
***COMPUTERS*** – All team assets (such as development laptops and desktops) utilize encrypted storage and are protected by up-to-date anti-virus software.
#### Comprehensive logging
We maintain comprehensive logs of every transaction on the system; with specific logging for login attempts. Our team uses these logs, and the automated alerts they feed, to investigate attempted unauthorized access.
#### Our team’s access
- Our team can access user data only with our security team’s approval, and only when required by law or to provide technical support. Full details can be found in our [Privacy Policy](/privacy/).
- Our employees and contractors sign a Non-Disclosure and Confidentiality Agreement to protect our customers' sensitive information.
- Our employees and contractors are screened by a leading background checking service.
- The access level of each of our employees is determined by need, periodically reviewed and revoked if no longer necessary. We enforce multi-factor authentication for all critical TeamRetro systems.
- Two factor authentication is required for administration access.
#### Responsible disclosure
We encourage everyone that practices responsible disclosure and comply with our policies and terms of service to participate in our vulnerability disclosure program. Please avoid automated testing and only perform security testing with your own data. Please do not disclose any information regarding the vulnerabilities until we fix them. We may, at our discretion, offer recognition for high-quality, impactful reports. Learn more about the [TeamRetro responsible disclosure program](/responsible-disclosure/).
## Third-party vendors and subprocessors
TeamRetro makes use of a number of third-party vendors to enable a rich online experience.
At TeamRetro, we are committed to being transparent about the third party vendors and subprocessors we work with to deliver and support our service. Our subprocessors are carefully selected based on their ability to meet high standards of security, privacy, and reliability.
We regularly review our vendor relationships to ensure they remain aligned with our compliance obligations, and we provide customers with clear visibility into how and where their data may be processed. For full details, please refer to our [TeamRetro subprocessor page.](/security/subprocessors/)
**Have a question or something to report?** Drop us a line at [security@groupmap.com](mailto:security@groupmap.com).
---
# Daily standups that bring the team together
URL: https://www.teamretro.com/standups/
// The product's own question icons (TeamRetro CDN topic images, as the standup templates use them),
// each defined once in a hidden sprite that every question reuses (MKT-3005).
## Most teams run a standup. Far fewer get anything out of it.
The daily standup is meant to be a short sync, but too often it becomes a fixed time that suits nobody and a lap of the table, and by lunch the blocker someone mentioned is forgotten. TeamRetro is a daily standup tool built for distributed teams: everyone answers when their day starts, the updates sit in one feed next to your retrospectives and health checks, and a blocker becomes a tracked action with an owner. Read it async, or take it live when something needs talking through. [The difference is facilitation, not format](/guides/daily-standup-guide/).
### Save time, every day
Easy and quick updates with built-in actions and reminders.
### Track progress against goals
Share sprint goals with the team, track progress and share wins.
### Instant summaries
Get summaries by person, time, project, goals or outcome with trAI.
### Flag and clear blockers fast
Spot blockers early and resolve them together.
## A template for every kind of check-in
Start with a template or create your own unique set of questions and add your sprint goals. Tailor the format with fully customizable questions.
### Daily Standup
Every weekday.
What did you do yesterday?
What will you do today?
What is blocking you?
### Async check-in
Written, on your own time.
What did you get done since your last check-in?
What's your focus today?
Anything blocking you?
### Weekly sync
Once a week.
What were your wins this week?
What are your top priorities next week?
Where do you need help or unblocking?
### Daily Stand-down
At the end of the day.
What did you finish today?
What carries over to tomorrow?
Any blockers for tomorrow?
## One setup, every standup covered
Each day gets its own persistent meeting room that the team can access at any time. No more scheduling friction. See the whole month at a glance.
Set the frequency and meeting cadence. TeamRetro takes care of the rest. The team gets gentle nudges and reminders by email, Slack or Microsoft Teams. Run it in real time or [async](/guides/daily-standup-guide/async-and-remote-standups/).
## Keep everyone pointed at the sprint goal
Add the sprint goal or objectives so the team keeps vision on what is important.
See who needs to work together with pairing and handoff to keep things flowing smoothly. The one who is blocked and the one who can unblock them can fix it on the same day.
## Updates just got simpler
No more schedule conflicts and time zone headaches. Everyone can submit updates in their own time while keeping everyone informed.
Your previous standup, blockers and action items are visible. Automate updates with [MCP](/mcp/) or with [trAI](/ai/).
Rich text format lets you add your own personality, links and team shout-outs. @mention team members to keep them in the loop.
## Blockers stay in sight until resolved
Blockers carry forward to your next standup, with a day count showing how long each one has been open.
Turn updates into actions with an owner and due date, so nothing slips through the cracks.
## Facilitate standups that flow
When it's time to meet, the chosen facilitator can run through the cards with ease, capture comments and live reactions as people share quick updates.
Want more? Add a timer or throw in a quick [icebreaker](/icebreakers/) to get the team talking.
Everyone leaves with a clear update, any follow-up items and a sense of what others in the team are working on. [The facilitation moves that keep it tight](/guides/daily-standup-guide/how-to-run-a-daily-standup/).
## Automated shareable summaries
Each standup gives you a list of blockers, tasks and participation rates as well as an AI summary you can refine and share.
Everyone gets an email update or a post in the Slack channel, or download and share with others outside the team.
## Intelligent summaries the way you need them
Different people need a different cut of the same standup. Ask [trAI](/ai/), TeamRetro's AI assistant, from inside the standup and it reads the day's updates the way you ask, from three lines for your manager to a rundown by person. Like everywhere else in TeamRetro, it only sees what you can see.
### By sprint goal
What moved the goal, what didn't, and what's in the way.
### By person
A paragraph per teammate, ready for a one-to-one or a handover.
### By project
Progress and blockers grouped by the work stream or project name.
### By your priorities
Tell trAI what matters this week and it reads the updates against that.
### By timeframe
Today's updates so far, or a look back over last week or last month.
## Frequently asked questions
---
# 3 nifty ways to keep your retros fun and exciting!
URL: https://www.teamretro.com/blog/3-nifty-ways-to-keep-your-retros-fun-and-exciting/
**As important as sprint retrospectives are, there’s also the chance that repetition breeds familiarity. It becomes a chore rather than an opportunity for continuous improvement. Having fun, fresh ideas for your scrum team whether they are distributed or in the same room can shift mindsets and bring back energy.** As part of our job to try out different techniques and games from time-to-time, we found 3 simple ways that can revitalize your sprint retrospectives.
For more formats, our [retrospective games](/guides/retrospective-games/) guide maps 20 of them to the problem each one fixes.
### Fun retro tip 1: get out of the building
Your team spends their entire day cooped up in the office or huddled behind their desk. Why not mix things up by taking your retrospective meetings beyond the office walls? A new environment can help your team get a new perspective on the project. A digital online retrospective tool means you are not bound by sticky notes or walls (literally and metaphorically).
Grab your devices (Or pen and paper if you choose to go old school). Head outside and enjoy the fresh air in a park, a change of scenery at a quiet cafe or a more informal one at the pub. A really great idea might be to run the retrospective in the environment where the client works and performs their job. This creates empathy and a deep understanding of what your end user is really experiencing.
#### What do we do.
Our team is distributed. So we ask each team member to pick their favorite cafe and run a Zoom Meeting. For those of us in the same location, we chose to have it in an open air cafe called Lyric Lane. After sharing what our beverage of choice, we created a time box for people to brainstorm directly into TeamRetro. To avoid the talking over each other and to ensure that everyone in the team was included, we did a round robin through the ideas and grouped them as needed. The change of scene was refreshing and a good opportunity to carry on working in a different space for a while after our meeting.
### Fun retro tip 2: run a just-in-time retrospective
A regular cadence is important but when something “interesting” has happened mid-sprint, there’s nothing dictating you to wait until the end of the sprint cycle. A Just In Time (JIT) retro brings everyone together to discuss the current hot issue. Moving quickly and in a timely manner helps to avoid sagas, mountains out of molehills, or other blockers that destroy team productivity.
Anything from a sudden departure, a change in technology or emerging product issue could be the trigger. In that sense, Agile has similarities to the Just In Time approach used in manufacturing. Rather than a “just in case” approach to running your retro, having your team come together not just because of a planned time but to address a specific set of issues or opportunities which means maximum engagement.
This is from Scrum Kanban Guide (about retrospective)
*The Scrum Guide dictates that the Sprint Retrospective take place after the Sprint Review and before the next Sprint Planning. This does not change when using Kanban. However, flow-based retrospective opportunities need not coincide within the boundaries of a Sprint. They can occur “just in time”. Correspondingly, changes to a team’s definition of “Workflow” may happen at any time, however, as these changes will have a material impact on how the Scrum Team performs, changes made during the regular cadence provided by the Sprint Retrospective event will reduce complexity and improve transparency.*
In short, strike while the iron is hot!
#### What do we do.
Apart from our usual cadence of sprint based retrospectives, everyone within the team looks for “retrospective opportunities” – any activities to inspect the flow as defined by the Team.
Examples include on-boarding a new team member to help them understand our retrospective process, to recognizing a new stakeholder that impacts on our development through to unexplained shifts in behavior or morale.
We kick off with a [team health check](/health-checks/) or radar that gives us insight into what might be the key areas of concern to focus our discussion on. We tend to use the [Mad, Sad, Glad retrospective](/retrospective-templates/mad-sad-glad-retrospective/) to air out issues and look at the circle and soups model to help manage expectations.
### Fun retro tip 3: be inspired by a favorite movie or TV show
Use a set of characters, places, symbols or concepts from popular culture to enliven the inner geek in us all. It’s a way to relate concepts and characters, spark interest while still addressing the main points at hand. If you want to go the extra mile, theme your retrospective. It will bring a few smiles, witty banter and renewed energy. Here’s one we found based on the TV show The Office. Courtesy of Gretchen Knode Scrum Master / Agile Coach at [Agile Initiatives.](https://www.facebook.com/agileinitiatives/?eid=ARDtvOxaXVOB_Vt13OzVWZCj_ek8Y4ndXalA0igpgy8hAtL9xUeePQlI0v-f9iFpZRdL0COfWe9I6JWM&timeline_context_item_type=intro_card_work&timeline_context_item_source=596025656&fref=tag)
The idea here is that the engagement comes from attaching meaning to characters and using that as a way to guide thinking based on what relates to them. Piggybacking this with a clip or a lead-up is also a great hook.
**What do we do?**
We recently had a team film night and watched Avengers Endgame. Inspired, we decided to create an Avengers-themed retrospective using the top 6 characters (yes — even Hawkeye was included!)
Creating Icons from Icons8, we went about representing different aspects of our online retro. Here’s what we came up with.
- **Captain America**: What do we want to protect?
- **Iron Man**: What experiments should we try?
- **Hulk**: What do we want to change?
- **Black Widow**: How can we improve our team?
- **Thor**: What are our biggest strengths?
- **Hawkeye**: What support do we need?
What made this process fun was the sense of empathy and highlights the role each person plays. They each bring their own perspectives and “super powers” for collaboration and teamwork. It was a great way to have open and honest discussions as well as creating our top 3 action items.
Do you have any ideas you think we should share around making team retrospectives fun, engaging and fresh? Write to us at [info@teamretro.com](mailto:info@teamretro.com).
Ready to run your own fun retro? [Try out TeamRetro now!](/retrospectives/?utm_source=3funtips&utm_medium=trb&utm_campaign=dmcs/)
---
# 5 tips for getting the most out of your agile team health check
URL: https://www.teamretro.com/blog/5-tips-for-getting-the-most-out-of-your-agile-team-health-check/
Team health checks are a really easy way of measuring and tracking a team’s well-being to inform data driven action points that help support a team’s continuous improvement!
If you’re new to team health checks, our [guide to running a team health check](/guides/team-health-check/) covers the basics. If you just want to make sure you’re making the most of them, we’ve pulled together our top five tips to help you on your way.
## Tip 5. aim to support not judge
Health checks are a great way to gain insight into the support your team needs; and can show you where you can bring the most benefit.
So, take care – this isn’t the time to show off your extrapolation skills. If a health check points to a team being ‘unhappy’, that doesn’t mean they aren’t delivering value.
Although it might be tempting to compare individuals or teams based on the results of a health check, such an undertaking is fraught. A team that records mainly “green” responses may simply feel uncomfortable discussing certain issues, while those registering “red” may be embracing the opportunity to improve.
That’s why you should make your first step adopting the mantra ‘support don’t judge’. Approach the team with an open and curious mind as such a mindset is conducive to supporting team growth.
To check you’ve embraced the right mindset, ask yourself ‘Who are you hoping to benefit?’; if your answer isn’t ‘Your team’, it’s time to recalibrate.
## Tip 4. talk to your team
This one may seem obvious, but it’s often missed.
When you have –
- a backlog of Everest proportions,
- an infinity of back-to-back meetings and
- you’re seriously considering skipping your morning shower to save yourself some time (please don’t, always shower),
you may find yourself inexplicably assuming the talents of your team extend to being able to read your mind. They can’t – so talk to them.
The main things to cover when you first run a health check –
- What a health check is and why they’re valuable
- The dimensions the health check includes and what they mean
- How health checks will happen in your team
- Any concerns your team may have
This step comes with a bonus.
Not only is this a chance for you to connect with your team, but it also helps to show you are genuine in your wish to be supportive, that your actions and words align, and that the introduction of health checks is not a box ticking exercise. When a team considers their manager genuine and supportive, team wellness is enhanced.
## Tip 3. connect to your existing process and practice
One of the easiest ways of integrating a health check into your team’s world is by aligning it with your retrospective.
Performing a health check before or after a retrospective means it won’t interrupt other workflow commitments. They can easily be aligned to asynchronous retros too.
Aligning it to your retro doesn’t mean duplicating exactly what happens during your retro.
The health check space is one in which responses are captured quickly and independently and it’s not a time to discuss issues nor explore treatments and solutions. It’s an opportunity to gauge team wellness at a particular point in time. You can even run a health check prior to your retro and use the data to define the focus for the next retrospective to address a particular area.
## Tip 2. make it regular
There are two key reasons for this –
Firstly – the foundation for improving team health is measuring it, and the cornerstone of that foundation is the ability to track it over time. Tracking will allow you to appropriately target areas of concern and assess the effectiveness of the type of support that’s been made available to your team. Using a health check connects to a data driven practice; it’s your tool to help define the actions and resources that will provide the support your team needs so they can improve.
Secondly – this is a chance for you to demonstrate you value your team and their well-being, and in a time poor world nothing says that quite like reserving a space for it in your schedule.
That’s why it’s important to hold a team health check regularly. If you find a monthly team health check a little too much, try every two months or whatever interval helps you build the health check habit.
## Tip 1. make it safe
It’s simply not possible to overstate the importance of conducting a team health check in a psychologically safe space.
Your team needs to feel comfortable in their courage; they need to feel they may offer honest and open responses without fear of adverse action (be it direct or indirect).
Some of your team members may already feel this, others may need some support to get there, and so here’s how you can help –
- Make your team health checks anonymous…really anonymous… not the sort of anonymous that can be easily reversed so it’s possible to take a sneaky peak at who said what…. actually anonymous… so no one knows who owns which response… including you. [ Psst… TeamRetro lets you run [team health checks](/health-checks/) that are anonymous to both participants and facilitators.]
- Share it with the team (and those supporting them) but no further. Sharing it beyond this increases the likelihood that the results won’t be used for the purpose for which the health check was designed.
Of course, you can [customize your team health check templates](https://help.teamretro.com/article/194-custom-health-models) so that it makes sense to your organization and the team, adding to its meaning.
Let us know if you have other tips you’d like to share.
If you’re new to team health checks, [test-drive our health checks](https://secure.teamretro.com/demo/health-checks?lang=en) with our team of friendly bots.
---
# Agile maturity assessment: how to measure and improve your team
URL: https://www.teamretro.com/blog/agile-maturity-assessment-how-to-measure-and-improve-your-team/
Your team is running sprints. There’s a backlog, a definition of done, and regular retrospectives. On paper, everything looks agile.
But something still feels off.
Releases are unpredictable. The same retro themes keep resurfacing. And if someone asked, “How mature is your agile practice?” the answer wouldn’t come easily.
That hesitation is exactly why agile maturity assessments exist, and why running them well, with the right tool, makes all the difference between a conversation that produces a slide deck and one that produces real change.
This article covers what an agile maturity assessment actually measures, the five levels teams get rated against, the models worth choosing between, and how to run one so it ends in decisions rather than a scorecard.
## What is an agile maturity assessment?
An [agile maturity assessment](/health-checks/agile-maturity-assessment/) is a structured way to evaluate how effectively a team or organization applies agile principles in practice.
It goes beyond a count of how many agile ceremonies you run. It looks at whether the underlying thinking is actually there – examining areas like collaboration, delivery flow, technical quality, and continuous improvement to identify strengths and the highest-leverage opportunities for growth.
More broadly, [maturity models](https://en.wikipedia.org/wiki/Maturity_model) are designed to measure how capable an organization is at consistently improving its processes over time. As the team matures, this translates into more predictable, adaptable outcomes, not just faster sprints.
## Why agile maturity assessments matter
Here’s a sobering stat: according to OutSystems’ [State of Application Development report](https://www.outsystems.com/blog/posts/agile-maturity/) (which surveyed over 1,500 application development professionals), only around 15% of organizations consider themselves fully mature in agile practices. About 60% remain stuck at the second or third maturity stages, going through the agile motions without realizing the full benefits.
Agile transformations often stall not because teams lack effort, but because there’s no shared, honest picture of what’s actually happening. Gaps stay invisible. And without visibility, it’s hard to know whether you’re genuinely improving or just staying comfortable.
Regular agile maturity assessments help teams and leaders in a few important ways:
- **They surface what’s really going on**. Day-to-day work makes it hard to see systemic issues. An assessment creates the structure and the pause, to look clearly at how your team is really operating, not just how it feels.
- **They focus your improvement energy**. Not every gap is equally worth fixing. Assessments help identify the changes that will move the needle most, so you stop spreading effort thin and start making targeted progress.
- **They create a shared language**. When everyone on the team rates the same dimensions, differences in perspective become visible. That honest gap between how different people experience the team’s ways of working can spark some of the most valuable conversations you’ll have.
- **They make progress visible**. Running assessments regularly turns individual snapshots into trends, and trends tell you whether your improvements are actually sticking, or quietly sliding back.
- **They give leadership something to work with**. For organizations running multiple agile teams, assessments enable cross-team comparisons and surface systemic blockers that no single retrospective can reveal.
## What does an agile maturity assessment measure?
The specific dimensions your assessment covers depend on the model you choose. But across all well-structured assessments, the goal is the same: rating how your team actually operates across the areas that matter most for delivery and improvement, not just whether ceremonies are happening on schedule.
Here’s a concrete example. When a team uses the Agile Teams maturity model in TeamRetro, they’re rating themselves across six categories:
- **Teamwork & collaboration**: how well the team communicates, resolves conflict, and operates as a self-organizing unit.
- **Agile ways of working**: whether ceremonies are happening consistently and driving real value, not just filling a calendar.
- **Planning & prioritization**: whether the backlog is well-groomed, work is prioritized by value, and capacity planning is realistic.
- **Technical excellence & quality**: how technical debt is managed and whether quality is built in from the start.
- **Product delivery & customer value**: whether the team is shipping things that matter, and tracking outcomes not just outputs.
- **Agile mindset, culture & continuous improvement**: whether the team genuinely embraces agile values, and whether psychological safety exists to surface problems early.
A team running the DevOps & continuous delivery model would rate themselves on CI/CD pipeline maturity, release and deployment practices, reliability and operations, security and compliance automation, and platform and infrastructure readiness. That is a completely different lens, built for a different context.
This is why model selection matters. The dimensions shape the conversation. Choosing the right one for your team’s current focus is what turns an assessment into a useful discussion rather than a generic survey.
## How agile maturity is measured: the 5-level scale
Once you know what dimensions you’re assessing, you need a scale to score them against. The most widely used structure organizes maturity into five levels, each describing a specific pattern of behavior rather than just a number:
- **Level 1: Initial / Ad hoc**. Processes are unpredictable and reactive. Agile may exist in name only.
- **Level 2: Developing**. Some agile practices are in place but inconsistent. There’s intent, but limited discipline.
- **Level 3: Defined**. Practices are standardized and consistently followed. The team understands not just what they do, but why.
- **Level 4: Managed**. Performance is measured and decisions are data-driven. Feedback loops are tight.
- **Level 5: Optimizing**. Continuous improvement is embedded in the culture. The team innovates its own practices and consistently delivers real customer value.
Each level within a dimension comes with a clear written description of what that level looks like in practice, so team members aren’t guessing what a “3” means. That consistency is what makes the results worth discussing.
Pssst…. Not every team needs to reach Level 5 in every dimension. What matters is knowing where you are and having a deliberate plan for the next step. A team that constantly rates at 5 might be the shining star in the organization or they may lack the benchmarking needed.
## TeamRetro’s maturity assessment models
A maturity model is the framework your assessment runs against. It defines which dimensions are being rated and what each level looks like in your specific context. Choosing the right model for your team’s current situation is what makes the difference between a focused, useful session and a generic exercise that produces a list of things everyone already knows.
TeamRetro offers 20 purpose-built models across the areas agile teams actually care about, along with the opportunity to create your own or to co-create one with AI.
Here are 5 that our team have used recently at our last round of team meetings –
- **Agile teams**: measures how well our team collaborates, plans, and delivers value through agile ways of working.
- **Leadership**: assesses how effectively our leaders inspire vision, communicate strategy, and develop us.
- **DevOps & continuous delivery**: evaluates our pipeline reliability, deployment speed, and operational resilience across our engineering team to deliver outputs to you.
- **Agile delivery**: understands how consistently our team plans, flows work, and improves delivery cycle over cycle.
- **AI adoption maturity**: tracks how confidently our team integrates AI tools into daily workflows with proper governance in place to ensure focussed AI features that bring the you benefit, without compromising on security.
At the industry level, assessments tend to fall into 3 broader categories. Let’s take a deep dive into these.
### Agile delivery
Designed for scrum teams and delivery-focused squads. It assesses how well the team plans and prioritizes work by value; how smoothly and predictably work flows from idea to done; how effectively the team collaborates and self-organizes; and how consistently feedback loops drive genuine improvement. Teams using this model typically run it quarterly, using the results to focus their retrospectives on the dimensions that scored lowest.
### Engineering excellence
Built for [engineering managers](/solutions/engineering-managers-solution/) and senior developers who want to go beyond process and assess technical health. It covers code quality and standards, architecture and scalability decisions, how actively technical debt is being managed, and how well the team enables and supports each other as engineers. It’s particularly useful for teams that score well on agile process metrics but still struggle with delivery predictability: the root cause is often here.
### DevOps & continuous delivery
A [DevOps maturity model](/guides/agile-metrics/maturity-models-and-health-checks/) built around the practices that separate teams who ship confidently from those who dread release day. It assesses CI/CD pipeline maturity, release and deployment processes, reliability and operations, security and compliance automation, and platform and infrastructure readiness. Teams working toward [DORA metric improvements](/guides/agile-metrics/dora-metrics/) often find this model maps directly to where the friction actually lives.
## Agile maturity assessment templates to start from
You do not have to write the rubric yourself. Each of the models above ships as a ready-made template with its dimensions already defined and all five levels described in plain language, so the team rates against the same words rather than against a bare number line.
Start from the model closest to what your team is working on right now. The [agile team assessment](/health-check-templates/agile-teams/) is the general-purpose starting point for a delivery team. [Agile delivery maturity model](/health-check-templates/agile-delivery-maturity-model/) goes deeper on planning and flow. [Engineering excellence](/health-check-templates/engineering-excellence/) and [DevOps & continuous delivery](/health-check-templates/devops-continuous-delivery/) move the lens onto technical health and release practice. The full set sits in the [health check template library](/health-check-templates/), and any of them can be edited, or used as the starting point for a model of your own.
## How to run an agile maturity assessment effectively
The key is to focus on insight and action, not just measurement. TeamRetro’s built-in flow walks teams through each of these steps automatically, but here’s the thinking behind them.
### 1. Choose relevant focus areas
Start with dimensions that are meaningful for your team’s current context. You can choose from purpose-built maturity models covering agile delivery, engineering excellence, DevOps, product management, and more, or build your own from scratch. A Scrum team early in their agile journey has different priorities to a scaled product organization, and your model should reflect that.
### 2. Collect responses privately
Honest feedback only happens when people feel safe giving it. You can collect responses anonymously before any results are shared with the group, removing the social pressure that skews ratings toward what people think leadership wants to hear. Every team member rates each dimension independently, and the aggregated picture only surfaces once everyone has contributed.
### 3. Review results as a radar chart
When results surface in TeamRetro, they appear as a radar chart showing the shape of your team’s maturity at a glance. High scores, low scores, and gaps between dimensions are immediately obvious. There’s no manual aggregation or waiting. You can sort dimensions from most positive to most negative to most mixed, so the conversation starts in the right place.
### 4. Walk through results as a team
TeamRetro’s Presentation Mode syncs screens across the team, in-person or distributed, so the facilitator can walk through results dimension by dimension without losing the room. At [Culture Amp](/case-studies/culture-amp/), a core company value is “learn faster through feedback.” Their engineering teams run both maturity assessments and health checks in TeamRetro precisely because Presentation Mode keeps the conversation anchored to what the data is showing, rather than drifting into anecdotes.
### 5. Prioritize a small number of high-impact improvements
Resist the urge to fix everything at once. With TeamRetro’s AI summaries (which generate commentary for each dimension and across the whole session), patterns emerge quickly, even across teams with a lot to say. Identify the areas where the gap is biggest and where closing it would move the needle most. One well-executed change builds more confidence than five half-finished ones.
### 6. Create accountable actions before you leave the room
This is where most assessments fall apart: the insights evaporate without owners or due dates. Actions are created directly within the session with an owner and a due date assigned before anyone closes their laptop. Those actions carry forward to the next session automatically, so nothing quietly falls off the radar. For teams using Jira, Asana, Trello, or Azure DevOps, action items can be pushed directly to your existing workflow.
### 7. Track trends across sessions
Run the same assessment every quarter or at major milestones. TeamRetro tracks how each dimension moves over time, displaying trend lines directly on the radar so you can see at a glance whether a dimension is improving, static, or regressing. When Ibrahim Abram, Procurement Specialist at Culture Amp, reflected on what he values most in TeamRetro, it was this: “I love the graph that shows the trends.” That’s the difference between a tool and a process.
## Common mistakes to avoid
Even well-intentioned assessments can go sideways. Watch out for these:
- **Treating it as a one-time event**. A single assessment gives you a starting point. The real value is in the trend: knowing whether you’re moving in the right direction and how fast.
- **Letting it become a performance review**. The moment people feel their individual performance is on the line, honest input disappears. Frame it clearly as a tool for the team to improve together. TeamRetro’s anonymous response mode exists specifically for this.
- **Optimizing for scores rather than outcomes**. Teams can game maturity assessments if the incentives are wrong. What matters is whether actual practices and delivery outcomes are improving, not whether the numbers look better.
- **Skipping the action planning**. An assessment without actions is just an interesting conversation. If the session ends without clear next steps and owners, the insight evaporates within a week. TeamRetro makes this the last required step before closing a session.
- **Running it in isolation from retrospectives**. [Agile maturity assessments](/health-checks/agile-maturity-assessment/) and [retrospectives](/retrospectives/) work better together. In TeamRetro, you run both from the same platform, so the themes that keep surfacing in your retros can inform what you focus on in your next maturity assessment, and vice versa.
## Why teams choose TeamRetro for maturity assessments
Most teams that try to run maturity assessments without a dedicated tool hit the same wall: the survey gets built in a spreadsheet, results get pasted into a slide, actions get noted down somewhere, and by the next quarter nobody can remember what was agreed. The insight doesn’t compound. It resets.
Manual assessments often fail because data is scattered across spreadsheets and slides, causing insights to reset every quarter. TeamRetro prevents this by centralizing the process with these key features:
- **Private feedback**: Anonymous responses ensure honest data and a safe environment for teams.
- **AI summaries**: Automated reports for each dimension save time on manual write-ups.
- **Persistent actions**: Assigned tasks carry over between sessions with reminders to ensure accountability.
- **Visual trends**: Radar charts display historical direction to track real improvement over time.
- **Workflow integrations**: Syncs directly with tools like [Jira](/integrations/jira/), [Asana](/integrations/asana/), and [Azure DevOps](/integrations/azure-devops/).
- **Enterprise reporting**: Organizations like Culture Amp use team tagging to compare trends and surface systemic blockers without losing local context.
## Frequently asked questions
### What is the difference between an agile maturity model and an agile maturity assessment?
The model is the framework; the assessment is the act of running it. A maturity model defines which dimensions get rated and writes out what each of the five levels looks like in practice. The assessment is the session where every team member rates those dimensions independently and the team reviews the aggregated result together. Choose the model first, because the dimensions decide what the conversation is about.
### How often should a team run an agile maturity assessment?
Quarterly suits most teams, or at a natural milestone such as the end of a program increment or a real change in how the team works. What matters is a steady cadence rather than a fixed number: often enough to see whether an improvement stuck, not so often that the ratings barely move between sessions.
### Who should take part, and should the ratings be anonymous?
Everyone who does the delivery work, rating independently. Anonymous responses are worth defaulting to, because the moment people think an individual rating will be traced back to them the honest material dries up. Have a facilitator or coach walk the results rather than a manager, and keep the framing on what the team will change next rather than on how the team scored.
### What questions does an agile maturity assessment ask?
Not “do you hold a standup”. A well-built assessment asks whether the underlying work is happening: is the backlog prioritized by value, does work flow predictably from idea to done, is technical debt being managed deliberately, does the team surface problems early, and does anything actually change after a retrospective. Each question is rated against a written description of all five levels, so a “3” carries the same meaning for everyone in the room.
## Ready to run your agile maturity assessment?
Understanding how your team really works today is the first step toward improving it.
An [agile maturity assessment](/health-checks/agile-maturity-assessment/) surfaces the gaps you’ve been sensing but couldn’t quite name, and gives your team a shared, honest foundation for doing something about them.
TeamRetro gives you proven templates, private feedback, radar chart results, trend tracking, AI summaries, and built-in action planning in one place, with zero setup required. To see how that fits together before you start, the page on [agile maturity assessments in TeamRetro](/health-checks/agile-maturity-assessment/) walks through the whole flow, from choosing a model to tracking the trend.
[Start your free assessment today](https://secure.teamretro.com/login/new?cc=www-blog). No credit card required.
---
# AI in Agile Project Management: What Teams Need to Know
URL: https://www.teamretro.com/blog/ai-agile-project-management/
If you've been searching for "ai in agile project management" lately, you're in good company. The [AI4Agile Practitioners Report 2026](https://www.scrum.org/resources/blog/ai4agile-practitioners-report-2026) found that 83% of agile practitioners now use AI tools, yet 55% spend 10% or less of their working time with them, and only 15% have had any formal training in using AI in an agile context. Adoption is nearly universal. Depth isn't.
That gap is what this guide is about. Not another opinion piece on whether AI will replace Scrum Masters (the industry has largely moved past that question), but a round-up of what the 2026 research and framework updates actually say: where AI fits across the agile lifecycle, how the Scrum Master role is being redefined, and what teams are doing in their first few sprints of adoption. Where our own experience at TeamRetro is relevant, we'll say so. Where it isn't, we'll point you at the source material instead.
## What AI in Agile Project Management Really Means
In agile delivery, AI means using machine learning and automation to support how teams plan, build, reflect, and continuously improve, without handing over the judgment calls humans need to make.
A useful way to think about it comes from Dave West's *Scrum Master 2.0: The AI Catalyst* keynote at the Online Scrum Summit 2026, which describes four engagement modes:
- **With AI**: tools enhance individual productivity. Most teams start (and stall) here.
- **Through AI**: software created by describing intent; specification quality and validation become the bottleneck, not development.
- **To AI**: AI acts with meaningful autonomy, and Scrum evolves toward a governance and oversight framework.
- **Of AI**: the product itself is AI, making model evaluation and data pipelines first-class engineering concerns.
Knowing which mode your team is in matters, because, as West notes, most teams think they're working "with AI" while quietly drifting "through AI" without redesigning anything about how they work together.
## What the 2026 Data Says About AI in Agile Teams
The most consistent finding across the current research is a speed paradox: individual gains don't automatically become team gains.
The OSM 2026 keynote pulls the evidence together. Controlled studies show AI completing certain development tasks 55% faster (GitHub/Microsoft, 2025). But longitudinal research across 211 million lines of code found code duplication quadrupled as AI adoption rose (GitClear, 2024), and a 2025 METR trial found no statistically significant productivity gain, even though participants believed they were 20% faster. As West puts it: "Individual fluency is not team capability — and nobody is accountable for closing that gap."
The AI4Agile report points to the same conclusion from the practitioner side. The biggest barrier to adoption isn't skepticism or tooling. It's integration uncertainty (54%): teams don't know where AI fits in their workflows. And the area where practitioners report the clearest value is the unglamorous one: drafting, summarizing, preparing, and documenting. AI earns its keep by creating space for facilitation, dialogue, and decision-making, not by replacing them.
## Where AI Fits Across the Agile Delivery Lifecycle
### Sprint planning and backlog refinement
AI-Native SAFe, released by Scaled Agile in June 2026, recommends starting with forecasting, knowledge discovery, and backlog refinement, augmenting the informed bets that planning has always been about. In practice that means historical velocity data flagging an overloaded sprint before it starts, and surfacing backlog items that lack enough definition to be picked up safely. For distributed teams planning async, that signal replaces the real-time gut-check a co-located team gets for free.
One caution from the OSM keynote: five AI-accelerated developers without a shared Sprint Goal create five diverging solutions, faster than ever. AI raises the stakes on alignment; it doesn't lower them.
### Delivery quality and the Definition of Done
This is where the 2026 guidance is most pointed. AI generates output fast; the Definition of Done is what ensures it's genuinely done, not done-ish. West's recommendation is to add explicit AI quality gates to the DoD: review checkpoints at consequential handoffs where human judgment is deliberately preserved. The GitClear duplication data is the argument for why: unreviewed AI output degrades quality quietly, in places nobody is watching.
### Retrospectives without the admin load
This is the part of the lifecycle we know best at TeamRetro, so treat this section as practitioner experience rather than neutral reporting.
The retrospective is where the industry conversation and the tooling meet. The AI4Agile finding (AI is most valued for summarizing and documenting) describes exactly the admin load that undermines retros: sorting feedback, writing up notes, chasing action items between sprints. In [TeamRetro](/retrospectives/), Auto-Suggest Groups clusters similar feedback during the Group step so teams move straight to discussion, and AI-Suggested Actions generates next steps tied back to the specific ideas that shaped them: reasoning shown, team votes, no black-box output the facilitator has to defend. For a step-by-step look at how each of these features works, see our guide to [AI-powered retrospective features](/blog/ai-tools-that-make-agile-retrospectives-easier-and-smarter/).
The OSM keynote adds a practice we'd underline: give your retrospective a standing AI lens. What did we delegate this sprint? What did we review? What did we trust too much? Teams that have never retrospected on their own AI use are, in West's words, the most dangerous kind: they think AI is going well because individuals are productive, but have never looked at it collectively.
*Want to try an AI-assisted retro with an AI lens built in?* [*Run one free in TeamRetro*](/). *No setup required.*
### Team health and sentiment over time
Research into remote retrospectives has found that [anonymity creates a more secure environment for honest feedback](https://www.researchgate.net/publication/392212352_Strategies_for_Effective_Remote_Retrospectives_Exploring_Retrospective_Games_Anonymity_and_Continuous_Reflection): psychological safety is simply harder to establish through a screen. The OSM keynote makes the same point from the other direction: humans working alongside AI need *more* trust to speak up when something looks wrong, not less.
AI helps here at the pattern level. In TeamRetro, the [Insights dashboard](/blog/unearthing-valuable-metrics-from-retrospective-and-health-checks/) tracks sentiment themes across retrospectives and [health checks](/health-checks/) over time, so if "deployment process" keeps surfacing across three consecutive retros, or psychological safety scores are quietly declining, it shows up in [the trend data](/blog/ai-sentiment-analysis-in-retrospectives/) rather than a spreadsheet nobody opens.
## The Scrum Master's New Role: The AI Catalyst
The sharpest reframing of 2026 belongs to Scrum.org. The Scrum Master's accountability hasn't changed (the 2020 Scrum Guide still says "the Scrum Team's effectiveness"), but what effectiveness means has. In 2026, it means ensuring AI accelerates the team, not just the individuals inside it.
West calls this the **AI Catalyst**: not the team's AI expert, but its AI effectiveness leader, working three moves: *diagnose* (where is the team on the fluency ladder, and which engagement mode is it really in?), *design* (recalibrate existing Scrum events for AI-assisted work rather than bolting on new ceremonies), and *develop* (build team habits like prompt templates, shared standards, and review checkpoints, not individual hacks).
One risk the keynote names that deserves wider attention: **capability debt**. When AI takes over the execution work that used to build junior practitioners' judgment, someone has to design deliberate learning pathways alongside AI use. That's a coaching problem, not a tooling one, and it lands squarely in the Scrum Master's lap.
## Governing AI at Scale: Lessons From AI-Native SAFe
For teams in scaled environments, [AI-Native SAFe](https://framework.scaledagile.com/ai/) (June 2026) signals where enterprise expectations are heading: smaller, AI-augmented teams; shorter, more iterative work cycles; and, notably, handoffs between humans and AI explicitly designed into the operating model rather than left to individual interpretation. It also introduces an "AI value architect" role covering cost, ethics, legal, and risk, and elevates governance, specifications and intent, and curated data management to first-class framework elements.
You don't need to run SAFe for the takeaway to apply: at any scale, the pattern is the same. Pair AI pilots with governance and outcome-focused KPIs, and design the human/AI handoffs on purpose.
## How to Introduce AI Into Your Agile Workflow
The OSM keynote closes with a three-sprint plan that matches what we've seen work: start small, stay empirical, and treat adoption itself as something to inspect and adapt.
1. **This sprint: diagnose.** Run a team-level AI fluency assessment, not a tool audit. Which engagement mode are you actually in? Where is AI being used individually and invisibly versus collectively and transparently? Be honest.
2. **Next sprint: design.** Update your Definition of Done for AI-generated output. Run one retrospective with an explicit AI lens: where did we trust too much?
3. **The sprint after: develop.** Build one shared workflow with prompt templates and review checkpoints, moving fluency from individual to team level.
4. **Ongoing: keep the ladder moving.** Retrospect on AI every sprint. Treat capability debt as a backlog item. Track whether recurring blockers are actually declining. TeamRetro's [Insights dashboard](/blog/unearthing-valuable-metrics-from-retrospective-and-health-checks/) makes that trend visible across as many teams as you run.
Two principles hold throughout. Be transparent about what the AI is doing: [psychological safety in retrospectives](/blog/how-online-retrospective-tools-build-psychological-safety/) collapses if people don't know whether feedback is anonymous or how AI is using it. And keep the facilitator in the room: AI handles grouping, summarizing, and suggesting, but it doesn't read the room. As West puts it: "You don't need a transformation programme. You need empiricism applied to AI adoption — one sprint at a time."
## The Risks of AI in Agile and How to Manage Them
**Overreliance on the output.** The worst version of AI-assisted delivery is a team waiting for the AI to tell them what they think. The honest disagreement (the moment someone finally says the thing nobody's been saying) can't be automated.
**Thin data producing thin insights.** Pattern detection is only as good as its inputs. New teams, low-participation teams, and performative retros will get outputs that don't reflect reality. Treat insights as a prompt for discussion, not ground truth.
**Capability debt.** Covered above, but worth repeating as a risk: if juniors stop doing the work that builds judgment, your team's future capability is quietly eroding while its current velocity looks great.
**Privacy and data security.** Retrospective feedback is sensitive. [Research into agile tool adoption](https://arxiv.org/abs/2508.03369) consistently flags privacy and trust as top adoption blockers. Check where your data lives and who can access it. TeamRetro holds a [SOC 2 Type 2 report](/security/) and is GDPR compliant, and customer data is never used to train AI models.
## What AI Changes About Agile and What It Doesn't
The 2026 evidence points one direction: AI in agile project management doesn't change what the ceremonies are for. It changes how much friction they carry, and it raises the bar on the human work of alignment, judgment, and honest conversation.
The frameworks agree on more than they differ. Scrum.org says upgrade your existing events rather than adding AI ceremonies on top. SAFe says design the human/AI handoffs deliberately and govern them. The practitioner data says AI's real value is clearing the admin so the conversation can happen. What's left, once the grouping is automatic and the summary writes itself, is the conversation. And the conversation was always the point.
That's the principle TeamRetro's AI features are built on: the AI shows its work, and the team stays in control. If you want to see what that looks like in your next retro, [try TeamRetro free with your team](/).
**Sources referenced:** [AI4Agile Practitioners Report 2026 (Scrum.org)](https://www.scrum.org/resources/blog/ai4agile-practitioners-report-2026) · Dave West, *Scrum Master 2.0: The AI Catalyst*, Online Scrum Summit 2026 · [AI-Native SAFe / Scaled Agile AI guidance](https://framework.scaledagile.com/ai/) · [GitClear code quality research](https://www.gitclear.com/) · [Remote retrospectives and anonymity research](https://www.researchgate.net/publication/392212352_Strategies_for_Effective_Remote_Retrospectives_Exploring_Retrospective_Games_Anonymity_and_Continuous_Reflection)
---
# AI sentiment in retrospectives: what it could mean for your team
URL: https://www.teamretro.com/blog/ai-sentiment-analysis-in-retrospectives/
Every team that runs retrospectives is quietly keeping a record of how it feels. Each month, a few dozen notes say what went well, what didn't, and what needs to change. Over a year, that adds up to hundreds of honest observations about how the team works, and how it has evolved.
But in reality, not everybody rereads them. The retro ends, the actions get written up, and the board is archived. The patterns are all in there, spread across a dozen boards. They're just not anywhere you can see them at once.
That's where using AI to explore team sentiment in retrospectives can help. In TeamRetro, AI securely reads what the team writes in every retro over time, and lets you and the team explore it further with:
- word clouds with drill-downs
- trAI, the built-in chat assistant
- trend lines in your team [Insights](/retrospectives/features/).
Below, we show what AI sentiment analysis looks like in TeamRetro, using one of our own teams as an example.
## What AI reads in a retrospective, and what it doesn't
TeamRetro's AI works from what your team writes in a retrospective. In Insights, it annotates the discussion with a theme, a sentiment, and keywords. The themes are the ones a retrospective keeps returning to: team dynamics, planning, people, leadership, process, and engineering. Your data is safe, isn't used to train models, and is not accessible to people who don't have the right access to your team.
The output unit is the topic or the theme, not the person. Nobody gets a mood score. That isn't a judgment AI should make. The AI doesn't read faces, tone of voice, calendars, or chat outside the meeting. It reads only what people chose to write down in the retro, so the signal is only as good as the retro that produced it.
The analysis runs on AWS Bedrock using Anthropic's Claude Sonnet 5.x. It's on by default and can be turned off at any time. Your data is processed briefly and is never stored or used to train the AI. TeamRetro does not build or train models of its own. Where the AI suggests something the team then acts on, a summary, a grouping or an action, a person reviews it and decides what to keep. The full detail, including the guardrails that monitor and restrict AI use, is on the [Responsible AI](/responsible-ai/) page.
There's no analysis of individuals. That would simply break psychological safety. What we want to know is what issues teams are currently putting forward for discussion based on the retrospective prompts.
In short, AI can tell us which topics are being brought up and whether they're framed more positively or negatively based on the context, headers, and theme of the retrospective.
## How we analyzed sentiment in our own retrospectives
Our marketing team made a good test case. It's four to seven people, it's stable, and it has worked together for a few years. Lately, though, it has taken on more: new projects, more responsibility, and a steady stream of feature releases to support. That kind of pressure tends to show up in a retro before it shows up anywhere else.
So we followed one thread, starting in a retro and looking at it from five views, each a different way of seeing the same retro data: trAI in the meeting, the word cloud and the sentiment trends chart in Insights, the team's own history through Claude over MCP, and finally what the team had done about it.
The data covers 11 monthly retros and 436 retro items, and we checked every finding against what the team actually wrote. Names and individual comments stay private, so what follows is aggregated. It's one small team, so treat it as a worked example, not a benchmark.
### View 1: in the meeting, with trAI
Each month we change our retro format to explore a different theme. In July, for example, we framed it around wins, battles, lessons and next steps:
During our latest retro, rather than rely on memory, we asked trAI to look back at the two retros before it:
It read both, pulled out the main concerns from each, and ranked them by the team's votes. Two had come up in both July and August: gaps in how we follow things up, and who looks after our AI agent workflows. Seeing them side by side, we put both straight onto that retro's agenda.
Still, two retros don't make a pattern. Was this a blip, or something bigger?
### View 2: the word cloud in team Insights
So at the end of the meeting, we stepped back and opened the word cloud in team Insights for the last quarter.
Shown by theme, the word cloud sizes each term by how often it came up and colors it by sentiment. Our Ceremonies & Meetings cloud was mostly big and green, with Meeting Cadence, Marketing Meetings, Standups and Retrospectives all prominent, a sign the team values its rituals.
Two smaller terms were red, though: **Meeting Scheduling** and **Communication Clarity**.
Drilling into them turned up calendar conflicts, and some uncertainty about how to manage the team kanban board, from classifying cards to making sure they're complete.
So the team's rituals were sound, but the scheduling and communication around them needed work. To see whether that was part of a wider shift, we needed a longer view.
### View 3: the team sentiment trends chart
That meant zooming out to the whole year. The trend chart in Insights tracks sentiment over time, alongside an AI-written summary of the major themes.
We used the breakdown view, which shows each sentiment as a share of all responses: green positive, gray neutral, red negative. Hovering over a point shows the split for the last known retrospective, and August caught our eye:
By August, our retros had turned noticeably redder. Negative responses had grown from under 7% at the start of the year to 31%.
That sounds alarming, but a redder chart isn't automatically bad news; sometimes it means a team is finally saying what needs to change. What the chart couldn't tell us was why.
#### The AI summary: where we looked first
Directly under the chart, an AI-written summary condenses everything the team wrote across the period into one paragraph. Ours was upbeat about the big picture, saying AI tools *"drive strong positive momentum."* It also named three things the team kept raising:
- *"meeting overload and scheduling overlaps create friction"*
- *"follow-up processes and communication clarity flagged as pain points"*
- *"ownership and role clarity spark tension, particularly around accountability and AI oversight decisions"*
There they were again: the follow-up gaps and AI oversight trAI had flagged, plus the meeting friction from the word cloud. Nobody had to reread a year of sticky notes to find them. **Use the summary to know where to look; use the themes to check it.**
#### The theme breakdown: checking the summary
To check it, we looked at the rows below the summary. Each recurring theme is drawn as a band: the thicker the band, the more the team wrote about that theme, and its color shows sentiment. **Read the thickness before the color.** A thick red band is something the whole team is raising, often under a topic such as "What isn't working?" or "What didn't go well?"
Around August, three themes carried most of the red:
- **Meeting Cadence & Optimization** swelled over June and July, with red running through it.
- **Communication Clarity & Channels** carried red through the middle of the year.
- **Dev & Automation Tools** was thick, with red underneath, as the team worked out who looks after the automated workflows it had built.
Underneath the Meeting Cadence swell is what the team actually wrote, like this from a single retro:
- *"Having too many meetings in one day - need to consolidate"*
- *"Ops meetings are important for check-ins – but don't have to be the full planned hour if not needed"*
- *"Can we put 5–10 min breaks between meetings?"*
- *"Individual kanban meetings – make it part of the weekly marketing meeting instead"*
### View 4: the rear-view mirror, with Claude over MCP
By now we knew what the team was raising, but not how long it had been building, so we went back to the team's own history.
We connected Claude to TeamRetro over MCP, which lets it read the retrospectives themselves (the cards, votes and actions), and asked it to trace each concern back through the year.
Every major theme had started small. Meeting load first appeared in February as a single card asking for fewer meetings, and by June it was the top-voted group. Follow-up and delegation began the same way, with one card about repeated reminders. Those first cards were thin lines in the themes view, easy to scroll past, and they only became clear priorities once the team started voting them up and flagging them as something to fix.
### View 5: the team's actions (arguably the most important view)
Spotting the pattern was only half the job. The other half was checking we'd done something about it. We asked Claude which actions came out of each theme and whether they'd been done. Most had:
- **Meetings.** The team dropped two recurring meetings, folding their items into the weekly marketing meeting, and moved its ticket review to the afternoon to keep mornings clear. A later retro noted: *"Stand-ups have improved and the quick sharing of daily focus has helped with staying on time."* Protecting focus time is next, with a shared booking system for focus slots now an open action.
- **Follow-up.** The team changed the retro itself, adding an opening column that asks *"What did you reflect, change and improve on from the last retrospective?"*, so follow-through gets checked in the room.
- **AI workflows.** The team ran prompt-sharing sessions, brought more people onto the same AI tools, and set up a monthly session to share how everyone's workflows run.
Some of these landed quickly; others are still in progress. That brought us back to where we started: the retro. The open items, like protecting focus time, carry into the next one, and the chart will show whether the red moves on to the next thing worth improving.
## The lessons we learned along the way
### A neutral chart can mislead
Around April, our chart went almost entirely gray, with 84% of responses neutral. It looked as if the team had gone flat.
It hadn't. That month's retro was run as an agenda, with topics called To Discuss, In Progress and Discussed, and short items like "R&D Submission". Status updates don't say how anyone feels, so the chart had little to read.
### Only positive sentiment could mean a winning or a dysfunctional team
If your team's sentiment is only ever positive, it could mean people don't feel safe saying what's really on their minds. Or the team may be doing so well that it isn't facing many challenges, and it's time to review the meeting's cadence or purpose, or try a different format. Either way, it's up to the Scrum Master to decide what to do next.
## Negative sentiment in a retrospective isn't always a bad sign
A single retro's sentiment is mostly noise. One hard sprint, one release, one departure will color an afternoon. The pattern is what matters, and ours showed a team that was asked what needed to change, answered specifically, and acted on it.
| Healthy red | Worth a closer look |
| --- | --- |
| You asked for it: the topic invites what needs to change | Red everywhere, with no clear theme behind it |
| It is specific: you can name the theme and the terms | The same red returning unchanged, retro after retro |
| It moves: once you act, the conversation shifts to the next issue | Silence: gray where you expected opinions |
None of the tools decided that for us. The team decided what it meant and what to do about it, in the room, with the people who wrote the words. What AI did was offer suggestions and prompts, and flag trends.
## How to use AI sentiment analysis in your retrospectives
1. **Read it as a prompt, not a verdict.** Open the next retro on the theme whose line moved: "Meetings have come up for three retros now. What would help?"
2. **Look at the moving lines first.** A theme that is turning negative and being raised more often is the one that will fill the next retro whether you plan for it or not.
3. **Keep it at team level.** Sentiment belongs to topics and themes. Don't try to work backwards to who wrote what; the retrospective's anonymity settings exist so people can be honest.
4. **Pair it with your health checks.** A [health check](/health-checks/) asks how the team feels, on a scale, about dimensions you chose in advance. Sentiment analysis reads what the team chose to raise. When the two agree, you have a pattern. When they disagree, you have found the conversation for your next retro.
5. **Don't trade the retro for the chart.** Cut the retros, or run them so nobody writes what they think, and the chart goes quiet at exactly the moment the team has the most to say.
**Questions worth asking.** These are the prompts we used, or ones the tools are built for:
- "What did our last two retrospectives ask, and what concerns came up?" (trAI)
- "Which concerns showed up as small signals before becoming major themes?" (Claude or another assistant over MCP)
- "What actions came out of our meeting-related feedback, and are they done?" (over MCP)
- "Summarize our last retrospective." (trAI or over MCP)
## Getting started with sentiment analysis in TeamRetro
Open Insights for any team that has run a few retrospectives in TeamRetro and look at the theme and sentiment trend chart first. The [help center article on topic sentiment](https://help.teamretro.com/article/374-topic-sentiment) walks through the five options for a topic's label and how the AI can analyze comments. If your team is not on TeamRetro yet, [start a free trial](https://secure.teamretro.com/login/new), run three retrospectives, and see what the trend line says about the fourth.
## Frequently asked questions
### What does AI sentiment analysis in a retrospective actually analyze?
AI sentiment analysis in a retrospective reads what your team writes during the meeting. In TeamRetro Insights, the AI annotates the discussion with a theme, a sentiment and keywords, and the trend chart shows positive, neutral and negative sentiment for each recurring theme over time, with word clouds, real examples and an AI-written summary behind it.
### Can it tell who wrote a negative comment?
Sentiment is assigned to topics and themes, not to people, so there is no per-person mood score. Whether comments include names depends on the anonymity setting you chose for the retrospective, which stays under your control.
### Which TeamRetro plans include AI sentiment analysis?
Team-level sentiment and topic insights are included on every plan, from a single team up to a large organization. Cross-team Insights and Reports, which compare sentiment across many teams in one account, are part of the Enterprise plan.
### Is our retrospective data used to train AI?
No. The analysis runs through AWS Bedrock, is on by default and can be turned off at any time. The data is processed briefly and is never stored or used to train the AI, and TeamRetro does not build or train models of its own.
---
# AI-powered retrospective features that make agile retrospectives easier and smarter
URL: https://www.teamretro.com/blog/ai-tools-that-make-agile-retrospectives-easier-and-smarter/
At TeamRetro, we’re passionate about helping teams continuously improve through the power of agile retrospectives. Not only is your time valuable, but we want to ensure the effort spent on the do-inspect-adapt cycle empowers teams to make meaningful adjustments.
We’ve developed a suite of AI-powered features designed to take your retrospectives to the next level. With TeamRetro, teams can streamline the retrospective process and save time on meeting preparation. Tedious tasks can be automated. Valuable insights are scoured and surfaced and actions can be recommended based on the discussion. Finally, it can even provide you with a summary of comments, as well as the overall meeting – ready to share.
Green flag! TeamRetro’s AI features prioritize data privacy: your retrospective data is never stored or used for training AI models, ensuring your sessions remain confidential and secure.
Ready to find out more?
This article will walk you through what it feels like having an AI powered agile retrospective, offer warnings and tips about AI, and how you can get the most out of TeamRetro’s AI functionality.
This post focuses on TeamRetro’s own AI features. For the wider picture, how AI is reshaping planning, delivery, and team health across the whole agile lifecycle, see our round-up of [AI in agile project management](/blog/ai-agile-project-management/).
## Keep things fresh with new AI generated retrospectives
Sick of the same old retro but can’t find a good set of new questions. Our [Generative AI](https://help.teamretro.com/article/386-using-ai-generated-templates) suggests various retrospective formats based on the key problem you are trying to solve. Not only can this help align the retrospective more directly with your current team needs, but also save you meeting preparation time.
Here’s one created in a few seconds to focus on Customer Value with the team.
AI provides a suggested format you can put into play straight away, or tweak to suit. Being able to provide a few prompts such as your language, team type and even the number of topics helps you quickly generate a brand new, fresh set of questions that will help pull your team out of the dreary mundane to a newly engaging think tank.
## Kickstart your retrospective sessions with AI-generated icebreakers
Creating a comfortable, engaged atmosphere from the very start can be key to a successful retrospective. [Icebreakers](https://help.teamretro.com/article/405-the-retrospective-process-icebreaker) can ease the session, boost energy and encourage openness without it being a time sink.
Add a quick prompt to get suggested icebreaker questions that fit your team’s mood or style.
Based on your prompt, TeamRetro’s AI will offer a list of questions to choose from. Each option is crafted to help meet specific objectives, whether it’s building rapport, tapping into creativity, or just getting everyone talking. You can review the list, pick the question that feels right for the group, and easily set the tone for a productive retrospective.
Once you select a question, you can run a facilitated icebreaker session that’s both time-boxed and interactive, keeping things efficient and fun.
## Streamline your discussions with automated grouping
Our [Automated Grouping](https://help.teamretro.com/article/160-retrospective-group-step) feature helps teams cut through the clutter and focus on what really matters by organizing similar feedback into clusters based on common themes. Instead of manually sorting through each comment, TeamRetro’s AI automatically groups feedback, so you can easily see patterns or themes. Grouping these will make it easier for the team to prioritize the topics that need the most attention.
Beyond simple semantics, AI-powered grouping takes into account the context of what is being said, the headers, and the themes to help pull together a list of suggestions that allow Scrum Masters and the team to more quickly make sense of the data. They can agree or disagree with groupings until they have reached a common understanding of the ideas.
## Get quick AI-generated insights of individual health check comments
It’s easy to feel overwhelmed by the amount of input when each team member provides detailed feedback. Our [AI-powered Summarization](https://help.teamretro.com/article/191-the-health-check-process-discuss) feature takes care of this by distilling comments into concise summaries.
These instant summaries show you the key issues and to see the overall team morale at a glance, without missing out on individual comments. By having the essence of each comment captured, the facilitator can address main points quickly, keeping the conversations concise, while honoring individual contributions.
## Clear, customizable meeting summaries
TeamRetro’s [AI-powered Meeting Summaries](https://help.teamretro.com/article/167-retrospective-share-step) bring retrospectives and health checks to a new level by providing a clear, concise overview of each session, including the outcomes and action items. This feature captures the main topics discussed, key themes, and the overall sentiment of the team, allowing people to see the big picture.
Each summary highlights:
- **Key Topics and Themes**: A quick glance reveals the top issues and successes, making it easy to track recurring themes across meetings.
- **[Sentiment Analysis](/blog/ai-sentiment-analysis-in-retrospectives/)**: Gain insights into team sentiment to understand overall morale and address underlying concerns proactively.
- **Actionable Outcomes**: Summaries include key outcomes and action items, making follow-ups easy and ensuring issues are tracked over time.
For added flexibility, facilitators can edit these AI-generated summaries to fine-tune details or emphasize specific points, speeding up the documentation process. Once finalized, the summary can be easily shared with the team, keeping everyone aligned and ensuring feedback leads to meaningful improvements.
## Get inspiration from automated AI suggested actions
One of the most valuable parts of any retrospective is translating feedback into concrete action items. TeamRetro’s AI-Generated Action Suggestions simplify this by analyzing recurring themes and suggesting actions for your team to consider.
Based on the feedback collected, TeamRetro’s AI suggests specific actions that address key issues. For example, if recurring feedback points to a backlog that is being overloaded or has not been reviewed and that user stories are not being well prioritized or managed, the AI might suggest setting up a structured backlog grooming process.
Once actions are agreed upon and committed, they can then be assigned owners, priorities and deadlines or integrated into the team’s workflow.
## AI-powered vs human-powered retrospectives: creating the perfect balance
While we do love what AI can do to support and enrich meetings, save on time and spark new conversations, we do also believe that it is most effective when it complements, rather than replaces, human facilitation. AI is the ally to the Scrum Master or Agile coach in leading engaging and productive discussions.
### Empathy and intuition: the human edge in retrospectives
Scrum Masters and Agile Coaches bring empathy, intuition, and real-time adaptability that make retrospectives a space where team members feel comfortable and valued. While AI can efficiently process data and identify patterns, human facilitators create an environment where trust and engagement naturally thrive. They remain the eyes, ears, and perhaps the heart on the ground.
While their AI companion churns away in the background, this gives them more capacity to scan the room and get a read of the room, and adjust the flow and energy as needed. Retrospectives often delve into deeper areas, including interpersonal dynamics and team morale. TeamRetro’s AI can highlight recurring themes, but it is the skilled facilitation of a Scrum Master or Agile Coach that helps guide these discussions with care and confidentiality.
By combining AI-driven insights with the facilitator’s experience and adaptability, teams get the best of both worlds: fast access to data and a nuanced approach that ensures the discussion stays relevant and impactful.
## Tips for effective AI integration in agile retrospectives
To help teams make the most of TeamRetro’s AI-powered tools, here are some practical tips for integrating AI seamlessly:
1. **Start Small** – AI doesn’t have to take over the whole process. It can simply be a workhorse for creating a final summary or just coming up with a new retro format. Introducing new workflows and features over time makes it easier to manage.
2. **Use AI suggestions as discussion prompts** – While teams can be impressed by the speed and accuracy of AI, such as grouping and offering suggested actions, this is also a good time to discuss and debate these prompts. As facilitators, this gives another opportunity to engage folks in critical thinking.
3. **Encourage better input.** AI can be an interesting way to see if the meaning and context of what people have written translate well into more summarized and aggregated formats. It can help be a litmus test for whether or not people have communicated their thoughts well enough to be understood by others.
4. **Make it your own** – Modify AI suggestions and outputs to what makes sense for the teams or individual. This little bit of sense-making will help people re-take ownership of the idea or action.
5. **Get feedback** – You could even run a retro on how AI impacts your team. Very meta!
With the right balance between AI tools and human facilitation, TeamRetro’s platform empowers your teams to get more out of their retrospectives, driving continuous improvement and team cohesion.
Ready to see how AI can transform your agile retrospectives? TeamRetro’s AI-powered tools make it easy to streamline your feedback process, identify key insights, and generate actionable steps. Start your journey with TeamRetro to create engaging, efficient retrospectives that drive continuous improvement every sprint.
**[Try TeamRetro today](https://secure.teamretro.com/login/new?cc=www-blog)** and experience a smarter way to facilitate retrospectives!
---
# 10 retrospective anti-patterns to avoid in 2026 for better team engagement
URL: https://www.teamretro.com/blog/avoid-these-retrospective-anti-patterns/
Retrospectives are a cornerstone of Agile, enabling teams to reflect, learn, and improve continuously. But even with the best intentions, retrospectives can fall victim to anti-patterns: subtle, recurring practices that reduce their value. It can leave the team with a bitter distaste for what should be a meeting that is designed to empower and encourage positive change.
As we enter 2026, let’s explore common retrospective anti-patterns, their consequences, and actionable solutions to ensure your retrospectives remain effective and engaging.
## 1. The “blame game”
**What it looks like:**
Team members use the retrospective as an opportunity to blame each other instead of addressing systemic issues, creating a toxic and unproductive environment.
**Real-life example:**
After a sprint with a failed deliverable, one developer blamed the testers for slow feedback, while the testers blamed incomplete stories. This led to arguments instead of solutions.
**How to avoid it:**
- Focus on processes, not people. Reframe personal attacks to encourage problem solving, not person blaming.
- Remind people of the Agile Prime directive as needed.
- Use tools like the 5 Whys technique to find root causes so that it moves the conversation forward.
- Create a psychologically safe space as Esther Derby highlights in *Agile Retrospectives: Making Good Teams Great*.
**Further Resources:**
- [Esther Derby’s Blog](https://www.estherderby.com)
- [How to Manage the BMW’s in meeting](/blog/how-to-manage-bmw-in-retrospectives/)
## 2. The team dysfunctions take over
**What it looks like**:
Underlying team dysfunctions such as mistrust, fear of conflict, or lack of commitment overshadow the retrospective.
**Real-life example**:
A team avoided discussing a critical defect issue due to fear of offending the lead developer. The problem then resurfaced multiple times, eroding trust and morale. The fear of saying anything only got worse over time.
**How to avoid it**:
- Address dysfunctions head-on using tools like Patrick Lencioni’s [Five Dysfunctions of a Team model](/guides/team-dynamics/five-dysfunctions-of-a-team/).
- Use exercises like creating Team Agreements to establish norms for respectful and open communication.
- Consider leveraging [online retrospective tools](/retrospective-tool/) like TeamRetro, which includes features to facilitate anonymous feedback, ensuring everyone can safely share their ideas.
**Resources**:
- [The Five Dysfunctions of a Team by Patrick Lencioni Exercise by Agile Mastery UK](https://agilemastery.co.uk/teams#049221d7-31c9-4a66-9ee9-69fb3abfb4a4)
- [Creating Social Contracts with Team Agreements that Improve Culture](/blog/create-social-contracts-with-team-agreements-that-improve-culture/)
- [Scrum.org – Creating a Team Working Agreement](https://www.scrum.org/resources/creating-team-working-agreement)
## 3. Lack of outcomes or action items
**What it looks like**:
Retrospectives end without clear, actionable next steps, leaving issues unresolved.
**Real-life example**:
A team repeatedly flagged poor sprint planning as an issue but didn’t create actionable steps to address it. The problem persisted, reducing the team’s trust in retrospectives and not understanding its value.
**How to avoid it**:
- Use the SMART framework to create specific, measurable, achievable, relevant, and time-bound action items.
- Assign ownership to each action and follow up in the next sprint review. [In our own data](/guides/follow-through-index/), actions with a named owner and a due date complete about 90% of the time.
- Ensure follow-up on actions from retro to retro, celebrate wins, and monitor progress.
**Resources**:
- [SMART Criteria – Wikipedia](https://en.wikipedia.org/wiki/SMART_criteria)
- [Action Tracking in TeamRetro](https://help.teamretro.com/category/184-tracking-actions)
## 4. The “groundhog day” retrospective
**What it looks like**:
Teams repeatedly discuss the same problems in every retrospective without resolving them. The question set is always the same, and responses are predictable, familiar, and static.
**Real-life example**:
For consistency, the same retro format was being used each sprint, and because of the nature of the product and job roles, the same repeated ideas and problems were coming up each fortnight. There didn’t seem to be any need for the retrospective.
**How to avoid it**:
- Prioritize and limit the number of issues tackled in each sprint.
- Focus on a specific theme or an aspect of the sprint that allows the team to focus on their ideas.
- Change the retro format or questions to explore different angles and perspectives.
- Change who facilitates the meeting or invite an observer or external facilitator.
**Resources**:
- [Choose the best retrospective meeting template for your meeting](/retrospective-templates/)
- [Scrum Paradigms: Chickens Vs Pigs – The Observer Role in Agile Meetings](/blog/scrum-paradigms-chickens-vs-pigs-the-observer-role-in-agile-meetings/)
## 5. Not having a clear process
**What it looks like**:
Retrospectives lack structure, leading to meandering conversations and missed opportunities for valuable insights. The meetings can go over time, or there isn’t the ability to have divergent and convergent thinking, discuss items in priority, or have meaningful discussions on individual items. The process changes each time, which also takes time for the team to relearn what needs to be done each time.
**Real-life example**:
Without a defined format, a team spent an entire retrospective debating tooling preferences, agreeing on a format and set of questions, and finding the right materials to start the brainstorming process, leaving no time to discuss sprint-related challenges.
**How to avoid it**:
- Use structured retrospective formats like Start-Stop-Continue or Sailboat retrospectives.
- Define objectives before the meeting and use a facilitator to guide discussions.
- Have [time-boxed](/blog/making-the-most-out-of-remote-retrospectives/) steps that go from opening the retro, reviewing the agile prime directive, reviewing previous actions, sharing the theme of the current process, and then having a clear process for ideation, prioritization, discussion, and action planning.
## 6. Skipping a retrospective
**What it looks like**:
Teams decide to skip retrospectives due to time constraints or assuming “everything is fine.”
**Real-life example**:
A team skipped retrospectives during a hectic product launch, believing they were unnecessary. Over time, unresolved issues piled up, causing delays and team frustration.
**How to avoid it**:
- Treat retrospectives as non-negotiable. They are essential for continuous improvement, even during busy periods.
- Keep them short and focused if time is limited.
- Remind teams of the value of retrospectives using data from past improvements.
**Resources**:
- [Benefits of Retrospectives – Mountain Goat Software](https://www.mountaingoatsoftware.com)
- [Why Regular Retrospectives Matter – Scrum Alliance](https://www.scrumalliance.org)
## 7. The “hijacked agenda”
**What it looks like**:
Discussions veer off-topic, dominated by a single individual or unrelated issues.
**How to avoid it**:
- Politely redirect tangents and consider anonymous contributions to ensure inclusivity.
- Park ideas that don’t relate to the current theme or focus of the retro.
## 8. Focusing on things outside the circle of influence and concern
**What it looks like**:
Team discussions revolve around problems outside their control or influence, such as company-wide policies or market conditions, leading to frustration and a sense of helplessness.
**Real-life example**:
In one retrospective, the team spent the majority of the time complaining about upper management decisions and market competition, leaving little energy or time to address internal processes they could actually improve.
**How to avoid it**:
- Use the Circle of Control, Influence, and Concern framework to help the team identify and prioritize issues they can control or influence.
- Encourage reframing: “What can we do given these constraints?”
- Redirect conversations back to actionable topics with gentle facilitation techniques.
- Set boundaries early in the retrospective, clarifying what can and can’t be addressed.
**Resources**:
- [Circle of Control Exercise](https://www.dianalarsen.com/blog/2010/07/26/circles-and-soup/) – Diana Larsen
## 9. Lack of engagement and participation
**What it looks like**:
Team members are disengaged, offering superficial feedback or no feedback at all, often due to fear, boredom, or a sense that their input won’t matter.
**Real-life example**:
During a retrospective, participants responded with minimal comments like “All good” or “Nothing to add.” The facilitator struggled to draw out meaningful input, leaving the session unproductive.
**How to avoid it**:
- Build psychological safety by establishing ground rules and ensuring there are no negative repercussions for honest feedback
- Use icebreakers or creative exercises to make retrospectives more engaging.
- Provide opportunities for anonymous contributions
- Vary the format to keep the team interested
- Actively follow up on past feedback to show the team that their input is valued and acted upon.
- Run a retro on your retro and ask the team about what they would like to see happen at the retrospective so that they can be more involved.
- Show how past data and actions that have been followed through have helped lead to positive change to add value to the process.
**Resources**:
- Building Psychological Safety in Teams – Amy Edmondson
- [Icebreaker Activities for Agile Teams](https://games.teamretro.com/)
## 10. The “boil the ocean” retrospective
**What it looks like**:
The team tries to tackle every issue raised during the sprint, resulting in an overwhelming and ineffective session with too many action items to manage.
**Real-life example**:
A team identified ten separate issues to address in one retrospective and attempted to solve all of them. They ran out of time, and none of the actions were followed through, leaving the team feeling overwhelmed and demotivated.
**How to avoid it**:
- Prioritize issues by importance and urgency using techniques like Dot Voting or an Effort-Impact Matrix.
- Focus on a maximum of 2–3 key issues per retrospective to ensure actionable outcomes.
- Keep a “parking lot” for less critical issues to revisit later.
- Remind the team that continuous improvement is an ongoing process and doesn’t require solving everything at once, especially at the retrospective itself.
By recognizing and addressing these retrospective anti-patterns, you can improve your effectiveness as a Scrum Master and create an environment where your team thrives. Tools like **TeamRetro** provide structured formats, action tracking, and feedback mechanisms to enhance your retrospectives and ensure they remain meaningful and productive.
Start 2026 by empowering your team with retrospectives that drive real change. Stay curious, stay agile, and keep improving! 🚀
---
# Add background images & illustrations to your agile retrospectives (fun, easy, and engaging)
URL: https://www.teamretro.com/blog/background-illustrations-to-make-your-retros-fun-as-well-as-easy/
You can now add a [background image or illustration](https://help.teamretro.com/article/317-backgrounds-and-illustrations) to your retrospective!
That’s right, with the saying *“a picture is worth a thousand words”* as our inspiration, this new feature helps you set the mood, create a little fun and inspire your team.
While words can be used to “describe” and “explain” illustrations can be used to “show”. Not only that, illustrations can also –
- communicate concepts
- evoke emotions
- spark ideas
Creating this new feature was the perfect excuse for us to collaborate with our friend and talented Illustrator, [Nelson Yap](https://www.instagram.com/nelson.yiap). Nelson created a number of illustrations based on our fun retro templates. Here are three of them here –
*Hot Air Balloon Retrospective*
*Three Little Pigs Retrospective*
*Roller Coaster Retrospective*
You can explore [more of Nelson’s illustration work](https://www.nelsonyiap.com).
When adding background illustrations you can choose from –
- TeamRetro’s background illustrations
- a background photo
- one of your own
The background will only appear on your online retro, not exports and reports. If the image isn’t quite right for the [mode](https://help.teamretro.com/article/316-dark-mode-theme) you’re using you can always adjust its opacity.
We hope these images help you establish a light mood that puts people at ease while appealing to the creative thinkers in your team.
Read our guide on [adding a background image to your retrospective](https://help.teamretro.com/article/317-backgrounds-and-illustrations).
Happy retro-ing!
---
# The best collaboration tools for remote teams in 2026 (and the layer most stacks miss)
URL: https://www.teamretro.com/blog/best-collaboration-tools-for-remote-teams/
Working across time zones, Slack threads, and async standups is the default now for most teams. But being technically connected and actually collaborating well are two different things, and the gap between them usually comes down to tools. In Zoom's 2025 research, [75% of employees said their organization's remote-work tools need an upgrade](https://www.zoom.com/en/blog/remote-work-statistics/). The right stack of remote collaboration tools won't fix every problem, but it removes the friction that makes distributed work harder than it needs to be.
We've learned this first-hand. TeamRetro is an online retrospective, team health check, estimation, and standup tool used by 60,000+ agile teams, and our own team is fully distributed. It took us a while to see that having good tools for communication and delivery wasn't enough. The missing piece was always the same: a consistent, structured space to reflect, surface what wasn't working, and actually do something about it. That shaped how we think about collaboration tools, not just what keeps a team connected, but what keeps it improving.
This guide breaks down the best collaboration tools for remote teams in 2026 by workflow stage: communication, project management, visual collaboration, and continuous improvement. Each section covers what the tools are actually for, so you can build a stack that supports your whole process, not just the obvious parts.
## What remote collaboration tools actually are
Remote collaboration tools are software that lets a distributed team communicate, manage work, and think together, in real time or asynchronously, without being in the same room. A complete stack usually spans four layers: communication (Slack, Microsoft Teams, Zoom), project management (Jira, Linear, Asana), visual collaboration (Miro, FigJam, TeamRetro), and the reflection layer that ties them together (retrospectives and team health checks).
Most "best tools" lists stop at the first three. The fourth is the one that decides whether a remote team keeps getting better or just keeps shipping. We'll get to why.
## What makes a remote collaboration tool worth adopting
Before the specific picks, it's worth being clear on what separates a genuinely useful tool from one that just adds noise. The best ones share a few traits.
**They reduce friction, not add it.** If your team needs a 20-minute orientation before they can contribute to a session, the tool is already working against you. Low setup overhead matters most for async contributors and occasional participants. We've seen teams abandon tools within a sprint because the join experience was too clunky.
**They fit your existing workflow.** A tool that pulls everyone into a separate system tends to get quietly abandoned. Integration with what your team already uses, Jira, Slack, GitHub, is the difference between a tool that gets adopted and one that sits unused after week two.
**They support both real-time and async work.** Distributed teams rarely share a clean nine-to-five. The best tools let people contribute when they're online and catch up when they're not, without losing context. This matters most for retrospectives, where async input before a session often produces more honest feedback than live contributions alone.
**They create outcomes, not just conversations.** Meetings without clear actions and owners are expensive chats. Tools that build in decision capture, action tracking, and summaries let you actually see whether the issues raised last sprint got resolved this one.
With those principles in mind, here's how to think about each layer of the stack.
## Communication tools for remote teams
Communication is the foundation. Get it wrong and everything downstream suffers: misalignment, duplicated work, and the slow erosion of team cohesion that's easy to miss until it's already a real problem.
### Slack
The de facto standard. Channels keep conversations organized by project or topic, and Slack integrates with almost everything else on this list, so it doubles as a workflow hub. The trick is channel discipline; too many and the signal drowns.
**Best for:** Day-to-day messaging, async updates, and workflow notifications.
### Microsoft Teams
The natural choice if you're already in Microsoft 365. Chat, video, and files in one place, with deep SharePoint, OneNote, and Outlook integration and the governance controls enterprise IT asks for.
**Best for:** Enterprise teams with existing Microsoft infrastructure.
### Zoom
Still the most reliable option for video, especially larger meetings and workshops. Breakout rooms are genuinely useful for facilitation; we use them in retrospective kick-offs so small groups can discuss before bringing themes back to the room, and [browser-based Zoom icebreaker games](https://games.teamretro.com/platforms/zoom/) open a call without anyone installing anything.
**Best for:** Video meetings, workshops, and all-hands sessions.
Once your team has a communication layer, the next challenge is organizing and tracking work across people and time zones, and keeping it visible to everyone.
## Project management tools for remote teams
Project management tools bring structure to distributed work: who owns what, what's in progress, and what's blocked. Without this layer, coordination happens in chat and work quietly falls through the gaps.
### Jira
The most widely used project tool for agile software teams: sprint boards, backlogs, and reporting built for scrum and kanban, at the cost of configuration overhead. Connect [Jira to TeamRetro](/integrations/jira/) and retrospective action items push straight into the backlog, so nothing gets lost between the retro and the next sprint.
**Best for:** Agile software teams managing sprints and backlogs at scale.
### Linear
Jira's structure without the bloat: fast, opinionated, and clean enough that issue tracking stops feeling like admin. If your team spends more time maintaining Jira than shipping, it's worth a look.
**Best for:** Product and engineering teams who want lightweight, fast issue tracking.
### Asana
Strong for cross-functional teams, product, marketing, design, and ops, where work spans functions that don't all think in sprints. Timeline views, workload management, and goal tracking keep it coordinated.
**Best for:** Cross-functional teams coordinating projects across departments.
With communication and project tracking in place, most remote teams think their stack is complete. It isn't. There's a third layer that's almost always missing, and it's the one that unlocks actual collaboration, not just coordination.
## Online whiteboard tools for remote teams
Communication tools keep people connected. Project tools keep work organized. Neither gives your team a shared visual space to think together, to brainstorm, map complexity, or work through ideas as a group.
That's where online whiteboards come in. For agile teams they earn their place across a range of sessions: sprint planning, retrospectives, team health discussions, and process mapping all benefit from a space where ideas can be surfaced, grouped, and prioritized visually rather than typed into a list.
The teams who get the most out of a whiteboard are the ones using it *during* structured sessions, not just for open brainstorming. When a whiteboard is connected to a facilitation process, with a clear purpose, a way to vote on priorities, and a path to action, it produces better outcomes than a blank canvas everyone adds sticky notes to and then never revisits.
### Miro
Miro is the most feature-rich online whiteboard available, with a vast template library covering everything from customer journey mapping to org design. A strong choice for teams that need a flexible visual workspace for many use cases. The trade-off is that without a structured facilitation workflow, boards get cluttered and hard to act on.
**Best for:** Teams needing a versatile visual workspace for diverse use cases.
### FigJam
FigJam is Figma's collaborative whiteboard, and it's popular with design-adjacent teams. If your team already works in Figma, FigJam offers low-friction visual brainstorming without leaving the ecosystem. Sticky notes, connectors, and voting stamps also make it usable for lightweight retrospective-style sessions.
**Best for:** Design and product teams already working in Figma.
### TeamRetro whiteboard
TeamRetro's built-in [whiteboard](/retrospectives/) is purpose-built for agile ceremonies: not a general-purpose canvas, but a focused space for structured team sessions. The difference is that it connects directly to the [retrospective](/retrospectives/) and [health check](/health-checks/) workflow, so your team moves from brainstorming to grouping to dot-voting to action capture in one tool, without switching tabs.
This matters more than it sounds. Many teams run a whiteboard separately from their retrospective tool, which means two setups, two links, two contexts to manage. An online whiteboard for retrospectives that's built into the facilitation workflow lets people add sticky notes at the same time, group similar themes through affinity mapping, and vote on priorities privately. The structure is already there, so the facilitator can focus on the conversation instead of the logistics. Teams tell us that removing that one moment of friction is what keeps people in the flow of the session rather than dropping out at the tool switch.
**Best for:** Agile teams running retrospectives, sprint reviews, and collaborative planning where structure and outcome capture matter.
## Retrospective and team health check tools
This is the layer most "best collaboration tools" lists skip entirely, and it's arguably the most important one for sustained team performance.
Communication tools help your team talk. Project tools help your team ship. But what helps your team *improve*? How do you catch friction before it becomes frustration? How do you make sure distributed team members feel heard, not just assigned tickets? It's a live problem: in [Owl Labs' 2025 State of Hybrid Work report](https://www.owllabs.com/state-of-hybrid-work/2025), 61% of hybrid workers said they feel left out in meetings. That feedback loop doesn't happen by accident on a remote team. It needs a deliberate, structured space to surface what's working and what isn't, sprint after sprint.
### TeamRetro
TeamRetro is purpose-built for [agile retrospectives](/retrospectives/) and [team health checks](/health-checks/), designed for remote and hybrid teams. Instead of a blank canvas, it gives you guided facilitation, so whether you're running a Start, Stop, Continue, a Mad, Sad, Glad, or a model like the Spotify Squad Health Check, the structure is already there. Your team shows up and focuses on the conversation, not the setup. TeamRetro also runs your [daily standup](/standups/), async by default, and can post the day's digest to Slack or Microsoft Teams.
What surprises teams most when they switch is the quality of the feedback. Independent voting means everyone submits their ideas privately before anything is revealed, so the loudest voice in the room doesn't shape what gets discussed. We've seen teams surface issues that had been invisible for months, simply because people finally felt safe writing them down without worrying about being singled out.
Picture the difference in practice. On an open board, the first person to speak anchors the discussion and quieter people tend to agree rather than add. With independent voting, everyone writes and votes before anything is revealed, so a blocker that three people were silently working around lands as a top-voted item instead of staying unsaid. Same team, same sprint, a very different retro.
> "TeamRetro helped our teams effectively manage retrospective meetings, even in a remote setup, saving time."
>
> **Václav Nidrle**, Trigama ([more reviews](/compare/reviews/))
The features that make it work for distributed teams:
- **Independent voting** prevents groupthink. Team members add and vote on items privately before results are revealed, surfacing more honest feedback than open-board formats.
- **275+ retrospective templates** covering formats from mood checks and futurespectives to full agile maturity assessments, plus community and AI-generated ones. Browse the [retrospective template library](/retrospective-templates/) to find the right one.
- **Team health check models** track sentiment across dimensions like psychological safety, happiness, and goal alignment over time, not just as a one-off snapshot.
- **AI-powered insights** group similar themes and highlight patterns automatically, so facilitators spend less time organizing and more time on the conversation.
- **Action tracking** carries items forward from retro to retro, keeping the team accountable between sessions without manual copy-paste into Jira or Slack.
- **Presentation mode** syncs screens across the whole team, in-person or distributed, so a facilitator can walk through results together without losing the room.
There are other [retrospective tools](/retrospective-tool/) out there, but few are built specifically for distributed agile teams.
## How to build your remote collaboration stack
The tools above don't work in isolation; they're most effective layered intentionally across your workflow. Here's how we think about building a stack that covers all four stages.
**1. Start with one communication tool and commit to it.** The biggest mistake distributed teams make is proliferating channels. More tools doesn't mean better communication; it means more noise and more places for information to get lost. Pick Slack or Teams, set channel conventions, and stick to them.
**2. Match your project tool to your team's complexity.** Jira for larger engineering orgs running multiple squads. Linear for smaller or faster teams where speed beats configuration. Asana when you're coordinating across functions that don't all think in sprints.
**3. Get a visual space connected to your retrospective workflow.** A standalone whiteboard is useful. A whiteboard built into your retrospective process is better: less setup, less context-switching, and a natural path from brainstorm to action. For agile teams this is one of the simplest, highest-value upgrades you can make.
**4. Don't skip the reflection layer.** This is where most remote teams underinvest. Shipping fast without a regular feedback loop accumulates team debt the same way you accumulate technical debt: slowly, then suddenly. A retrospective practice, run consistently, turns lived experience into real improvement.
**5. Keep the stack lean.** The best remote collaboration stack is the smallest one that covers all four layers. Tool sprawl is a real cost: [Owl Labs found 64% of employees juggle too many communication tools](https://www.owllabs.com/state-of-hybrid-work/). Every extra tool is a new onboarding burden, a new notification stream, and another integration to maintain. Fewer, better tools beat a sprawling toolkit every time.
## Quick reference: the remote collaboration stack
| Category | Recommended tools | Primary use case | Best for |
| --- | --- | --- | --- |
| Communication | Slack, Microsoft Teams, Zoom | Messaging, video, async updates | All distributed teams |
| Project management | Jira, Linear, Asana | Task tracking, sprint management, roadmaps | Engineering and cross-functional teams |
| Online whiteboard | TeamRetro, Miro, FigJam | Visual brainstorming, retrospectives, planning | Agile and design teams |
| Retrospectives & health checks | TeamRetro | Continuous improvement, health tracking, action follow-through | Agile teams running regular retros |
## Final thoughts
The best remote collaboration stack isn't a single tool. It's the right combination working together across every stage of how your team operates: one for communication, one for managing work, one for thinking visually, and one that creates the space to reflect and improve.
Most remote teams have the first three covered in some form. The fourth is where the gap usually lives, and where TeamRetro comes in. It's the layer that ties the rest together, giving your team a structured space to surface what's working, fix what isn't, and keep getting better at collaborating, not just at staying connected.
## Frequently asked questions
**What are the best collaboration tools for remote teams in 2026?** A complete stack spans four layers: communication (Slack, Teams, Zoom), project management (Jira, Linear, Asana), visual collaboration (Miro, FigJam, TeamRetro), and continuous improvement (TeamRetro). The best stack is the smallest one that covers all four.
**What are the four types of collaboration tools?** Communication, project management, visual collaboration (online whiteboards), and retrospective or team health check tools. Most teams cover the first three and skip the fourth.
**Do remote teams need a separate tool for retrospectives?** A purpose-built tool adds what a general whiteboard can't: independent voting, ready-made templates, action tracking between sessions, and health trends over time. You can run a retro on a blank canvas, but a structured tool produces better outcomes with less effort.
**What's the difference between an online whiteboard and a retrospective tool?** A whiteboard is a flexible blank canvas. A retrospective tool wraps that canvas in a facilitation workflow, format, anonymous voting, grouping, and assigned actions, so the team moves from ideas to outcomes.
## Build the layer your stack is missing
Most remote teams have communication and project tracking covered. The reflection layer is where the gap usually lives. Run your next retrospective in TeamRetro and see what surfaces when everyone gets a private, structured space to be honest.
---
# What makes the best icebreakers for teams?
URL: https://www.teamretro.com/blog/best-icebreakers-for-starting-conversations-with-online-teams-2021/
No matter how many times they’ve raced before, athletes warm up their muscles prior to heading to the starting block. They don’t take their warm-up lightly. In fact, it’s the cornerstone of their race; helping to ensure they deliver peak performance when it counts and avoids unnecessary injury.
Similarly, anytime groups of people come together to meet, a warm up in the form of an icebreaker can increase their focus and efficacy. Importantly, they can create and support tiny but vital fibers of human interaction within the context of the workplace. They build neutral spaces for social calibration in which colleagues may emit and receive subtle signals of inclusion and trust thereby nurturing an atmosphere of psychological safety. Our [bank of work icebreakers sorted by goal](/icebreakers/icebreaker-questions-for-work/) groups them by what you want the warm up to achieve.
## Why use icebreakers?
You’ve probably got a massive backlog that keeps getting bigger, a calendar full of back-to-back meetings and it’s your turn to cook dinner.
Well, the value that an icebreaker can bring to the team is hard to ignore –
- A lot has been [written](https://www.thecut.com/2016/09/back-to-school-icebreakers-are-awkward-but-they-work.html) about the safety of the environment icebreakers help foster; they nurture spaces in which people are happy to share and are therefore better positioned to collaborate.
- In fact, [research](https://books.google.com.au/books?hl=en&lr=&id=4ITxDwAAQBAJ&oi=fnd&pg=PA293&dq=the+psychology+of+icebreakers&ots=ZiG6p1rp_w&sig=mziSScGDw1Qu-AWEP7BWktNtN8A#v=onepage&q=the%20psychology%20of%20icebreakers&f=false) points to the common ground established by icebreakers improving the efficiency of distributed teams.
and let’s not forget they’re fun and –
- A [fun workplace](https://www.businessnewsdaily.com/9640-fun-at-work.html) seems to be the gift that keeps on giving (to all involved) as they support team cohesion and learning. Let’s face it – a fun place is one where people want to be!
So, if you’re looking for a simple tool that nurtures a positive, safe, productive work environment – using icebreakers is the way to go.
## So, what makes an effective icebreaker?
An icebreaker is a simple activity, undertaking, or game that helps people foster connections and build rapport.
Importantly, they can create and support tiny but vital fibers of human interaction within the context of the workplace. They build neutral spaces for social calibration in which colleagues may emit and receive subtle signals of inclusion and trust thereby nurturing an atmosphere of psychological safety.
## Effective icebreakers adhere to the 3E rule, they are:
### Easy
Keep them so simple that people could respond almost instantly. Keep the playing field level. It’s not a demonstration of knowledge nor expertise. All answers are correct. There are no scoreboards – everyone wins!
### Enjoyable
This is a chance to bask in positivity, play, and have fun! The key ingredient is inclusivity. Yep – it’s recess time on that playing field and everyone is welcomed!
### Explainable
Almost every word that is shared during an icebreaker can help to build a connection. So, giving people a chance to explain is giving people a chance to connect. The great thing is – it doesn’t stop there! Allowing people this time to tell their story gives your team safe points to connect beyond the icebreaker and continue to foster a sense of team.
## Tip from TeamRetro
- Go first! Model the behavior you’re keen to see.
- Show how easy the icebreaker is. Have fun. Explain what you mean.
- Let your words build connections with your team then allow their words to do the same.
- Always let people know in advance when you plan to use an icebreaker.
- Surprises (no matter how well intended) aren’t always everyone’s cup of tea.
To help get you started, we created a collection of [free online icebreaker games](https://games.teamretro.com/games/) that you can use to run your next agile retrospective meeting or health check. Remote teams love quick rounds of [Two Truths and a Lie](https://games.teamretro.com/games/two-truths-and-a-lie/) and [guess the emoji](https://games.teamretro.com/games/emoji-guess/) to warm everyone up.
---
# Top planning poker software for agile teams in 2026
URL: https://www.teamretro.com/blog/best-planning-poker-tools-for-agile-teams/
When estimation feels more like guesswork than a team effort, it’s time to rethink your approach.
Agile teams do their best work with clarity, speed, and shared context. When estimating means a mix of opinions, gut feelings, and scattered tools, even a strong team loses momentum. Planning poker software fixes the mechanics (private voting, a shared reveal, and a number the whole team agrees on) so the conversation, not the loudest voice, sets the estimate.
The tools below all do the core job. Where they differ is everything around it: whether they plug into [Jira, GitHub, or Linear](/estimations/), whether they’re free, and whether estimation lives on its own or alongside your retros and planning. This guide compares the current options, with pricing and features **verified in July 2026**, and gives a clear pick for each situation. New to the technique itself? Start with our [agile estimation guide](/guides/agile-estimation-guide/).
## What to look for in a planning poker tool
The best estimation tools don’t just collect votes. They help the team make a better decision and keep that decision where the work already lives.
- **Real-time collaboration**: live voting, a simultaneous reveal, and room for discussion when estimates split.
- **Integration**: does it connect to Jira, GitHub, Linear, or Slack, and does it write estimates *back*, or only import them?
- **Customization**: can you match the deck and scale (Fibonacci, t-shirt sizes, custom) to how your team estimates?
- **Reporting**: can you see where votes diverged and learn from it over time?
- **Cost**: is there a genuine free tier, and does paid pricing scale by user, facilitator, or a flat fee?
## The best planning poker tools for agile teams
### 1. Free Planning Poker by TeamRetro
TeamRetro’s Planning Poker is a free, real-time estimation room built to remove friction: share a link and start, with no account required. Cards stay hidden until everyone has voted, so no one anchors on the first number they see.
**Key features:**
- No sign-up: share a room link and estimate straight away
- Anonymous voting with a simultaneous reveal to avoid groupthink
- Lightweight, browser-based, built for remote and distributed teams
- Graduates into [full TeamRetro estimation](/estimations/): import from Jira, Azure DevOps, GitHub, or Linear and sync agreed story points back
**Best for**: teams that want a frictionless free room now, and the option to bring estimation alongside their retros, health checks, and backlog sync later.
**Pricing**: free forever, unlimited participants, no account required.
New to running sessions? Our [planning poker guide](/guides/agile-estimation-guide/) covers how to facilitate a round, size work in [story points](/guides/agile-estimation-guide/what-are-story-points/), and [compare estimation techniques](/guides/agile-estimation-guide/estimation-techniques/).
### 2. PlanningPoker.com
PlanningPoker.com is one of the longest-running branded rooms, with a clean interface and Jira import/export. Players join free; the game organizer pays for the paid tier.
**Key features:**
- Customizable decks and timers
- Anonymous, real-time voting
- Jira import/export of stories, estimates, and notes
**Best for**: teams that want the familiar, established planning poker room with Jira import/export.
**Pricing**: free for players; paid organizer plans, so confirm the current price on their site.
### 3. Kollabe
Kollabe is a free, no-sign-up room that bundles planning poker with retrospectives and standups in one interface. It shows up at the top of several “best free planning poker tool” roundups, though the lists that rank it first appear to be self-promoted rather than independent, so that reputation is worth reading with some caution.
**Key features:**
- Free to start, no sign-up for a quick session
- Planning poker, retrospectives, and standups in one interface
- Anonymous voting, custom decks, and large rooms (up to 500 participants)
- Jira, GitHub, Azure DevOps, and Linear estimate sync on paid plans
**Best for**: small teams that want a simple, free, no-account room for one-off estimation sessions.
**Pricing**: free tier (10 members per room, 7-day meeting history, limited meetings per month); Planning Poker plan $12/month; Premium (adds retros, full history, and AI tools) $29/month.
**Note**: Kollabe does not publish SOC 2 or GDPR certifications, so it may not clear an enterprise security review, and free-tier history is limited to 7 days.
### 4. Parabol
Parabol is an open-source (AGPL) agile meeting platform that runs sprint poker, retrospectives, and standups in one place, so like TeamRetro it is a multi-tool rather than a single-purpose poker app.
**Key features:**
- Sprint Poker with hidden voting; Fibonacci, five-finger, t-shirt, and custom scales
- Multi-dimensional estimation, for example value and effort together (as in WSJF)
- Import from and sync estimates back to Jira, GitHub, GitLab, and Azure DevOps
- SOC 2 Type II, GDPR-ready, and self-hostable
**Best for**: teams that want an open-source, all-in-one tool and can work within the free meeting cap, or move to a paid plan.
**Pricing**: free Starter for up to 2 teams and 10 meetings/month (unlimited users, 30-day history); Team $8 per active user/month; Enterprise adds SAML SSO and on-premises hosting.
### 5. Planning Poker Online
Planning Poker Online (by We Agile You) is a polished paid room with real integrations and compliance credentials.
**Key features:**
- Real-time voting with visual results and sidebar issue management
- ISO 27001 and GDPR compliance
- Jira, Linear, GitHub, and Azure DevOps import (plugin or CSV)
**Best for**: teams that want a structured, compliant tool and are comfortable paying per facilitator.
**Pricing**: free plan (9 votings and 5 issues per game); Premium $30 per facilitator/month (or $300/year).
### 6. Planning Poker for Jira (Atlassian Marketplace)
If your backlog lives in Jira, native Marketplace apps keep estimation in-platform and write story points straight to the issue. Popular options include Agile Poker and Planning Poker by Appfire.
**Key features:**
- Runs directly inside Jira, against your real issues and story-point fields
- Multiple estimation methods (planning poker, async, magic estimation)
- Estimation history and insights on the board
**Best for**: Jira-centric teams that want estimates written back to issues without leaving Jira.
**Pricing**: commercial apps priced on Atlassian’s per-user tiers (small teams often free); check each app’s pricing tab.
### 7. PlanningPoker.live
PlanningPoker.live is a free, open-source room with genuine two-way sync and an AI facilitation twist.
**Key features:**
- Free and open-source, no sign-up, sync and async voting
- Two-way Jira and Linear sync; start sessions from Slack
- “PokerBot” AI session summaries (some AI features are credit-metered)
**Best for**: open-source or privacy-minded teams that want free real Jira/Linear sync.
**Pricing**: free; certain AI features use refillable monthly credits.
### 8. Zenhub
Zenhub builds planning poker into a GitHub-native project-management suite, so estimation happens on the board you already use.
**Key features:**
- Planning poker and estimates inside your GitHub workflow
- Sprint automation and velocity reporting
- Deep GitHub integration, plus Slack and Figma
**Best for**: GitHub-native engineering teams that want estimation in their actual PM tool, not a separate room.
**Pricing**: free ($0, up to 50 users, 2 GitHub repos); Teams from $4.99 per user/month billed yearly ($7.50 monthly).
### 9. PlanITPoker
PlanITPoker is a straightforward tool with a flat paid tier, popular with small teams.
**Key features:**
- Shareable-URL rooms with story management
- Voting stats and distribution graphs
- Story import via Jira XML or CSV
**Best for**: small teams that outgrow the free cap and want flat pricing rather than per-seat billing.
**Pricing**: free for up to 7 participants; Premium $20/month (flat) for unlimited participants.
### 10. Estimioo
Estimioo is a modern, AI-forward tool with cheap flat pricing that also covers retros and standups.
**Key features:**
- AI-assisted story-point suggestions
- Anonymous voting with an instant reveal
- Jira integration on the paid tier
**Best for**: teams that want AI-assisted estimation at the lowest paid price point.
**Pricing**: free plan; Team $7 per workspace/month (flat, not per seat), adding Jira and more AI.
### 11. scrumpoker-online.org
scrumpoker-online.org is a no-frills, multi-language free room that runs in a tab next to Jira.
**Key features:**
- Instant no-sign-up rooms, unlimited participants
- Fibonacci, t-shirt, half-point, and custom decks
- Six-language interface and QR-code sharing
**Best for**: teams that want the simplest possible free, multilingual browser room.
**Pricing**: free; Premium $40/year removes ads and adds a timer, auto averages, and a reusable room ID.
**Note**: no project-tool integrations, it’s deliberately standalone.
### 12. planningpokertool.com
planningpokertool.com is a minimalist, privacy-first free room with no accounts.
**Key features:**
- Completely free, no registration, unlimited participants
- Multiple scales (Fibonacci, t-shirt, powers of two)
- Sessions auto-delete after 24 hours
**Best for**: a throwaway, privacy-first estimation room for a single session.
**Pricing**: free (no paid tier).
## Comparison table
| Planning poker tool | Best for | Pricing | Jira |
| :-- | :-- | :-- | :-- |
| **[Free Planning Poker by TeamRetro](/free-planning-poker-for-agile-teams/)** | A frictionless free room that graduates into full estimation | Free forever, unlimited participants | Yes, import and sync via [TeamRetro estimation](/estimations/) |
| **PlanningPoker.com** | The established, familiar branded room | Players free; paid organizer plans | Import/export |
| **Kollabe** | A free, all-in-one room for one-off sessions | Free tier (limited); $12/mo poker, $29/mo Premium | Sync on paid plans |
| **Parabol** | Open-source all-in-one within a free meeting cap | Free (2 teams, 10 meetings/mo); from $8/active user/mo | Import and sync |
| **Planning Poker Online** | Compliant, structured estimation | Free tier; $30/facilitator/mo | Yes (plugin/CSV) |
| **Planning Poker for Jira** | Teams that live in Jira | Atlassian per-user tiers | Native |
| **PlanningPoker.live** | Open-source teams wanting real sync | Free (open source) | Two-way sync |
| **Zenhub** | GitHub-native engineering teams | Free tier; from $4.99/user/mo | Via GitHub |
| **PlanITPoker** | Small teams wanting flat pricing | Free (7 users); $20/mo flat | XML/CSV import |
| **Estimioo** | Cheap, AI-assisted estimation | Free; $7/workspace/mo | Paid tier |
| **scrumpoker-online.org** | The simplest free multilingual room | Free; $40/yr premium | None |
| **planningpokertool.com** | A private, throwaway free room | Free | None |
## Which planning poker tool is best for your team
There’s no single winner. The right tool depends on where your work lives and what you need beyond a vote.
- **You want free with zero setup**: Free Planning Poker by TeamRetro, planningpokertool.com, or scrumpoker-online.org. All run in the browser with no account.
- **Your backlog is in Jira**: a native Marketplace app keeps estimates in-platform, or [TeamRetro estimation](/estimations/) imports Jira issues, runs the session as a team, and syncs the agreed story points back.
- **You’re GitHub-native**: Zenhub keeps estimation on the board you already use.
- **You want estimation alongside retros and health checks**: TeamRetro brings planning poker into the same place as your other agile ceremonies, so the decision and the discussion stay together.
The best tool is ultimately the one your team keeps using. If that means a free room for now, start there, and when you want estimates to live alongside the rest of your team’s work, [TeamRetro](/estimations/) is ready when you are.
Need help improving your team’s overall process? See how [Reward Insight used TeamRetro to measurably increase their agile maturity](/case-studies/reward-insight/).
## Frequently asked questions
### What is the best planning poker tool?
There isn’t one best tool for every team. The right pick depends on where your backlog lives and what you need beyond voting. For a free, no-sign-up room, Free Planning Poker by TeamRetro, planningpokertool.com, and scrumpoker-online.org all work well. For teams in Jira, [TeamRetro’s estimation](/estimations/) or a native Atlassian Marketplace app keeps points in sync. For GitHub-native teams, Zenhub builds estimation into the board. Match the tool to your workflow rather than chasing a single winner.
### What is the best free planning poker tool?
[Free Planning Poker by TeamRetro](/free-planning-poker-for-agile-teams/) is free forever with unlimited participants and no account required, and it graduates into full team estimation with Jira, Azure DevOps, GitHub, and Linear sync when you need more. planningpokertool.com and scrumpoker-online.org are also genuinely free, no-sign-up browser rooms; PlanningPoker.live is free and open-source with two-way Jira and Linear sync. Zenhub’s free tier includes planning poker for GitHub teams of up to 50 users. Kollabe and Parabol are free all-in-one options that also run retrospectives and standups, though both cap their free tier: Kollabe limits meeting history and monthly meetings, and Parabol allows 10 meetings a month across up to two teams.
### What is the best planning poker tool for Jira?
Two approaches work well. Native Atlassian Marketplace apps run inside Jira and write story points straight to issues, priced on Atlassian’s per-user tiers. Alternatively, [TeamRetro](/estimations/) imports the Jira issues you’re planning into an estimation session, runs planning poker as a team, and syncs the agreed story points back, which is useful when you also want the discussion, retros, and health checks in one place.
### Do planning poker tools integrate with Jira?
Many do. TeamRetro, PlanningPoker.com, Planning Poker Online, PlanningPoker.live, PlanITPoker, Estimioo, Parabol, and Kollabe all offer Jira import or sync in some form, and the Atlassian Marketplace has several native planning poker apps. Integration depth varies: some only import a CSV of stories, while others write agreed story points back to the issue automatically, so check the direction of sync before committing.
### How much do planning poker tools cost?
Most offer a free tier. Free options with no account include TeamRetro, planningpokertool.com, and scrumpoker-online.org. Paid plans range widely: Zenhub is around $4.99 per user per month billed yearly, PlanITPoker is a flat $20 per month, Estimioo is $7 per workspace per month, scrumpoker-online.org is $40 per year, and Planning Poker Online is $30 per facilitator per month. Native Jira apps follow Atlassian’s per-user pricing. Always confirm current pricing on the vendor’s own page before you buy.
Ready to try it? [Run a free planning poker session](/free-planning-poker-for-agile-teams/), no sign-up and no limits, or [see how estimation works in TeamRetro](/estimations/).
---
# The best retrospective tools for agile teams, compared
URL: https://www.teamretro.com/blog/best-retrospective-tools/
If you're comparing online [retrospective tools](/retrospective-tool/), the hard part isn't finding one. It's matching the tool to how your team actually works. A distributed scrum team that needs anonymous input and health-check trends wants something different from a co-located team that just needs a quick board once a sprint.
This guide compares the retrospective tools teams evaluate most often, with pricing, standout features and what each one is best for, so you can shortlist quickly and pick with confidence. We re-checked every tool's pricing and features against its own site in **September 2026**.
We make TeamRetro, so read this the way you would read any vendor's comparison. Every price and feature below was checked against the vendor's own site in September 2026.
### What to look for in a retrospective tool
- **Templates and facilitation**: enough formats to keep retros from going stale, with guided steps so anyone on the team can run one. If you want to try formats first, browse [retrospective templates](/retrospective-templates/).
- **Anonymity and voting**: honest input depends on people feeling safe; check whether both come on every plan or only higher tiers.
- **Health checks**: tracking [team health](/health-checks/) over time is what turns a retro board into a continuous-improvement habit.
- **Integrations**: Jira, Slack and Teams, so the actions you agree on land where the work happens.
- **Pricing model**: this matters more than the headline number. Most dedicated retro tools price **per team** (cost is flat no matter how many people join); Miro, Parabol and ScatterSpoke price **per user**, which is cheaper for a tiny team but grows with headcount.
- **Security and privacy**: one team doing client work has as much to protect as fifty. Look for SSO and a choice of hosting region on the plan you'd buy, backed by a SOC 2 audit.
### Retrospective tools at a glance
| Tool | Best for | Pricing model | Free plan | Health checks |
| --- | --- | --- | --- | --- |
| **TeamRetro** | Retros, standups, health checks and estimation in one | Per team, from $250/team/year | 30-day trial | Yes |
| **EasyRetro** | Simple board-based retros, big template library | Per team | Yes | Limited |
| **Retrium** | Structured, facilitator-led distributed retros | Per team room, from $39/mo | Trial only | Yes (Team Radar) |
| **Parabol** | Open-source, self-hostable retros plus poker | Per active user, free–$8/mo | Yes | Yes (paid plans) |
| **Neatro** | Facilitation-first guided retros | Per team, from $23.20/mo | Yes | Yes (radar) |
| **Miro** | Whiteboard-first teams who also run retros | Per user, from $8/mo | Yes | No (not a retro tool) |
| **GoRetro** | Retros tied to sprint metrics | Per team, from $29/mo | Yes | Sprint analytics |
| **Echometer** | Recurring team-health measurement, EU hosting | Per team, from €29/mo | Yes | Yes |
Pricing was verified against each vendor's site in September 2026; plans change, so always check the vendor for current details. Here's each tool in more depth.
### The best free retrospective tools
"Free" covers a lot of ground in this category, so the useful question is what each free plan gives up. These rows were re-checked against each vendor's own pricing page in September 2026.
| Tool | What the free plan gives you | Where it stops |
| --- | --- | --- |
| **IdeaBoardz** | Unlimited boards, no account at all, PDF and Excel export | No paid tier and no active development since 2020, with no stated security or data guarantees |
| **RetroTool** | Anonymous boards with no signup, unlimited cards and participants, secret voting, 12-month retention | 3 basic templates free; the advanced set (SWOT, DAKI, Three Little Pigs) is paid |
| **Neatro** | Up to 10 members forever, unlimited retros and Team Radars, every ready-to-use template | 30 days of data history; Premium facilitation features are a 14-day trial |
| **Parabol** | Unlimited users across 2 teams, 10 meetings a month | 30-day history, 2 custom templates, 3 AI retro summaries a month, and no team health checks (Team plan and up) |
| **EasyRetro** | 2 public boards a month, unlimited participants, the full 100+ template library | No teams or team boards, and only 2 boards on the dashboard including archived ones |
| **GoRetro** | 1 team, 5 public boards and 2 team boards per 31-day cycle, unlimited users and guests | Exports, retro analytics, Jira sync, happiness index, polls and icebreakers are all paid |
| **Echometer** | 1 team, 25 workspace members, unlimited retro guests | 1 retro a month once the trial ends, and a 2-retro archive |
| **Retrospected** | Unlimited retrospectives, full customization, anonymous accounts, 40 posts | Sessions are public until you pay; encryption and private boards are Pro |
For a one-off retro where nobody wants an account, IdeaBoardz and RetroTool are the shortest path. For a free plan a small team can actually live on, Neatro's 10-member tier and Parabol's 10 meetings a month go furthest before the ceiling bites.
TeamRetro is deliberately not in that table, and it is worth saying why: there is no free forever plan. The 30-day trial carries every feature, health checks and estimation included, and asks for no card. If a permanent free tier is a hard requirement, one of the eight above is a better fit, and it is worth knowing that upfront.
### Where another tool may fit better
Four situations where another tool on this list is likely the better fit, worth knowing before you start a trial.
- **You need a permanently free plan.** We do not have one. The 30-day trial carries every feature and asks for no card, and then it stops. Neatro's 10-members-forever tier and Parabol's 10 meetings a month are the two free plans a small team can actually live on; IdeaBoardz and RetroTool need no account at all.
- **Your team is under about five people and you pay per seat elsewhere.** Per-team pricing is our advantage at 15 people and our disadvantage at three. Parabol at $8 per active user, or Miro if you are already paying for it, will cost you less.
- **You want a blank canvas, not a guided session.** If a confident facilitator designs the workshop anyway, our guided stages are in the way. Miro and Spreo give you the infinite canvas and get out of the way, and Spreo's facilitation extras (a shared jukebox, timers, spinners, confetti) lift the energy of a live room.
- **You want to run it on your own infrastructure.** We are closed source and hosted. Parabol is AGPL-3.0 with documented Docker and Kubernetes self-hosting, and Retrospected is GPL-3.0 with a $599 one-time self-hosting license. If self-hosting is a hard requirement, one of those two is the better starting point.
If one of those describes your team, the tool named is worth looking at first. Everything below assumes none of them does.
### In this guide
1. [TeamRetro](#teamretro)
2. [EasyRetro](#easyretro)
3. [Retrium](#retrium)
4. [Parabol](#parabol)
5. [Miro](#miro)
6. [Neatro](#neatro)
7. [GoRetro](#goretro)
8. [Echometer](#echometer)
9. [ScatterSpoke](#scatterspoke)
10. [RetroTool](#retrotool)
11. [TeleRetro](#teleretro)
12. [Reetro](#reetro)
13. [IdeaBoardz](#ideaboardz)
14. [Metro Retro (now Spreo)](#metro-retro-now-spreo)
15. [RetroTime](#retrotime)
16. [Retrospected](#retrospected)
17. [Frequently asked questions](#frequently-asked-questions)
## TeamRetro
### Overview
TeamRetro runs guided [retrospectives](/retrospectives/), team [health checks](/health-checks/) and [estimation](/estimations/) in one place, so the conversation, the trends behind it and the follow-up actions live together instead of scattered across three tools. Retros are template-led with anonymous input and independent voting, and health checks let you track how the team feels over time, which is what turns a retro board into a continuous-improvement habit rather than a one-off meeting.
It's SOC 2 Type 2 and GDPR compliant, offers SSO on every plan, can be hosted in the US or EU, and has a wide range of [integrations](/integrations/) including Jira, Confluence, Azure DevOps, Slack and Microsoft Teams. Pricing is per team, not per seat, so the cost stays predictable as the team grows.
### Top three features
- Guided facilitation with anonymous input and independent voting.
- Team health checks and Insights dashboards that track trends over time.
- Estimation (planning poker) built into the same tool.
**Trial:** Yes – 30 days, no credit card required.
**Price:** Per team, from $250/team/year (about $20.83/month) for a single team of up to 25 members; organization plans start at $50/month. There's no free-forever plan, but the 30-day trial includes every feature.
### What customers say
“There is no other product on the market that delivers this number of features at this level of quality at this price. It is extremely valuable for remote teams, but we also found value using it for in-person retros for its organization, anonymous capabilities, and reporting.” – [Source Forge](https://sourceforge.net/software/product/TeamRetro/)
### Great for
Best when retros, daily standups, health checks and estimation should live in one place and you expect to add teams. The catch: no free forever plan. See [TeamRetro for enterprise teams](/enterprise/) for scaling across an organization.
## EasyRetro
### Overview
EasyRetro is a lightweight, board-based retrospective tool with a large template library (100+) and a usable free plan. Its public-board model lets an unlimited number of participants join a single board, and it offers free team-building extras like a Kudos Generator and Icebreaker Bingo.
It integrates with Slack and Confluence on paid tiers.
### Top three features
- 100+ retrospective templates.
- Public boards with unlimited participants.
- Free team-building tools and surveys.
**Trial:** Free plan available.
**Price:** Free plan (2 public boards a month, plus the full template library); paid tiers add private and team boards. EasyRetro doesn't publish transparent pricing on its site, so check the vendor for current paid rates.
### What customers say
“We began using this software before the pandemic, but it was critical during that period. We needed a lightweight tool to conduct retros, and it was nice to not have to figure it out with drawing tools or messy Notion pages. This tool does one job and one job really well. Very worth it.” – [Capterra](https://www.capterra.com.au/reviews/185134/easyretro)
### Great for
Best free-plus-cheap retro board with a big template library. The catch: no scheduling, no health checks, no action carry-over, and no SOC 2 audit of its own.
[Compare EasyRetro with TeamRetro](/compare/easyretro-alternative/) in our side-by-side breakdown.
## Retrium
### Overview
Retrium is a facilitation-focused retrospective tool built around a library of guided techniques and its "Team Radar" health-check format. Anonymous feedback and real-time collaboration help teams surface honest input, and each Team Room holds an unlimited number of users.
Retrium integrates with Jira Cloud on every plan.
### Top three features
- Structured "Team Radar" health-radar retros.
- Guided retrospective technique library.
- Unlimited users per Team Room.
**Trial:** Yes – 30 days.
**Price:** $39 per Team Room per month; the Business plan is $715 per Team Room per year (about $59/month) and adds SAML SSO and SOC report access. There's no free plan.
### What customers say
“I like how quickly you can get a meeting started with Retrium. When my team needs to start a retrospective, we can invite who needs to be there, select our format, and get started.” – [G2](https://www.g2.com/products/retrium/reviews#reviews)
### Great for
Best for a facilitator who wants to be walked through a technique. The catch: priced per Team Room, which gets awkward past a handful of teams.
[Compare Retrium with TeamRetro](/compare/retrium-alternative/) in our side-by-side breakdown.
## Parabol
### Overview
Parabol is an open-source tool that runs retrospectives, sprint poker and standups, and emails a meeting summary to attendees afterwards. Because it's open source, the codebase is fully auditable, and Enterprise customers can self-host. It bills only for active users, so people who go quiet for a month aren't charged.
Team health is a recurring meeting of its own since Parabol rebuilt it in 2026, with 10 built-in question packs (Project Aristotle, Edmondson, Lencioni, the Spotify squad health check, Gallup Q12 and more) plus your own questions. As of October 2026 it is generally available, asks five Likert questions per check across five fixed categories, shows a five-check trend line per category, and is on the paid Team and Enterprise plans only.
It integrates with Jira, GitHub, Azure DevOps, Slack, Microsoft Teams and Google Calendar.
### Top three features
- Open-source, fully auditable codebase.
- Retros, sprint poker, standups and team health checks in one tool.
- Active-user-only billing.
**Trial:** Free Starter plan (no separate trial needed).
**Price:** Free Starter tier (2 teams, 10 meetings a month); the Team plan is $8 per active user per month. Self-hosting and single-tenant deployment are available on Enterprise.
### What customers say
“We primarily use Parabol for running our retros. We love the intuitive UX, great design and lot’s of templates to use for your team’s retrospectives summaries emailed to the team are a great feature, too!” – [G2](https://www.g2.com/products/parabol/reviews#reviews)
### Great for
Best if you want one open-source tool for retros, poker, standups and team health checks, and you might self-host it. The catch: $8 per active user per month, so the bill tracks headcount, and team health is not on the free tier.
[Compare Parabol with TeamRetro](/compare/parabol-alternative/) in our side-by-side breakdown.
## Miro
### Overview
Miro is a general-purpose infinite whiteboard where retrospectives are one use-case among many, run from templates rather than a dedicated retro workflow. It's strong when a team wants a single flexible canvas for ideation, mapping, planning and retros, and it has one of the deepest integration catalogues on this list.
Miro integrates with Jira, Asana, Linear, ClickUp, Azure DevOps, Slack, Microsoft Teams and Google Workspace (250+ integrations in total), and is SOC 2 Type II and ISO 27001 certified.
### Top three features
- Infinite freeform whiteboard.
- 250+ integrations.
- AI-assisted workflows.
**Trial:** Free plan available.
**Price:** Free plan (3 editable boards); paid plans from $8 per member per month (billed annually). Priced per user.
### What customers say
“Miro is an invaluable tool for optimizing collaboration and project management. Its benefits in efficiency, communication and dynamism of meetings are widely productive. I recommend Miro to any team that wants to improve their work processes and collaboration.” – [Capterra](https://www.capterra.com.au/reviews/128955/miro).
### Great for
Best if the team already lives on a whiteboard and retros are one of ten things you do there. The catch: it is not a retro tool, so nothing structures the session or remembers last time.
[Compare Miro with TeamRetro](/compare/miro-alternative/) in our side-by-side breakdown.
## Neatro
### Overview
Neatro is a facilitation-first retrospective tool that keeps psychological safety front of mind: people brainstorm privately first, then share anonymously. It offers 70+ templates and a team "radar" health check, with a polished guided flow that walks a team through each step.
### Top three features
- 70+ retrospective templates plus a team radar.
- Strong guided facilitation flow.
- Unlimited custom templates and exports (paid).
**Trial:** Yes – 14 days, no credit card.
**Price:** Free plan (up to 10 members, 30-day history); Premium is $23.20/team/month and Pro $31.20/team/month (billed annually). Priced per team.
### What customers say
“The tool is super easy to use. Also I really like the created templates as I can join my retrospective and choose with the team which one to use, depending on our topics.” – [G2](https://www.g2.com/products/neatro/reviews)
### Great for
Best free plan a small team can live on, at 10 members forever. The catch: 30 days of history on that plan.
[Compare Neatro with TeamRetro](/compare/neatro-alternative/) in our side-by-side breakdown.
## GoRetro
### Overview
GoRetro ties retrospectives to sprint data, pairing anonymous feedback and templates with sprint monitoring and analytics. Its Sprint Pro tier adds planning poker and a capacity calculator, so retros sit alongside the numbers they're reacting to.
It integrates with Slack and Jira Cloud, and is SOC 2 Type II and ISO 27001 compliant.
### Top three features
- Sprint monitoring and analytics.
- Planning poker and capacity calculator (Sprint Pro).
- Advanced action-item tracking.
**Trial:** Yes – 30 days, full features, no credit card.
**Price:** Free plan plus a 30-day trial; Premium is $29/team/month and Sprint Pro $49/team/month (billed annually). Priced per team, with unlimited users.
### What customers say
“My team and I use GoRetro for team retrospectives at the end of each sprint. It allows writing feedback anonymously, commenting on the cards, “likes” and even gifs for a touch of humor. It does its job perfectly.” – [G2](https://www.g2.com/products/goretro-goretro/reviews#reviews)
### Great for
Best if you want the retro sitting next to sprint metrics. The catch: exports, analytics, Jira sync and polls are all behind the paywall.
[Compare GoRetro with TeamRetro](/compare/goretro-alternative/) in our side-by-side breakdown.
## Echometer
### Overview
Echometer pairs retrospectives with psychology-based team health checks, using scheduled surveys and a cross-team dashboard to measure how teams are doing over time. It's hosted in Germany, which makes it a natural fit for EU teams with data-residency requirements.
Echometer is GDPR compliant with a DPA, and integrates with Jira.
### Top three features
- Psychology-based health checks with automated scheduling and a cross-team dashboard.
- Custom anonymous survey builder.
- 50+ templates with a collaborative board.
**Trial:** Yes – free plan available.
**Price:** Free plan (one retro a month); Pro is €29/team/month and Business €49/team/month (billed annually). Priced per team, in EUR, with German hosting.
### What customers say
“What we like best is usability, modern design and the basic attitude behind the tool – giving responsibility to the teams.” – [Capterra](https://www.capterra.com.au/software/213109/echometer#reviews)
### Great for
Best if EU hosting and recurring team-health measurement are the requirement. The catch: one retro a month once the trial ends.
[Compare Echometer with TeamRetro](/compare/echometer-alternative/) in our side-by-side breakdown.
## ScatterSpoke
### Overview
ScatterSpoke has repositioned itself as an AI feedback platform for engineering leaders. It still runs retrospectives, but the emphasis is on rolling up feedback from retros, standups and surveys into AI-synthesized themes, sentiment metrics and prioritized action items.
### Top three features
- AI-generated themes and sentiment.
- Prioritized action items across retros, standups and surveys.
- AI "Agent Surveys".
**Trial:** Yes – free plan available.
**Price:** Free (1 seat); Pro is $29 per seat per month (up to 5 seats); Business is $149/month including 5 seats. Priced per seat.
### What customers say
“I’ve tested several multi-purpose tools, but I like that this one is focused specifically on retrospectives. It’s awesome to see the data-driven approach!” – [Product Hunt](https://www.producthunt.com/products/scatterspoke/reviews)
### Great for
Best if you want retro data rolled up across many teams. The catch: per-user pricing.
[Compare ScatterSpoke with TeamRetro](/compare/scatterspoke-alternative/) in our side-by-side breakdown.
## RetroTool
### Overview
RetroTool is a simple, whiteboard-style retrospective board you can start without signing up. It includes a private area to gather thoughts before sharing, drag-and-drop grouping, dot voting and a timer. It's functional but appears to be lightly maintained.
### Key features
- Single-page retrospective.
- Private area before sharing.
- Zero-knowledge encryption (top tier).
**Trial:** Yes – 90 days on paid plans.
**Price:** Free (Anonymous plan, unlimited cards and participants); Individual $10/team/month; Company $20/team/month. Flat per-team pricing.
### What customers say
“Easy to use – very intuitive – setup in just a few seconds – easy to share.” – [Capterra.](https://www.capterra.com.au/reviews/202624/retrotool)
### Great for
Best for a retro nobody wants an account for, today. The catch: three templates free, and the advanced set is paid.
[Compare RetroTool with TeamRetro](/compare/retrotool-alternative/) in our side-by-side breakdown.
## TeleRetro
### Overview
TeleRetro offers polished, engaging online retrospectives with an AI retro bot, pulse/health checks and analytics. You can bring images and music into the session, vote with emojis, and keep things on track with a timer and icebreakers.
### Top three features
- AI retro bot.
- Pulse and health checks.
- Icebreakers with music and video.
**Trial:** Yes – free plan (1 team, 3 retros).
**Price:** Team is £26/month (£21/month billed annually); Business is £72/month (£58/month billed annually). Priced in GBP.
### What customers say
“Cool background images. Ease of customizing the board with different columns. Best tool to work on virtually. Helps running retrospection meetings online.” – [Capterra](https://www.capterra.com.au/reviews/214521/teleretro)
### Great for
Best if you want the retro itself to feel lively, with an AI bot, music and icebreakers built in. The catch: the free plan stops at 3 retros, and pricing is in GBP.
[Compare Teleretro with TeamRetro](/compare/teleretro-alternative/) in our side-by-side breakdown.
## Reetro
### Overview
Reetro is an AI-assisted retrospective tool for agile teams. It offers AI meeting summaries, sentiment analysis and card grouping, customizable health checks and a happiness index, plus an action tracker. Retros can be run inside Slack or Microsoft Teams.
Reetro integrates with Jira, Azure DevOps, Confluence, Slack and Microsoft Teams; it's ISO 27001 certified.
### Top three features
- AI summaries, sentiment analysis and card grouping.
- Customizable health checks and happiness index.
- Action tracker with Jira and Azure DevOps export.
**Trial:** Yes – free version available.
**Price:** Free tier (3 teams, limited active boards); paid plans available. We couldn't verify Reetro's current pricing from its own site at the time of writing, so check the vendor.
### What customers say
No reviews available at the time of writing.
### Great for
Best if you want AI summaries and customizable health checks on a free tier. The catch: anonymous input and multi-voting are both paid-only, and the current pricing is hard to pin down from their own site.
[Compare Reetro with TeamRetro](/compare/reetro-alternative/) in our side-by-side breakdown.
## IdeaBoardz
### Overview
IdeaBoardz is a dead-simple, shared-URL brainstorming board for collectively gathering input, reflecting and retrospecting. It's functional and free, but it's a legacy tool that's no longer actively developed, with no stated security or data guarantees.
### Top three features
- Optional login.
- Export as PDF or Excel.
- Runs in any modern browser.
**Trial:** Free to use.
**Price:** Free.
### What customers say
“It is one of the easiest tools to organize and manage ideas regarding anything that we want to implement in the future implementation.” – [G2](https://www.g2.com/products/ideaboardz/reviews#survey-response-7387852)
### Great for
Best zero-friction one-off: no account, unlimited boards, PDF and Excel export. The catch: no active development since 2020 and no stated security guarantees.
[Compare IdeaBoardz with TeamRetro](/compare/ideaboardz-alternative/) in our side-by-side breakdown.
## Metro Retro (now Spreo)
### Overview
Metro Retro has been rebranded as **Spreo** (after an interim stint as Ludi). The old `metroretro.io` address now redirects on. The product itself lives on as a freeform, visual whiteboard for retros, planning and workshops, with playful templates and the illustrated stickies it was known for.
### Top three features
- Infinite freeform whiteboard.
- Playful retro templates.
- Design mode and meeting mode.
**Trial:** Yes – 30-day trial (the free plan was retired in 2024).
**Price:** No free plan; paid plans are priced per member (a 10-license example works out to roughly $40/month billed annually).
### What customers say
“The interface is very simple, and super easy for everyone to learn. Being able to see what others are doing/saying/commenting on in real time is priceless.” – [G2](https://www.g2.com/products/metro-retro/reviews#reviews)
### Great for
Best playful canvas for workshops, planning and the occasional retro. The catch: it is whiteboard software now, and EU-hosted only.
[Compare Metro Retro with TeamRetro](/compare/spreo-alternative/) in our side-by-side breakdown.
## RetroTime
### Overview
RetroTime (at retroti.me) offers a very simple, real-time way for teams to collaborate: add a sticky note, align it to a category, and vote. You can hide comments during collection, assign action items, and export the summary to your sprint tool.
### Top three features
- Real-time board.
- Hide comments during collection.
- Action items and summary export.
**Trial:** Yes – free tier.
**Price:** RetroTime offers a free tier and low-cost paid plans, but we couldn't verify its current pricing from the site at the time of writing, so check the vendor before you commit.
### What customers say
No reviews available at the time of writing.
### Great for
Best if you want a lightweight real-time board and nothing else. The catch: a small tool with a small surface.
[Compare RetroTime with TeamRetro](/compare/retrotime-alternative/) in our side-by-side breakdown.
## Retrospected
### Overview
Retrospected is open-source software (GPL-3.0) for running simple retrospectives. Boards are public on the free plan and can be encrypted or made private on paid tiers, and the whole thing can be self-hosted.
Retrospected includes integrations with Slack, GitHub, Microsoft and Okta.
### Top three features
- Open source and self-hostable.
- Encrypted, private sessions (paid).
- Multilingual interface.
**Trial:** Yes – free Basic plan.
**Price:** Free Basic (40 posts); Pro $12.90/month; Unlimited $49.95/month; self-hosting is a $599 one-time license. Not SOC 2 certified.
### What customers say
No reviews available at the time of writing.
### Great for
Best if you want to run your own retro server under an open-source license. The catch: boards are public until you pay, self-hosting is a $599 one-time license, and security is your problem.
[Compare Retrospected with TeamRetro](/compare/retrospected-alternative/) in our side-by-side breakdown.
## Frequently asked questions
### What is the best retrospective tool?
There's no single best retrospective tool. The right one depends on your team. For guided retrospectives plus team health checks, estimation and reporting in one place, TeamRetro is the strongest all-rounder; for a quick free board, EasyRetro or Parabol's free tier work well.
### What's the best free retrospective tool?
EasyRetro, Parabol, Neatro, GoRetro and Echometer all offer free plans that suit small or co-located teams. TeamRetro doesn't have a permanent free plan, but its 30-day trial includes every feature, health checks, estimation and reporting included.
### Are retrospective tools priced per user or per team?
It varies, and it matters as you scale. Most dedicated retro tools (TeamRetro, Neatro, GoRetro, Echometer and Retrium) price per team, so cost is flat regardless of how many people join. Miro, Parabol and ScatterSpoke price per user, which is cheaper for a tiny team but grows with headcount.
### Which retrospective tools work best for remote teams?
All the tools here run online. For distributed teams, look for anonymous input, independent voting and async support so people contribute honestly across time zones. TeamRetro, Retrium and Parabol are all built with remote retros in mind.
### Do I need a dedicated retrospective tool, or is a whiteboard enough?
A whiteboard like Miro is flexible but unstructured. A dedicated retrospective tool adds guided steps, templates, voting, action tracking and health checks, which is what keeps retros consistent and turns them into follow-through, not a one-off discussion.
### We are a team of three. Which retrospective tool should we pick?
Probably not ours, at that size. Per-team pricing is an advantage at 15 people and a disadvantage at three, so look at Parabol's free Starter tier (unlimited users across 2 teams, 10 meetings a month) or Neatro's free plan (10 members forever, unlimited retros and Team Radars, 30 days of history). Both give a team of three a real retro rather than a trial clock. Come back to TeamRetro when the team grows or a second team starts running retros.
### Which retrospective tools can I self-host?
Parabol, and it is the clearest answer here. It is AGPL-3.0 with documented Docker and Kubernetes deployment, plus on-prem and air-gapped options on Enterprise. Retrospected is the other open-source option, licensed GPL-3.0, though self-hosting it is a $599 one-time license. TeamRetro is closed source and hosted, with a choice of US or EU hosting, so if running the software on your own infrastructure is a hard requirement, one of those two suits you better.
All pricing and features were verified against each vendor's site in September 2026. Details change over time, so check the vendor for the latest.
---
# The best team health check tools in 2026
URL: https://www.teamretro.com/blog/best-team-health-check-tools/
A team health check tool is software that lets everyone on a team anonymously rate the same
set of dimensions, such as delivery, psychological safety and workload, then track how those
scores move over time and turn the gaps into owned actions. The best ones are owned by the
team rather than by HR, keep individual ratings private so the honest answers surface, and
make the trend across quarters as easy to read as the first result.
That definition matters, because "team health check" gets used for three very different
things: a purpose-built agile tool, a published framework you facilitate yourself (the Spotify
squad model), and an org-wide HR engagement survey. They solve different problems, and picking
the wrong category is the most common mistake. This guide sorts the real options into those
three groups, tells you what each is good at, and gives a clear best-for pick.
We build one of these tools, so treat us as a party with a view. Every competitor fact here was
checked against the vendor's own live pages in July 2026, and the Parabol facts were rechecked
on 1 October 2026 after Parabol released Team Health. Pricing and features change,
so confirm the current details before you commit.
## What separates a real health check tool from a survey
Before the picks, four traits separate a tool that changes how a team works from one that just
collects opinions.
**Anonymous rating.** The moment people sign their name to a low score, the low scores dry up.
Anonymity is the single feature that decides whether you measure what people think or what they
are willing to say out loud.
**Stable dimensions you can trend.** A health check is only worth running repeatedly if the
questions stay the same, so the scores are comparable quarter to quarter. A tool that makes the
trend easy to see (often as a team radar tracked over time) is doing the job; a one-off
snapshot is not.
**Action follow-through.** Scores that don't lead to an owned, dated action teach the team that
being honest changes nothing, and the numbers quietly converge on a safe, meaningless 4. The
tool should carry actions from one check to the next.
**Fit with how the team already works.** For agile teams that means living beside retrospectives
and integrating with Jira, Slack, and the rest of the stack, not pulling everyone into a
separate HR system once a year.
## Category 1: Dedicated agile team health check tools
These are built for a team to run its own health checks on a rhythm. This is the category most
people mean by "team health check tool", and where the four traits above actually show up.
### TeamRetro: best dedicated agile team health check tool
TeamRetro is a retrospective and [team health check tool](/health-checks/) built around exactly the loop above:
anonymous rating, dimension-by-dimension discussion, trends across quarters, and actions tracked
through to done. It ships 45+ ready-made health check models, including the
[Spotify squad health check](/health-check-templates/squad-health-check/),
plus custom and AI-generated models, and several rating formats (numeric, Likert, happiness,
and matrix scales). Results plot onto a team radar you can trend over time, comments summarize
automatically, and actions carry owners and due dates from one session to the next. For
organizations running many teams, cross-team reporting on the Enterprise plan rolls the picture up today without turning
scores into a league table.
Where it fits: agile teams and coaches who want the whole health-check loop in one place, and
who usually run retrospectives too. It is a paid product (with a free trial), so a team that
only wants a one-off facilitated workshop with no software may be better served by the free
framework in Category 2.
**Best for:** teams that want a dedicated, anonymous, trend-tracking health check that lives
next to their retrospectives.
### Echometer: best for a psychology-grounded approach
Echometer
(echometerapp.com) positions itself around psychology-based retrospectives and health checks,
spun out of a university psychology faculty. Its health check draws on a large library of items
(the vendor cites 200+) across dimensions like psychological safety, team maturity, agility,
morale, and eNPS, and it records the long-term development of a team automatically. It also
covers 1:1 meetings, which the others here mostly don't.
**Best for:** teams that want a research-flavoured question bank and don't mind a smaller,
more specialised tool. (Some of Echometer's impact figures are vendor-reported, so read them
as marketing, not independent evidence.)
### Parabol: best open-source, self-hostable option for a five-question pulse
Parabol
is primarily an agile meeting tool: retrospectives, sprint poker estimation, standups, and
check-ins. Team health used to be a one-question mood round inside a retro. In 2026 Parabol
rebuilt it as a standalone recurring health check meeting with 10 built-in question packs,
including Google's Project Aristotle, Amy Edmondson's psychological safety scale, Lencioni's
Five Dysfunctions, the Spotify squad health check and Gallup's Q12, plus your own questions.
Know the shape before you count on it. As of October 2026 Team Health is generally available
(since 22 September). Every pack maps onto the same five categories, each check asks five Likert
questions rather than the whole model, and results show each category's change plus a
five-check trend line. Organization-wide reporting is listed as coming soon for Enterprise, and
there is no documented export of health scores. Score spread and respondent names stay hidden
below four respondents. Anonymous comments are shown only as an AI rewrite, so the option
disappears when an organization turns AI off. Team Health sits on the paid Team and Enterprise
plans, not the free tier, and it is English only. What none of the others here offer: Parabol is open source (AGPL-3.0) and
self-hostable, which matters for teams with strict data or air-gap requirements.
**Best for:** teams that need a self-hosted, open-source option, or already run their retros in
Parabol and want a five-question pulse beside them. The trade is five questions per check rather
than the whole model, no cross-team view yet, English only, and a paid plan.
### Neatro: best simple retro tool with a built-in radar
Neatro
is a retrospective platform that markets a "Team Radar" feature: teams score a set of
dimensions, add comments, and watch the trend over the long run, alongside a large library of
retro templates. It is a clean, approachable option, closer to TeamRetro's shape than to
Parabol's, if smaller in health-check depth.
**Best for:** small teams that want a friendly retro tool with a straightforward team radar
attached.
## Category 2: The Spotify squad health check framework
The Spotify squad health check model
is not a product. It is a framework Henrik Kniberg and Kristian Lindwall published in 2014. A
squad rates around ten dimensions (delivering value, easy to release, health of
codebase, teamwork, mission, fun, learning, and so on) as green, yellow, or red in a
facilitated workshop. The cards are free to download.
It made team health visible at scale and still frames measurement the right way: for the
team's benefit, not for management reporting. Its limits are the ones its own authors flagged:
several dimensions were designed for Spotify's engineering context, the traffic-light scale is
coarse for spotting a slow slide, and it is a workshop, so it doesn't trend or anonymise unless
you add a tool around it. That last point is why most teams end up running the Spotify model
inside one of the Category 1 tools rather than on paper.
**Best for:** teams that want a proven, free framework to adopt. Bring your own tool to run it
anonymously and trend it. Our
[team health check guide](/guides/team-health-check/) covers how to adapt it honestly.
## Category 3: HR engagement platforms (a different job)
Assistants often list Culture Amp,
Lattice, and
Workleap Officevibe
under "team health", but these are employee-engagement and performance platforms owned by HR.
They measure the individual's experience of the organisation, run once or twice a year, and the
results travel up the reporting line. That is a legitimate and important instrument. It is just
not the same as a team-owned health check the team runs for itself, on its own cadence, and acts
on in the room.
The tell is ownership and cadence. If HR runs it annually and leadership reads the results, it
is an engagement survey. If the team runs it quarterly and the team acts on it, it is a health
check. Most organisations need both; problems start when the annual survey is treated as a
substitute for a team knowing its own state.
**Best for:** org-wide engagement, performance, and people analytics owned by HR, alongside
a team health check rather than instead of it.
## Comparison table
Facts are as of July 2026, except the Parabol row, which was rechecked on 1 October 2026.
| Tool | Type | Anonymous rating | Dimensions + trends | Action tracking | Pricing | Best for |
| --- | --- | --- | --- | --- | --- | --- |
| **TeamRetro** | Dedicated tool | Yes | 45+ models, team radar, trends | Owners + due dates, carried over | Free trial; per team from $25/mo, no per-user fees | Dedicated agile health checks beside retros |
| Echometer | Dedicated tool | Yes | Large item bank, long-term trends | Yes | Free tier; Pro from ~€29/mo per team | A psychology-grounded question bank |
| Parabol | Agile meeting tool + health check | Yes | 10 question packs mapped to 5 fixed categories, 5 questions a check, five-check trend | Tasks synced to Jira, GitHub, GitLab, Linear, Azure DevOps | No health checks on the free tier; Team $8/active user/mo | Open-source / self-hosted health checks |
| Neatro | Retro tool + radar | Yes | Team Radar with trends | Via retro actions | Free up to 10 members; Premium ~$23/mo per team | A simple retro tool with a radar |
| Atlassian Team Health Monitor | Free workshop (framework) | No (open group vote) | 8 attributes, point-in-time | No (manual) | Free | A facilitated workshop, no software |
| Miro | Whiteboard (templates) | Not health-specific | Community templates on a blank canvas | No (manual) | Free (3 boards); Starter $8/member/mo | Teams that already live in a whiteboard |
| Spotify squad model | Framework | No (workshop) | ~10 dimensions, no built-in trend | No | Free to download | A proven framework to adopt with your own tool |
A note on two tools people expect to see here.
Atlassian's Team Health Monitor
is a free, well-designed facilitated workshop (now one unified set of eight attributes for all
team types), but it is scored openly as a group, gives a snapshot rather than a trend, and is a
play, not software.
Miro
is an excellent online whiteboard, but "health check" there means a community template you copy
onto a blank canvas: there is no built-in anonymous scoring, trending, or action tracking. Both
are good at what they are; neither is a purpose-built health check tool.
## How to choose
- **You want the full loop (anonymous rating, trends, actions) in one dedicated tool:**
start with TeamRetro, or Echometer if the psychology-based question bank appeals.
- **You need open source or self-hosting:** Parabol, whose Team Health is now a recurring
check of its own, at five questions per check, English only and on paid plans. For a simple retro tool with a radar attached, Neatro.
- **You want a free framework and will facilitate it yourself:** the Spotify squad model, or
Atlassian's Team Health Monitor for a workshop. Add a tool if you later want anonymity and
trends.
- **You need org-wide engagement data owned by HR:** Culture Amp, Lattice, or Officevibe. They
complement a team health check rather than replacing it.
## Frequently asked questions
**What is a team health check tool?** Software that lets a team anonymously rate the same
dimensions, trend the scores over time, and turn gaps into owned actions, owned by the team
rather than HR.
**What are the best team health check tools in 2026?** TeamRetro and Echometer for a dedicated
agile tool; Parabol for an open-source, self-hostable option, with a standalone Team Health
check since September 2026 that asks five questions rather than the whole model, has no
cross-team view yet, is English only and needs a paid plan; Neatro for a simple retro tool with a team radar
attached; the Spotify model and Atlassian's monitor as free frameworks; Culture Amp, Lattice,
and Officevibe for org-wide HR engagement.
**Is the Spotify squad health check a tool or a framework?** A framework: free downloadable
cards, facilitated as a workshop. Add a tool to make it anonymous and trend it.
**What's the difference between a health check and an engagement survey?** A health check is
team-owned, frequent, and acted on in the room; an engagement survey is HR-owned, annual, and
reported up the line.
## Run your first health check this week
If you want the full loop (anonymous ratings, a team radar you can trend across quarters, and
actions tracked through to done), TeamRetro runs it out of the box, including the Spotify squad
model as a ready template.
---
# CLAUDE.md for teams: how we turned five people's AI memories into shared rules
URL: https://www.teamretro.com/blog/claude-md-for-teams/
Every developer who works with an AI coding agent is quietly writing a rule book. Claude Code's [auto memory](https://code.claude.com/docs/en/memory) saves notes from your corrections as it works, your personal `~/.claude/CLAUDE.md` collects the preferences you got tired of repeating, and a few personal skills grow up around the jobs you do every week. All of it is private. Auto memory is machine-local and per repo: your teammates' agents never see it.
So five people learn the same lesson separately, each in a private file. The rules your team most needs are already written down. They're just not written down anywhere shared.
In September, five of us ran a memory harvest: we pooled those private files and asked which rules deserved to become team rules. This is how we did it, what earned promotion, where each rule went, and what we found, including the rules we got wrong.
## What a memory harvest is
A memory harvest is a team practice with three steps. Each person exports their private agent memories and personal rules. One reviewer clusters the entries across everyone's exports. The rules that several people wrote down independently get proposed for the shared files: the project `CLAUDE.md`, `AGENTS.md`, a shared skill, or a check in CI.
It's the maintenance step context engineering usually skips. We've argued before that [context files need a feedback loop](/blog/context-engineering-needs-a-feedback-loop/) driven by the agents that use them. A harvest is the same loop run across people instead of sessions: it's Stage 4 of the [agent feedback lifecycle](/guides/ai-agent-retrospectives/agent-feedback-loops/), aimed at the notes already stranded in private memory.
The tooling for this is thin. Of ten AI coding tools we looked at, only Devin ships a loop that watches a session, proposes a shared rule and waits for a human to approve it. The rest rely on files people write and commit by hand, or instruction sets an admin pushes out. None of them mines several people's private memories for candidate team rules.
## What we did
On 17 September 2026, five developers each ran an export script over their own Claude Code memories, their personal global `CLAUDE.md` and their personal skills. The script transmits nothing. Each person read their own bundle, deleted anything that shouldn't travel, and only then submitted it.
The five bundles held 444 memory entries, 5 global `CLAUDE.md` files, 13 personal skills and 194 rows describing the skills installed in each repo. One reviewer, an AI agent working with a human, clustered the entries across all five bundles and wrote up a proposal for each cluster. On 22 September, four of us voted on two review pages. The promotions landed as ordinary pull requests in three repos: our main product repo, a games repo and our shared skills plugin.
The bundles live on a branch that never merges. Only the promotions leave, each as a separate PR against the repo it governs, reviewed like any other change.
## What earns promotion: count authors, not entries
**A rule earns promotion when two or more people wrote it down independently.** Count distinct authors, never entries. This one rule did most of the work, and it needed three refinements before it could be trusted.
**Weigh the heavy user.** One bundle held 251 of the 444 entries, across 10 repos. Everyone else brought 37–68 entries across 1–4 repos. So "two authors" usually meant "our heaviest agent user plus one", and a cluster without the heavy user was rarer and stronger evidence. We marked those clusters separately.
**One person is one author.** One developer exported from two machines. That's one author. One person restating the same rule three times is emphasis. Corroboration needs a second person.
**Shared sources aren't independent.** Two people's global `CLAUDE.md` files were byte-identical in their first four sections, because both had adopted the same published text: Andrej Karpathy's coding guidelines for AI agents. Both were quoting one upstream document, so it counted as a single source. Any future cluster resting only on that pair gets checked against the upstream wording first.
To classify each cluster we borrowed the four operators from [ExpeL](https://arxiv.org/abs/2308.10144), a research method for agents that learn rules from experience: **ADD** a new rule, **UPVOTE** one the shared docs already have, **DOWNVOTE** one the evidence contradicts, **EDIT** one that's close but wrong. Downvote and edit matter as much as add. A harvest that can only add rules makes your context files longer and never more correct.
The threshold decides what the reviewer proposes, not what the team may adopt. A second review page listed the one-author facts that looked worth sharing, and the room voted on each. They got in because people read them and agreed.
## Where each rule should live
Agreeing on a rule is half the decision. The other half is its altitude: the level where it will actually be read and applied. (Our guide chapter on [where a fix should land](/guides/ai-agent-retrospectives/where-should-the-fix-land/) covers the ladder in full.) For harvested rules, this is the routing table we used:
| The rule is | It belongs in | Why |
|---|---|---|
| A standing fact every session in this repo needs | The project `CLAUDE.md` | It loads at the start of every session |
| The same, for every AI tool the team uses | `AGENTS.md`, imported from `CLAUDE.md` | One file every tool can read |
| Only relevant to part of the codebase | A path-scoped rule in `.claude/rules/` | Loads only when the agent touches matching files |
| A procedure used across several repos | A skill in a shared plugin | Plugins carry skills, not `CLAUDE.md` |
| A procedure specific to one repo | A repo skill | Loads when the task calls for it |
| Reference detail too long for every session | A doc, plus a one-line pointer in `CLAUDE.md` | A doc nothing loads is a doc the agent never reads |
| Mechanically checkable | A lint rule, test or CI check | Prose warns; a check stops it |
| About what the agent does, like git commands or killing processes | A hook in a shared plugin | CI never sees the agent's actions; a hook stops the command |
| A preference about your own tools, machine or budget | Your personal `CLAUDE.md` or memory | It isn't a fact about the codebase |
Two rows need emphasis. First, a [Claude Code plugin](https://code.claude.com/docs/en/plugins-reference) can ship skills, agents and hooks, but not a `CLAUDE.md`. Procedures cross repos in a plugin; standing rules have to be placed in each repo that needs them.
Second, **only delete the private memory once the destination auto-loads.** Move a rule into a doc that nothing loads and the agent simply forgets it. Where a rule went into reference docs, the private memory shrank to a pointer instead of disappearing.
## What to do with contradictions
Pooled memories disagree. Resolve a contradiction by scope where you can, supersede the stale side, and leave disagreements about preference in an explicit unresolved bucket.
**Check scope first.** One contradiction was about how to set up dependencies in a second working copy of a repo: two people had written opposite rules. Both were true in their own repo. A later change to a shared skill had since settled it for both, and our heaviest user's memory turned out to be the stale side, so that is the one to supersede rather than quietly delete.
**Supersede, never overwrite.** When a shared rule changes, add the new rule with a date and keep the old one readable, the way an [architecture decision record](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions) supersedes an earlier decision. The next reviewer can see what changed and why.
**Keep an unresolved bucket.** The second contradiction was which AI model subagents should use. Two people wanted one top-tier model for every subagent; one picked models by task. The vote split two "discuss", two "agree". It stayed unresolved on purpose, because it's about how much each person is willing to spend on their own account, not a fact of the codebase. It stays in each person's private rules.
## What the harvest found
Fifteen promotions landed from the first review page: 11 for our main product repo (two of them also applied to the games repo), three for the shared skills plugin, and one fixing the harvest's own exporter. Seventeen more landed from the second page: one-author facts the room agreed to share, plus two clusters the first count had wrongly recorded as one-author. On the second page, one item was voted down, three were parked for more discussion or a better home, and three were agreed but need code or a skill rather than a doc line. The model question stayed open.
**The most repeated cluster was about comments.** Three authors, one of whom had written it down four times: comments state durable facts about the code; they never narrate the change or its history. One author noted that subagents are the usual offenders.
**The broadest was about evidence.** Four of the five authors had written a version of "verify before asserting; a failed search is not evidence of absence." Reviewer claims are hypotheses, and failing to reproduce a bug doesn't prove it can't happen. It was the closest thing the team had to a shared house rule, and it was written down nowhere shared.
A related cluster, from two authors, was about stale git state: a local branch far behind the remote, a search run against the wrong checkout. Each of its five incidents produced a confident, false claim that reached a commit message or PR description.
**Harvesting corrected wrong guidance, not just missing guidance.** Three findings were DOWNVOTE or EDIT calls on guidance we already had:
- Our shared `AGENTS.md` told agents to run the repo-wide `lint:fix` when changing lint rules. Three people had separately warned against it: the repo doesn't lint clean at baseline, so a repo-wide fix buries your diff in unrelated formatting.
- A shared skill said to fall back to the API if `gh pr edit` failed. It doesn't fail: it prints a non-fatal notice, exits 0 and leaves the pull request unchanged. A fallback keyed on a failure that never happens never runs. Three authors had hit this across three repos.
- An existing warning in our agent docs called one database mistake "safe" because it errors immediately. Three people had hit it on three different tables. In one case the mistake passed review, passed CI and crashed only at runtime.
**Some agreed rules belonged in a machine check.** The database warning above is mechanically checkable: a test that reads the schema would end the whole class, where the doc only warns about it. "Never hand-edit the generated schema file" was agreed as true and still parked, because prose is the wrong enforcement. Two other agreed items were already written as step-by-step procedures, which makes them skills. Several items left the vote as tickets instead of documentation.
**A rule can be default behavior and still need writing.** Two people had independently written "never commit or push unless asked". One put it best: "writing files is not permission to commit them." Any agent should already behave this way. Two people wrote it down because it kept happening anyway, which is the argument for making it explicit.
**The harvest found a bug in the harvest.** Each bundle carried a version stamp so the review would refuse to compare bundles built by different collection rules. The stamp came from the plugin's version, not the exporter's. All five bundles were built by byte-identical scripts and stamped with three different versions. The safety gate could never fire on a real rules change and would fire on every unrelated plugin update. That fix was one of the fifteen.
## How often to run it
The first harvest is the expensive one: months of private notes, cleared in one bounded session. After that, keep a five-minute standing check at a regular team sync: anything new that more than one person has written down?
Five failure modes to design against:
- **Write-only**: rules get promoted and nobody checks whether the agent's behavior changed.
- **Stale with no owner**: a shared rule outlives the code it describes.
- **Promoted on n=1**: one person's strong opinion becomes a team rule because they were first to write it.
- **One doc holding four kinds of content**: standing rules, procedures, reference and history in a single file nobody reads end to end.
- **Abstracted until useless**: a rule generalized so far from the incident that caused it that it no longer tells the agent what to do.
## What we'd change next time
Comparing our process with tools that learn on their own showed four gaps. We're adding a fix for each to the harvest before the next run.
**Rules about the agent's own actions need a hook.** Two of our promotions were about what the agent does, not what the code says: subagents committing to the wrong branch, and a broad process kill taking out the shell it ran in. CI never sees either. A [hook](https://code.claude.com/docs/en/hooks) can stop the command before it runs, and a shared plugin carries it to every machine that installs it.
**A rule people keep re-learning isn't working.** This is the write-only failure mode above, and a harvest can measure it. If a rule was promoted last time and people still wrote it into their private memory afterwards, the shared line isn't working. That's the signal to move it out of prose and into a hook or a check.
**Check that a memory is still true before promoting it.** One memory warned about a live bug that had already been fixed. Promoted, it would have handed everyone a false warning. Anything that names a file, a function or a bug will be checked against the current code first.
**A harvest only sees what people wrote down.** Entry counts ran from 37 to 251 per person, which says more about who writes things down than about who hits problems. Next time, each person can first ask their agent to read their own recent session transcripts and list the corrections no memory covers. They decide which ones to save. The transcripts stay out of the shared bundle.
We also considered letting an agent do the whole job: watch sessions, write its own rules and load them automatically. Some tools already work this way, and our [map of agent feedback loops](/guides/ai-agent-retrospectives/agent-feedback-loops/) includes one. That works well for one person's setup. For rules a whole team relies on, we still want people to read each one and vote.
## Run one by hand
You don't need special tooling. Our export was a small script, but every step works by hand:
1. **Export privately.** Each person copies their auto memory folder (in Claude Code, `~/.claude/projects//memory/`), their `~/.claude/CLAUDE.md` and any personal skills into one folder per person.
2. **Prune before sharing.** Each person deletes anything that shouldn't travel: credentials, customer details, anything about a named colleague. Nothing leaves without its owner reading it.
3. **Cluster by meaning.** One reviewer, human or agent, groups entries that say the same thing in different words and records who wrote each one.
4. **Count distinct authors.** Two or more independent authors is a candidate. Merge one person's machines, discount shared upstream text, and note which clusters stand without your heaviest user.
5. **Classify and route.** Label each candidate ADD, UPVOTE, DOWNVOTE or EDIT, then give it a destination from the routing table above.
6. **List contradictions separately.** Resolve by scope where you can; leave the rest unresolved and say so.
7. **Let the room vote.** Put the proposals on one page, the one-author facts on a second, and decide together.
8. **Land each promotion as its own PR** against the repo it governs. Keep the raw bundles out of main.
## Frequently asked questions
### What is a memory harvest?
A memory harvest is a team practice for AI coding agents: each developer exports their private agent memories and personal rules, one reviewer clusters the entries across everyone's exports, and the rules that several people wrote independently are promoted into shared files such as `CLAUDE.md` or `AGENTS.md`. It's the team-level maintenance step of context engineering.
### How many people need to agree before a rule goes into CLAUDE.md?
We use two or more independent authors. Count distinct people, not entries: one person restating a rule three times, or exporting from two machines, is still one author. Two people who copied the same published text aren't independent either. The threshold decides what gets proposed; the team still votes on every promotion.
### What belongs in a team CLAUDE.md versus personal memory?
Standing facts every session in that repo needs belong in the project `CLAUDE.md`, because it loads automatically. Procedures go in skills, reference detail goes in docs with a pointer, and anything a machine can check goes in a lint rule or test. Preferences about your own tools, machine or budget stay personal.
### Should team rules go in CLAUDE.md or AGENTS.md?
Rules every AI tool should follow go in `AGENTS.md`; Claude-specific instructions stay in `CLAUDE.md`. Claude Code can read `AGENTS.md` directly or through an `@AGENTS.md` import, so one file can serve every tool your team uses.
### What do you do when two developers' memories contradict each other?
Check scope first: both can be true in different repos, and a later tool change may have settled it. If one side is stale, supersede it rather than overwrite it. If the disagreement is about preference rather than a fact of the codebase, leave it unresolved and keep it in each person's private rules.
### How often should a team run a memory harvest?
Run one bounded session to clear the backlog, then keep a five-minute standing check at a regular team sync for new candidates. The first harvest is the expensive one; after that the volume should be small.
## Make it a team decision
In a memory harvest, the team decides which rules become shared; the reviewer only proposes. The export, the clustering and the counting can all be automated. The vote can't, and shouldn't be. Which rules bind everyone, which stay personal, and which disagreements stay open are calls for the people who will live with them. It's the same point we make in [the report exists, the room doesn't](/guides/ai-agent-retrospectives/the-report-exists/): an aggregate view is only useful once the people who own the fixes decide together.
That's a [retrospective](/retrospectives/) with different inputs. When our [AI agents filed their own retro items](/blog/our-ai-teammates-joined-our-retro/), the evidence came from their sessions. This time it came from our own private notes, and the room did the same job: read the pattern, pick the altitude, give each fix an owner. If your team already has a regular retro, a memory harvest fits in as one agenda item. The full practice is in our [guide to AI agent retrospectives](/guides/ai-agent-retrospectives/).
*Run a harvest of your own, or think our threshold is wrong? Tell us: [ai-discussion@teamretro.com](mailto:ai-discussion@teamretro.com).*
---
# Context engineering needs a feedback loop
URL: https://www.teamretro.com/blog/context-engineering-needs-a-feedback-loop/
Context engineering is the discipline of giving an AI agent the right information, in the right shape, at the right time, so it does good work instead of guessing. In practice, for most teams, that means files: a `CLAUDE.md` at the repo root, an `AGENTS.md`, a folder of rules and conventions, a system prompt someone tuned once. You write down how your project works so the agent doesn't have to rediscover it every session.
It's genuinely the highest-leverage thing you can do to make agents useful. And almost everyone doing it has the same unspoken problem: those files go stale, and nobody knows which parts. You wrote the context once, the codebase moved on, and now half of it is quietly wrong. The discipline has an input, writing context, and no maintenance loop. That's the gap this post is about.
## Context is code, and code rots
We already know documentation rots. The build step you documented gets replaced, the folder you described gets renamed, the convention you wrote down gets superseded, and the doc keeps confidently describing the old world. Context files are worse than ordinary docs on this, for two reasons.
First, **an agent reads them literally and acts on them.** A human skims a stale README, senses it's off, and asks someone. An agent takes `CLAUDE.md` at its word. If it says "run `make setup`" and that target was deleted last quarter, the agent doesn't shrug. It burns time trying to make the wrong thing work, or it invents a workaround and moves on, carrying the bad instruction into its output.
Second, **incorrect context is worse than missing context.** A gap, the agent can sometimes reason around or flag. A confident wrong statement, it trusts. The most expensive lines in your context files aren't the missing ones. They're the ones that used to be true.
So you need a maintenance loop. The trouble is the usual candidates don't work. You won't audit `CLAUDE.md` line by line on a schedule. Nobody does. You won't notice it's stale from the outside, because it reads fine. The staleness only reveals itself at the moment of use, to whoever is using it. And increasingly, whoever is using it isn't a person.
## The one witness who knows
Here's the shift. The agent that just ran a session against your project is the only participant that knows, concretely, which parts of your context helped and which parts lied to it. It just used the files. It hit the stale build command. It found the folder that doesn't exist. It followed the pattern that turned out to be three patterns. That knowledge exists for about as long as the session does, and then it's gone.
Nobody tells you which context is missing or wrong, except the thing that just suffered from it. That's the feedback loop, sitting right there, unclaimed. All you have to do is ask the agent to write down what it learned before the session closes, and structure the ask so the output points straight at the files that need editing.
## The session retro log is the maintenance loop
This is exactly what an end-of-session AI retro produces. At the end of a working session the agent writes a short, honest entry: what went well, where it hit friction, and, the part that matters here, every friction item is tagged with one of ten fixed root-cause labels and ends with a ticket-sized "→ Fix:". Two of those ten labels are pointed directly at your context files:
- **`missing-documentation`**: the agent needed something the project should have documented, and didn't. This is your context file's *to-write* list. Every one of these is a line you should add to `CLAUDE.md` or your docs.
- **`incorrect-documentation`**: the docs existed but were wrong or out of date. This is your context file's *to-fix* list. Every one of these is a stale line the agent caught the only way it can be caught: by using it and hitting the wall.
Add a third and you've covered most of the maintenance you'll ever need: **`ambiguous-instruction`**, where a brief or a rule could be read more than one way. That's the loop. You don't audit your context files on a calendar; you let the agents that use them tell you, in the moment of use, exactly which lines to change, with the evidence attached, because the practice is evidence-cited only.
And there's a fourth signal that's easy to miss: **the guesses.** A good entry lists every point where the agent filled a gap with an assumption. Each guess is a place your context was thin enough that the agent had to invent an answer. Read a week of guesses and you have a to-do list for your context files that you could never have written yourself, because you already know the answers, and so you can't see where they're missing.
Here's the shape of what comes back. An illustrative example, not real data:
```markdown
## Friction
- CLAUDE.md says "run `make setup`" but that target was removed; the
actual setup is `pnpm install && pnpm db:migrate`. Lost ~10 min.
(incorrect-documentation)
→ Fix: Update the "Getting started" block in CLAUDE.md to the pnpm commands.
- Nothing documents that integration tests need the worker running.
Found it by reading the CI config. (missing-documentation)
→ Fix: Add a "Running tests" note naming `pnpm worker` as a prerequisite.
## Guesses I made
- Assumed the `api/` package is the public surface and `internal/` is not,
because nothing states it. Please confirm before I rely on it again.
```
Every line there is a specific edit to a specific file. That's a maintenance loop a person will actually run, because the work of finding the problem, the expensive part, is already done.
## Why this beats auditing by hand
You could try to keep context files fresh the old way: schedule a review, read them top to bottom, check each claim against reality. It doesn't happen, and even when it does it's the wrong instrument. Reading a doc in the abstract, you can't tell which lines are stale. They all read plausibly. The staleness is only visible under use. The retro log is context maintenance *driven by real use*: only the lines that actually tripped an agent get flagged, so you fix what's genuinely broken instead of re-reading what's already fine. It's the difference between a smoke detector and walking the building sniffing for smoke.
It also compounds. Fix the `incorrect-documentation` items this week and next week's sessions hit that wall less, so the log gets shorter and shifts to deeper issues. Your context files trend toward accurate not because anyone audited them, but because the people, and agents, using them had a cheap, structured way to report the drift. That's healthy human-AI collaboration: the agent surfaces the drift, the human decides the edit. The same loop works across people too: we [pooled five developers' private Claude Code memories](/blog/claude-md-for-teams/) and promoted the rules several of us had written down independently.
## Start the loop
If you're already investing in context engineering, this is the missing half: the maintenance loop that keeps the investment from rotting. It's open source and MIT-licensed:
- **Get the skills and prompt pack:** [github.com/TeamRetroHQ/teamretro-skills](https://github.com/TeamRetroHQ/teamretro-skills): a Claude Code skill that writes the end-of-session entry, one that synthesizes entries into a brief, and a tool-agnostic prompt pack for Cursor, GitHub Copilot, or any agent you can prompt.
- **See the full practice:** [how to gather feedback from your AI agents](/blog/gather-feedback-from-ai-agents/) covers all ten labels, the human sanity-check, and how the entries feed [a team retrospective](/retrospectives/), not just your context files.
- **Go deeper on the loop itself:** [agent feedback loops](/guides/ai-agent-retrospectives/agent-feedback-loops/) maps the whole landscape: the capture-to-fix loop, the tools that run it, and where a session retro fits.
One nuance worth keeping. When an agent reports the docs are wrong, check before you edit, because sometimes the docs are right and the agent misread them. That's still a useful signal (a line easy to misread is a line worth rewriting), but it's a different fix, and it's why a human stays in the loop. The agent is a participant flagging what tripped it, never the authority on what your project should say.
Your context files are only as good as their last honest correction. The agents using them are handing you those corrections at the end of every session. You just have to write them down. And if your team wants those fixes to land somewhere people already look, the agent can prepare its recommendations and post them onto your board itself via the [TeamRetro MCP server](/mcp/), confirmed by you, marked `[AI retro]`, next to the rest of your team's improvements.
---
# Create your team’s social contracts with effective team agreements
URL: https://www.teamretro.com/blog/create-social-contracts-with-team-agreements-that-improve-culture/
Often used by agile teams, a social contract paves the way for everyone in the team to work together better. They list the agreed ways a team will behave with each other. Typically, without a clear agreement, there’s often a lack of clarity as to how team members should interact.
Let’s face it, working together is challenging. Whether your team is new (forming and storming) or a seasoned group (performing and adjourning), working with others requires effort. Different personalities, backgrounds, and the company’s ethos influence how a team performs.
Innocent actions of one person can easily frustrate, distract, or annoy others. While one team member may be very chatty during meetings, another may find that rude. Even behaviors with positive goals such as recognition of effort might be missing the mark.
How people interact in a meeting defines culture. From raising an opinion and being heard without judgment through to whether or not you turn the video camera on during the discussion. All form part of the norms that define the culture of a team.
One of the ways to build a positive culture is to address issues and create [team agreements](/guides/team-dynamics/team-norms-and-working-agreements/).
## What are team agreements for agile teams?
Team agreements are the behaviors that a team promises to demonstrate when working with each other on a daily basis. They can cover a number of workplace contexts including –
- decision making
- meetings
- communicating
- information sharing
- supporting each other
These are the ground rules for behavior. They make it psychologically safe for everyone to participate as a team.
Here, psychological safety means that team members can share their ideas without the fear of judgment, bias, status, or authority. This allows people to focus on a project rather than worry about surviving socially.
Team agreements are usually created at the start of the project by the team. They can include things such as:
- Using the [agile retrospective prime directive](/guides/scrum-masters-retrospective-guide/what-is-the-retrospective-prime-directive/) as part of retros
- Everyone has an equal voice and is a valuable contributor.
- If you are assigned a job, you should own the task and keep it up to date.
- Complex tickets should be discussed with the person before simply being assigned.
- Use of code words to indicate a need.
- Clear meeting cadence and purpose.
- How the team communicates and works remotely, with flexible hours, or different time zones.
## The benefits of team agreements
There are plenty of benefits of having team agreements. They –
- help reduce team conflict.
- help people better manage stress and anxiety.
- lay the foundation for cooperation, collaboration, and continuous improvement.
- build trust and help create belonging.
- give the team a sense of control and security.
- build relationships within the team
- help move the team through the Tuckman team development model.
So done right, team agreements can amplify the greatness of your team.
## How to create team agreements?
Unsurprisingly, creating team agreements is best done with the team. It’s a collaborative process. It can be done manually in person with sticky notes. It can also be done online with [a good retrospective tool](/retrospective-tool/).
The advantage of an online retrospective tool is the ease with which input can be kept anonymous. Again, this is to foster a psychologically safe environment in which people can share their ideas.
### 1. Explain the need
The first step is to explain the need for creating the team agreement. Most people will already understand the rationale but it’s a good reminder nevertheless. You can set aside some time at the start of your retrospective or have a specific meeting to talk about this.
The benefits of having a team agreement include –
- having a way to define and improve the team’s culture
- having clear and defined ways of working with each other successfully
- knowing the expectations of each other and having a working understanding
- being generally happier at work when the team gels
### 2. Create individual accountability
Next, ask everyone to type in a positive behavior they think aligns with the organization, their team, and themselves. This is what makes the agreement unique to their team and creates buy-in.
When getting people to brainstorm and add ideas, it can be helpful to give them a few sentence starters. This helps ensure that the agreements are behavioral-based and are framed in a positive way.
Here are a few suggestions –
- You can count on me to ________________
- We can be a great team by ________________
- We can overcome some of our frustrations and issues by ________________
- One thing I love about this team is when ________________
- We can improve the way we work by ________________
Each point of the agreement should be a standalone concept to keep it simple.
### 3. Propose agreements for discussion
Generally speaking, it’s a good idea to have people [propose an agreement](https://help.teamretro.com/article/266-team-agreements) before it is accepted. This ensures that everyone understands and genuinely accepts the agreement as opposed to it simply being a box-ticking exercise.
An online tool such as TeamRetro allows you to have the option to either have people add agreements directly to a list or to propose them to the group. If an agreement is proposed everyone else can then choose to support it (thumbs up), not support it (thumbs down) or remain neutral. This allows you to quickly see if there is consensus within the group before it is confirmed as an agreement.
### 4. Facilitate group discussions
Once the agreements have been shared, give everyone a chance to read through them and ask clarifying questions. You can group identical items if need be.
Facilitate a discussion and allow concerns, questions, and comments to be explored. Objections should be noted. Then decide upon which to include by voting.
Not all proposed agreements will be accepted. Talk these through with the group to ensure it’s understood why that was the case. The goal is to work through all the proposed agreements before closing the meeting.
The proposed behaviors that are accepted are the team agreements that form the social contract.
### 5. Reflect on the agreements
Once the agreements have been added to the list, it’s a good idea to review them. Get further comments and address any new concerns that may have come up. A good question to ask can be –
“When looking at our team agreements, how do we think it will impact the way we work together, and how does that feel?”
The feedback informs any final revisions the agreements may need.
### 6. Use the agreements
Finally, at the start of future meetings, it’s a good idea to quickly reference the agreements to help set the tone for your session. Alternatively, you can use it as a reflection at the end of the meeting to see if the team stuck to their agreements.
TeamRetro displays team agreements on your dashboard. This means they are always at your fingertips.
## Traps to avoid when creating team agreements
### 1. Lack of real consensus
The most obvious trap is when not everyone in the team truly commits to the agreements.
Head nodding at the collaboration meeting can simply be that. People first need to understand before they buy-in. This means that the agreement has to make sense to them, as well as align with their values.
As we’ve touched on before, this is also why each team has to come up with its own set of agreements. Borrowing or piggybacking another team’s agreements does little to improve traction. It will only serve to reduce the sense of ownership.
If the agreements are pushed down from top-level management, this can increase the disconnect.
Having ample time to talk through concerns and address them before making them part of the final agreement is important.
### 2. No rituals
The agreements then need to translate into actions and daily rituals. If not, they are simply words on a page.
There may be different interpretations of the agreements. This would lead to differences in behaviors.
One way our team has managed this is to come up with code words. The code words summarize our team agreements. Here’s a sneak peek at what we do.
- Cross-check- Team members agree that for critical, customer-facing actions a cross-check is required. A colleague of a similar role and skill will quality check and vet the work to verify accuracy.
- Sushi time – We love having fun at work. Sometimes a bit too much. If someone says ‘sushi time’ they are asking to have focussed work time. Because we have agreed to it, no one is offended, and we quickly quieten down.
- Bikeshed – If a topic comes up that cannot be resolved immediately then that topic is parked. The topic is put in the “bikeshed” and taken out again later for discussion.
### 3. Blame and shame
Team agreements can be used inappropriately. In other words, they can be used to attack or finger point.
As a scrum master, it is important to ensure that people feel safe at work. Fear has no part to play. People need to be able to own their mistakes as part of their continuous improvement.
There is an effective way to manage the misuse of the agreements. Ask people to pinpoint good examples where others have demonstrated positive behavior. However, have them reflect on themselves when asking which agreements they can improve upon.
## How to make team agreements stick?
### 1. Lead by example
As a scrum master, it’s important for you to demonstrate the behaviors in the agreement. If you start to stray, so will the team.
Make it clear that you would like someone to nudge you if you start to head off track and that you will do them the same for them.
### 2. Keep them in view
Make the agreements as visible as possible.
You can publish the list to Slack or MS Teams. It doesn’t matter how you do it, it’s all about reminding people of the behaviors they agreed to.
### 3. Revisit and revise
Over time, your team will change and so will the environment you work in. So your agreement should change too.
Having a regular cadence to revise and update the agreement will make the agreement more meaningful and keep it current.
### 4. Different teams, different agreements
Don’t be fooled. Each team is different, even if they have similar roles.
Make sure that each team has their own agreements that are unique and that works for them.
### 5. Acknowledge and recognize
Teams that demonstrate the behaviors they committed to are worth their weight in gold. Recognizing the efforts of the team regarding the agreements will help reinforce that great behavior.
## Ready to create a team agreement?
TeamRetro lets you run online agile retrospective and health checks easily and effectively. It lets you create [team agreements](https://help.teamretro.com/article/266-team-agreements) that you can refer to in future meetings.
Agreements can be proposed by the team members anonymously and safely. Team members can indicate their support for agreements before they are accepted. Help make your teams go from good to great today!
#### Create a team agreement now
---
# Creating positive working relationships between the product owner and agile retrospective team
URL: https://www.teamretro.com/blog/creating-positive-working-relationships-between-the-product-owner-and-agile-retrospective-team/
The relationship between the Product Owner, Scrum Masters and Developers is critical to an Agile Team’s success. It’s a symbiotic relationship that relies on clear communication, aligned goals, transparency, and is founded on trust. Building a product that is widely adopted or continuous improvement is the usual goal, but the cohesion and dynamics of the team can determine how smooth and pain-free that process is.
We wanted to learn more, so we went out to find a Product Owner to share their insights and stories.
Following his product roadmap presentation at the Perth Agile MeetUp, we sat down with Adam Mullett, author of the book [*From “No” to “How?: Get Buy-in and Lead Change*](https://from-no-to-how.square.site/) and a Product Owner to ask him for his take on the level of involvement a Product Owner should have in a retrospective.
What we got was more than just an answer to a question, but a demonstration of the role of the Product Owner and a renewed appreciation of trust, transparency, and discipline.
## The relationship between Product Owner, Scrum Masters, and agile team
Adam seemed somewhat taken aback when asked if a Product Owner should be involved in the retrospective.
The question stemmed from the observation that some people involved in agile perceived the presence of the Product Owner at the retrospective as optional, or even a hindrance.
After only a brief pause, his response was an emphatic “yes!”
He went on to outline ‘why’ –
One of the important aspects of Agile is that it is not about being fast, but about being adaptable- which leads to more success, such as better adoption of a product.
When it comes to running a team’s retrospectives, not only is it important to facilitate the process but it’s equally important to manage the culture. The team relies so much on the direction and the input of the Product Owner as a subject matter expert. The Product Owner fosters an environment in which a can team can strive to be high performing, being responsible for outcomes, and self-managing so that they remain accountable to their stakeholders.
## Trust and transparency
Adam perceives that fundamental to the fabric of a Product Owner is trust and transparency.
“For me, being transparent is a gift because you are sharing what you think or what you know. If the team can’t get that out of you, then you aren’t giving them what they need to make them successful.”
“There should be no secrets between the team, the Scrum Master, and the PO. For me, I would zero in on those things. I’d rather raise the issue and dive into conflict rather than leave it to fester.”
“Being able to discover something that is stopping a team from going forward is really valuable.”
Adam offered an example of two team members who weren’t talking to each other in a team he once coached.
“It was unfathomable! So, if there was a comment connected to the issue made during the retrospective, I would keep diving in, drilling down into the ‘why’, until they realized that their lack of communication was the problem.”
Although the approach was somewhat confrontational, once the issue was brought to the fore it was easier to address, and team members were later thankful the matter had been sorted.
“Sorting out these types of issues could be as simple as offering different working hours. Not talking to another was simply not a good reason to not be a high-performing team. “
## Bring people into the conversation
A Product Owner should keep collaboration front of mind, which is why Adam aims to co-create.
“If I’m doing something, I want to do it with you, not to you. No change will ever be successful if you’re doing it alone”
“Because team collaboration is needed for co-creation to take place, it’s important to know how and when to bring people into the conversation. Choosing the way conversations happen can make a big difference.”
“For example, it’s easier to show someone your work, rather than having to convince them. A one hour prototype that you can talk to is much more effective sometimes than a big planning session where you are trying to sell your idea. Other times it might be better to co-create.”
## Be disciplined with process and outcomes
When discipline is viewed as a platform of support rather than a barrier to flexibility, it can act as a mechanism of team empowerment.
Discipline can be as simple as starting a meeting on time, finishing on time, and having a strict definition of ‘ready’. They are the small, agreed behaviors to which team members adhere with a view to mindfully improving team cohesion and respect.
It’s Adam’s view that with discipline, healthy habits can be fostered that support high functioning teams.
“I was a Product Owner in a project where there were 23 teams and a general mindset of getting through this sprint, then another sprint, and another sprint, and so on, just get through the sprint however we could.”
“Then we started to become more disciplined in the sprint.”
“Yes, it was tough in the first month because we were trying to do two things at once. But after that, it was smooth sailing. And the team was able to continue improving and growing as a high-performing team. In fact, others in the organization were wanting to be part of that team.”
It was also observed that the teams that lacked discipline would experience problems.
So what should happen if team members didn’t embrace a disciplined approach?
“If someone comes unprepared, then it’s important to make the purpose of the meeting clear and how their actions do not support that purpose.”
“It’s about focus. During product grooming, for example, if people start to talk about a particular ticket, then it’s about bringing the focus back to why we are having this meeting and what we are aiming to achieve as an outcome for that ceremony.”
Of course, the Scrum Master helps keep this discipline.
In terms of their retro, Adam added that once a team understands and appreciates the structure their discipline has built, they are far more focused and efficient, without having to engage in System 2 thinking, as described in the book [Thinking Fast and Slow](https://mlsu.ac.in/econtents/2950_Daniel%20Kahneman%20-%20Thinking,%20Fast%20and%20Slow%20\(2013\).pdf) by Daniel Kahneman.
“Having a clear process keeps things easy. Teams don’t want to have to worry about things such as which room or which technology they are using. Their focus is on the actual problem.”
## Build up your team as they build solutions
As far as Adam is concerned, there is no lack of clarity as to the role of the Product Owner; if you are a Product Owner, you are part of the agile team.
“I feel like it’s the Product Owner’s role, with support from the Scrum Master, to build the culture and create clarity for the team.”
“Teams hate not knowing where they are going. They turn on each other, they get antsy, they try to look busy, and all sorts of other dysfunctions. If you can give people a reason, a ‘why’, a strategic direction, then they will say ‘okay, cool. Got it!’ So it’s about being loosely coupled but tightly aligned. That way we all know where we are going then allow the team to get there.”
Adam has worked with fully in-person, remote, and hybrid teams. For 18 months, he worked with people spread from Sydney through to India. No matter the make-up, one of the success factors of a high-performing team was the understanding of what would happen next.
“So if one thing happens in our retrospective, then someone would go off to create a ticket in Jira. People could still work together even if they weren’t always in the same room. Having strong ways of working helped to accommodate that”.
## The role of the product owner in an agile retrospective
Circling back to the question of the role of the Product Owner in the retrospective, Adam noted the Product Owner is a participant.
In his opinion, the retrospective itself can be run by anyone in the team, with his preference that the facilitation be rotated among team members so that those skills can be developed and appreciated by the team.
“I think the team wants the PO to be honest and to be open as they participate”
In terms of what a product owner hopes to help achieve at a retro, Adam’s response is simple – it’s for the team to get better at what they are doing.
Why?
“Because the PO is accountable for outcomes to the organization in terms of how long something took through to resources used. The team is responsible for delivering the outcomes. So the Smart PO will attend the retrospective to listen. They won’t tell people what to do, or that they should do it “this way”. If the team already knew, they would have done it.”
Adam views the retrospective as an opportunity for the team to –
1. discover solutions
2. to find things out as they go in order to be a high performing team and
3. to move up the maturity ladder.
The Product Owner wants to help build a high performing team for many reasons –
1. to improve predictability
2. to have good, solid, regular user story management
3. to improve overall confidence and quality
as features get developed over time.
## Encourage and enable changes at your retros
So why do retros work?
“I think it’s because the team is empowered to come up with things that they can change. They can define SMART goals that they can put into effect over the next two weeks. They are coming up with the problem that impacts them, so they are self-directed to the change.”
It was noted that some people may fear change because something is being done to them, and they don’t feel like they have the control.
“Something I reference in From “No” to “How?”, is the sphere of influence and loci of control. It’s important to help the team focus their conversations on where their locus of control lies so that they are empowered and feel capable of making changes.”
“They should feel they can lean on the PO to leverage their influence or social capital to influence beyond the team’s sphere of influence.”
“In the meantime, if an agile team feels like they are in control of their destiny, then they can change their world and make things happen. They feel more empowered to do things and can then go ahead and get things done.”
## How a product owner can guide a team away from dysfunction
We couldn’t let Adam go without asking for his advice as to how to transition a team from dysfunction to high performance.
The key take-aways:
1. Ensure everyone knows where they are going, their purpose and ensure they are all on the same page.
2. Make sure there’s good communication; whether it be team member to team member, to Product Owner to Scrum Master, communication needs to be open and honest.
3. Discipline! Give people the platform for creativity. Start on time, focus on what the meeting’s about. It provides a structure so people can flourish.
4. Always tell them ‘why’
5. Call out dysfunction. Identifying problems, conflicts and errors is great because something has been discovered.
Do you have any other [insights](https://www.youtube.com/watch?v=bUtHQXm6HKY) or stories to share about how you have improved working relationships between your scrum team and product owner? We’d love for you to [share with us](mailto:info@teamretro.com).
About [Adam Mullett](https://www.linkedin.com/in/adam-mullett-57250213/)
[*From “No” to “How?: Get Buy-in and Lead Change*](https://from-no-to-how.square.site/) encourages the sharing of outcomes from failed improvement attempts with peers and the boss as a way of both cementing the lesson and sharing the learning with others.
[Try a demo with our fun bots](https://secure.teamretro.com/demo/health-checks/0bd55a69-9990-46a9-ad28-15f012d5563a)
or
[Start Your 30-day Free Trial](https://secure.teamretro.com/login/new?cc=www-blog)
---
# Daily standups in TeamRetro: post before you meet, and keep every blocker in sight
URL: https://www.teamretro.com/blog/daily-standups-in-teamretro/
Daily standups in TeamRetro are now available on every plan, and they sit next to your retrospectives and health checks. Everyone posts an update when their day starts, so any time you do spend together goes on the problems. Every blocker becomes an action on the list your team already works from. The [standups page](/standups/) shows how it works, and you can run your first one on a free trial.
## Ask trAI for the summary that suits you
Not everyone wants the same view of the team's updates. A product owner may care about one project, a manager about the whole week, and an engineer about what is blocking them. Ask [trAI](/ai/) in your own words and it pulls the summary from your team's standups in the shape that makes sense to you. For example:
- "Give me an update on what's happening with Project X."
- "Summarize this week's activity from our standups."
- "What's still blocked, and who owns it?"
- "What has Maya worked on since Monday?"
## Why the daily sync belongs next to the retro
The standup is the meeting most teams run most often, and the one whose output disappears fastest. A blocker raised at 9:15 has usually been forgotten by lunch. Two people agree a handoff in passing, and on Thursday each of them finds out the other has been waiting since Monday.
Retrospectives and health checks have the opposite problem. They produce actions and agreements that matter, but only every couple of weeks, and the daily friction that should feed them lives in a chat thread or a call nobody wrote down.
Standups close that gap. They join [retrospectives](/retrospectives/), [health checks](/health-checks/) and [estimation](/estimations/) in TeamRetro, and all four share one action list, one set of agreements and one record of how the team is trending. A blocker raised on Tuesday morning is the same item the retro reviews on Friday, with the same owner and the same due date. In other words, it helps you remember, so you don't have to.
## What you get straight out of the box
### Async by default, live when you need it
Each day gets its own standup room that stays open. People post when their day starts, and teammates reply with comments, reactions and @mentions. When something needs talking through, a facilitator takes the standup live in present mode, walking through each update with live reactions, and can add a timer or open with an [icebreaker](/icebreakers/).
### A template for each kind of check-in
Start from Daily Standup, Async check-in, Weekly sync or Daily Stand-down, or write your own questions and save them as a team template. Each question is marked as done, doing or blocked work, which is how TeamRetro knows what to carry forward and what to count as a blocker. You can add the sprint goal too, so every update is read against it.
### Set it up once
Choose the days and the time, and TeamRetro sends the invites and a reminder to anyone who hasn't posted yet, by email, [Slack](/integrations/slack/) or [Microsoft Teams](/integrations/microsoft-teams/). Updates are written in TeamRetro, and the reminder carries a button that opens the standup.
### Yesterday's plan comes back to you
The next morning, your previous update waits at the top of the new one. Close each line as done, continued or still blocked, and a blocker that is still blocked shows how many days it has been open.
### Blockers become actions
Give a blocker an owner and a due date from the standup's Actions pane, or ask [trAI](/ai/), TeamRetro's AI assistant, to create actions for the day's blockers. They join the same list as your retrospective and health check actions, and they stay in sight until someone clears them.
### A summary when it closes
Each standup closes with a list of blockers, tasks and participation, plus an AI summary you can edit before you share it. The team gets it by email, or as a post in your Slack or Microsoft Teams channel, and you can download it for people outside the team. Inside the standup, trAI can cut the same updates by sprint goal, by person, by project or across last week.
## Async, live, or a blend
Most distributed teams settle on a blend: written updates by default, plus a short live window for the two or three things that need a conversation. The format should be a choice your team makes, and a daily video call kept out of habit is a choice too. Our guide to [async and remote standups](/guides/daily-standup-guide/async-and-remote-standups/) covers when the written format works better, and how to keep people posting to it.
## How to run an effective daily standup
On your team, open the Standups tab, choose Create a standup series, pick a template and create the standup. Standups are included on every TeamRetro plan, including the free trial. If you are new to TeamRetro, [start a free trial](https://secure.teamretro.com/login/new?cc=www-blog) and run your first standup this week. For the facilitation side, from the three questions to the anti-patterns that make people dread the meeting, read the [complete guide to daily standups](/guides/daily-standup-guide/).
## Frequently asked questions
### Can we run the standup without a meeting?
Yes. Async is the default. Each person posts their update in the standup room whenever their day starts, and teammates reply with comments, reactions and mentions. A facilitator can still take it live when something needs a conversation.
### Does it work with Slack or Microsoft Teams?
Yes. Connect either one and TeamRetro posts the invites and reminders in your channel, with a button that opens the standup. Updates are written in TeamRetro, and when the standup closes the summary can be posted back to the channel.
### What happens to a blocker raised in a standup?
It comes back at the top of the owner's next update until it is cleared, with a count of the days it has been open. Give it an owner and a due date and it joins the same action list as your retrospective and health check actions.
### Which plans include standups?
Every TeamRetro plan, including the free trial.
### Where can I find more tips on running better daily standups?
Our [Daily Standup Guide](/guides/daily-standup-guide/) covers the questions to ask, how to keep the meeting short and the anti-patterns to avoid. If your team is distributed, read the section on [async and remote standups](/guides/daily-standup-guide/async-and-remote-standups/).
---
# End of year retrospective: an exercise in gratitude
URL: https://www.teamretro.com/blog/end-of-year-retrospective-an-exercise-in-gratitude/
There’s a lot to be said for [showing gratitude in the workplace](https://www.forbes.com/sites/forbescoachescouncil/2021/12/29/the-benefits-of-showing-gratitude-in-the-workplace/?sh=34031a3917dd); and with the end of 2025 in sight, it struck us as the perfect opportunity to reflect upon that for which we are grateful at TeamRetro.
Of course, as passionate advocates of agile and shameless fans of retrospectives, we couldn’t help ourselves – with a blank template and a few clicks of a mouse, we whipped up a gratitude template.
Here’s TeamRetro’s 2025 Retro, the people and things for which we are grateful, and what we’ll be taking with us into 2026.
## The people for whom we are grateful
We are grateful for our ‘curious’ and ‘creative’ **clients** who allow us to do what we do (and it’s what we love doing!).
It’s wonderful to see our clients quickly embrace and deliver value through TeamRetro and the new features we released throughout 2025.
Our clients inspire us to continue to improve, to remain curious and to embrace new knowledge and experiences.
We are grateful for our talented and supportive **colleagues** who create and curate TeamRetro.
They walk the agile manifesto talk, and in doing so they make TeamRetro a pretty special place to work.
We are grateful for the generosity of the **agile community** who are always open to share their knowledge and experiences with us.
## The experiences for which we are grateful
It’s no surprise that those wonderful people mentioned above paved the way for the experiences for which we are most grateful.
Connecting with our clients lets us hear first-hand, how we had helped them achieve their goals. It also informed our next steps and concepts for product improvement.
Connecting with our team delivered all manner of happiness.
Like teams across the globe, we made time to engage with each other, foster connections with each other, and strengthen our trust and respect for each other.
When times got tough, we knew we had each other’s back. We got through it, and we got better.
Improving, and improving and improving were awesome!!!
From bug fixing to feature releasing, knowing the value we were offering to our clients was a real buzz!
We were delighted to support the AgileAus conference and absolutely thrilled and honored to receive awards from SourceForce.
2025 gave us a lot to be grateful for.
## What we’ll be taking into 2026
Our team learned a lot in 2025.
We learned about ourselves, and we learned about each other.
2025 reinforced the importance of our health and our team’s health, and the positive momentum good health delivers.
2025 delivered to us all manner of kindness and offered us some wonderful examples of the strength of kindness in the face of adversity.
Finally, 2025 confirmed once and for all, it is possible to eat too much chocolate.
## Thank you!
Everyone at TeamRetro is looking forward to next year – what we will do, who we will meet and what we will learn.
Thank you to everyone for giving us so much for which we are grateful.
[Try a demo with our fun bots](https://secure.teamretro.com/demo/health-checks/0bd55a69-9990-46a9-ad28-15f012d5563a)
or
[Start Your 30-day Free Trial](https://secure.teamretro.com/login/new?cc=www-blog)
---
# Everything you need to know about futurespectives
URL: https://www.teamretro.com/blog/everything-you-need-to-know-about-futurespectives/
## What is a futurespective?
A futurespective is a process agile teams can undertake at the start of a project. They help teams to shape a high-level strategy that supports the smooth delivery of their goal.
During a futurespective a team will consider the project within the context of things such as –
- the skills, expertise and experience of the team members
- the resources they can access
- the risks and obstacles they may encounter, and
- the parameters within which they must work
in order to produce
- a shared understanding of the project trajectory, and
- confirm the first steps the team needs to take to get started.
While futurespectives and retrospectives follow pretty similar processes, they differ in a couple of important ways –
- a retrospective looks back over a short period of time to review what happened. This is done so as to inform the team’s next steps.
- a futurespective considers the whole project in order to anticipate what may happen. This is done to shape a project strategy and the first few steps needed to start the project.
## Why run a futurespective?
There are two key reasons a Scrum Master may run a futurespective. The first is to kick start a new project, and the second is to restart an existing one.
A futurespective gives a team a chance to create and grow the connections that are important for [team health](/blog/what-is-an-agile-team-health-check-and-why-are-they-important/). They are an opportunity to team build: the perfect time to explore your team’s motivations and fears, and share how members have worked well in the past. This presents a Scrum Master with –
- valuable insight into how they can best support their team, and
- the chance to start important conversations such as dealing with unpredictability.
Additionally, they help the team build a vision and purpose. It’s no surprise then that futurespectives are a wonderful way to align newly formed teams or check the calibration of established ones.
When it comes to the project, a futurespective is a brilliant planning mechanism. They can be used to identify things such as –
- areas of concern or perceived risks
- resources and tools needed
- gaps in the team.
This means shaping solutions to address such hurdles can start sooner than later.
A futurespective can also be used to set the tone for a project. This is why Scrum Masters can also use the futurespective to –
- include a warm up or [icebreaker game](https://games.teamretro.com/games/)
- draw upon Larson’s [Circles and Soup](https://www.lucidmeetings.com/glossary/circles-and-soup)
- set [SMART goals](https://www.groupmap.com/portfolio/elementor-20134), and
- add to [team agreements](/blog/create-social-contracts-with-team-agreements-that-improve-culture/)
Importantly, futurespectives ensure that at the start of the project, all team members are on the same page.
Futurespectives are also a great way to restart a stalled or stuck project. They can help reenergize an unmotivated team, shake up the repetition of retrospectives, and help a team revisit their goals.
## Futurespective Prime Directive
A prime directive is popularly understood to be a guiding principle. Although it’s possible to find a number of Futurespective Prime Directives, [Caroli and Caetano’s](https://www.thoughtworks.com/en-au/profiles/p/paulo-caroli-and-taina-caetano) version is the one most widely cited.
Underpinned by the [Agile Manifesto](/health-check-templates/agile-manifesto-values/), and like the [Retrospective Prime Directive](/guides/scrum-masters-retrospective-guide/what-is-the-retrospective-prime-directive/) it complements, Caroli and Caetano’s Futurespective Prime Directive is a mindset. It aims to foster a positive, collaborative context within which a team can deliver the best possible outcomes.
The Directive sets an optimistic tone. It reinforces the importance of the involvement of the whole team and the shared ownership of the team’s vision of the future. For it to be most effective, the team must feel [psychologically safe](/health-check-templates/psychological-safety-check/). After all, trying to predict the future is a big ask! The safer the team feels, the more ideas they will be comfortable to offer.
## How to run a futurespective?
There are currently two main approaches as to how to run a futurespective.
1. Consider the project as if it has been delivered
2. View the project as if it is to be delivered
The first approach has participants imagining they are their future selves looking back at the project that has been successfully finished. This approach has participants imagining they are thinking back on all of the goals they have delivered and how they did so. They (creatively) reminisce about the things that went well, the hurdles they encountered, and how they overcame them. They are effectively doing a retrospective in the future (so, a futurespective).
It’s possible for the team to have a great deal of fun with this approach. An end of project lunch could be held during the futurespective. A warm up can include reference to what their future selves did in the past year of which they are most proud, or the latest (future) trend or (future) film can be discussed.
The second approach is a little more straightforward. Participants are invited to look ahead and offer their perspective of what the future has in store (so again, a futurespective). This approach is possibly better suited to a team who are new to agile, or simply less comfortable with the other.
Regardless of which vantage point your team prefers to adopt for their futurespective, the purpose and the process remain the same.
The five steps of a retrospective can be applied to a futurespective. The important thing to keep in view is the different mindset that is to be adopted.
#### Step 1 - Set the futurespective stage
Once you’ve embraced the Futurespective Prime Directive mindset and picked a point of view from which to examine the project, it’s time to choose a template.
Online futurespective templates offer all sorts of benefits. They are an ideal tool when it comes to remote team engagement. They can also support the delivery of asynchronous futurespectives. An online template captures all input as you go so there’s no time wasted at the end of your futurespective rewriting ideas, input and action items. Best of all, they can [integrate](/integrations/) with your existing workflow to save you even more time.
The best template to choose is one that will help your team produce their high-level project strategy, the way they want. With so many amazing templates available, we’ve built an [online futurespective template selector](/retrospective-templates/) to help you choose the right one for your team. As far as our team goes, we share our favorite futurespectives below.
#### Step 2 - Gather futurespective data
Using the template as a guide, participants are invited to offer their input. Allowing time for quiet, individual brainstorming where team members can contribute their ideas anonymously will help overcome such barriers as groupthink.
The Scrum Master should encourage participants to draw on their past experience and knowledge to populate the template. Everyone is to be reminded to offer their best (informed) guess. It’s important to acknowledge that any predictions they make that don’t come true, won’t be held against them.
#### Step 3 - Generate insights
It’s at this stage of the futurespective that the team’s shared understanding of their project strategy will start to germinate. So it’s vital to make sure all ideas are understood and if not, clarity is sought.
Again, reference to previous projects plays an important role here. It’s an opportunity for the team to learn about what they each bring to the table and how it can be used to support the project and team.
#### Step 4 - Decide what to do to start the project
It’s very easy to get swept up with team building and delivering high-level vision, but it’s important to make sure your futurespective produces what’s needed to get the project started. Shaping action items is the way to do this. Make sure you limit the number of actions to the number you need to get things started, and keep them SMART.
Some actions may apply to the team more so than the project. Actions that support the team’s ability to work together can be included as a [team agreement](/blog/create-social-contracts-with-team-agreements-that-improve-culture/).
#### Step 5 - Summarize and end the futurespective
The last step is to summarize the futurespective. This ensures that all team members understand the action items before the meeting is closed.
Ending the meeting with a [Return on Time Invested (ROTI)](/blog/return-on-time-invested/) is informative and a healthy habit to support. It helps the Scrum Master gauge the effectiveness of meetings and make adjustments if needed.
Finally, the Scrum Master will share the outcomes of the futurespective and follow up on the actions.
## Examples of futurespectives
Here are our top three futurespectives to help get you started.
### State of Nirvana futurespective
The State of Nirvana futurespective sees team members define their version of nirvana. They step out what they expect to have achieved by the first, third, sixth and tenth month, with the ideas they share building an outline of their way forward. [Learn more about State of Nirvana futurespective.](/retrospective-templates/state-of-nirvana-futurespective/)
### Plus, Minus, Interesting (PMI)
The PMI Futurespective helps a team view a topic from multiple perspectives. It ensures a broad view of the project is considered as team members cannot dismiss the variety of inputs that they themselves have put together. [Learn more about Plus, Minus, Interesting (PMI)](/retrospective-templates/plus-minus-interesting-pmi/).
### SCOR futurespective
The SCOR Futurespective is a reimagining of the [SWOT analysis template](/retrospective-templates/swot-analysis-for-teams/) to include team empowerment. Weaknesses are reframed as challenges and participants identify risks rather than threats. This way, participants view them as less ominous and therefore more manageable. [Learn more about SCOR futurespective](/retrospective-templates/scor/).
If these aren’t quite what you’re looking for, don’t forget, TeamRetro lets you customize your futurespective or create your own.
We hope this run through of what a futurespective is has given you another tool in your kit and you have what you need to help your team experience success.
Here’s to you and your team’s future!
---
# Free agile tools for better retros and sprints in 2026
URL: https://www.teamretro.com/blog/free-agile-tools-for-better-retros-and-sprints/
Running agile ceremonies effectively is key to team performance. Whether you’re planning a sprint, kicking off a retro, or looking to energize a meeting, the right tools make it easier. That’s why TeamRetro offers a set of free agile tools: RetroIdeas, the Icebreaker Generator, and Planning Poker. These browser-based, AI-enhanced tools are designed to help teams improve collaboration, estimation, and engagement – all at no cost.
## TeamRetro’s free agile tools
### RetroIdeas: AI-generated retrospective templates
Looking to keep retrospectives fresh and relevant? RetroIdeas offers an ever-growing library of retrospective templates, generated by AI and categorized by theme and goal. Whether you’re focused on team morale, sprint delivery, or continuous improvement, there’s a template to match.
Key ways to get the most from RetroIdeas:
- Rotate templates each sprint to maintain engagement.
- Choose based on your team’s vibe: serious, celebratory, or constructive.
- Bookmark your favorites for easy reuse.
If you’re looking for more guidance on facilitating great retrospectives, check out our practical guide on [how to run a sprint retrospective](https://help.teamretro.com/article/261-starting-a-retrospective). You can also explore our collection of [fun retrospective templates](/retrospective-templates/) to keep things creative and engaging.
✅ Explore it here: [ideas.teamretro.com](https://ideas.teamretro.com/)
### Icebreakers: kick off agile meetings with a turn-based icebreaker question
Set a positive tone for your retros, standups, or team check-ins with TeamRetro’s Icebreaker Tool. It delivers thoughtful, AI-generated icebreaker questions designed to spark connection and ease into the conversation.
Cool features that make this tool stand out:
- Categories like fun, personal growth, and work-related questions.
- Built-in timer to keep the meeting on track.
- [Name spinner](https://games.teamretro.com/games/random-name-picker/) to randomize who answers next.
- Ability to edit or add your own custom questions.
Use it to:
- Build rapport among team members.
- Break the ice in hybrid or remote settings.
- Encourage more open and engaging meetings.
For teams also looking to measure engagement and team dynamics over time, our [Agile Health Check tools](/health-check-templates/) offer a structured way to assess and improve team culture and performance.
✅ Try it here: [free online icebreaker games](https://games.teamretro.com/games/)
### Agile planning poker: estimate story points with confidence
TeamRetro’s free Planning Poker tool helps Agile teams estimate user stories collaboratively and accurately. With this online version, each participant picks an estimate independently, and all cards are revealed at once.
Top features include:
- Multiple estimation scales (Fibonacci, T-shirt sizing, custom).
- Supports hybrid and remote teams.
- Instant visibility of results with quick rounds of discussion.
- No sign-up or setup required.
Here’s how it helps:
- Avoids bias from early estimates.
- Drives better consensus through discussion.
- Simplifies sprint planning for any team setup.
✅ Use it here: [planning-poker.teamretro.com](https://planning-poker.teamretro.com/), or get up to speed first with [how to run a planning poker session](/guides/agile-estimation-guide/how-to-run-planning-poker/) and [how story points work](/guides/agile-estimation-guide/what-are-story-points/).
If you’re new to estimation or want a refresher, our [beginner’s guide to Planning Poker](/blog/how-to-use-planning-poker-in-agile-estimation/) walks you through the process step by step.
## Why use these free agile tools?
### Accessible, intuitive, and AI-powered
These tools are:
- Free to use
- Web-based and accessible from any device
- No account creation required
- Built for remote and face-to-face collaboration.
You can go from idea to action in minutes, without sign-ups or learning curves.
## Make every agile ceremony count
Here’s how to use these tools across your agile cycle:
- **Before a retro**: Use RetroIdeas to find a fun, engaging template tailored to your team
- **At the start of your meeting**: Use the Icebreaker Tool to set the tone and build engagement
- **During sprint planning**: Use Planning Poker to estimate actions together and align as a team
## Small tools, big impact
TeamRetro’s free agile tools were designed with one goal: to make your retrospectives, meetings, and sprint planning more engaging, inclusive, and effective. They’re intuitive, fast to use, and built for real-world team needs.
Try them today, for free. No payment or sign-up required, no strings attached.
👉 [**RetroIdeas (Free AI-generated retrospective template)**](https://ideas.teamretro.com/)
👉 **[Free meeting icebreaker tool](https://games.teamretro.com/)**
👉 **[Free planning poker for agile teams](/free-planning-poker-for-agile-teams/)**
---
# Fun retrospective ideas and games to keep retros fresh
URL: https://www.teamretro.com/blog/fun-and-easy-retrospective-ideas/
Retros go stale quietly. The format stops surprising anyone, the same three people talk, and the session survives as a calendar entry nobody defends. This post is a set of ideas for keeping them worth attending: lighter formats, icebreakers that are not corny, and games that work over video. If you are still working out how to run one in the first place, start with the guide to [running effective retrospectives](/guides/running-effective-retrospectives/) or the chapter-by-chapter [Scrum Master’s guide to retrospectives](/guides/scrum-masters-retrospective-guide/), then come back here for the ideas.
Here we share simple and effective ways to keep your retrospectives fun and easy. From choosing the right [retrospective template](/retrospective-templates/) and setting the stage to non-cheesy ice breakers and handy tips for remote or in-person meetings. It’s all about running a retro your team will love.
## What is a fun retrospective anyway?
Running a fun retrospective doesn’t mean you have to hold it on a rollercoaster. They don’t need the Scrum Master to be a stand up comedian, nor do they need to trigger howls of laughter from the team. A fun retrospective is simply one that the team enjoys and finds rewarding.
Importantly, fun retrospectives are **[safe and inclusive](/guides/scrum-masters-retrospective-guide/how-to-build-a-psychologically-safe-space/)**. This is simply because it is a lot easier to enjoy an experience when fear is absent and everyone can join in.
Here’s how you can run a fun retrospective and avoid those boring, repetitive meetings.
## Sprint retrospective ideas
### 1. Reset and reframe your retros
When you step into the room, switch on a smile along with the lights. The mindset you pick for the retrospective will set the mood for the meeting.
If you’ve chosen a particular theme for the retro, dress the room, your background, or yourself to make a statement. If you’re using an online tool that includes a welcome message, sneak in a reference to fun. Turn up your own energy and model your sense of fun which will pave the way for others.
### 2. Vary your retrospective formats
There are all sorts of themes and templates to choose from. From movies, food, hobbies and interests; if you can think of it, there’s probably a theme and template to match. If you’re more DC than Marvel, you can always change the template to what you want. Here are some of the fun retro templates our teams have used –
#### Superhero retrospective
Discover your team’s super powers and weaknesses, along with evil nemeses and sidekicks. It’s all in the name of working together to overcome the villainous challenges that may attempt to undermine your next sprint goal!
#### Goldilocks retrospective
Finally we have a reason we were told so many strange stories as a kid. It was so, when we grew up, we could use them to run retros!
The Goldilocks retrospective is a fun way to help a team find how the team feels about the current state of play. By picking a topic, e.g. Deployment, you can then gauge which parts of the process are too hot (firefighting, running too fast, causing burn out), too cold (laggy, slow and lacking energy) or just right.
#### Oscar academy
Celebrating wins is fun, so is this retrospective. It focuses on the positives and celebrates those that helped make them happen.
Use this at the end of an epic or major release to acknowledge your best actors, key moments and celebrate as a team.
**Keen to try a different retrospective template?**
Check out this nifty site that helps you **[choose the best template for your next retrospective](/retrospective-templates/)** or explore **[more retro formats](/guides/scrum-masters-retrospective-guide/retrospective-templates/)**.
### 3. Run a ‘non-corny’ icebreaker for team building
An [**icebreaker**](/blog/best-icebreakers-for-starting-conversations-with-online-teams-2021/) is a great way to start a retrospective. Starting with a fun icebreaker is a great way to have fun. Don’t worry, even if the laughter gets loud, it will still count as work.
Some of our favorite fun icebreakers include –
- What piece of office equipment would you grab during a zombie apocalypse?
- What is the most unusual kitchen utensil you have?
- What would you do if you won the lottery?
- Which supervillain do you most respect and why?
- If you could go to a mythical place for your next holiday, where would it be?
For more fun icebreakers, check out our **[funny icebreaker questions](/icebreakers/funny-icebreaker-questions/)**, or let our [free icebreaker questions game](https://games.teamretro.com/games/icebreaker-questions/) pick one for the team.
### 4. Get feedback from the team
At the end of the meeting, ask the team for feedback and if they enjoyed the retro. Ask a quick check out question, “like what did you think about today’s retro?”.
A simple survey like a Return on Time Invested lets the team score the retro out of 5 and will also let you know if they found the meeting fun and productive.
Adding a **[ROTI (Return on Time Invested)](/blog/return-on-time-invested/)** at the end of the retrospective is a handy way to get quick feedback.
### 5. Switch Scrum Master roles
If your team has always had a dedicated Scrum Master, taking turns as to who runs the retrospective next is a great way of keeping things fresh. A [random name picker](https://games.teamretro.com/games/random-name-picker/) takes the guesswork out of deciding who goes next. It’s also an easy way of increasing the team’s understanding of the role of the Scrum Master and seeing different styles of facilitation in action.
### 6. Introduce fun retrospective games
An agile game is a fun, interactive activity that dives into an aspect of agile. The whole team works toward a common goal with their agile understandings helping to achieve it. They are a safe way of exploring agile that can be both fun and informative.
For formats grouped by the problem they fix, rather than by how novel they are, see our guide to [retrospective games](/guides/retrospective-games/).
Check out our list of **[agile games](/guides/scrum-masters-retrospective-guide/agile-games-facilitate-team-building/)** you could try at the start of your next retro.
### 7. Turn up the fun in your remote retros
There are lots of ways to connect teams, even if they are miles apart. You can
- Turn on the camera, and turn up the smiles. Smiles have a way of spreading when seen.
- Use filters and backgrounds that match your meeting theme.
- Get someone to be the DJ to play music during the meeting.
- Run a funny **[virtual icebreaker](/blog/virtual-icebreakers-for-remote-teams/)** to get things started.
### 8. Get creative with in-person retrospectives
Injecting fun into an in-person retrospective can start with the location. After all, meeting rooms tend not to be the most inspiring of places. Move to a different room, hold the retrospective outside or even head to a cafe. If moving to another location is off the table, pop some food on the table!
Being in the same place means physical icebreakers can be used. Try kicking off with musical chairs, a knock out tournament of ‘rock, paper, scissors’, or a human knot.
Park the post-its and use a digital tool instead. Your team will be able to use all the features they include that help build psychological safety as well as emojis and GIFs.
## Should I make my retrospectives fun?
If you’re still not sure if you should add a little fun to your team’s retrospective, here are some final points (along with the research) to consider.
- As well as increasing creativity, fun is an important factor in engagement.
- Fun can help to increase [**productivity**](https://www.emerald.com/mrr/article-abstract/37/8/682/310239/Play-hard-work-hardFun-at-work-and-job-performance) in an agile team.
- Fun also builds resilience in the workplace and supports **[employee retention](https://www.greatplacetowork.com/resources/blog/purpose-at-work-predicts-if-employees-will-stay-or-quit-their-jobs)**.
- It can help team cohesion and foster [**workplace happiness**.](/health-check-templates/work-happiness-radar/)
Fun and safety work hand in hand. Fun gently nurtures psychological safety by supporting team connectedness. Together they are able to help smooth over ripples of change such as transitioning from remote to hybrid or even in person models.
For other fun formats, check out these suggestions from the [Agile Scrum Group](http://agilescrumgroup.nl/) – **[Retrospective ideas pdf.](https://agilescrumgroup.nl/wp-content/uploads/Retrospective-Ideas-ENG-1.pdf)**
## Ready to make your retro fun?
[Run a fun retro now!](https://secure.teamretro.com/login/new?cc=www-blog)
Head over to our blog and check out **[3 Nifty Ways to Keep Your Retros Fun and Exciting!](/blog/3-nifty-ways-to-keep-your-retros-fun-and-exciting/)**
---
# How to gather feedback from your AI agents
URL: https://www.teamretro.com/blog/gather-feedback-from-ai-agents/
An AI agent shipped code for you this week. It read your brief, dug through the codebase, hit a wall where the documentation was wrong, guessed its way past it, and moved on. Then the session ended, and everything it learned about where your project fights back went with it. Nobody asked the one participant who just spent an hour inside your repo what slowed it down.
Retrospectives exist to close exactly that gap for people: the team meets, names what helped and what got in the way, and turns it into change. AI agents are now doing real work on your team, and they hit the same friction your people do, sometimes more of it. So the question is simple. If an agent does the team's work, why isn't it in the retro?
This guide is about adding that voice. Not a new retrospective format, not automating your people's input: a new participant. The AI contributes feedback; your team still decides what it means. Here's how to gather it, and how to bring it into the retrospective you already run.
This post is the quick start. The practice now has a complete guide, [AI agent retrospectives](/guides/ai-agent-retrospectives/), covering the full loop from capture to the team ceremony; start here, go there for the full picture.
## Why your AI agent's experience is worth capturing
The case for a human retro is that memory fades and lessons go unshared. With an AI agent the problem is sharper: its working memory doesn't fade, it evaporates. The moment a session closes, the context is gone. None of it carries to the next session unless something writes it down: the missing README it wished existed, the environment variable that wasn't documented, the brief that could have been read three ways.
And agents accumulate a specific, useful kind of signal. Over an hour of work an agent notices things a person skims past because a person already carries the context in their head:
- The onboarding doc that describes a build step that no longer exists.
- The function that three call sites use differently, so "follow the pattern" points at three patterns.
- The brief that said "clean up the config" without saying which config, or how clean.
- The test suite that needs a service running that nothing tells you to start.
A human developer hits these too, shrugs, works around them, and rarely files anything, because the friction is beneath the threshold of "worth raising in the meeting". An agent, asked the right way, will report every one, with the evidence attached. That is the value: not that the AI is smarter about your process, but that it is a fresh pair of eyes with no ego and no accumulated tolerance for the papercuts. Human-AI collaboration works best when both sides can say what slowed them down.
One guardrail before we go further, because it shapes everything below. **The AI is a participant, never a facilitator or a judge.** It contributes items to the retrospective the way any participant does. It does not run the meeting, score your team, or decide what to fix. Humans read its feedback, sanity-check it, and choose what matters. Keep that line and the practice stays healthy; blur it and you've handed your improvement process to a tool that can't be accountable for the outcome.
## The practice: an end-of-session retro
The mechanism is small on purpose. At the end of a working session (a coding task, a research job, a refactor) the agent writes one honest retro entry to a file in the repo it was working in. It takes the agent under a minute. A human spends about the same again sanity-checking it. That's the whole loop.
A good entry has four parts:
1. **What went well**: the moments worth keeping, cited to something concrete that happened in the session. Not praise, not filler. If it can't point to a specific moment, it doesn't go in.
2. **Friction**: where the work got harder than it needed to. Each friction item is tagged with one of ten fixed root-cause labels (below) and **ends with a ticket-sized "→ Fix:"**, the rule that makes it useful. No finding without a fix.
3. **A "Do this first" top fix**: the single change that would have helped most. One item, surfaced to the top, so a busy reader who reads nothing else reads the thing that matters.
4. **Guesses made**: every point where the agent filled a gap with an assumption. These are gold. A guess is a place your context was ambiguous or missing; the agent is showing you exactly where it had to invent an answer.
Two principles keep the entries trustworthy. **Evidence-cited moments only**: every point references something that actually happened, so nobody's reading generic advice. And **the honesty runs both ways**: the agent critiques the material it was handed *and* its own mistakes. An entry that only blames the codebase and never says "I misread this and wasted twenty minutes" isn't being honest; the practice asks for both.
## The ten root-cause labels
Every friction item gets exactly one label. A fixed, small vocabulary is what turns a pile of individual gripes into a pattern you can act on: when the same label shows up across ten sessions, you know where to spend your next hour. The ten cover the ways real work gets blocked.
| Label | What it means | Where the fix usually lands |
| --- | --- | --- |
| `ambiguous-instruction` | The brief could be read more than one way. | The person writing the task |
| `missing-context` | Information the agent needed wasn't provided. | The brief, or the shared context |
| `incorrect-context` | Information it was given was wrong or stale. | The brief, or the shared context |
| `missing-documentation` | The repo doesn't document something it should. | The docs / CLAUDE.md / AGENTS.md |
| `incorrect-documentation` | The docs exist but are wrong or out of date. | The docs / CLAUDE.md / AGENTS.md |
| `work-material-friction` | The material being worked on made the change hard (tangled code, account, or template). | The work material / tech debt backlog |
| `missing-access-or-tool` | A credential, permission, or tool wasn't available. | Ops / platform / access control |
| `agent-error` | The agent got it wrong: misread, wrong turn, wasted effort. | The agent's own account, honestly |
| `changed-requirements` | The goal moved partway through the session. | Planning / scope management |
| `environment-friction` | The dev environment fought back: flaky build, slow setup, broken tooling. | Developer experience |
*(v2 of the skills renamed `codebase-friction` to `work-material-friction`; older entries carrying the old label still count as the same cause.)*
Notice how the labels split responsibility cleanly. Some point back at *you*: `ambiguous-instruction`, `missing-context`. Some point at the *project*: `missing-documentation`, `work-material-friction`, `environment-friction`. And `agent-error` points at the agent. That spread is the point: it stops the log becoming a list of complaints and makes it a map of where improvement is owed, on every side.
## The log: plain markdown, in your repo
There is no product to install for the capture step. The agent writes to `docs/ai-retros/entries/` as plain markdown, committed alongside the code. That's a deliberate choice:
- **It lives where the work happened.** The friction was in this repo; so is the record of it. Anyone reading the git history sees the feedback next to the change that prompted it.
- **It's diffable and greppable.** Want every `missing-documentation` item from the last month? That's a `grep`. Want to see friction trend down after you fix the build? It's in version control.
- **It's tool-agnostic.** Markdown in a folder works with any agent, any editor, any process. Nothing proprietary, nothing to migrate later.
Here's an illustrative example entry. This is a made-up session to show the shape, not real pilot data:
```markdown
# Session retro — add rate limiting to the public API
Agent: Claude Code · 2026-07-13 · ~50 min
## Do this first
→ Fix: Document the Redis connection setup in CLAUDE.md — three of us
will hit this same wall. (missing-documentation)
## What went well
- The `middleware/` folder has a clear pattern; the existing auth
middleware was a clean model to copy for the rate limiter.
- Tests ran fast once the service was up.
## Friction
- Nothing documented that the test suite needs Redis running locally.
Spent ~15 min chasing a connection error before finding it by reading
docker-compose.yml. (missing-documentation)
→ Fix: Add a "Running tests locally" section to CLAUDE.md naming the
Redis dependency and the `docker compose up redis` command.
- The brief said "add sensible rate limits" without numbers. I chose
100 req/min per key. (ambiguous-instruction)
→ Fix: Decide the real limits with the team and put them in the ticket.
- `config/limits.ts` and `config/throttle.ts` both looked like the right
home for the setting; I couldn't tell which was canonical. (work-material-friction)
→ Fix: Merge or clearly comment which config owns rate limiting.
## Guesses I made
- Assumed 100 req/min because the payment endpoints use that. May be
wrong for read-heavy public endpoints — please check.
- Assumed rate-limit responses should be 429 with a Retry-After header.
```
Read that as a participant's note, because that's what it is. It's specific, it owns its own guesses, and every problem comes with a next step.
## Bringing it into your team retrospective
Individual entries are the raw material. Before your retro, a companion synthesis step reads the entries since last time and produces a one-page brief for the meeting: the friction that repeated, the top fixes clustered by label, the guesses that keep recurring in the same place. It's held to the same standard as the entries (**no praise or filler, no finding without a fix**), and its honesty runs both ways too: it critiques the entries it was given (thin evidence, a fix that's too vague to action) as readily as it summarizes them.
Then the human part, which doesn't change:
1. **Read the brief before the retro**: treat it as one more participant's pre-read, not the agenda.
2. **Put the top one or two items on the board**, next to what your people brought. Now the AI's `missing-documentation` note sits alongside a teammate's "onboarding took me a week", and you can see they're the same problem.
3. **Discuss and decide as a team.** The agent surfaced the item; the humans in the room own what happens next. Some items you'll action, some you'll park, some you'll disagree with. All fine: that's a participant contributing, not a system dictating.
There are two ways to close this last step, and the first one costs nothing:
- **With any retro tool.** The brief is just a document. Read it before the meeting, add the top item or two to whatever board you run, sticky notes included. The whole practice works this way, end to end, without TeamRetro or any other specific product.
- **With TeamRetro, the agent posts for itself.** If your team runs its retros in [TeamRetro](/retrospectives/), the agent can prepare its recommendations from the log and, with your confirmation on each item, post them through the [TeamRetro MCP server](/mcp/): parked items queued for your next retro, actions when a fix already has an owner, or ideas contributed straight onto a running board. Every posted item is prefixed `[AI retro]`, so the room can see which participant raised it. That's the difference in one line: instead of you carrying the AI's feedback to the meeting, the participant hands it in itself.
## Getting started in about 10 minutes
The whole thing is open source under an MIT license. The [teamretro-skills repo](https://github.com/TeamRetroHQ/teamretro-skills) covers both paths: `ai-session-retro` (writes the end-of-session entry) and `ai-retro-brief` (synthesizes entries into the pre-retro brief) need no product at all, and `teamretro-post-recommendations` adds the posting path for TeamRetro teams. A tool-agnostic prompt pack rounds it out.
To start:
1. **Clone the repo** and drop the skills into your Claude Code setup, or lift the prompt pack if you work in something else.
2. **Not on Claude Code?** The prompt pack is written to work with Cursor, GitHub Copilot, or any agent you can hand a system prompt: same four-part entry, same ten labels, same "no finding without a fix".
3. **Run one session with it on.** At the end, read the entry it wrote. That first read is usually the moment it clicks: the agent will have named something about your project you half-knew and never wrote down.
Point the entries at a `docs/ai-retros/entries/` folder in whatever repo your agents work in, commit them, and you've started.
## Honest limitations
This is a young practice and it earns trust by being straight about what it can't do.
- **An AI can't see all of its own mistakes.** Some `agent-error` friction is invisible to the agent that made it. It doesn't know what it doesn't know. Human review isn't optional garnish; it's how the blind spots get caught. This is why the AI stays a participant and never the judge.
- **One entry is an anecdote.** You need roughly five entries before the patterns mean anything. A single session's friction might be that session's bad luck; the same label five times is a signal. Give it a couple of weeks before you conclude much.
- **The agent reports its experience, not the ground truth.** When it says the docs are wrong, check: sometimes the docs are right and the agent misread them. That's still useful (it means the docs are easy to misread), but it's a different fix.
- **Garbage briefs make garbage entries.** The practice surfaces friction; it doesn't invent insight where there was none. A session with a clear brief and a clean repo produces a short, boring entry, which is exactly right.
None of that undercuts the case. Your AI agents are already doing the work and already hitting the walls. The only question is whether you find out. Give them a minute at the end of the session to tell you, read what comes back with a human's judgment, and bring the honest parts into the retro you already run. That is where a participant's feedback belongs: right beside your people.
We ran the whole loop on our own team, agents included. See what happened when [our AI teammates joined our retro](/blog/our-ai-teammates-joined-our-retro/).
---
*Building context files for your agents? See why [context engineering needs a feedback loop](/blog/context-engineering-needs-a-feedback-loop/). And if you're new to running retros at all, start with [how to run an agile retrospective](/retrospectives/).*
---
# How to get estimation consensus faster in agile teams
URL: https://www.teamretro.com/blog/get-estimation-consensus-in-agile-teams/
Agile estimation meetings are meant to create clarity, not confusion. Yet many teams still struggle to reach estimation consensus efficiently.
If you have ever watched a team debate a single story for 20 minutes, bounce between opinions, and still end with **“Let’s just go with 5”**, you are not alone.
The good news is that you can get estimation consensus faster without rushing, forcing agreement, or turning estimation into a battle of confidence.
In this guide, we will walk through practical ways to improve alignment, reduce friction, and run a smoother [**agile estimation meeting**](/estimations/) that actually helps your team plan with confidence.
## Why estimation consensus takes time and why it matters
Consensus is not slow because your team is doing it wrong. It is slow because estimation involves different assumptions, different levels of context, different experiences, and different interpretations of risk. When teams do not surface those differences early, they get stuck in long, unproductive discussions.
What a designer can validate quickly in a prototype may require significant engineering effort to build and maintain, which is why teams often estimate the same story differently. Alternatively, a user experience issue that requires workflow changes can be mitigated through improved user interfaces.
Consensus matters because it is not just about choosing a number. It is about building a shared understanding of what the work involves and what it will take to deliver the outcome.
## Tips for reaching estimation consensus faster
### 1. Start with the goal: shared understanding, not perfect accuracy
A fast meeting is not always a good meeting, and a slow meeting is not always bad. But if your team’s goal is **“pick the right number”**, you will end up arguing endlessly. Instead, guide the team toward this shared goal: **“We want enough alignment to move forward with confidence.”**
Make this explicit at the start of the meeting through [**team agreements**](/blog/create-social-contracts-with-team-agreements-that-improve-culture/) or a visible reminder so everyone is aligned before estimating.
### 2. Agree on what “done” means before estimating
A major reason teams cannot align is that they are estimating different outcomes. Before estimating, confirm:
- What is included
- What is explicitly excluded
- What **“done”** means for this story
- Whether there are dependencies or testing requirements
This step improves estimation speed because it removes ambiguity early, and ambiguity is what slows everything down. Spelling out the [acceptance criteria](/guides/agile-estimation-guide/acceptance-criteria/) and a shared [definition of done](/guides/agile-estimation-guide/definition-of-done/) before anyone votes is the fastest way to be sure the team is estimating the same thing.
### 3. Use story points the way they are meant to be used
Many estimation meetings drag because teams treat points like time. But **[story points](https://agilealliance.org/resources/experience-reports/estimates-terrible/)** are not hours. They are a relative way to compare work based on complexity, effort, and uncertainty.
If your team keeps converting everything into **“how many days”,** consensus becomes harder because time estimates feel personal and risky. To speed things up, remind the team:
- Points are comparative, not exact
- You are estimating as a team, not defending a personal opinion
- Uncertainty is part of the estimate, and that is okay
When teams treat story points as shared signals rather than personal commitments, consensus forms faster. Strong estimation consensus is a foundation of effective agile estimating and planning, not a separate activity. For a deeper breakdown of why points measure relative effort instead of time, see [how story points actually work](/guides/agile-estimation-guide/what-are-story-points/).
### 4. Use reference stories to speed up decisions
If every story feels like a fresh debate, your team will keep starting from zero. Reference stories from past sprints can establish a baseline. For example:
- **“This is similar to the login validation story we estimated as a 3”**
- **“This feels like the reporting feature we rated as an 8”**
- **“This is smaller than the dashboard redesign, which was a 13”**
[Reference stories](https://www.agile-academy.com/en/agile-dictionary/reference-story-scrum/#:~:text=Jan%20Neudecker,support%20agile%20transformation%20in%20organizations.) build context and speed up agreement by anchoring estimates to shared past experiences.
### 5. Keep user stories small enough to estimate quickly
If the story is too big, you will never get a consensus quickly. A good rule of thumb is this: If you cannot estimate it in under 5 minutes, it is probably too large or unclear. During your agile estimation meeting, look out for warning signs like:
- **“We will figure that out later”**
- **“It depends”**
- **“There are a lot of unknowns”**
- **“This touches everything”**
These are signals that the story needs to be broken down, clarified, or scoped before you estimate it. Smaller stories lead to faster discussions and more reliable user story points.
### 6. Timebox the discussion without shutting people down
Consensus takes time, but it should not take forever. Try this structure:
1. Read the story (30 seconds)
2. Clarify requirements and discuss (1–2 minutes)
3. Estimate silently (15 seconds)
4. Reveal estimates (10 seconds)
5. Discuss only the outliers (2 to 4 minutes max)
6. Re-estimate if needed (30 seconds)
Timeboxing works because it forces focus. Instead of letting every opinion turn into a debate, it keeps the team centered on the differences that matter.
### 7. Focus on the assumptions behind the estimates
When people disagree, the goal is not to make everyone agree on a number. Here are some prompt questions that can help:
**“What assumptions are creating this gap?”**
**“What are you including in your estimate that others might not be?”**
**“What might be something you see that the others don’t see?”**
For example, one person might include edge cases while another assumes a basic workflow. Exploring those assumptions quickly aligns the team and helps achieve estimation consensus faster. It is also a great way for people to learn and understand what others might need to do in terms of their part of the job. (Remember: The estimate should be for the whole team, not just their own section.)
### 8. Make uncertainty visible instead of arguing about it
Sometimes, the story is genuinely unclear. Instead of forcing agreement, consider:
- Estimating with a **[confidence check](https://www.scrum.org/resources/blog/winning-estimation-tactics-agile-teams-calibration-confidence)**
- Adding a **[spike to research unknowns](https://agileseekers.com/blog/managing-technical-spikes-and-discovery-work-in-agile-sprints)**
- Splitting work into “known” and “unknown” tasks
This supports better effort estimation techniques for software development by separating uncertainty from effort instead of mixing the two. When the team can name where a story sits on the [cone of uncertainty](/guides/agile-estimation-guide/cone-of-uncertainty/), consensus becomes easier.
## A simple structure to get estimation consensus faster
If you want a lightweight way to apply the tips above consistently, this flow brings them together into a repeatable agile estimation meeting structure. It mirrors a live [planning poker session](/guides/agile-estimation-guide/how-to-run-planning-poker/) — estimate silently, reveal together, then discuss only the outliers.
### Step 1: clarify (2 minutes)
This is where we align on what estimation means for the team, shared understanding over perfection and confirm the Definition of Done. It’s also where assumptions, constraints, and unknowns are surfaced so everyone is estimating the same thing.
### Step 2: estimate silently (30 seconds)
This is where we use story points properly, estimating relatively rather than translating to time. Reference stories help anchor thinking, while silent estimation avoids bias and premature influence.
### Step 3: reveal together (10 seconds)
This is where differences become visible without pressure. Revealing at the same time gives everyone an equal voice and turns variation into useful data rather than debate.
### Step 4: discuss outliers only (3 minutes)
This is where estimation earns its keep. The highest and lowest estimates explain what they are factoring in unknowns, edge cases, dependencies, technical risk, or prior experience with similar work. This conversation exposes assumptions the rest of the team may not have considered, so everyone leaves with the same understanding of scope and risk.
### Step 5: re-estimate (30 seconds)
This is where we test whether that shared understanding actually exists. If estimates move closer together, the work is likely clear and ready to plan. If they don’t, it’s a signal the story needs to be split, clarified, or de-risked before moving forward.
## Final thoughts
If your estimation meetings feel slow, the solution is not to talk less. It is to talk about the right things: assumptions, scope, uncertainty, and shared understanding.
When your team gets better at surfacing those details early, estimation becomes faster and more useful. You spend less time debating numbers and more time aligning on what it will take to deliver.
That is what leads to stronger estimation consensus and better sprint planning.
If you want to make estimation a structured, repeatable part of how your team plans and not just a quick voting exercise, TeamRetro’s estimation meetings guide teams through story-by-story estimation with anonymous voting, simultaneous reveals, and focused outlier discussions. It keeps conversations centered on assumptions and risk, helps teams reach genuine consensus, and connects estimates directly back to the tools your team already uses.
Teams that improve estimation consensus spend less time debating numbers and more time making confident planning decisions. Try estimation meetings in the TeamRetro app and see how clearer conversations lead to faster, more confident sprint planning.
[Learn more about agile meetings](/estimations/)
---
# Giving kudos with Kudo Cards in retrospectives
URL: https://www.teamretro.com/blog/giving-kudos-with-kudo-cards-in-retrospectives/
In an Agile world driven by metrics, velocity, and constant delivery, it’s easy to forget the simple power of saying “thank you.” Enter Kudo Cards: a small yet mighty tool from [Management 3.0](https://management30.com/practice/kudo-cards/) practices designed to nurture appreciation, amplify psychological safety, and reinforce Agile values within your team.
If you are someone committed to team culture, it’s time to add this humble practice to your toolkit.
## Kudo Cards in Management 3.0
Kudo Cards, also known as appreciation or motivation cards, originated in the [Management 3.0 framework](https://management30.com/practice/kudo-cards/). They provide a structured yet lightweight way for team members to acknowledge each other’s contributions. The word ‘kudo’ comes from Greek, meaning ‘praise’ which is exactly what kudos is for.
Unlike top-down rewards, Kudo Cards thrive on peer-to-peer recognition, making gratitude an everyday part of Agile ceremonies like retrospectives and health checks. They can be a simple, fun activity through to something more serious.
## Why give kudos?
Imagine this: You’ve just wrapped a sprint. Bugs were squashed, blockers cleared, and the team navigated a tense stakeholder review. In your retrospective, there’s a brief silence until one team member says, “Hey, kudos to Priya for stepping in on the API issue. Totally saved our sprint.” Smiles appear. The mood shifts. Recognition changes the room.
Kudo Cards are a peer-to-peer recognition tool that gives team members a structured, positive way to acknowledge each other’s contributions.
Psychology tells us that recognition plays a vital role in intrinsic motivation. A few reasons why kudos matter:
- **Reinforce positive behavior**: Recognition strengthens the likelihood of repeated collaboration and supportive behaviors.
- **Boost team spirit**: Simple acknowledgements create a sense of belonging and camaraderie.
- **Foster a growth mindset**: By praising effort, learning, and persistence, kudos encourage continuous improvement.
- **Encourage radical candor**: By mixing honest feedback with appreciation, teams create safe environments for growth.
- **Keeps people engaged** – both during and outside of the meeting.
According to studies on employee motivation, **peer recognition** can boost performance by up to 14%. In remote or hybrid Agile teams, these micro-moments of appreciation act as emotional glue.
## Practical implementation steps
To put kudos into practice, here are a few suggestions:
- **Set aside a few minutes** in retrospectives or health checks specifically for kudos. This can be at the very start or at the end of the meeting depending on your preference.
- **Use a structured system** such as physical cards, a kudos wall, or TeamRetro’s built-in kudos feature that will help you keep a record of all kudos over time.
- **Encourage specificity**: thank teammates for clear contributions or actions.
- **Lead from the front** – Model the behavior with an example.
## Best practices for sprint retrospective kudos
Want your kudos moments to really matter? Simple. Keep them clear, authentic, and balanced.
Keeping it intrinsic is also important. Jurgen Appelo’s rules for intrinsic rewards, as detailed in Management 3.0, emphasize preventing negative motivation. These include not promising rewards in advance, keeping anticipated rewards small and to reward publicly and continuously. The goal is to focus on rewarding the process, not just the outcomes in peer to peer rewards.
You don’t have to reward everyone who gets a card. For example you can reward the person with the most cards or draw from a random card and reward its recipient. Let your team decide who deserves the golden ticket.
It’s also a nice idea to thank the person who writes the Kudo Cards too or to have different people read out kudos each time.
## Giving kudos in TeamRetro
TeamRetro makes it easy to weave kudos into your retrospectives and health checks. Facilitators, meeting participants and guests in a meeting can give kudos to other members. (Only observers, as their name would suggest, cannot give kudos).
Here’s how you can recognize your team:
([full help guide here](https://help.teamretro.com/article/464-giving-kudos "kudo cards in retrospective guide"))
### Types of Kudo Cards
Not all kudos are the same. Here’s a quick breakdown of the different types of Kudo Cards:
**Thank you**
For showing appreciation when someone helped you out.
*e.g.* “Thank you, Sam, for jumping in to debug the issue so quickly.”
**Proud of you**
For recognizing growth, courage, or stepping up.
*e.g.* “Proud of you, Jen, for leading the client demo with confidence.”
**Great job**
For acknowledging solid, reliable contributions.
*e.g.* “Great job, Chris, coordinating with QA to get the release out on time.”
**Very happy**
For celebrating something that made the team or you feel good.
*e.g.* “Very happy with how you handled the feedback, David. It turned things around.”
**Congrats**
For celebrating milestones or achievements.
*e.g.* “Congrats, Maria, on closing your first story this sprint!”
**Impressive**
For highlighting standout effort or impact.
*e.g.* “Impressive work, Samuel, fixing that critical bug in just a few hours.”
These moments of acknowledgment ripple outward, lifting not only the individual but the whole team atmosphere. In TeamRetro, enabling kudos ensures that recognition is seamlessly woven into your retrospectives and health checks, turning gratitude into a regular part of Agile life.
## Ready to build a culture of appreciation?
Kudos is more than a nice-to-have. It’s an excellent way to acknowledge contributions, build team spirit, and boost overall team happiness. Whether you’re running retrospectives, health checks, or day-to-day chats, integrating kudos with TeamRetro turns recognition into an intentional practice.
👉 **Start your free trial with [TeamRetro](https://secure.teamretro.com/login/new?cc=kudosBlog "TeamRetro start free trial")** and see how easy it is to foster a culture of gratitude in your Agile team.
---
# How online retrospective and health check build psychological safety
URL: https://www.teamretro.com/blog/how-online-retrospective-tools-build-psychological-safety/
Running your retrospective with an online tool can be an ideal way to build [psychological safety](/guides/scrum-masters-retrospective-guide/how-to-build-a-psychologically-safe-space/) by providing a way for the team to share their ideas safely, celebrate success and find ways to improve, without playing the blame game.
They provide a platform where ideas can be safely and anonymously shared about what went well, what did not, and what they want to improve. By [choosing the right retrospective tool](/retrospective-tool/) with features that support this such as independent input and voting, it can create the perfect setting for continuous improvement.
Scrum Masters who properly facilitate meetings with these tools can help reduce fear of judgment or reprisal. By following up with any issues quickly, this lets the team know that they are being heard.
While it can never replace the skills and traits of the servant leader that is the Scrum Master, having the right online retrospective tool that has safety in mind will establish agreed protocols in meetings, adapt to your needs, and keep track of agreed actions.
Here’s our take on how to build psychological safety through the humble retrospective. For the bigger picture, see our full guide to [psychological safety at work](/guides/psychological-safety-at-work/).
## Helps the team understand what psychological safety is
Online retrospective tools that include team health checks can help people better understand what psychological safety means for them.
The health checks offer team members questions to support individual reflection. The questions included in the [Psychological Safety health check](/health-check-templates/psychological-safety-check/), for example, connect to the indicators of safety used by researcher, [Professor Amy Edmondson](https://www.hbs.edu/faculty/Pages/profile.aspx?facId=6451). An online tool also offers a team the flexibility to decide and define what safety means for them with a custom health check.
Scrum Values can also be explored using an online retrospective tool. The [Scrum Values health check](/health-check-templates/scrum-values-radar/) can help a team measure and track their value alignment. This can then help support conversations around development and growth as well as helping to improve relationships within the team.
Importantly, team health checks can help measure and track psychological safety within the team. This means that decisions around actions made to support safety can be informed by data. The impact of those actions can be tracked over time.
## Helps you set the stage for your retro
An online retrospective tool can provide templates that support the needs of your team. If that need is fostering psychological safety, it can inform the choice of template you make. Adding headings to your retro that ask people how they can build safety in their team means you are already providing a space for ideas to be heard.
A Welcome Message can be used to help set the tone for the meeting. It can remind people of the helpful habits that build safety.
Displaying the Retrospective [Prime Directive](/guides/scrum-masters-retrospective-guide/what-is-the-retrospective-prime-directive/) at the start of your retrospective reminds the team of the mindset needed to ensure the meeting is both positive and improvement oriented.
Having a facilitated workflow that can be customized can also build psychological safety.
Being able to set the stage includes
- Making it anonymous or semi-anonymous to make it safer for people to share their ideas
- Allowing independent voting on ideas that is not biased
- Having a familiar and effective workflow from brainstorming to generating action items
- Being able to propose and give feedback on ideas as well as actions
## Levels the playing field
An online retrospective tool gives each person the chance to have the opportunity to contribute, rather than just about being the most dominant person in the room.
Simply put this means that each person can share their own ideas, comment on others, have an equal number of votes for discussion, and to support specific proposed actions. All voices are heard at the same volume and are of equal importance.
Anonymous input helps with this. Submitting ideas anonymously means team members aren’t influenced by the person who suggested it. Instead, the idea is viewed on its own merits.
Using independent voting to decide on what is discussed and which actions are taken forward is an effective way of supporting psychological safety. Each person has a fixed number of votes with equal weight as part of a “dot-mocracy”
The way in which an online retrospective tool allows for input to be captured also helps maintain a level playing field. All participants have the same opportunity to submit the same type of input at the same time. It’s not dependent on having room to stick ideas on a physical board, nor for people to wait their turn. People can record their questions, comments and feedback simultaneously while discussion is taking place. Again, this means that all ideas can be captured and the whole team can see all comments that have been offered. See [how Typewise’s distributed team uses online retrospectives](/case-studies/typewise/).
## Helps remove fear and bias
One of the most effective ways online retrospective tools help to support psychological safety is by reducing the opportunities for judgment. When team members fear being judged, they are more likely to self edit their input in order to avoid it. This may result in fewer, less varied ideas being generated.
When the retrospective is set to anonymous names are removed from all input. No one knows who submitted what; not even the Scrum Master (unlike handwritten notes). Such anonymity lets team members share their ideas without fear of judgment or retaliation. This means people are more likely to be more honest and more creative.
## Fosters feedback
As well as capturing questions without the fear of interrupting discussions, online tools allow participants to visually reflect their thoughts. Emojis and GIFs can be used to offer a sense of what a participant feels without the pressure of going into detail. When it comes to deciding on proposed actions, using a thumbs up, thumbs down, or up and down, is a quick indication of a preference without having to offer a reason.
Other features such as a [ROTI (return on time invested)](/blog/return-on-time-invested/) can also support psychological safety. As it is yet another simple way team members can provide feedback and feel heard.
## Creates a space for ideas to be shared openly – beyond space and time
Online retrospective tools are particularly well placed to support asynchronous meetings. This is because members of the team are able to determine the time that best suits them to offer their input.
It also means that one time zone isn’t being favored over another. Additionally, remote, hybrid and in-person teams have the same retro experience.
## Helps set ground rules for the team
Online retrospective tools can also include a mechanism to build [Team agreements](/blog/create-social-contracts-with-team-agreements-that-improve-culture/). This helps psychological safety as such ground rules reflect the behaviors that a team promises to demonstrate when working with each other. They can cover what the team feels is important when working together. This can include a range of understandings such as how to deal with noise up to how conflicts are to be addressed. The clarity and shared understandings about behavior they deliver makes the workspace a psychologically safe one in which to participate.
## Helps build team connectedness
An online retrospective tool can help build team connectedness. From sharing ideas, proposing and accepting actions, through to adding topics about acknowledgement and kudos. The tool gives each person their own space to think, and also the chance to share and listen.
When it comes to remote teams, an online tool is a real game-changer. It overcomes the barriers of distance and puts everyone on the same virtual page.
## Allows you to identify anti-patterns
Online retrospective tools are able to address a number of issues that can reduce the safety of traditional meetings. They are able to counteract bias by supporting equitable, inclusive input.
Specifically, the anti-patterns they can help identify –
1. Teams are not holding retrospectives
2. Team members are not participating during the meeting
3. Action items are not being followed up
Online tools can capture data that could be missed during the retrospective itself. They can reflect participation rates, with low rates pointing to the possibility of low levels of safety.
They also facilitate transparent processes that foster divergence and encourage openness.
## Run a retro today
[Test drive the range of retrospectives](/retrospective-templates/) TeamRetro offers or sign up for a [free trial](https://secure.teamretro.com/login/new?cc=www-blog) (without a credit card) today!
---
# How to manage the BMWs in your retrospectives
URL: https://www.teamretro.com/blog/how-to-manage-bmw-in-retrospectives/
There’s an acronym used in [Agile](https://en.wikipedia.org/wiki/Agile_software_development) – BMW – and we don’t mean Bayerische Motoren Werke, the German brand of luxury cars well known around the world.
We’re talking about the “Bitching, Moaning, Whinging” session that can sometimes happen during retrospectives. As much as we would love to believe that retrospectives are always rainbows and sunshines with a focus on the agile manifesto and prime directive, not all teams and meetings will fall neatly into this paradigm.
And look, we get why BMWs can happen during a [retrospective](/retrospectives/) – a time when a team reflects on what happened in the iteration and identifies actions for improvement going forward.
While BMWs will exist, to varying degrees within retrospectives, the last thing you want is for it to hijack your retro and everyone leaving your meeting with the wrong focus.
So how might we balance out giving the people the opportunity to share what the problems are without it turning into the next soap drama?
Here at [TeamRetro](/), we’re sharing some ways to manage BMW in retrospectives.
## Activate the “spidey sense”
They say prevention is better than the cure and we totally agree with this saying! We advise scrum masters to turn on their “spidey senses” and sense from the standups and one-on-ones if something is brewing. If it is, address those issues before the retro so you manage BMW in retrospectives by keeping them out and the constructive feedback in.
## Manage BMW in retrospectives with a timebox for a soapbox
BMWs are pretty inevitable and instead of letting it all stew in, we suggest there is a way to let it stew out strategically. Here’s how:
1. Schedule one minute in your retro to “let go” – let your team air out something that’s made them mad, lose focus or just need to get off their chest.
2. You can use the [timebox feature](https://help.teamretro.com/article/168-timer) in TeamRetro to “fix” the amount of time.
3. And use the information as a way to focus actions / solutions or park it if it needs to be solved after the retro.
## Call an elephant an elephant
The saying “there’s an elephant in the room” typically means that there is an obvious problem or difficult situation that people do not want to talk about. Giving this “elephant” space to be listed on the retro topics for discussion means there will be less hidden issues and agendas, giving your team confidence to say what they need to.
## Change the focus
A typical [Agile Retrospective](/retrospective-templates/agile-retrospective/) asks 4 basic questions – what went well, what went less well, what do we want to try next and what puzzles us – that gets teams thinking about the outcomes of the last sprint, and what actions they should focus on next.
If you are finding this style of retro is opening the BMW can, then why not look at putting on a different hat with your retros?
There’s the [Starfish Retrospective,](/retrospective-templates/starfish-retrospective/) which is a data gathering activity to foster the thinking around practices and the value the team gets from it. It helps team members to understand each other’s perceived value on such practices.
Or try the [mad sad glad retrospective](/retrospective-templates/mad-sad-glad-retrospective/) which frames discussion around the emotional journey of your team during the previous sprint, and is a great way to identify opportunities to improve team morale and job satisfaction.
There are many more retro hats to put on and try with TeamRetro – [WRAP,](/retrospective-templates/wrap-retrospective/) [FLAP](/retrospective-templates/flap-retrospective/) and the [Four Ls](/retrospective-templates/4ls-retrospective/) – give them a go for something innovative and creative that will engage your team best!
Another model to try out too is the [Circle and Soups](https://www.innovationgames.com/circles-and-soup/#:~:text=This%20game%2C%20introduced%20by%20Diana,wall%20of%20the%20unproductive%20blame.) model by Diana Larsen to help people reconcile what they can and can’t influence.
Why not try some of these styles to not only manage BMW in retrospectives but also to have fun!
## Switch Scrum Master roles
While a scrum master typically runs the retrospectives, it doesn’t mean they should be the only one doing this.
Changing up the facilitators for retrospectives can have many advantages, including:
- Different styles which might make retros more exciting as it changes with each facilitator;
- Provides an opportunity for all team members to have responsibility to run a successful retro for their team members;
- Professional development for all team members;
- Less BMW because team members who you work and collaborate with are running the retros.
## Data don’t lie
If you find your retrospectives become unfocused with too much BMW, one thing we can suggest and have seen work well is to allow for voting for items or learnings to focus on independently.
Independent voting keeps things real allowing the team to decide on where the focus should be.
Voting can be done by using the sticky dot methods if you’re running retros physically with the good old post-it notes. Or, if you’re doing your retros online, we at TeamRetro have created a + vote system, accessible by a click of a button.
Once you have collected the data, talk to it. Use it as evidence to back up your retros or focus on improving data outcomes rather than people.
With this data in hand you now know where to direct the conversation and move the thinking into problem solving and action planning.
## Follow up
Following up on the retrospective action items involves delegating tasks to each team member.
By agreeing to follow up either as a separate team meeting, with one-to-ones, or with other stakeholders, the Scrum Master can assist teams to own their retro items.
## Manage BMW in retrospectives with TeamRetro
TeamRetro is an enterprise-ready online retrospective tool for remote teams. Our guided and creative retrospective techniques ensure your retros are worthwhile – each and every time!
[Try it FREE](https://secure.teamretro.com/login/new?emailAddress=&cc=www-blog) for 30 days today and see if it can help you to manage BMW in retrospectives.
---
# How to run a remote retrospective: by agile coach, Kelly Cook
URL: https://www.teamretro.com/blog/how-to-run-a-remote-retrospective-by-agile-coach-kelly-cook/
A global pandemic has certainly placed many pauses in the way we do things and how we work. Remote retrospectives is a result of this trend.
For Agile teams, retrospectives are a crucial part of their working methodology.
Retrospectives provide the opportunity for a team to look back and see how they can improve. Retrospectives can be a catalyst for organizational change as well as team change. They can be a place to build and enable teams, or to help teams start their journey from the best possible place.
So how do you make sure that retrospectives still occur during a global pandemic that’s made most teams work in a more distributed and/or remote way?
We recently came across [this article on running remote retros](https://web.archive.org/web/20211205235303/https://www.itproportal.com/features/life-in-lockdown-how-to-run-a-remote-retro/) from [Kelly Cook](https://web.archive.org/web/20220121165244/https://www.itproportal.com/author/kelly-cook/), Agile Coach of [AND Digital](https://and.digital/), focused on sharing advice and guidance on how to run remote retros. Let’s summarize Kelly’s key points.
## Tip 1: fostering collaboration in remote retrospectives
To foster collaboration through remote retros, it’s crucial to encourage team members to be explicit. Kelly offers some tips on this topic:
- check in regularly.
- conduct anonymous team [health checks](/health-checks/).
- be visible.
- choose the appropriate tools that will allow for easy remote collaboration and help facilitate open, honest and transparent communication.
## Tip 2: removing barriers
As Zoom calls become the new favorite way to communicate, we now have a screen acting as a physical barrier between team members. Kelly offers the following tips for removing barriers:
- clarify how your team wants to work together to achieve their objectives. Once done, make sure you stick to this way of working.
- summarize throughout your retro.
- facilitate better conversations.
- manage conflicts.
## Tip 3: maximize engagement during your remote retrospectives
Remote retrospectives can be successful when you maximize input from your team. Kelly again offers the following advice to maximize engagement:
- start your retros by setting the scene.
- minimize distractions and set clear roles, like timekeepers, and scribes.
- keep team members focused through games, music, or something that keeps energy and focus high.
- review the team’s actions and ensure that each person has ownership of specific tasks.
## Try TeamRetro for your remote retrospectives
If you are still looking for the right [retrospective tool](/retrospective-tool/) to help you run remote retros, we’d like to help!
TeamRetro is an enterprise-ready online retrospective tool for remote teams. Our guided retrospective techniques ensure your retros are worthwhile – each and every time.
[Try TeamRetro FREE for 30 days](https://secure.teamretro.com/login/new?emailAddress=&cc=www-blog).
---
# How to run an icebreaker for meetings, workshops, and training sessions
URL: https://www.teamretro.com/blog/how-to-run-an-icebreaker/
To run an icebreaker, just three things are needed. The right mindset, a great question and someone to give a gentle nudge to get things started and move the icebreaker along. Before you know it, your icebreaker is done, and you have set the stage for a more effective retrospective meeting.
Even with all the benefits that running an icebreaker can bring to a team and their meeting, sometimes it can be tempting to skip straight to the retrospective. This is especially the case when your backlog is overflowing and you just don’t have the head space to think of a question. That’s why we asked our team to design an [icebreaker tool for agile teams](https://games.teamretro.com/) that would take the effort out of running icebreakers.
TeamRetro’s [icebreaker tool](https://games.teamretro.com/) makes running icebreakers easy. Designed with agile teams in mind, it can generate [icebreaker questions](https://games.teamretro.com/games/icebreaker-questions/) and help you decide who goes next. It can even help you keep an eye on the time!
So let’s look at how to run an icebreaker so you can help your team get more out of their retrospective, or any standup, kickoff or one-on-one you open with one of our [icebreakers for meetings](/icebreakers/icebreakers-for-meetings/).
## Step into the icebreaker headspace
The first thing to do when running an icebreaker is to switch on the right mindset.
- Be curious.
- Be positive.
- Be an advocate for icebreakers.
Remember, icebreaker questions aim to foster connections between people so they work better together. Those connections come about when people share their stories with each other. The more people share, the greater the connections. People are more likely to share when they feel their stories are being received positively and with genuine interest.
Keep in mind, there’s no such thing as a wrong answer to an icebreaker question, which is why they are so great at helping to create safe spaces. All answers are welcome and all input is valued. It’s a space where inclusivity and diversity is naturally celebrated.
Lastly, don’t forget that by running an icebreaker you are delivering a lot of value to your retrospective meeting. You are helping to create a safe, positive, collaborative space. You are contributing to the productivity of the meeting. Best of all, you are making work fun.
## Choosing a great icebreaker question
To choose a great icebreaker question head over to TeamRetro’s [icebreaker tool](https://games.teamretro.com/) and click start. Yes, it really is that easy!
If you would like your icebreaker question to have a little more focus, you can filter the questions by the following categories.
### Agile games
An agile game is a fun activity aligned to an aspect of agile. They see the whole team work toward a common goal. As well as building connections between team members they also help to deepen their understanding of agile.
### Building safety
These icebreaker questions help to explore and foster a safe workspace. They offer the team the chance to share stories of trust, empathy and growth. These questions help start supportive conversations that can continue long after the icebreaker is done.
### Deep and meaningful
This category of icebreaker questions gives people the chance to share insights and ideas they may not have otherwise shared at work. They let people explore and predict possibilities, while the group gets to know more about each other. In doing so, they can help a team expand their perception of each other. These are great to use when a reminder is needed that we’re all human.
### Fun
This group of [funny icebreaker questions](/icebreakers/funny-icebreaker-questions/) is pretty self-explanatory. They are deliberately creative and a little bit silly, all in the name of having fun at work. Rest assured, they will still deliver all the benefits of an icebreaker, even if the laughter gets loud.
### Get to know
The ‘Get to know’ icebreaker questions have been shaped with new teams and teams with new members in mind. They support the very early stage of when people meet. They help to start inclusive conversations that form the foundation of connections.
### Quick/check-ins
This set of icebreaker questions is your go-to when you feel you are pushed for time. They are short and fast, but they still deliver value. These save you time so you don’t have the excuse to skip the icebreaker.
### Team building
These icebreaker questions help nurture your team. They create space for celebration. They showcase collaboration and teamwork. They boost morale, explore values and fuel productivity. If you are looking to actively support your [team’s health](/health-checks/), these are the icebreakers for you. And when you want full activities rather than just questions, our [team building games for work](/icebreakers/team-building-games-for-work/) pick up where these leave off.
### Virtual or remote
Remote teams will easily relate to this category of icebreaker questions. They reference their virtual context as a common point of discussion. These icebreakers also see team members share aspects of their homes as a reflection of themselves.
### Warm-ups
Although not technically an icebreaker, we included this category for established teams. Warm-ups help people focus on the task at hand. These activities help your team direct their full attention to the retrospective and to switch off from other thoughts and tasks. You can read more about warm-ups here.
### Work focussed
If your team isn’t too keen on running an icebreaker before their retrospective, this set of questions will help you navigate that resistance. These [icebreaker questions for work](/icebreakers/icebreaker-questions-for-work/) connect to what everyone in the team has in common – their place of work. They help the icebreaker habit to be established by exploring that common ground.
## How to facilitate an icebreaker
Facilitating an icebreaker is very straightforward and comes down to just three steps –
- Kicking it off
- Making sure everyone has had a turn
- Wrapping it up
### Kicking it off
Kicking off an icebreaker starts with finding someone to go first. If you’re meeting a brand new team for the first time, and you’re the Scrum Master or facilitator, that person should be you. Going first lets you introduce yourself, set the tone, and model the kind of open, respectful sharing you want to see from everyone else.
TeamRetro’s icebreaker tool includes a built-in [random name picker](https://games.teamretro.com/games/random-name-picker/) that nominates who goes next, so you don’t have to choose people manually. That keeps the process transparent, fair, and free from any unconscious bias.
### Making sure everyone has had a turn
It’s important that everyone gets a chance to answer the icebreaker question. Inclusive retrospectives start with making sure no one is left out, especially quieter or remote team members.
Here again, TeamRetro’s [icebreaker tool](https://games.teamretro.com/) does the heavy lifting. Each time someone answers, their name is automatically removed from the pool of people still to respond. You don’t have to remember who has already had a turn — the tool tracks participation for you and makes it easy to see who’s next.
### Wrapping it up
Once everyone has answered the icebreaker question, it’s time to bring the activity to a close and smoothly transition into your retrospective. When the question is particularly engaging, conversations can run long and eat into your retro time.
To help with this, TeamRetro’s [icebreaker tool](https://games.teamretro.com/) includes a timer so you can keep the activity within a set timebox. It gives you a clear, neutral reference point if you need to move the discussion along and make sure your retrospective starts on time.
Before you wrap up, thank everyone for sharing and acknowledge the contributions they’ve made.
For more, check out our [top 5 tips for running icebreakers](/blog/top-5-tips-for-running-effective-icebreakers/).
You can also explore our blog where we share [what makes the best icebreakers for teams](/blog/best-icebreakers-for-starting-conversations-with-online-teams-2021/), along with [quick but effective icebreakers to launch your next retrospective.](/blog/quick-but-effective-icebreakers-to-launch-your-next-retrospective/) Or browse the full library of [icebreaker questions](/icebreakers/), grouped by use case.
---
# How to run great retrospectives online with remote and distributed teams
URL: https://www.teamretro.com/blog/how-to-run-great-retrospectives-online-with-remote-and-distributed-teams/
As [predicted](https://www.siliconrepublic.com/careers/remote-flexible-working-fixed-offices-future-of-work) some time ago and recently catalyzed, the popularity of remote working continues apace.
Whether partially or fully remote, the benefits of such a workforce are hard to ignore –
- increased productivity and reach
- decreased costs
- access to a diverse talent pool
- better retention and employee satisfaction
Within the context of agile, the retrospective is critical to the success of a team. So, given the increasing popularity of a remote workforce, it stands to reason it’s important for an Iteration Manager or Scrum Master to be able to facilitate an online retrospective as effectively as they would one that’s face to face.
With this in mind, we’ve put together the following to share our tried and true tips for running effective online retrospectives.
## What makes an effective online retrospective?
Here at TeamRetro, we practice what we preach, running regular retrospectives in order to improve our product and our team.
From our perspective, regardless of the medium of their delivery, an effective retrospective has the following characteristics –
- has a regular cadence
- operates with a shared understanding of what’s expected of the team
- allows all voices to be heard
- occurs in a safe, judgment-free space
- adheres to the allocated time
- is easily and concisely documented
- supports team morale
- delivers a clear set of actions for the next sprint, and a shared understanding as to who is responsible for their delivery
Ensuring these outcomes are delivered in an online environment boils down to two key elements
- An online environment supportive of retrospectives
- Appropriate online facilitation techniques
Here’s how to do it.
## Step 1 – Prepare the online environment (set the virtual stage)
Consider the space in which you and your team run your face-to-face retrospectives –
- You may be using a whiteboard with team members taking it in turns to stand up and add to it, or perhaps sticking post-its onto a board.
- Participants may offer a quick explanation or comment as they add each of their points, before the team discusses things more broadly. If an impasse is reached, it’s possible things are talked through until a consensus is reached.
- It’s possible you know it’s time to wrap up when you see people heading for lunch, or hear a knock on the meeting room door.
Clearly, while the above may work for those of the team based in the office, the same cannot be said for those working remotely; the above obviously needs to be translated into a virtual space. While this may require some investment, an environment that supports both co-located and remote participants equally, is a valuable risk mitigation treatment on many levels.
### Choose your online retrospective tool
[Online retrospective tools](/retrospectives/) have been developed with both remote and co-located teams in mind, and offer an organized process for running a retrospective.
There are a myriad of [sprint retrospective tools](/retrospective-tool/) but overall they should be designed to –
- make facilitation easy
- be secure, fast and reliable
- address common retrospective anti-patterns
- shape a safe, equitable space
- easily capture inputs from all participants
- record and track action items
- gauge meeting effectiveness
- present ideas one by one to ensure everyone is focused
- augments your video conferencing tool
- integrates action items into your workflow
### Choose your communication tool
Will you be using video conferencing, teleconferencing, or will you be relying on VoIP?
The mechanism your team uses to complement your online retrospective tool will inform the facilitation techniques used to support the retrospective process itself.
For example we use video conferencing and an internal messaging system such as Zoom and Slack to support our real time online retrospectives.
- Our screens are on and microphones are unmuted (this means that our facilitator can see we are engaged).
- From time to time, links to documents and other files are shared on a dedicated and secure messaging channel.
- The scrum master may share their screen throughout the retrospective as needed.
### Consider a dry run
Delivering retrospectives to a remote workforce is very difficult to do on the fly; without the convenience of co-location it can be difficult to convey last minute decisions, delegate the Scrum Master role, change times etc. These things are also incredibly frustrating and isolating for the team.
The importance of planning and following through cannot be understated. While some discipline may be needed to deliver this, the return (saved time, focused retrospective, team alignment) will be worth it.
In order to ensure the virtual space is suitable to facilitate retrospectives, it’s helpful to ensure –
- all participants know how to use the technology, so a dry run helps.
- the technology works, so home VPNs and low connectivity can be addressed beforehand.
- there is an easy and agreed process for people to follow.
The simplest way to achieve this is to rehearse or walk through a retrospective. This way your team can demonstrate both the retrospective tool and communication mechanisms work, and they know how to use them!
### Before your retrospective
**Build cadence**, by locking in a regular time slot in everyone’s schedule. Ensure all team members have made the retrospective a priority by giving them plenty of time to organize their commitments (kids etc) and double check time zones are aligned.
**Draft a** [**team agreement**](https://help.teamretro.com/article/266-team-agreements)**;** these are the ‘house rules’ for the retrospective meeting itself, and a worthwhile exercise to do with your team. This aligns to building the team culture and how people interact with each other. Things such as “we won’t multitask” (which is always tempting to do during internal virtual meetings), or “always laugh at jokes, even the bad ones” could be included. The agreement isn’t written in stone, and can be updated at any time.
**Choose a template** that will support the needs of your retrospective and team. If you’re looking for a way to help your team re-frame challenges, the [Netball Retrospective](/retrospective-templates/netball-retrospective/) may be what you’re looking for; if your team works well with a direct approach, the [Working Not Working Retrospective](/retrospective-templates/working-not-working-retrospective/) will help them get straight to the point.
**Confirm the options** you wish to apply to your template. Adding a [ROTI](/blog/return-on-time-invested/) can help gauge the effectiveness of the meeting, allowing participants to add reactions, comments, or GIFs can increase participation and add an element of fun to the retrospective.
**Consider the psychological safety** of the space. If your team is new, looking to build up trust, or you wish to ensure personalities don’t influence the perception of ideas, having participants contribute anonymously or use an alias may help level the playing field.
**Share the template** to counteract [recency bias](/blog/tips-to-overcome-recency-bias-in-your-retrospectives/). By sending the template out at the start of the sprint with the brainstorming page open, team members can add notes whenever they wish during the sprint.
**(If it hasn’t already happened) circulate the action items** from the last retrospective in order to remind the team of what was previously agreed upon. This will ensure no one will feel they are being ambushed during the retrospective itself.
## Step 2 – Run the retrospective (collect data)
**Warm up with an** [**icebreaker**](/icebreakers/virtual-icebreakers/), a simple activity, undertaking, or game that helps people foster connections and build rapport. Our [free icebreaker games](https://games.teamretro.com/games/) run right in the browser — great for [remote teams](https://games.teamretro.com/use-cases/remote-teams/) joining from anywhere.
**Then kick off with an overview** of the retrospective to ensure everyone is on the same page. This can include quickly running through the team agreement and the process steps that make up the retrospective.
**Keep an eye on the time**, this means starting on time and keeping an eye on the clock. [Timeboxing](/blog/timeboxing-for-scrum-teams-and-successful-retrospectives/) is a great way to do this.
**Maximize** **engagement** throughout the retrospective with –
- permission-based progression (questions such as ‘is everyone happy to move on?’, ‘can we head to the next step?’)
- requesting clarification of ideas and responses
- checking in with quieter participants
**Leverage the online retrospective tool** to support the process and don’t be afraid to go back a step. The tool is there so there’s no need to remember what comes next, that’s not to say you can’t back track if needed.
## Step 3 – Look for ways to improve (decide what to do)
With the key items prioritized and discussed, a key element of the retrospective, and indeed Agile is to determine what the next steps are to improve processes, increase value, solve problems or simply experiment on.
**Give the team the space and time to** come up with potential solutions and proposed actions that the others can deliberate on.
**Capture action items** as they are proposed, confirming they have been recorded correctly at the time.
**Review all action items** (including those outstanding) and tick off those that have been delivered. Always align an action item to a date and person responsible for their delivery. This is a good time to talk about things that might be blocking an action or any impediments that might slow it down.
## Step 4 – Wrap things up (close the retrospective)
**Finish up by summarizing** the main areas covered, the agreed actions, the time and date of the next retrospective, and **thanking** everyone for participating.
**Share the summary** of the retrospective along with the agreed action items.
**Follow up** with the team to help them stay accountable and to remove impediments
If done properly, running remote retrospectives can bring an incredible amount of value to your team.
## Ready to run your retro?
Using an online retrospective tool such as TeamRetro allows the Scrum Master or meeting facilitator to focus on the needs of the team rather than the mechanics of the online retrospective. Ideas and comments can be captured instantly and prioritized for discussions. Actions can be tracked, shared or integrated and followed up at the next meeting. Each person in the team has an equal opportunity to contribute in a psychologically safe space and can be time boxed to ensure everyone stays on task.
TeamRetro takes care of the process so participants can focus on conversations and actions to take forward. There’s no need to take our word for it – you can [test drive a range of retrospectives](/retrospectives/) or sign up for a [free trial](https://secure.teamretro.com/login/new?cc=www-blog) (without a credit card).
Have a great retro!
---
# How to tell if your team feels psychologically safe
URL: https://www.teamretro.com/blog/how-to-tell-if-your-team-feels-psychologically-safe/
[Psychological safety at work](/guides/psychological-safety-at-work/) describes a workplace environment where individuals feel safe to take risks, share ideas, and experiment without fear of judgment or punishment. It’s not just a buzzword; it’s foundational to fostering creativity, collaboration, and innovation.
Why does psychological safety matter? Because when team members don’t feel safe, they hold back. Fear stifles creativity and decision-making. In a retrospective, for example, the lack of psychological safety can lead to withheld ideas, silence during discussions, or resistance to feedback, all of which hinder the team’s ability to improve.
## The business case for psychological safety
Psychological safety delivers value. It underpins key workplace outcomes like innovation, knowledge sharing, and productive conflict resolution, all critical to high-performing Agile teams. Google’s landmark Project Aristotle revealed that psychological safety is the *most important factor* in team success. It’s the foundation that enables dependability, clarity, meaning, and impact, the crucial components of exceptional teamwork.
Let’s explore how psychological safety (or the lack of it) shows up in your retrospectives and team dynamics.
## Signs of psychological safety in action
### 1. Conflict: how it’s managed matters
| **In a Psychologically SAFE Space** | **In a Psychologically UNSAFE Space** |
| :-- | :-- |
| Conflict is observed and addressed. | Conflict is rare or entirely avoided. |
| Conversations are candid and direct. | Conversations are overly diplomatic or brief. |
| Concerns and alternative ideas are explored openly. | Ideas are rushed to consensus to avoid tension. |
Psychological safety doesn’t mean the absence of conflict. Rather, it means conflict is embraced as a way to challenge ideas constructively and seek the best solutions. When teams feel safe, members raise concerns, suggest alternatives, and work toward meaningful resolutions.
**What to Watch For**:
- **Unsafe**: Few disagreements or overly cautious language (“Maybe we could…” or “Possibly…”).
- **Safe**: Healthy dissent, open debate, and exploration of diverse ideas.
**Why It Matters**: Retrospectives thrive on honesty and diverse perspectives. A team that avoids conflict may miss opportunities for breakthrough improvements.
### 2. Engagement: who’s at the table?
| **In a Psychologically SAFE Space** | **In a Psychologically UNSAFE Space** |
| :-- | :-- |
| High and voluntary participation. | Low engagement or minimal input from members. |
| Everyone contributes ideas. | The team leader dominates discussions. |
| Questions and feedback flow freely. | Questions and feedback are rare. |
When people feel safe, they focus on the work instead of self-preservation. They’re more likely to voice opinions, ask questions, and challenge assumptions. All of those are critical behaviors in retrospectives.
**What to Watch For**:
- **Unsafe**: Silent team members, reluctance to ask questions, or passive agreement.
- **Safe**: Robust discussions, enthusiastic contributions, and curious questions.
**Why It Matters**: Engaged team members drive more effective retrospectives. Higher engagement leads to better decisions, stronger accountability, and actionable improvements.
### 3. Mistakes: are they discussed or hidden?
| **In a Psychologically SAFE Space** | **In a Psychologically UNSAFE Space** |
| :-- | :-- |
| Mistakes and failures are shared openly. | Mistakes are hidden or denied. |
| Problems are analyzed for improvement. | Problems are ignored or blame is assigned. |
| Lessons learned are shared with the team. | Errors are avoided in discussions. |
How your team reacts to mistakes can reveal a lot about psychological safety. In a safe environment, mistakes are viewed as opportunities for learning and growth. When safety is absent, mistakes are sources of fear and blame.
**What to Watch For**:
- **Unsafe**: Reluctance to admit errors, finger-pointing, or silence about problems.
- **Safe**: Open acknowledgment of mistakes, shared problem-solving, and learning moments.
**Why It Matters**: Retrospectives are a prime opportunity to learn from mistakes. Teams that embrace errors as learning experiences improve faster and more consistently.
### 4. Team connectedness: trust and relationships
| **In a Psychologically SAFE Space** | **In a Psychologically UNSAFE Space** |
| :-- | :-- |
| Team members know each other personally and professionally. | Interactions are limited to professional contexts. |
| Help is offered and requested freely. | Help is limited to formal roles and responsibilities. |
| Connections span across organizational levels. | Connections are siloed within the team. |
Strong interpersonal connections are a hallmark of psychological safety. When team members trust and understand one another, they’re more willing to collaborate, give feedback, and embrace diverse perspectives.
**What to Watch For**:
- **Unsafe**: Limited personal interaction, rigid adherence to roles, or fear of “judgment from above.”
- **Safe**: Genuine connections, mutual support, and a sense of belonging.
**Why It Matters**: Trust and empathy foster collaboration, creativity, and resilience, the key ingredients for productive retrospectives and team success.
### 5. Measuring psychological safety
| **In a Psychologically SAFE Space** | **In a Psychologically UNSAFE Space** |
| :-- | :-- |
| Team uses surveys and tools to measure safety regularly. | Measurement is avoided or done superficially. |
| Honest feedback is encouraged and received anonymously. | Feedback is rare, and team members fear reprisal. |
How do you know if your team feels psychologically safe? Consider using structured tools and frameworks to measure safety levels:
- **Amy Edmondson’s Psychological Safety Scale**: A [research-backed framework](https://hbr.org/2023/02/what-is-psychological-safety) for assessing team safety through targeted questions.
- **TeamRetro’s Team Health Check**: A [quick, effective way](/health-check-templates/team-health-check/) to measure and track psychological safety over time, identifying specific areas for improvement.
**What to Watch For**:
- **Unsafe**: Ongoing and persistent low morale and team health scores that cannot be readily mitigated or a lack of engagement.
- **Safe**: A balanced set of team health metrics with a relatively high level of engagement and participation.
**Why It Matters**: Measurement ensures you’re making progress toward a safer and more productive team culture.
### 6. The role of leadership in psychological safety
| **In a Psychologically SAFE Space** | **In a Psychologically UNSAFE Space** |
| :-- | :-- |
| Leaders admit mistakes and show vulnerability. | Leaders avoid admitting fault and appear infallible. |
| All voices are actively invited into discussions. | Only a few dominant voices shape decisions. |
| Empathy and support are demonstrated consistently. | Concerns are dismissed or minimized. |
Leaders play a pivotal role in shaping a psychologically safe environment. Key behaviors include:
- **Vulnerability**: Admitting their own mistakes to normalize imperfection.
- **Inclusivity**: Actively soliciting input from all team members, especially quieter voices.
- **Empathy**: Demonstrating understanding and support when team members share concerns or make mistakes.
**Why It Matters**: When leaders model these behaviors, they set the tone for the rest of the team, creating a culture of openness and trust.
### 7. Psychological safety and innovation
| **In a Psychologically SAFE Space** | **In a Psychologically UNSAFE Space** |
| :-- | :-- |
| Bold ideas and experimentation are encouraged. | Risk-taking is avoided due to fear of failure. |
| Divergent thinking is celebrated and explored. | Teams default to groupthink or safe decisions. |
| Knowledge is shared freely across the team. | Knowledge hoarding occurs to maintain control. |
Psychological safety is a catalyst for innovation. When team members feel secure:
- They are more likely to experiment and propose bold ideas.
- They engage in divergent thinking, exploring multiple solutions to a problem.
- They share knowledge freely, leading to better decision-making and collaboration.
**Why It Matters**: Teams that innovate are better equipped to adapt to change and deliver value, a critical advantage in today’s fast-paced environment.
### 8. Psychological safety in remote teams
| **In a Psychologically SAFE Space** | **In a Psychologically UNSAFE Space** |
| :-- | :-- |
| Team members use cameras to build connections. | Video is avoided, limiting trust-building cues. |
| Clear norms support respectful and open dialogue. | Communication norms are vague or non-existent. |
| Anonymous tools encourage honest feedback remotely. | Feedback mechanisms are missing or ignored. |
Creating safety in virtual environments can be challenging but is entirely possible. Consider these tips:
- **Use Video Calls**: Seeing facial expressions helps build trust.
- **Set Clear Communication Norms**: Encourage open dialogue and respectful disagreement.
- **Leverage Tools Like TeamRetro**: Facilitate anonymous input to make everyone feel heard.
**Why It Matters**: Remote teams can thrive when they feel connected and secure, leading to more effective collaboration and retrospectives.
### 9. Psychological safety in retrospectives
A retrospective is only as effective as the environment in which it takes place. When team members feel safe, they engage deeply, explore ideas fearlessly, and learn from mistakes openly. Conversely, an unsafe environment leads to superficial discussions and missed opportunities for growth.
**How TeamRetro Can Help:**
- **Check-in and Check-out Questions**: Begin and end retrospectives with thoughtful questions to gauge team mood and reflections, such as:
- ***Check-in**:* “How are you feeling about this sprint?” or “What’s one thing you’d like to achieve today?”
- ***Check-out**:* “What’s one thing you’re taking away from today’s discussion?” or “How are you feeling after this retrospective?”
- **Independent Brainstorming**: Encourage team members to ideate privately before sharing, reducing the influence of dominant voices.
- **Unbiased and Private Voting**: Use private voting tools to prioritize ideas or actions without bias or peer pressure.
- **Anonymity**: Enable anonymous feedback and suggestions to ensure everyone feels secure in sharing their honest thoughts.
- **Retrospective Templates**: Use tools designed to encourage open dialogue and structure meaningful conversations.
- **Icebreakers**: Kickstart sessions with activities that build trust and break down barriers.
- **Team Health Checks**: Monitor psychological safety regularly and identify areas for improvement.
- **AI-Powered Insights**: Spot patterns and address issues before they escalate.
## Comprehensive overview: safe vs. unsafe behaviors
| **Category** | **In a Psychologically SAFE Space** | **In a Psychologically UNSAFE Space** |
| :-- | :-- | :-- |
| **Conflict Management** | Conflict is observed and addressed constructively. | Conflict is rare or avoided entirely. |
| | Conversations are candid and direct. | Conversations are overly diplomatic or brief. |
| | Concerns and alternative ideas are explored openly. | Ideas are rushed to consensus to avoid tension. |
| **Engagement** | High and voluntary participation from all team members. | Low engagement; discussions are dominated by a few voices. |
| | Everyone contributes ideas and asks questions. | Questions and feedback are rare. |
| | Robust, enthusiastic discussions. | Team members appear passive or reluctant to share opinions. |
| **Handling Mistakes** | Mistakes and failures are shared and analyzed for learning. | Mistakes are hidden, denied, or met with blame. |
| | Lessons learned are shared with the team. | Errors are avoided in discussions. |
| **Team Connectedness** | Team members know each other personally and professionally. | Connections are limited to formal, professional interactions. |
| | Help is freely offered and requested. | Help is limited to strict roles and responsibilities. |
| | Relationships extend across organizational levels. | Interactions are siloed within the team. |
| **Measuring Safety** | Team uses surveys and tools to measure safety regularly. | Measurement is avoided or done superficially. |
| | Honest, anonymous feedback is encouraged and acted upon. | Feedback mechanisms are missing or feedback is feared. |
| **Role of Leadership** | Leaders admit mistakes, invite all voices, and show empathy. | Leaders avoid admitting fault, dominate decisions, or dismiss concerns. |
| **Fostering Innovation** | Bold ideas and experimentation are encouraged. | Risk-taking and divergent thinking are avoided. |
| | Knowledge is shared freely to improve collaboration. | Knowledge hoarding occurs to maintain control. |
| **Remote Work Dynamics** | Video calls are used to build connection and trust. | Video is avoided, limiting trust-building cues. |
| | Clear norms support open and respectful dialogue. | Communication norms are vague or nonexistent. |
| | Anonymous tools encourage honest remote feedback. | Feedback mechanisms are missing or ignored. |
Ready to build a safer, more engaged team? [Start your free trial with TeamRetro](https://secure.teamretro.com/login/new?cc=www-blog) to run safe and easy retrospectives, measure team health and track actions for improvement over time.
Sign up today and create a space where innovation, connection, and productivity thrive!
---
# What is planning poker? A beginners guide for agile estimation
URL: https://www.teamretro.com/blog/how-to-use-planning-poker-in-agile-estimation/
Estimating user stories can be tricky. Too often, discussions drag on or estimates feel arbitrary. That’s where Planning Poker comes in — a fun, structured way to bring your team together for accurate, team based estimates.
Planning Poker, also known as Sprint Poker or Estimation Poker, is a collaborative technique that helps Agile teams estimate the effort required for user stories or tasks.
It’s a structured, often gamified activity that typically takes place before sprint planning. Using a deck of estimation cards, each team member privately selects a card that represents their view of the effort involved. When revealed, the group discusses differences and works toward consensus.
## What is an online planning poker session?
In an online Planning Poker session, teams use digital cards instead of physical ones. Estimates are cast anonymously and revealed simultaneously. It’s more efficient, inclusive, and free from bias.
If the estimates differ, the team discusses why. A second round of voting may follow, or the team can adjust the final score by consensus. This can be really useful for remote and hybrid teams, but works just as well for people in the same room to save time.
This ensures that estimates reflect a shared understanding of the work, not just the opinions of the most vocal team members…. And avoids all that manual mental math and decimal place calculations in a flurry of post it notes.
👉 *Try it with your team:* [*Run a Planning Poker Session Online*](https://planning-poker.teamretro.com/)
## Why use planning poker in agile estimation?
Here are 5 great reasons!
1. **It builds shared understanding** – by revealing everyone’s estimate, it uncovers assumptions, dependencies and missing details early, leading to better defined stories.
2. **It removes bias and groupthink** – Everyone estimates privately, so it’s not influenced by the most senior, confident or vocal team member, allowing balanced accurate estimates.
3. **Estimates are collaborative, and even fun** – Structured, inclusive processes keep estimation session focused, time boxed and engaging. A game-like nature can boost morale and participation.
4. **It improves accuracy over time** – By comparing complex tasks to simpler ones, teams naturally calibrate their sense of effort and complexity to help create smoother sprint planning.
5. **It encourages continuous learning** – Differences represent an opportunity to learn. It highlights technical risks, unclear requirements or edge cases and may help the team get a better understanding of what “done” really means.
## How to run a planning poker session (step-by-step)
👉 *Try it with your team:* [*Run a Planning Poker Session Online*](https://planning-poker.teamretro.com/)
1. **Add or import your list of tasks or items for estimations.**
The facilitator presents the user story or task. Everyone should have enough context before estimating.
2. **Select a deck.**
Decide on the estimation scale (e.g. Fibonacci, T-shirt sizes, [Powers of Two](https://columbia.edu/~ask2262/Obsessions/KudinoorFibonacciStoryPoints.pdf)). Since Planning Poker practitioners shy away from estimating by time (turns out humans are pretty bad at it), you also need to decide what measure – often referred to as the scale – you will use to estimate a task’s effort. These are the numbers or units you will see on your playing cards.
3. **Start estimating.**
Each team member selects their card independently. Estimates remain hidden until everyone has chosen.
4. **Review together.**
All cards are revealed at the same time to prevent bias.
5. **Discuss differences.**
If estimates vary, the team discusses why. Often, the highest and lowest estimators explain their reasoning.
6. **Redo if needed.**
A second round helps the team reach consensus.
7. **Record the estimate.**
The final score is added to the backlog item, ready for sprint planning.
## Benefits of planning poker for teams
Planning Poker is a practical way to bring clarity, confidence, and collaboration to your sprint planning. It helps teams move beyond guesswork by focusing on meaningful conversations about why something is complex, not just how long it will take. Every card turned becomes a spark for discussion about assumptions, dependencies, and risks that might otherwise stay hidden. When teams estimate together, they uncover blind spots early, align on priorities, and build a shared understanding of what “done” really means.
Over time, this consistency leads to better sprint forecasts, fewer last-minute surprises, and more predictable delivery. It also levels the playing field by giving everyone from developers to designers to testers an equal voice, creating a culture where all perspectives matter. By treating estimation as a team learning moment rather than a numbers game, Planning Poker turns planning into a collaborative rhythm that keeps teams connected, informed, and focused on delivering value.
## When NOT to use planning poker
Planning Poker is a great way to build shared understanding and align on effort, but it’s not always the best fit. Here are a few times to consider another approach:
- **Story is too vague or oversized** – Estimating work that isn’t well defined can cause confusion. Refine or break it down first.
- **Trivial tasks** – Small items, like fixing a typo, don’t need a formal estimation session.
## Pro tips for better sessions
Some Agile teams choose to skip estimations because they find them time-consuming, inaccurate, or unnecessary. Estimates can easily be misinterpreted as commitments, leading to pressure and frustration rather than collaboration. Others feel that discussions often take longer than the value they provide, especially when requirements aren’t clear or when real data from past sprints offers better insight. For teams focused on continuous delivery and learning, estimation can sometimes feel like a distraction from actually building and improving.
That said, when done with the right mindset and structure, estimation can still be a powerful tool for building shared understanding and alignment. Here are some pro tips to make your estimation sessions more effective:
- **Use a reference story** – Select one baseline item (e.g. “Implement login with Google authentication”) and compare other stories against it.
- **Estimate effort, not time** – Focus on complexity, not hours.
- **Split or park unclear stories** – If consensus isn’t reached after two rounds, break the story down or revisit later.
- **Encourage open discussion** – Differing estimates often surface risks or overlooked details.
- **Use best case, worst case, and ideal scenarios** – Consider optimistic, pessimistic, and most likely effort to balance estimates.
Want to go deeper? Our agile estimation guide covers [how to run a planning poker session](/guides/agile-estimation-guide/how-to-run-planning-poker/), [story points](/guides/agile-estimation-guide/what-are-story-points/), and [worked estimation examples](/guides/agile-estimation-examples/).
## Embrace the power of collaboration
Planning Poker is more than just an agile game. When used with intention, it becomes one of the simplest and most effective ways for Agile teams to stay aligned, reduce bias, and plan smarter together.
👉 Ready to give it a try? [Run your next Planning Poker session](https://planning-poker.teamretro.com/) and see how simple, inclusive estimation can transform your sprint planning.
---
# 60+ icebreaker questions for agile and scrum teams
URL: https://www.teamretro.com/blog/icebreaker-questions-for-agile-and-scrum-teams/
You know that awkward silence at the start of a sprint planning session? Everyone's on the call, someone's fiddling with their mic, and nobody quite knows how to kick things off. That's exactly what icebreaker questions are for, and when they're done well, they can shift the whole energy of a meeting in under two minutes.
For scrum masters and agile practitioners, a good icebreaker isn't just a warm-up. It's what makes the difference between a meeting where people hold back and one where they actually show up.
This guide covers icebreaker questions organized by agile ceremony (from daily standups to sprint retros), along with tips for running them well, a question of the day bank, and ideas for remote and hybrid teams. If you'd rather not pick by hand, our [free icebreaker questions game](https://games.teamretro.com/games/icebreaker-questions/) serves one up for the whole team. For a broader bank sorted by goal rather than by ceremony, see our [icebreaker questions for work](/icebreakers/icebreaker-questions-for-work/).
> **⚡ Quick answer**
>
> Icebreaker questions help agile teams increase participation, build psychological safety, and improve collaboration. The best questions are short, optional, and matched to the ceremony being run. Use them at the start of standups, sprint planning, retrospectives, and team kickoffs to get people talking before the real work begins.
## Icebreaker questions by ceremony: quick reference
Not sure which type of icebreaker fits your meeting? Here's the quick version:
| Ceremony | Best icebreaker type | Time limit | Goal |
| --- | --- | --- | --- |
| **Daily standup** | Quick check-in | 30–60 sec | Get people talking |
| **Sprint planning** | Reflection or curiosity | 1–2 min | Arrive mentally present |
| **Retrospective** | Psychological safety | 2–3 min | Open up honest sharing |
| **Team kickoff** | Personal connection | 3–5 min | Build team identity |
## What makes a good icebreaker question?
A bad icebreaker can make people cringe, feel put on the spot, or quietly disengage, which is why so many [teams say they hate icebreakers](https://games.teamretro.com/use-cases/teams-that-hate-icebreakers/). A good one takes about 60 seconds, gets a nod or a laugh, and opens people up before the real work starts. For a deeper look at the research behind this, check this article on [what makes the best icebreakers for teams](/blog/best-icebreakers-for-starting-conversations-with-online-teams-2021/).
Here's the difference:
| Good icebreaker | Bad icebreaker |
| --- | --- |
| Has no wrong answer | Puts someone on the spot |
| Anyone can answer quickly | Requires deep thought or preparation |
| Invites self-expression | Forces disclosure or vulnerability |
| Fits the context and tone of the meeting | Same question used every week (gets stale) |
| Passing is always allowed | Mandatory participation enforced |
## Five tips for running icebreakers well
Before you dive into the question banks below, it's worth knowing what separates a good icebreaker from one that falls flat. These five things make the difference.
1. **Answer first.** Before asking your team, give your own answer. It models the behavior you want and creates psychological safety. As [Prof. Amy Edmondson of Harvard Business School](https://hbr.org/podcast/2019/01/creating-psychological-safety-in-the-workplace) has shown, safety starts with the person at the top of the room.
2. **Rotate who picks the question.** Don't let the scrum master own it every time. Rotating builds buy-in and gives people a reason to engage before the meeting even starts. A [random name picker](https://games.teamretro.com/games/random-name-picker/) makes choosing who goes next fair and bias-free.
3. **Match the depth to the ceremony.** A standup gets a 30-second question. A retrospective can handle something more reflective. Don't use a deep team bonding question before a 15-minute standup.
4. **Time-box it explicitly.** Tell the team: "We're spending 90 seconds on this before we begin." Naming it makes it feel intentional, not chaotic.
5. **Make passing normal.** Some days are hard. Let people say "pass" without explanation. That's the difference between an icebreaker and an interrogation.
For a full breakdown of each of these, see our guide on [top tips for running effective icebreakers](/blog/top-5-tips-for-running-effective-icebreakers/).
## What are the best icebreaker questions for agile teams?
With the basics covered, here are the question banks. Each section is matched to a specific ceremony so you're not guessing which question fits which meeting, and our [meeting icebreakers](/icebreakers/icebreakers-for-meetings/) cover the rest, from staff meetings to one-on-ones.
### Standup icebreaker questions (keep it under 60 seconds)
Standups are short by design. One quick standup icebreaker question, answered in a single sentence, is all you need, and [TeamRetro's standup tool](/standups/) can open the meeting with one. If you want a ready-to-go set, [TeamRetro has standup-specific icebreaker questions](https://games.teamretro.com/icebreakers/icebreaker-questions/for-standups/) you can share as a link, with no account required for participants.
1. What's one word that describes how you're feeling today?
2. If your current sprint were a weather forecast, what would it be?
3. What's one small win from yesterday, inside or outside work?
4. Tea, coffee, or something else, and why?
5. What song would be the theme tune for your day so far?
6. What's your current browser tab count?
7. On a scale of 1–5, what's your energy like today?
8. What emoji sums up your morning?
9. What is the most unusual kitchen utensil you have?
10. What would your out-of-office message say if you were being 100% honest?
### Sprint planning and backlog refinement
These sessions require focused thinking. A slightly warmer icebreaker helps people arrive mentally before the work begins, without eating into planning time.
1. What's one thing you're genuinely looking forward to this sprint?
2. If this sprint were a film genre, what would it be?
3. What's one assumption you're holding about this work that you'd like to test?
4. What's the most useful thing you learned last sprint?
5. What's one thing you're hoping goes differently this sprint compared to the last?
6. If you could swap one item on the backlog for something completely different, what would you add?
7. What tool or process has saved you the most time recently?
### Sprint retrospective icebreakers
1. On a scale of 1–10, how would you rate your energy this sprint? What would have made it a 10?
2. What's one word you'd use to describe last sprint, and one word for how you want the next one to feel?
3. What's something outside work that went well for you recently?
4. If last sprint were a TV show, what would this episode have been called?
5. What's one thing you learned this sprint, about the work, the team, or yourself?
6. What's one thing you wish you'd said out loud during this sprint but didn't?
7. If you could change one thing about how we work together, what would it be? (Great segue into the retro itself.)
8. What's a small, specific thing another team member did this sprint that you appreciated?
### Team bonding questions for kickoffs and new members
When the team is new or someone just joined, team bonding questions need to do more heavy lifting. Give people a little more time here. These also work well as agile team building activities when you have a full team day or a [new-hire onboarding session](https://games.teamretro.com/use-cases/new-hire-onboarding/).
1. What did you want to be when you grew up, and how close did you get?
2. What's a skill or hobby you have that most people here wouldn't guess?
3. Tell us your name, your role, and one thing that brought you genuine joy this week.
4. What's your remote work superpower?
5. What does your ideal workday look like?
6. What's something you've changed your mind about in the last year?
7. What's the best piece of professional advice you've ever received?
## Agile team building activities and icebreaker games
Sometimes a question isn't enough, especially for kickoffs, team days, or when you want to do something a bit different before a retro. [Agile team building activities](/icebreakers/team-building-games-for-work/) that double as icebreakers give everyone a chance to interact without anyone being singled out.
Some formats that work well:
- **Icebreaker Questions**: choose from a category, create your own, or let AI generate something new. Spin the wheel to see who goes next.
- **Emoji Guess**: emojis appear one by one to reveal a hidden answer. Race to guess it first. Fast, competitive, and works great before a standup.
- **Imposter Syndrome**: everyone gives a one-word clue based on a secret image, but one person saw something different. Use the clues to vote out the impostor.
- **Franken-draw**: each person draws a hidden section of a creature without seeing the others. Stitch them together at the end for chaotic results. Great for team days and kickoffs.
- **Teams Against Agility**: a cheeky card game where you submit your funniest answer to a prompt and the judge picks the winner. Perfect for end-of-sprint wind-downs.
All free, no sign-up needed for participants: just share the link and play at [games.teamretro.com](https://games.teamretro.com/).
### Would you rather: agile edition
1. Would you rather have no sprint deadlines ever, or always have a perfectly clear backlog?
2. Would you rather pair-program all day or work in complete silence?
3. Would you rather have a two-hour retrospective with no action items, or a 10-minute one with three?
4. Would you rather never have another blocker, or have blockers that always resolve in under an hour?
5. Would you rather run every meeting as an async video, or never have another async update?
6. Would you rather be the best estimator on the team or the best facilitator?
### This or that: quick warm-ups
1. Kanban or Scrum?
2. Async standup or live standup?
3. Sticky notes or spreadsheets?
4. Two-week sprints or four-week sprints?
5. Verbose tickets or minimal tickets?
6. Story points or t-shirt sizing?
7. Sprint demo to stakeholders or skip it and ship?
## How to use a question of the day for work
A [question of the day for work](/icebreakers/question-of-the-day/) is a simple recurring ritual: one rotating icebreaker question, answered by everyone, at the start of your regular meeting. Done consistently, it builds the kind of team knowledge that pays off in planning sessions, hard conversations, and the retrospectives that actually move things forward.
The science backs this up: research from [Strategy+Business](https://www.strategy-business.com/blog/Why-the-first-five-minutes-of-a-meeting-shape-its-outcome) shows that the sooner someone speaks at the start of a meeting, the more they contribute throughout. Getting people talking in the first few minutes isn't a warm-up formality. It actively shapes the whole session.
The question of the day works best when it's:
- Owned by whoever is facilitating that day, not always the scrum master
- Drawn from a shared bank the whole team contributes to
- Time-boxed: 60 to 90 seconds maximum
- Optional to answer: passing is always fine
Consider building a simple rotation: each team member picks one question per week, posted in Slack before the standup. Over a few sprints, you end up with a team artifact that reflects your culture. For async teams, this works especially well: posting the question in Slack before the meeting gives quieter members time to think before they're asked to answer live.
## How do you use icebreakers in sprint retrospectives?
A sprint retrospective icebreaker sits right at the start of the retro, before brainstorming begins. The goal isn't entertainment. It's to lower the emotional temperature in the room so people feel safe enough to be honest about what went wrong.
Here's how to run one effectively:
1. **Pick a question that matches the tone of the retro.** If the sprint was rough, go warm and personal. If the team is in a good place, something playful works well.
2. **Answer it yourself first.** This sets the tone and models the openness you're hoping to see.
3. **Use a name spinner to decide who goes next.** TeamRetro's icebreaker tool does this automatically so no one is put on the spot.
4. **Time-box it.** Two to three minutes is usually enough. Set a visible timer and stick to it.
5. **Transition clearly.** Once everyone has answered, acknowledge it and move into the retro. The energy carries over.
## Should scrum teams use icebreakers every sprint?
Yes, but keep them short and varied. The risk isn't overusing icebreakers, it's using the same one every sprint until it becomes a formality people zone out through.
Here's what a healthy rotation looks like in practice:
- Standup icebreaker questions every few days, drawn from a shared bank so it never feels repetitive
- A new sprint retrospective icebreaker each retro, matched to the format you're running
- Deeper team bonding questions and agile team building activities at kickoffs, team days, or when someone new joins
Teams that do this consistently tend to have higher psychological safety, more honest retrospectives, and fewer people "on mute but not really there." It's a small habit with a compounding return.
## Icebreaker for remote and hybrid agile teams
That applies to remote and hybrid teams too, arguably even more so. Without the casual hallway conversations and visible body language of an office, those two minutes at the start of a meeting often carry more weight than they would in person.
Check out our dedicated post on [virtual icebreakers for remote teams](/blog/virtual-icebreakers-for-remote-teams/) for a full list of activities designed for the online space, and our broader guide on [running great retrospectives with remote and distributed teams](/blog/how-to-run-great-retrospectives-online-with-remote-and-distributed-teams/).
### Ideas that work well online
- Visual prompts: "Hold up something on your desk that represents how you're feeling" gets people off mute and on camera.
- Async questions of the day: post in Slack before the meeting so quieter team members can think and respond at their own pace.
- Polls and reactions: "Beach or mountain cabin? Drop an emoji" gets everyone interacting without putting anyone on the spot.
### Remote-specific icebreaker questions
1. What's your current background noise?
2. Show us something in your workspace that you actually like.
3. What's the best thing about working from where you work right now?
4. If your home office had a name, what would it be?
5. What's your go-to WFH beverage, and how many have you had today?
6. What's the strangest thing that has ever appeared on screen during one of your calls?
7. One skill that helps you work remotely that you didn't expect to need:
## Wrapping up: small questions, big impact
Icebreaker questions aren't about forcing fun. They're about creating the conditions for real collaboration. People perform at their best when they feel safe enough to take interpersonal risks, and that starts long before the hard conversations happen.
Start small. Pick one standup icebreaker question or a sprint retrospective icebreaker and rotate it. Watch what happens over a few sprints. The teams with the most honest retros and the healthiest sprint rhythms are almost always the ones that also take two minutes at the start of every meeting to actually connect as people.
Want to go further? Here are the best places to start:
- [How to run an icebreaker](/blog/how-to-run-an-icebreaker/): step-by-step facilitation guide
- [Virtual icebreakers for remote teams](/blog/virtual-icebreakers-for-remote-teams/): activities designed for the online space
- [Quick icebreakers to launch your next retrospective](/blog/quick-but-effective-icebreakers-to-launch-your-next-retrospective/): matched to specific retro formats
- [What makes the best icebreakers for teams](/blog/best-icebreakers-for-starting-conversations-with-online-teams-2021/): the research behind why they work
- [Top 5 tips for running effective icebreakers](/blog/top-5-tips-for-running-effective-icebreakers/): practical tips for facilitators
- [Fun retrospective ideas](/blog/fun-and-easy-retrospective-ideas/): agile team building activities for when you want to mix it up
- [TeamRetro icebreaker tool](/icebreakers/): free tool with name spinner, timer, and AI questions built for agile teams
TeamRetro makes it easy to run collaborative retrospectives with everyone contributing honestly, whether they're in the room or dialing in from the other side of the world. [Icebreakers are built in](https://help.teamretro.com/article/405-the-retrospective-process-icebreaker) so you never have to start from scratch.
💡 Ready to run your next icebreaker? [Try it free at games.teamretro.com →](https://games.teamretro.com/)
---
# Ensuring top-tier data security with TeamRetro: our journey to SOC2 and GDPR compliance.
URL: https://www.teamretro.com/blog/is-teamretro-soc2-compliant/
At TeamRetro, we understand the paramount importance of data security and compliance for our valued customers. We are pleased to announce that we are SOC 2 Type I and Type 2 compliant. You can also get a copy of our [SOC 3 report](/documents/groupmap-soc-3-final-report-2026.pdf).
Specifically: TeamRetro holds a SOC 2 Type 2 report covering Security, Confidentiality, Availability and Privacy. An independent auditor has examined the controls across our policies, product, platform and infrastructure under AICPA attestation standards, and found them effective. You can request a copy of our SOC 2 report via our [Trust Center](https://trust.teamretro.com/).
Achieving this standard with an unqualified opinion provides a third-party industry validation that TeamRetro provides enterprise-level security for customers’ data.
The independent audit was conducted by [Assurance Lab](https://www.assurancelab.com.au/?hsLang=en) following the SSAE 18, ISAE/ASAE 3402, and GS 007 standards. Their accredited reports were provided through their AICPA Partners, a leading association for accounting professionals.
An unqualified opinion on a SOC 2 Type 2 audit report demonstrates to TeamRetro’s current and future customers that TeamRetro manages customer data with adherence to the highest security and compliance standard. Information security practices, policies, procedures, and operations meet the SOC 2 standards for security.
We also uphold the principles of the General Data Protection Regulation (GDPR), providing our customers the choice to host in either the US or the EU.
Here are some of the ways we keep your data secure and maintain your confidentiality and privacy.
## Secure personnel
- TeamRetro takes the security of its data and that of its clients and customers seriously and ensures that only vetted personnel are given access to TeamRetro resources.
- All TeamRetro contractors and employees undergo background checks prior to being engaged or employed by us in accordance with local laws and industry best practices.
- Confidentiality or other types of Non-Disclosure Agreements (NDAs) are signed by all employees, contractors, and others who have a need to access sensitive or internal information.
- We embed the culture of security into our business by conducting employee security training & testing using current and emerging techniques and attack vectors.
- Our policies, internal systems, and access are based on role and function and are designed to ensure we can continue supporting customer needs without compromising data privacy.
## Secure development
- All development projects at TeamRetro, including support services, follow secure development lifecycle principles.
- All development of new products, tools, and services, and major changes to existing ones, undergo a development box review approval to ensure security requirements are incorporated into the proposed development.
- Software development is conducted in line with [OWASP Top 10](https://owasp.org/www-project-top-ten/) recommendations for web application security.
- We maintain documented Systems Development Life Cycle policies and procedures, as well as backups, availability, and change control.
## Secure testing
- TeamRetro deploys third-party penetration testing and vulnerability scanning of all production and Internet-facing systems on a regular basis.
- We perform static and dynamic software application security testing of all code, including open-source libraries, as part of our software development process.
- Our applications are tested on staging environments using anonymized, aggregated, and non-identifying data before deployment and undergo a formal approval process.
- We employ a web application firewall and security management platform to enable continuous and ongoing application protection.
## Cloud security
- TeamRetro’s cloud ensures security with complete logical customer isolation in modern architecture. TeamRetro’s cloud leverages the native physical and network security features of the cloud service and relies on the providers to maintain the infrastructure, services, and physical access policies and procedures.
- All data is also encrypted at rest and in transmission to prevent unauthorized access and data breaches.
- We implement role-based access controls and the principles of least privileged access and revoke access as needed.
The full TeamRetro Privacy Policy is published on the TeamRetro website at [teamretro.com/privacy](/privacy/) and addresses how personal information and intellectual property are collected, used, retained, disclosed, disposed of, and anonymized.
The Privacy Policy also provides details of the assigned Privacy Officer, assigned EU and UK Representative, and contact information. Further information and requests for a Data Processing Agreement can be found at [teamretro.com/gdpr](/gdpr/).
Enterprise clients interested in receiving a copy of our SOC 2 Type 2 or Type 3 report can do so at [teamretro.com/security](/security/).
## What is TeamRetro?
TeamRetro is an enterprise-ready online retrospective tool for remote teams. Our guided retrospectives and health checks ensure productive and effective meetings – every single time. We’re SOC 2 Type 2, GDPR compliant, and ready to help agile leaders and teams drive continuous improvement.
---
# Easy and fun remote retrospectives: insights from World Retrospective Day 2020
URL: https://www.teamretro.com/blog/making-the-most-out-of-remote-retrospectives/
## Celebrating the power of remote retrospectives
World Retrospective Day 2020 is a volunteer-based, globally coordinated effort to share stories and insights to improve Agile retrospectives. Two events held were the World Retrospective Day Lightning talks by Remote Forever and the Agile Club of Egypt monthly meetups. As teams become increasingly remote, running online team meetings that empower and drive continuous improvement is a key focus for Scrum masters. While there may be reduced travel costs and time, there are increased challenges in how remote meetings, especially retrospectives can be best run to ensure engagement and a sense of connection.
[TeamRetro’s](/) CEO and Co-Founder, Jeremy Lu, spoke at both events on the topic of **“Making the most out of your remote retrospectives.”** We share some of the key messages as well as learnings and insights from both the events here.
## The pros and cons of running remote retrospective meetings
Going digital does mean adjustments to how team meetings run. But there are some neat benefits. Removing production blocks, reducing bias and allowing independent brainstorming and voting for actions can improve the quality of data as well as build psychological safety. Time that would have been spent writing up reports, manual collation and recording can now be spent on team relationships or giving more time to deep dive into discussions that matter.
On the other hand, reliance on an individual’s internet set up, security and the lack of accountability can negatively impact team trust. The increase of social dissonance as we lose the physical cues means that the role of the scrum master as the conductor of the social orchestra becomes evident. Building team culture from planned and explicit activities to setting ground rules for meeting hygiene are good practices to help to start to overcome these cons.
At the same time, irrespective of whether or not the team is distributed, co-located, remote or some blended hybrid, individuals in a team want:
- to be heard
- to be valued
- to be guided
- to feel safe
- to be resourced
- to be grown
So how can the humble retrospective play its role in helping address those team needs? Here are some ideas.
### 1. Develop a team social contract
Setting the right focus and tone before you begin your retrospectives goes a long way to creating an engaging, safe and productive space for team members to speak up. The culture, group expectations, and agreed ground rules are more likely to stick and have an impact if they are created together and made visible.
We grabbed a couple of balloons and all wrote down things that we heard but did not feel like it was useful for a meeting. We then “popped” these balloons in an audible and significant way if we noticed these behaviors and words in a meeting. We then wrote down a list of guiding behaviors that our team wanted to use as part of our retrospectives as well as any team meetings and frame this when we kick start our remote retrospectives. In fact, it appears on our remote retro.
If you don’t want to go that far, then you can always rely on the Agile Prime Directive. However, addressing basic meeting etiquettes such as turning on cameras and audio, call signals to slow down, speed up, or make comments and other rituals can help make meetings more successful. If accountability and social dissonance are common in your meetings, then having processes like round-robin discussions, call-out facilitated conversations or liberating structure formats can help build that team engagement.
**Takeaway**: Whether you do it formally or more of an informal ritual, understanding and managing the social contract for your team builds trust, psychological safety, and clear online meeting retrospective etiquette.
**2. Pick the right retrospective format to fit your purpose – fun? easy? focussed?**
With so many different retrospectives formats and questions out there, Scrum Masters are spoilt for choice when it comes to variety. However, to get the most out of the retrospective, it was suggested that the choice of retrospective format requires intention, thought, and consideration so that it serves the purpose of the meeting.
This does mean the format will change from time to time which in its own right will lend itself to reducing the repetition fatigue. It will also mean that you are entering the meeting with intent and can focus the conversation.
Take this example below.
This team used the Mad Sad Glad approach to kick off their initial retrospective. This format has a more personal touch and requires people to consider their emotional responses to the last sprint. It helps to air out any potential issues and address any emotional barriers to help teams move past the storming stages of team formation.
The next few retrospectives focused more on action-based, focusing on a Stop, Start, Continue retrospective and the StarFish retrospective. These formats lend themselves to more action-based brainstorming and allow teams to consider time trade-offs between tasks.
As teams transitioned to working from home, they then focussed on changes in the process and how to work from home to talk through what they needed to do in a remote environment, followed by a standard agile retrospective at the end of the year.
Using the 4L retrospective next allowed them to reflect on the activities to date to share learnings as well as what they have liked and longed for. Finally, a FLAP (Future considerations, lessons learned, Accomplishments and Problem areas) was a futurespective process to help the team decide what they wanted to see going forward.
Of course, you can always create your own set, or choose topics that are seasonal or interest-based. There’s also the option to create retrospectives based on interest, festive seasons, famous TV shows, or a shared passion.
**Takeaway**: While a variety of retrospective formats is great to break meeting fatigue cycles, choosing one that is aligned with your team and product’s current state can improve the focus, intention and outcomes of your retrospective meetings.
**3. Power up your retro flow.**
Beyond splitting groups into smaller breakout rooms, there are some additional ways that you can level up on your team meetings.
At the start of each retro, run a short, sharp but friendly activity that allows people to check-in. Share a word, or facial expression that demonstrates how you felt about the last sprint, or even what was the last thing that made you smile is a great way to kick start the meeting. Remind them about the prime directive, social contract and remind them of why they are here to do.
You can assign roles so that people can all contribute. The Co-pilot can help manage the tech and meet goals. The time police keep the meeting flowing and reminds people on time as they start to overrun. The energy monitor might run a quick check-in during the meeting or get a sense from people as to how the meeting is going and the Action Avenger can call out if there are actions that are not being discussed or captured.
Using a range of facilitation methods that allow people to contribute throughout the process keeps people engaged and lets you sense the vibe of the room. For E.g. using reactions on comments helps to capture sentiment, and the pass the baton pattern means that one participant can pick the next speaker.
Finally, if your meetings are longer than an hour then include a planned break. It just gives people time to breathe and re-calibrate. Take a break away from the screen or run an activity with the team that’s fun and can lift the energy. We call for lights out which means mics and cameras on (music on if they want) for a little focus time before coming back together.
**Takeaway**: Team engagement strategies through powering up the process flow at the very start and throughout the meeting can lift energy and accountability.
**4. Experiment with different time-box recipes.**
One way we can make sure meetings don’t run overtime is to use time-boxing. There’s a [countdown timer](/blog/timeboxing-for-scrum-teams-and-successful-retrospectives/) in TeamRetro for each stage that can be used for example to give people a sense of how much time is left, as well as the I’m finished button to give you the heads up when people are ready to move on.
Assuming you are running an asynchronous 60-minute meeting, here’s our time box recipe that seems to work.
It may however be better to think of this in terms of a base recipe rather than a formal guide. Much like the pizza dough, the final pizza flavor is the combination and quantity of ingredients you decide to add on. If you think there’s a greater need for team bonding, then check-ins, appreciations, and check-outs might be important. Data can be gathered before the meeting asynchronously. Grouping of similar ideas can be done before the meeting and then ideas are voted on when read for discussion. Alternatively, if there is less need for rapport building, then this might be used more on building consensus for action items. For self-organizing teams, allow more time for them to group ideas that have come up. If there are lots of comments, then have them work in smaller groups under specific sections. While this might be good for a 60-minute meeting, you can simply change the ratios for a longer session.
**Takeaway**: The end of the meeting time is the main constraint for teams who like to finish on time with clear outcomes. Trying out new time-box recipes can help keep meetings on track and be a good marker for guiding conversations.
**5. Make your retrospectives easy, fun and human!**
Remember bring a pet day? Crazy shirt/hat day? Share a meal day? Who says we can’t do that online? Adding a little fun and team-building activity can be a good way to relieve stress, learn a little more about your team and get insights you won’t find in your standard retrospective. Here are a few things we heard teams have been doing while remote. (Some of our teams actually do this at the end as a reward for a good retrospective.)
- Use mood checkers.
- Play a game – agile or just for fun.
- Watch a movie together on Discord.
- Run a team-building activity — for example, if you are in a plane that crashed into a desert, what 10 items you want with you in order to survive.
- Story or picture telling: try asking everyone to tell a story about something, even something as small as a cup or a pair of shoes! Or to take a picture of something near them to share
- Guess the song: test your scrum masters singing capabilities by asking them to sing songs for the team to guess!
- Solve a random problem that someone else in the team has.
- Share a recipe that everyone tries at home and tastes.
**Takeaway:** Encourage compassion. It is not easy to move to a fully online team retro or remote working. We as humans are social beings after all. Having some fun, social activities can make it easier to build bonds and empathy that can make your retrospectives more meaningful and effective.
## Excited to level up your remote retrospective?
We hope these insights provide a little inspiration. If you have others you’d like to share or would just like to swap notes, ask for advice or find out more, [just get in touch!](/contact-us/) We’d love to hear from you. TeamRetro.
---
# Meet trAI, your in-meeting AI assistant
URL: https://www.teamretro.com/blog/meet-trai-your-in-meeting-ai-assistant/
Facilitating a meeting well and keeping an accurate record of it pull in opposite directions. You either follow the discussion or you write it down, and whichever you pick, the other one suffers.
trAI is our answer to the second half. It's TeamRetro's AI assistant, and the thing that makes it different from most AI features is where it lives: in the side panel of the meeting you're running right now.
## What it actually does
trAI works in retrospectives, health checks, estimation sessions and [standups](/blog/daily-standups-in-teamretro/). You type what you want in the panel, and it does the admin while you keep facilitating.
It reads:
- Summarize this meeting, or a past one
- Search across your team's feedback by topic or theme
- Show health-check results and trends over time
- Look up previous estimation sessions
- Show who's on the team and how the team has been tracking
And it writes, on your behalf:
- Add ideas to the board, vote on them, post comments, give kudos
- Create, update, complete or reassign actions, and show what's overdue
- Add or update working agreements
- Park a topic for the next retro
The prompts that earn their place are the boring ones. "Summarize the themes so far" in a retro, so you can check the team agrees before moving on. "Compare these results to last time" in a health check, while the radar is still on screen. "How did we size work like this before?" in an estimation session, so a contested number has some history behind it instead of just louder opinions.
## What it can't do
What trAI can't reach is what decides whether you can hand it to a whole team.
trAI acts as you, with exactly your permissions. It can never see or change anything you couldn't see or change yourself, so turning it on doesn't widen anyone's access to anything.
Three hard limits are worth knowing before you hand it to a team. It can't reveal who wrote an anonymous idea, comment or survey response — anonymity survives the assistant. It can't reach the internet, or any system outside TeamRetro. And it won't follow instructions written inside meeting content: if someone types "ignore your rules" onto a sticky note, that's just a sticky note. It acts on what you type in the chat, and nothing else.
Each conversation is private to the person who opened it. It acts only when you ask it to, and everything it creates stays visible and editable like any other item in the meeting — so if it captures an action badly, the team can see that and fix it. It's doing the typing, not making the decisions.
Your meeting content is processed briefly to answer you, and is never stored by the model or used to train it. trAI runs on Claude Sonnet via AWS Bedrock; we don't build or train models ourselves. The full position, including what runs where, is on [responsible AI](/responsible-ai/).
## Who decides whether it's on
Three answers, because "is it on for the account" and "may this role use it" are different questions:
- **It starts on — except on Enterprise.** trAI is on by default on trial and paid plans. On Enterprise accounts it is off by default, so your organization can review it before rolling it out.
- **Account owners and admins** hold the account switch under **Settings → AI & Features → AI Assistant**.
- **Team administrators** choose which roles may use it under **Team Settings → Roles & Permissions → Use the AI assistant**. Team members are allowed by default; guests can't use trAI at all.
## trAI or the MCP server?
We now ship two ways to ask an assistant about your teams, and the difference is simply where you're standing.
trAI is inside the meeting, for the person facilitating right now. The [TeamRetro MCP server](/mcp/) is for the rest of your week: it connects Claude, ChatGPT, Copilot or Gemini to your teams so you can ask from the assistant you already work in — which teams have a retro overdue, what's still open from last sprint, how health is trending.
Most teams end up using both, and they don't overlap much in practice. One is a facilitation tool; the other is how you catch up on Monday morning.
## Try it
trAI is in the side panel of your next retro, health check, estimation or standup session. There's a fuller tour, including the admin controls and the example prompts above, on the [trAI page](/ai/).
---
# Feature spotlight: define your retrospective templates
URL: https://www.teamretro.com/blog/new-define-your-retrospective-templates/
Here at [TeamRetro](/), we’re excited to share features to make your online, hybrid or face to face retrospectives even more organized, accessible and creative.
We’re pleased to introduce a feature where you are able to define your own retrospective templates either for your team, or at an organizational level for all teams! Save your favorites in your template library that you can then use to run again.
Let’s find out how this works.
### Create retrospective templates for a team
This feature is applicable for one team who might want to creatively customize their own retrospective but is only relevant or applicable to just that one team.
For example, we created an [Avengers themed customized retrospective template!](/blog/3-nifty-ways-to-keep-your-retros-fun-and-exciting/)
Creating Icons from Icons8, we went about representing different aspects of our online retro. Here’s what we came up with.
- **Captain America**: What do we want to protect?
- **Iron Man**: What experiments should we try?
- **Hulk**: What do we want to change?
- **Black Widow**: How can we improve our team?
- **Thor**: What are our biggest strengths?
- **Hawkeye**: What support do we need?
#### You can create your own team retrospective templates when you create a new retrospective, or under your team settings.
### Create and share retrospective templates for the organization.
This feature is very handy if you would like your teams across the whole of your organization to use the same retrospective templates so that it is consistent or aligns with your culture, language and values.
If you create an organizational template, these will be accessible by all users associated with your organization’s accounts. It’s a creative way to share the love of good practice, successful retrospectives and even offering choice and alternatives for your colleagues and fellow scrum masters.
#### You can create your own organizational retrospective templates when you create a new retrospective, or under your organizational settings tab.
### Questions about our new feature?
Thank you to our community of TeamRetro users for this suggestion. This idea first came from a financial institution in France who had an extremely creative team. They created custom templates including the “Three Little Pigs” asking what would fit under a House of Straw, a House of Sticks and a House of Bricks.
If you have any questions about this new feature, [reach out to us anytime.](/contact-us/)
---
# 12 new retrospective ideas to break the rinse and repeat cycle
URL: https://www.teamretro.com/blog/new-retrospective-ideas-to-break-the-cycle/
We're halfway through the year. If your retrospective has settled into the same three columns, the same five people talking, and the same quiet nod at the end, you already know what next sprint's retro will sound like. That predictability is the problem. When a team can guess the questions, they start giving you guessable answers, and the honest, awkward, genuinely useful stuff never makes it onto the board, let alone the action list.
So I went looking. As our team's Scrum Master, part of my job is to keep the room alive, and over the last few months our team has worked through dozens of different retrospective formats from the [retrospective template library](/retrospective-templates/). Most were fine. Some fell flat. But a handful genuinely broke the cycle: they changed the questions, changed who spoke up, and surfaced things our usual format never would. These are the ones we have handpicked to refresh the palette as they say.
One thing up front, because it matters: **this isn't about making your retro silly.** A themed board or a playful prompt isn't the point; it's simply the on-ramp. The goal is to lower the stakes just enough that people feel safe saying the real thing, in a format their brain hasn't already pre-answered. Fun is the mechanism; honest improvement is still the outcome.
## Why the same retro stops working
There's nothing wrong with [Start, Stop, Continue](/retrospective-templates/start-stop-continue-retrospective/) or [Mad, Sad, Glad](/retrospective-templates/mad-sad-glad-retrospective/). They're classics because they work. But any format, run on repeat, eventually trains the team to autopilot. People learn the shape of the answer the format wants and give you that, not what they actually think. This isn't just my experience: Mike Cohn warns that the same thing happens to any retro [conducted "the same way each and every time"](https://www.mountaingoatsoftware.com/blog/overcoming-four-common-problems-with-retrospectives), and Retromat creator Corinna Baldauf [puts it plainly](https://retromat.org/blog/why-do-we-vary-activities/): "if you keep asking the same questions, you will keep getting the same answers."
So here are the formats that did the unsticking for us. Each links to a ready-to-run template. Pick one for your next retro and see what surfaces. If the cycle is the format rather than the ideas, [retrospective games](/guides/retrospective-games/) groups 20 of them by the problem each one solves.
## Break the format, not just the questions
Changing the *questions* helps a little. Changing the *format* helps a lot. A new structure makes everyone approach the sprint from an angle they haven't rehearsed, which is exactly when the interesting stuff falls out. It's the same reason a change of scenery or a fresh metaphor unsticks a conversation: the brain can't coast. Atlassian makes the same case: [vary the technique, or retros go stale](https://www.atlassian.com/blog/teamwork/revitalize-retrospectives-fresh-techniques) and slide into glorified status meetings. Professional Scrum Trainer Stefan Wolpers files the never-changing retro as a named [anti-pattern](https://age-of-product.com/sprint-retrospective-anti-patterns/) he calls "Groundhog Day". And Aino Corry, author of [Retrospectives Antipatterns](https://metadeveloper.com/retrospective-antipatterns/), counts running every retro the same way among her antipatterns too; at the 2026 Online Scrum Master Summit she called breaking out of it "escaping the rinse".
### 1. Working, Not Working
The [Working, Not Working retrospective](/retrospective-templates/working-not-working-retrospective/) strips everything back to two questions. No softening, no "glad", no metaphor, just *what's working* and *what isn't*. We ran this after a messy sprint where people were dancing around the real issue, and the bluntness of it gave everyone permission to be direct. Best when you want honesty over nuance and you're short on time.
### 2. KALM: Keep, Add, Less, More
[KALM](/retrospective-templates/kalm-retrospective/) is the upgrade for teams who've outgrown Start/Stop. Instead of a binary "do it or don't", you get four dials: **Keep**, **Add**, **Less**, and **More**. That "Less / More" axis is the magic: most team problems aren't "stop doing this entirely", they're "we're doing too much of this and not enough of that". It surfaces the dial-turning conversations that Start/Stop forces into all-or-nothing.
### 3. What? So What? Now What?
[What? So What? Now What?](/retrospective-templates/what-so-what-now-what-retrospective/) is built to fix the most common retro failure: lots of discussion, no action. You walk the team through three steps (what happened, why it matters, and what we'll do about it) so every observation is pushed toward a decision. If your retros keep generating the same complaints sprint after sprint without anything changing, this is the format that closes the loop.
### 4. Speed Car
The [Speed Car retrospective](/retrospective-templates/speed-car-retrospective/) frames the sprint as a car: engines push you forward, parachutes hold you back, and there's a cliff ahead if you ignore the risks. It sounds light, but the metaphor does real work: people who'd never say "our process is slowing us down" will happily attach a parachute to the car. Great for surfacing friction without anyone feeling like they're pointing fingers. Unlike the [Sailboat retrospective](/retrospective-templates/sailboat-retrospective/), the key focus here is putting the team in the driver's seat. They accelerate, turn the wheel and move in the right direction... or not.
## Retros for the mid-year reset
June is a natural checkpoint. Goals set in January have either drifted or quietly died, energy is different from where it started, and nobody's stopped to notice. These three are built for the halfway moment.
### 5. Mid-Year Goal Check-In
The [Mid-Year Goal Check-In](/retrospective-templates/mid-year-goal-check-in/) is the obvious one to run this month, and most teams skip it. It pulls the team back to the goals you set at the start of the year and asks the honest questions: what's on track, what's slipped, and what's no longer worth chasing. Half a year of hindsight makes this conversation far more useful than it would've been in Q1: you're working with real evidence, not optimism.
### 6. Energy Levels
The [Energy Levels retrospective](/retrospective-templates/energy-levels/) takes the team's temperature instead of the sprint's. Where's energy high, where's it draining away, and what's quietly burning people out? At the mid-year mark, when fatigue tends to creep in unannounced, this one catches the human signals that a velocity chart will never show you. Run it anonymously and you'll get the truth.
### 7. Appreciation Round
The [Appreciation Round](/retrospective-templates/appreciation-round-retrospective/) is the simplest reset here, and the one teams underrate the most. Everyone calls out something a teammate did that made a difference. It's not filler: naming good work out loud refills the tank, builds the psychological safety that every other retro depends on, and reminds a tired team why the work matters. A great one to open a heavier session with.
## Retros for the AI era
The way teams work has shifted fast, and the retro is a good place to make sense of it. These two are genuinely current; they didn't exist as conversations a couple of years ago.
### 8. AI Agents
The [AI Agents retrospective](/retrospective-templates/ai-agents-assemble-retrospective/) gives the team space to reflect on how AI tools and agents are actually landing in your workflow: what's saving real time, what's creating new kinds of rework, and where the team needs clearer guardrails. If "should we be using this more, or less?" keeps coming up in side conversations, put it on the board.
### 9. AI Evolution
The [AI Evolution retrospective](/retrospective-templates/ai-evolution-retrospective/) takes the longer view: how the team's relationship with AI has changed over time, and where it's heading. It's a good periodic check-in for teams who've moved past experimenting and want to be deliberate about how these tools fit their process.
## Themed formats that lower the stakes
This is where the "fun" lives, and where I'll repeat the caveat. A theme isn't the point; it's a way to get a guarded team talking. Wrap a familiar reflection in an unfamiliar story and people drop their meeting-face. Pick a theme your team will actually enjoy, keep the questions real, and these earn their place.
### 10. Studio Ghibli Journey
The [Studio Ghibli Journey retrospective](/retrospective-templates/studio-ghibli-journey-retrospective/) frames the sprint as a gentle adventure: the companions who helped, the obstacles along the way, the small moments of wonder. The calm, reflective tone is the opposite of a blame session, which makes it surprisingly good for teams that need to talk about a hard stretch without it turning tense.
### 11. KPop Demon Hunters
The [KPop Demon Hunters retrospective](/retrospective-templates/kpop-demon-hunters-retrospective/) leans into a bit of pop-culture energy: the demons (problems) the team faced, the powers that helped you win, and the encore you're planning next. It's high-energy and a little ridiculous in the best way, ideal for a team that's been heads-down and needs the room to lift before it can reflect.
### 12. Among Us (Agile Edition)
The [Among Us retrospective](/retrospective-templates/among-us-agile-edition-retrospective/) reframes the sprint around tasks completed, "impostors" (the hidden blockers that sabotaged your flow), and emergency meetings (the moments you had to regroup). The game framing makes naming blockers feel collaborative rather than accusatory: you're hunting the impostor together, not blaming a person.
**And that's just the start.** Between themed boards, structured formats, and seasonal one-offs, there are 275+ ready-to-run options in the [retrospective template library](/retrospective-templates/), so you can keep rotating long after these twelve.
## How to introduce a new format without losing the room
A new format only works if the team's with you. A few things I've learned the hard way:
- **Say why.** Open with one line: *"We're trying a different format today to shake loose some new thinking."* People go along with novelty far more easily when they know it's intentional, not a gimmick.
- **Match the format to the moment.** A bruising sprint wants [Energy Levels](/retrospective-templates/energy-levels/) or an [Appreciation Round](/retrospective-templates/appreciation-round-retrospective/), not a comedy theme. A coasting team can handle something playful. Read the room first.
- **Keep the questions real.** The theme is the wrapper; the reflection underneath should be as serious as ever. If a prompt is only fun and surfaces nothing useful, cut it.
- **Use anonymity for the honest stuff.** A fresh format lowers the social barrier; anonymous input lowers it further. For anything touching workload, trust, or morale, let people [contribute without attribution](/retrospectives/) so you get the real picture.
- **Don't change every single time.** Novelty works because it's a break from the norm. Rotate formats every few sprints, not every sprint, or the "new" one becomes the new autopilot.
## Keeping it fresh *and* serious
Here's the thing I want to leave you with. Bringing energy to a retro and taking the retro seriously are not opposites; they're the same job. A team that's relaxed, curious, and a little bit entertained will tell you things a tense, bored team never will. The format's job is to create that safety; your job as facilitator is to turn what surfaces into real, owned action.
So this mid-year, break the cycle. Pick one format off this list that your team would never expect, run it at your next retro, and watch what comes out when people aren't on autopilot. Then do the serious part: capture the actions, assign the owners, and follow through. That's the whole game: a fresh way in, a serious way forward.
## Frequently asked questions
**How often should you change your retrospective format?** Every few sprints, not every sprint. Variety works because it breaks the routine; change too often and the variety itself becomes the new autopilot.
**Do fun retrospective formats actually improve outcomes?** Yes, when the questions underneath stay serious. The playful wrapper lowers the social barrier so people share honestly; the reflection and the action items are still the point.
**What's a good retrospective to run at the mid-year point?** A Mid-Year Goal Check-In, ideally paired with an Energy Levels retro to catch fatigue before it spreads.
**How do you introduce a new format without resistance?** Say why you're changing it, match the format to the team's mood, keep the questions genuine, and use anonymous input for the sensitive stuff.
## Break your team's retro cycle this month
You don't need a hundred new ideas; you need one that your team won't see coming. Browse the [retrospective template library](/retrospective-templates/), pick a format that fits where your team is right now, and run it at your next retro. Fresh way in, serious way forward.
---
# Nine top agile retrospective ideas and games to keep your team engaged
URL: https://www.teamretro.com/blog/nine-top-agile-retrospective-ideas-and-games-to-keep-your-team-engaged/
We all lose focus from time to time. As retrospectives get repeated and stale, people start to hit auto-pilot and get side-tracked or distracted in the retrospective. They start getting vague with their responses, put on their grumpy pants, or simply disengage altogether due to boredom.
That’s why we have pulled together this list of nine of the best agile retrospective ideas and games to help keep your team engaged. These can help to support team connectedness, safety and fun. They bring focus to the room without singling anyone out. They can even help bring some fun to your meeting!
For the full set grouped by the problem each one fixes, see our guide to [retrospective games](/guides/retrospective-games/).
### 1. Energy levels
Before the team jumps into the retrospective, ask everyone to call out, type or use their hands to indicate their current energy level. You can quickly see how the team feels and what energy is being brought into the retrospective.
5 means you are fully charged and ready to go. 1 means you are here but drained and running flat.
This game is a perfect warm up for the [Energy Levels](/retrospective-templates/energy-levels/) retrospective idea which helps people share what charged them up, and what drained them from the last sprint. For more quick warm-ups before a retro, browse our [free icebreaker games](https://games.teamretro.com/games/).
This game can highlight what is motivating your team. Their responses give you insight into things that give them energy so that you can aim to replicate this going forward. Likewise knowing what they need to re-charge can set the next sprint off in the right direction.
### 2. Statement orbit
Statement Orbit is a fun retrospective game that can get an agile team moving…literally! This can be used interactively for both online and in-person meetings.
An object is placed in the middle of the room with the team members standing around it. If you are online, the camera can act as the object.
Statements are read aloud, with team members invited to move toward the object if they agree with it and away from the object if they disagree. The size of the step they take should reflect the degree to which they agree or disagree.
Here are some examples or you can have people go round and call out their own statement.
- The last sprint went off without a hitch.
- Everyone was able to complete their tasks to the right quality and at the right time.
- We were able to demonstrate improved velocity.
- There were no errors, rework or impediments.
- We worked well as a team and created value.
- We acted according to our Scrum Values.
- We are working and acting according to our team agreements
As people move back and forth, this lets you see where people are far apart. This can be followed up with a discussion.
Then, you can align this with a retrospective theme. For example, you can build team cohesion and battle epics with the [Superhero retrospective](/retrospective-templates/superhero-retrospective/). If values and team agreements are not being experienced, then the [Scrum Values retrospective](/retrospective-templates/scrum-values/) may well be the way to go.
### 3. Sailboat retrospective
If your last sprint left the team feeling all at sea and hoping for some plain sailing with their next one, then get onboard with this fun retro idea. The [Sailboat](/retrospective-templates/sailboat-retrospective/) retrospective is designed to help your crew reflect on their last sprint, and plot a successful course going forward. This can help them remember the vision and plan ahead based on what they have already learned and to develop a more positive mindset.
Like all good sailors, they need to consider their conditions. The wind (what moves them forward), rocks (the risks they may face), the sun (what makes them feel good), anchors (what can slow things down or stop them completely) and, of course, where they are heading.
This retrospective idea can be useful when your team is having trouble seeing the big picture or are kick starting off a new epic or project. It helps them focus on their goal and plot a course to achieve it!
### 4. Starfish retrospective
If you are finding your retros a bit of a talk fest, with no action or commitment, then this action oriented format might be the way to go.
The [Starfish](/retrospective-templates/starfish-retrospective/) retrospective idea helps teams to think about the degree to which actions and activities are most effective in creating value and team cohesion.
It’s different from more traditional retro ideas because rather than just listing down what happened in the last sprint, the team is encouraged to be more specific and think about practices that are generating value. It can also help the team members gain insight into each other’s perception of those practices.
As well as thinking about what they should start and stop doing, the team thinks about what they could do more and less of. They also define what they should keep doing. This way, the Starfish retrospective idea can help a team decide which of their practices should have more or less energy directed toward them. It can be a great way of helping a team step away from unhelpful practices without them feeling like they are going cold turkey.
It’s best to run a Starfish after a few retrospectives have happened. This way the team has a period of activity to look back on and compare.
### 5. ESVP
How do you ask people how they are feeling without asking people how they are feeling?
You run an ESVP.
The ESVP is designed to engage and focus on those involved in the retro. At the same time, it gains insight into the participants’ attitudes toward the agile retrospective meeting itself.
ESVP stands for ‘Explorers, Shoppers, Vacationers and Prisoners’. Participants indicate which of four personas they most relate at that point in time. They are invited to choose from –
An explorer – Will dive in and discover new things
A shopper – Will see what can be procured
A vacationer – Will relax and switch off
A prisoner – Does not want to be there
Setting the stage with an ESVP can help a Scrum Master gauge the attitudes of the people in the room. This lets them shape their next steps and helps everyone make the most of their meeting time.
An ESVP can give everyone insight into the current motivations of the group. This means you’ll get more out of your meeting because you can see the attitudes and expectations of the people there and adjust your approach.
### 6. Rose bud thorn
Roses aren’t just for Valentine’s Day or special occasions. The sweet scent of the rose can sometimes mask the thorns that serve to protect them.
The [Rose, Bud, Thorn](/retrospective-templates/rose-bud-thorn-retrospective/) retrospective idea plays on this metaphor. It helps a team identify the positive outcomes (Rose), the opportunities (Bud), and the pains (Thorn) from their last sprint.
This game reminds your team to approach challenges as manageable obstacles that come along with delivery value. Getting past the thorns, nurturing buds and then harvesting the blooms is the goal of this game.
### 7. The retro anti-pattern bingo
This game has the team being made aware of things that can negatively impact a retro and to be on the active look out for them during a retro. Inspired by [Ben Linders](https://www.benlinders.com/), this game could be just the thing to help address issues without making people feel singled out.
Each team member is given a bingo board that includes retro anti-patterns. This includes things like distractions, jumping to solutions, blaming the process, lack of action items. The center square is a wild card, or you can add your own anti-pattern.
As the team goes through the retro, they can mark off things they noticed on their board. At the end of the retro, people can see if they scored 5 in a row. You could have people shout out “Bingo!” during the game but this could also serve as a distraction.
This retrospective game is great for helping teams reset their behaviors, or simply introduce good meeting etiquette. It can also be a fun way to teach new teams what habits they should avoid.
### 8. Sherlock retrospective
If you have a team of mystery buffs, try the [Sherlock](/retrospective-templates/sherlock-retrospective/) retrospective idea for your next meeting. It’s especially helpful if the team needs to unravel the cause of a particularly puzzling sprint. Engaging a team might not always be about fun. It could be the problem solving, logical aspects and feeling the sense of achievement when solving a tough problem.
The team looks at their last sprint like a mystery. They list what cases were closed, and the clues that helped them. They define what they found to be elementary, as well as what puzzles remain.
This way, like Sherlock, team members are encouraged to put emotion aside and just look at the facts. This easy retro can be a helpful way of encouraging teams to unpack tricky problems with calm and logic as they generate ideas.
### 9. GIF me a break!
This retrospective game is simple, fast and fun. It works especially well with remote online agile teams.
Just before the team jumps into the retro itself, each person is asked to find and share a GIF that represents the last sprint. The GIF they share could be quite topical, or a classic from [Giphy](https://giphy.com/). Each person picks a gif and then shares their screens to explain why they picked that gif.
GIF Me a Break is a fun way a Scrum Master can gain insight into what the team thought of the last sprint without having to ask them directly. It’s also a way of injecting some fun into the meeting following a particularly challenging sprint.
## Bonus tips for running great retrospective ideas and games
**Keep them inclusive**
When choosing a retrospective idea make sure it’s one the whole team can enjoy. Keep language, accessibility and people’s backgrounds in mind. The simplest way of doing this might be to ask them which one they’d like to try.
**Book end the retro with fun**
Using games is a great way to build team connectedness. Making sure they are limited to the start and end of the retro is a great way to make sure they don’t become distracting and that your retrospective is still meaningful and worthwhile.
**Timebox**
Whether it be a great retrospective idea or fantastic game, timeboxing the game is an important principle in agile that can also be practiced while still making the retro valuable and fun.
**Keep it relevant**
Picking a theme, topic or issue that is relevant to your team is what keeps them engaged. Don’t simply rely on a theme. At the end of the day, making sure that people are able to relate to the discussion is what will drive engagement.
## Want more?
Check out our [Scrum Master’s Retrospective Guide](/guides/scrum-masters-retrospective-guide/) where we look at [what agile games teams play to help them learn and grow](/guides/scrum-masters-retrospective-guide/agile-games-facilitate-team-building/). You can also head to our [agile blog posts](/blog/) for some [fun and easy retrospective ideas](/blog/fun-and-easy-retrospective-ideas/).
TeamRetro lets you create engaging and effective Agile Retrospectives. Create and customize your own templates, explore team happiness and create actions for continuous improvement.
[START A RETROSPECTIVE](https://secure.teamretro.com/login/new?cc=www-blog)
---
# Online retrospective games vs formats: what actually works
URL: https://www.teamretro.com/blog/online-retrospective-games/
A retrospective game isn't there to be fun. It's there to lower the guard that keeps remote teams polite, vague, and quiet, so you get the honest signal a retro depends on.
That's why online retrospective games matter more than they look. On a video call, the usual cues that pull people into a conversation are gone. The confident talkers fill the silence and the quiet thinkers check out. A good game cuts through that, giving everyone the same low-pressure way in and surfacing the issues that would otherwise stay unsaid.
But there's a catch: most of what gets called a “retrospective game” is really just a format with a nice picture on it. This guide draws a clear line between the two. On one side are the proven formats that structure most retros. On the other are the genuine games, the ones with an actual mechanic, that get a quiet team talking. We'll cover both, when to reach for which, and where even a good game hits its limit.
## Games vs. formats: why the difference matters
A quick word on labels first, since they get used loosely: retrospective games, formats, techniques, templates, often interchangeably. Here's how this guide uses them: a **format** is the structure (the prompts people respond to), a **template** is that format pre-built and ready to run, and a **game** adds a mechanic, something like a surprise, a reveal, or a guess, that changes how people behave. So Sailboat is a format and a template, but calling it a game is generous: you're still filling in columns. Don't confuse any of this with [agile games](/blog/the-best-agile-games-for-building-teams-learning-and-creativity/) either. That's a broader category of activities spanning the whole delivery process, and its own topic. Nor with [team building games for work](/icebreakers/team-building-games-for-work/), which are about bonding and trust rather than reflecting on a sprint.
Why does it matter? Left to their own devices, most retros default to open discussion. Someone asks “So, how did the sprint go?” and waits. A long pause, then the same two people talk while everyone else stares at their thumbnail. The full reference list lives in our guide to [retrospective games](/guides/retrospective-games/), grouped by the problem each one fixes. This post is about which of them earn the name.
A format replaces that blank prompt with structure. A game goes further: it gives people something to react to before they've had time to self-edit. Both have their place, and the payoff is the same: better data. Retros only work if people tell the truth about what's slowing them down, and online that rarely happens by accident. The rest of this guide is about making that happen on purpose.
## Start with a solid retrospective format
Most online retrospectives should still start from a proven format, the reliable structures your team already recognizes. For a routine sprint they're all you need to get a useful conversation going, and the choice matters less than people think: [Mad, Sad, Glad](/retrospective-templates/mad-sad-glad-retrospective/) when the sprint was rough, [Start, Stop, Continue](/retrospective-templates/start-stop-continue-retrospective/) when you want action items by the end of the hour.
We keep the full list, grouped by the problem each format fixes, in the [retrospective games guide](/guides/retrospective-games/): 20 formats with when to reach for each, how long it runs, and how to run it remotely. Rather than repeat it here, this post takes the argument the list cannot: a format only structures the conversation. It doesn't guarantee anyone opens up. New to facilitating? Our guide on [how to run a retrospective](/guides/running-effective-retrospectives/) walks through the five phases and a ready-made agenda. When your team is quiet, tired, or going through the motions, that's when you reach for an actual game.
## The retro games we played
There's real evidence behind this, not just facilitator folklore. A study in [*Empirical Software Engineering*](https://link.springer.com/article/10.1007/s10664-021-10043-z) tracked six Scrum teams running game-based retrospectives and found the games directly countered the problems that make retros worth skipping in the first place: lack of structure, dull repetition, and a handful of people carrying the whole conversation. Worth remembering next time a busy sprint makes the retro feel optional. Those are usually the sprints that need one most.
So we put it to the test. Over the last couple of months we ran a game in every one of our own team's retros. The honest reason was that attendance had gone quiet, and we wanted to see if a game would pull people back in. Here's what we played, with the real screenshots from each session:
1. **Your sprint in three emojis:** three emojis each, then everyone unpacks their own.
2. **Describe your sprint, and let AI draw it:** everyone uses TeamRetro's built-in image generator to turn the last few weeks into a picture.
3. **Guess who wrote which card:** the same idea, kept anonymous, then guess who made each one.
4. **Team Spectrum:** place yourselves on a spectrum, then guess where your teammates landed, with scores.
5. **The AI-generated sprint artifact:** feed the finished retro's summary into an AI image generator for a newspaper, poster, or Sprint Wrapped card.
### 1. Your sprint in three emojis
Before any discussion, everyone drops three emojis to sum up the sprint, then explains them. The shorthand is faster and more disarming than prose. Someone will admit in a skull, a fire, and a sob emoji what they'd carefully hedge in a full sentence.
_We ran ours as a quick mood check straight in the chat. Three emojis, then everyone unpacks their own._
Prefer a GIF? That works just as well as an alternative format: a single well-chosen GIF (a burning building, say) often says more than a paragraph. Either way it's a quick, low-effort opener, especially when time is tight.
### 2. Describe your sprint, and let AI draw it
Ask everyone to describe their sprint experience over the last few weeks, then let TeamRetro's built-in image generator turn that into a picture. Each person shares what came back and talks through why. Reacting to your own weird little image is far easier than answering "so, how did the sprint go?", and the picture usually says the quiet part out loud.
_Our "June Mood" board. The prompt was simply: create an image that describes what the sprint felt like._
The board filled up fast: a wide-eyed monkey losing its grip on a fistful of flying tasks, someone at their desk staring into a screen full of lightning. Every image became a way into a conversation we would otherwise have had to drag out of people.
### 3. Guess who wrote which card
Run the same board, but keep every submission anonymous, then have the team guess who made each card. It turns a passive review into a game and surfaces assumptions along the way: "I was sure that was you" says as much as the image itself.
_The guessing in action: teammates dropping their guesses in the comments under each anonymous image._
One honest warning: this only works if your team already has high trust and good camaraderie. Guessing "who's the burnt-out one" is fun when people feel safe and pointed when they don't. If you're not sure where your team sits, save this one and start with something lower-stakes.
### 4. Team Spectrum
This is the one that got the most buy-in of the lot, and it's a proper game with scores. [Team Spectrum](https://games.teamretro.com/) (one of our free Icebreaker Games) puts a reflection prompt on a spectrum, then makes everyone guess where their teammates landed. We used it for the sprint itself. The prompt was "how well did the sprint stories align with the bigger picture?", running from "everything fit" on one end to "felt disconnected" on the other. Everyone privately placed themselves, then the team guessed each other's positions, scoring points for getting it right.
_A real reflection prompt, played as a spectrum. You score by guessing where teammates put themselves._
The guessing is what makes it work. Predicting where someone landed forces you to actually consider their sprint, not just your own, and every wrong guess is a small, safe surprise that gets people talking. The leaderboard turns a reflection nobody was excited about into something they wanted to win.
_Round one done. The scoreboard did more for attendance than any calendar reminder._
Use it when you want a genuine reflection but the team keeps treating retros as a chore. The scoring is the hook; the alignment conversation is what you actually walk away with.
### 5. The AI-generated sprint artifact
This one isn't an opener. It's what we did with the retro once it was over. We took the output, TeamRetro's [AI Meeting Summary](/blog/ai-tools-that-make-agile-retrospectives-easier-and-smarter/), which already pulls the key themes, sentiment, and outcomes, and fed it into an AI image generator with a strong style prompt: a 1960s newspaper front page, a wartime propaganda poster, an 80s movie one-sheet, a Spotify Wrapped-style recap card. Then we shared the results back with the team.
We ran a few prompts on one month's summary. Here's what came back, no cleanup and no cherry-picking. Click through the deck:
Every one of those came from the same meeting summary. Seeing the sprint retold in a new form makes it stick, and the gap between the artifact and reality (the "that's not how it actually felt" moment) often surfaces a point the retro glossed over. The "octopus-level multitasking" headline did more to open up a workload conversation than any check-in question we've tried. Use it to close out a milestone or end-of-quarter session you want people to remember.
**Want to try these without the setup?** Every game here runs on a free template in TeamRetro, and the AI Meeting Summary that powers the sprint artifact is built in, so you can run the retro and generate the artifact in the same place.
## Facilitating retro games remotely
The activity gets you started. Remote facilitation is what decides whether online retrospective games actually work, and it's where most online retros quietly fail. Three things make the biggest difference.
**Timebox tightly.** Online attention is short and silences feel longer. Put a visible timer on each phase: a window to add input, another to group and vote, a hard stop for discussion. Tight boxes create urgency and stop one topic eating the whole hour.
**Make input anonymous.** Hierarchy travels down a video call fast. When people contribute anonymously, the junior engineer raises the concern the tech lead was tiptoeing around. It's also what makes a game like Guess Who work at all. Anonymous entry defangs rank and gets you the real feedback, not the safe version.
**Let people pre-enter async.** Don't make everyone think on the spot with their camera on. Open the board beforehand so people can add thoughts in their own time. The quiet, deliberate thinkers contribute properly instead of being steamrolled by the fast talkers, and you start the live session with raw material already there.
Get these three right and almost any activity above lands. Get them wrong and even the cleverest game turns back into an open discussion with a scoreboard on top.
## When a game won't fix the problem
One honest caveat: a game won't fix an unsafe team.
If people don't trust each other, no clever format will pull out the real issues. Neither will an AI-generated newspaper. They'll fill in the safe cards, laugh at the artifact, and save the real conversation for the DM afterwards. Anonymity and playfulness help at the margins, but they're a patch, not a cure. When the same problem resurfaces sprint after sprint with no one willing to own it, that's a signal a template can't answer.
If you're not sure which one you're dealing with, don't guess from tone on a video call. A quick health check before the retro tells you in minutes whether you're looking at a flat team or an unsafe one. It's a numeric read on trust, safety, and morale. If the numbers are low, that's the actual agenda item. No game fixes that. Only the follow-through does.
That work sits underneath all of this. It's facilitation and leadership: following through on action items so people see that speaking up changes something, modeling that it's safe to disagree, and dealing with the behavior that makes people go quiet. Online retrospective games are a powerful tool for a team that trusts each other enough to be honest. They're not a substitute for building that trust.
## Match the game to the sprint
The best online retrospective game is the one that matches what your team needs this sprint: a solid format when the conversation needs structure, a genuine game when it needs unsticking. Match it to the job, run it with tight timeboxes and anonymous input, and watch whether the honesty is real or performed.
Every format here is a free template in TeamRetro. Anonymous input, async pre-entry, timeboxing, and the AI summaries that power the remix game are all built in, so you focus on the conversation, not the setup.
Browse the [retrospective template library](/retrospective-templates/), pick a format from the [retrospective games guide](/guides/retrospective-games/), warm up with [Icebreaker Games](https://games.teamretro.com/), or pull fresh prompts from [RetroIdeas](https://ideas.teamretro.com/activities/) when a format feels stale.
For more on keeping retros engaging, see [3 nifty ways to keep your retros fun and exciting](/blog/3-nifty-ways-to-keep-your-retros-fun-and-exciting/) and [how to run an icebreaker](/blog/how-to-run-an-icebreaker/).
---
# Online whiteboards for retrospectives: templates and techniques that work
URL: https://www.teamretro.com/blog/online-whiteboards-for-retrospectives/
Most teams use an online whiteboard the same way. Someone opens a blank canvas, people drop in sticky notes, and then everyone stares at a wall of disconnected ideas trying to work out what to do with them. It is better than nothing, but it is a long way from what a structured visual session can do.
The teams that improve fastest are not the ones with the most tools. They are the ones who run sessions with a clear flow: think privately, group by theme, vote on what matters, dig into the causes, and leave with actions someone owns. That is a method, not a feature. So instead of pointing teams at a separate whiteboard and hoping the method survives the tool-switching, we built the whiteboard into the session. This guide covers where a visual canvas earns its place across retrospectives, health checks, and estimations, and the templates that make it useful.
## Why a blank canvas is not enough for a team session
A blank canvas is a starting point, not a method. For a retrospective, a health check, or a planning conversation, what a team actually needs is a flow that protects honest input and ends in something concrete. Three things break down on a general whiteboard without that structure:
- **Ideas stay disconnected.** Sticky notes pile up with no way to surface the relationships between them. The team discusses individual points instead of the pattern underneath, treating symptoms rather than causes.
- **The loudest voice still wins.** Without independent input, where everyone adds their thoughts before anything is visible to others, the first few contributions anchor the conversation. Quieter people self-edit before they have even typed a note.
- **Actions do not survive the session.** When the board is the only artifact, the actions live on a canvas that gets closed at the end of the call. There is no carry-forward, no owner, no accountability.
This is where [psychological safety](/blog/how-to-tell-if-your-team-feels-psychologically-safe/) and structure meet. A session that supports private input, guided steps, and visible action capture does not just run more smoothly. It creates the conditions where people say what they actually think, which is the only version of a retrospective worth running. Harvard's Professor Amy Edmondson, [whose research on psychological safety](https://www.library.hbs.edu/working-knowledge/psychological-safety-is-an-asset-not-a-luxury) underpins how high-performing teams operate, found that people speak up more honestly when they are protected from immediate judgment. Independent brainstorming, private until the facilitator reveals the board, is how that protection gets built into the session by default.
## The gap a facilitator pointed out
A senior agile practitioner on a large, distributed team described the gap precisely. Her team follows the standard flow of brainstorming, grouping, and voting. Where she got stuck was right after the team aligned on the topic they most wanted to discuss.
*Real feedback from a facilitator on a distributed team, and one of the requests that shaped how we built whiteboards into TeamRetro (personal details redacted).*
Before jumping to solutions, she wanted to do some root cause analysis, to make sure the team was solving the real problem rather than a symptom. With a separate whiteboarding tool she would spin up a quick working space and run a technique like a Fishbone diagram or 5 Whys. Inside a retrospective, there was no good home for that. In her words:
> "What I find myself wishing for is an additional optional workflow step after voting that provides a dedicated collaborative space for root cause analysis. Essentially, something that helps teams explore and document the causes behind an issue before moving into action planning."
>
> *A senior agile practitioner, distributed software team*
This is exactly the kind of feedback the whiteboard was built for. Rather than send teams out to a separate tool, we put a dedicated, collaborative space for root cause analysis right where she wanted it: after voting, before actions, without leaving the retrospective.
Here is what it looks like in practice. Say the team votes up "the mobile checkout shipped three weeks late." The easy reaction is "estimate better next time." Open a Fishbone against that idea instead, and the real picture appears: the staging environment was down for four days, scope expanded mid-sprint, and the product owner was unavailable for two key decisions. The fix that follows is specific, and the whole team can see the reasoning behind it, rather than one person's hunch.
## Whiteboards, built into the session
TeamRetro's collaborative whiteboard is a shared visual canvas that lives inside the meeting. Everyone can sketch, map a framework, and draw together at the same time, with each person's cursor visible live, and without leaving the retrospective to do it.
You can add a whiteboard wherever the discussion needs one:
- **Against an idea**, to dig into a specific item the team voted up (this is the root cause analysis step the facilitator above was missing).
- **Against a comment**, to expand on a single point.
- **At the meeting level**, as a standalone canvas the whole team can browse.
A few things make it work as a facilitation surface rather than a free-for-all. The facilitator or creator can **lock** a board so only they can edit while presenting or once it is finalized. **Presenting** broadcasts a board to every participant, so nobody is scrolling on their own. And every whiteboard can be **exported** as PNG or SVG, and is **included in the session report**, so the thinking is captured rather than lost when the call ends. It works the same way across retrospectives, health checks, estimations, and maturity assessments.
## The templates, and when to reach for each
A blank canvas is still there when you want it. But most of the time you want a structure to work into, so the team spends its energy on the thinking rather than drawing boxes. TeamRetro ships nine templates, which fall into three jobs.
**For getting to the root cause:**
- **5 Whys.** Ask "why" in sequence until you reach the underlying cause rather than the first visible symptom. Reach for it when a single problem keeps recurring and you suspect the team is fixing the wrong layer.
- **Fishbone (Ishikawa) diagram.** Map the possible causes of a problem into categories so the team can see cause and effect at a glance. Reach for it when an issue has several contributing factors and you want to sort them before discussing fixes. To build a whole session around this kind of root cause analysis, there is also a full [Fishbone (Ishikawa) retrospective template](/retrospective-templates/fishbone-ishikawa-retrospective/).
**For deciding and prioritizing:**
- **Impact/Effort matrix.** Plot options by the value they deliver against the work they take, so the quick wins and the time-sinks are obvious. Reach for it when the team has more ideas than capacity.
- **SWOT.** Lay out strengths, weaknesses, opportunities, and threats. Reach for it in a planning conversation or a quarterly review, or start from the ready-made [SWOT analysis template](/retrospective-templates/swot-analysis-for-teams/).
- **North Star.** Align the team around the one guiding metric that matters. Reach for it when priorities are scattered.
- **The Golden Circle.** Work outward from why, to how, to what. Reach for it when the team needs to reconnect a piece of work to its purpose.
**For mapping people and time:**
- **Stakeholder map.** Place the people involved in a decision by influence and interest. Reach for it before a change that touches teams outside the room.
- **RACI.** Set out who is responsible, accountable, consulted, and informed. Reach for it when ownership of a follow-up action is unclear.
- **Timeline.** Lay events out in sequence. Reach for it when the team is reconstructing what happened over a sprint or an incident.
## Using whiteboards in retrospectives
A TeamRetro retrospective runs in steps: everyone brainstorms privately, ideas are grouped, the team votes, and the top issues get discussed and turned into actions. The whiteboard slots in after voting and before actions, the moment the team has agreed on what matters and needs to understand it before fixing it. Open one against the top-voted idea, pick a template, and dig in together.
Reach for a whiteboard when:
- **A problem keeps coming back.** Run a 5 Whys or Fishbone on the top-voted issue to find the root cause, not the first fix that comes to mind.
- **The sprint is a blur and people remember it differently.** A Timeline rebuilds what actually happened, event by event, before the team draws conclusions.
- **The discussion is going in circles.** Sketching the process or the system on a shared canvas gives everyone the same thing to point at.
- **An action needs a clear owner.** A quick RACI settles who is responsible, accountable, consulted, and informed before the session closes.
**Picture it.** You are running the sprint retro. The team votes up "we keep missing the sprint goal," and the room's first instinct is "commit to less next time." Instead of taking that at face value, you open a whiteboard on that idea and drop in the 5 Whys template. A few whys down, the real cause is not over-commitment at all: stories are being pulled in without clear acceptance criteria, so work bounces back late in the sprint. The action writes itself, and the whole team watched how you got there rather than taking your word for it.
## Using whiteboards in health checks
A health check gives you the numbers; a whiteboard turns them into a conversation. People rate each [team health check](/health-checks/) dimension privately, the results are revealed as a radar or bar chart, and then the real work starts, because a rating on its own does not explain itself.
Reach for a whiteboard when:
- **A dimension scores low and the reasons are tangled.** Map the causes on a Fishbone so the team debates the causes, not the number.
- **Scores are split.** When some people rate "communication" a 2 and others a 5, put the reasons side by side and find out why the same team sees it so differently.
- **A theme runs across dimensions.** Sketch how "delivery," "process," and "fun" feed into each other instead of treating each score in isolation.
Because health check data is tracked over time, whatever the team uncovers is there to revisit next session, so a dimension that is quietly sliding back is hard to miss.
## Using whiteboards in estimations
When a team estimates together and the numbers come back far apart, that spread is information: someone is seeing complexity, a dependency, or an edge case the others are not. A whiteboard makes that hidden picture shared, so the re-estimate rests on the same understanding rather than on who argued hardest.
Reach for a whiteboard when:
- **Estimates are far apart.** Break the story into its parts on the canvas until the reason for the gap shows itself.
- **The work depends on other teams or systems.** Map the dependencies and unknowns before anyone commits to a number.
- **Scope is fuzzy.** Sketch the flow or the acceptance criteria so the team is sizing the same thing.
- **There is more to do than capacity allows.** An Impact/Effort matrix sorts what is worth doing against what it will cost.
Across all three ceremonies the move is the same: when the conversation gets stuck, a whiteboard turns it into a shared picture, and because it lives inside the session, whatever the team draws is captured in the report rather than lost on a separate canvas.
| Ceremony | Where a whiteboard helps | What the team leaves with |
| --- | --- | --- |
| Retrospective | A deep dive on the top-voted issue, with a 5 Whys or Fishbone | The real cause named, not just the symptom, and owned actions |
| Health check | Unpacking a low or split rating into the reasons behind it | A shared understanding of why a dimension scored the way it did |
| Estimation | Breaking a story down when estimates come back far apart | A re-estimate grounded in the same picture of the work |
## Why built-in beats a separate whiteboard tool
Plenty of teams stitch their session together across tools: a whiteboard for brainstorming, a separate retro board for voting, a Jira ticket or Slack message for actions. It is a common setup, and it is where follow-through quietly dies.
Every tool switch mid-session costs focus. People open the wrong link, lose the thread, or check out during the transition, and the facilitator spends energy on logistics instead of the conversation. Sticky notes on a general whiteboard do not become tracked actions on their own. Someone has to go back after the call, read the board, translate ideas into tasks, and assign them, and that step is where most retrospective actions are lost.
Building the whiteboard into the session removes the switch. The canvas, the voting, the root cause analysis, and the actions all live in one place, and the actions carry forward into the next session's Open Actions step automatically. Health check ratings, retrospective themes, and follow-ups build up in the same place over time, so you can see how the team is actually developing, not just whether one meeting went well.
## Try it in your next retrospective
The blank canvas was never the problem. The missing piece was a structure around it, and a place to dig into the real cause before the team commits to a fix. Run your next retrospective in TeamRetro, add a whiteboard where the discussion needs one, and see what surfaces.
## Frequently asked questions
**What is a collaborative whiteboard in TeamRetro?**
A shared visual canvas inside the meeting. Several people can sketch, map a framework, and draw together in real time, with each person's cursor visible, without leaving the session. It sits alongside private brainstorming, grouping, voting, and action tracking rather than being a separate tool.
**Where can I use a whiteboard?**
Across retrospectives, health checks, estimations, and maturity model meetings. You can open one against a specific idea, against a comment, in the chat, or as a standalone board at the meeting level.
**Which templates does the whiteboard include?**
Nine, plus a blank canvas: 5 Whys and Fishbone for root cause analysis; Impact/Effort matrix, SWOT, North Star, and the Golden Circle for deciding and prioritizing; and Stakeholder Map, RACI, and Timeline for mapping people and events.
**Can I run root cause analysis like 5 Whys or Fishbone in a retrospective?**
Yes. Once the team has voted on the issue that matters most, open a whiteboard against that idea, pick the 5 Whys or Fishbone template, and work through it together before moving into action planning.
**Can I present, lock, and export a whiteboard?**
Yes. A facilitator can present a board so everyone follows the same view, and lock it so only they can edit while presenting or once it is final. Boards export as PNG or SVG and are included in the session report, so the thinking is captured rather than lost.
---
# Our AI teammates joined our retro
URL: https://www.teamretro.com/blog/our-ai-teammates-joined-our-retro/
We build retrospective software, so our team's retro board is a fairly ordinary place: Start, Stop, a column of open actions, the usual Friday arguments. Last week it gained some new contributors. Six of the cards weren't written by anyone human: they were filed by the AI agents we work with every day, summarizing the friction from their own working sessions with us.
Let's be precise about what this is, because the phrasing matters. This is not an AI sitting *in* the retro: no bot facilitating the meeting, no AI feature summarizing the humans' cards. The agents that do real work on our team (the ones writing code, editing content, running audits) showed up to the ceremony the way any teammate does: with their own account of how the work went. Participants, not facilitators; the meeting stayed ours.
This wasn't a stunt, either. The push came in one of our own retros: someone said the onboarding docs were out of date (again) and someone else mentioned an agent had flagged exactly that to them mid-session that morning, in passing, before the context scrolled away. The agent had known; nothing in its world said the observation was worth keeping. So for the past few weeks we've been running an experiment on ourselves: the practice is the one we described in [how to gather feedback from your AI agents](/blog/gather-feedback-from-ai-agents/). At the end of each substantial AI-assisted working session, the agent writes a short, structured retro entry of its own work: what went well, what dragged, what each drag cost, one root-cause label per item, and a proposed fix. The entries accumulate in the repos the work happened in. When enough had built up, a companion process read them all and filed the recurring patterns straight onto our retro board, prefixed `[AI retro]` so nobody mistakes the author.
Here's what our newest teammates had to say about working with us.
## What they found
**The headline they led with was about themselves.** The top card read: *"Start verifying before acting — agent execution error is 38% of friction (2× the next cause); the recurring cost is asserting a cause, pushing, or retargeting before checking live code, data, or branch state."* The single biggest source of friction in our AI-assisted work, by the agents' own accounting, was the agents, specifically the habit of acting on an assumed state of the world instead of checking the live one first. We'll take honesty like that from any colleague.
**The biggest team-shaped theme crossed every boundary a person wouldn't.** Git and branch-state errors under concurrent-agent work showed up in eight sessions across two repos: stale bases, unread branch targets, one agent moving a branch another was using, a PR retargeted without verification. No single session would have ranked this anywhere near the top; each instance was a shrug and a few lost minutes. Ranked across eight sessions, it was unmissable.
**It caught us shipping on partial checks.** Four sessions where something was pushed or merged after a narrower check than CI actually runs: a bare type-check instead of the full build, targeted tests instead of the suite. Twice in one repo, on the same day.
**And the most uncomfortable cards weren't about the work at all; they were about follow-through.** One card noted that a testing-convention gap had let a reproducible crash slip past two rounds of review, and that the fix document had been *proposed the day before and never written*. Another noted the same tool stall had now cost two sessions, "no standing fix shipped between them." A third: the same requirements-creep pattern, three consecutive sessions, "each noting it recurring from the last." The agent, it turns out, remembers what we said we'd do.
## The two things worth staring at
**First: none of this was visible to any individual.** That's not a failure of attention; it's the shape of the problem. AI-session friction is chronic and minor, so it never triggers a postmortem, and it evaporates when the session ends. Each of us had absorbed our share and moved on. The ranking (*this* pattern costs the team most) only exists in the aggregate view, and the aggregate view only exists because the entries were comparable: same schema, same small set of root-cause labels, every claim citing a dated session. This is the aggregation idea at the center of [the guide this post accompanies](/guides/ai-agent-retrospectives/), and it's the part we most wanted to test on ourselves.
**Second: the agents didn't blame anyone, including themselves, loosely.** The entries follow two rules that turned out to matter more than we expected. Friction items describe the gap and what it cost, never who caused it: no names, no "X's brief." And "the agent made a mistake" is a *residual* label, only used when the inputs were genuinely adequate, which is exactly why the 38% figure got our attention: it survived that discipline. The result read like a good retro contribution: specific, evidence-cited, blameless, and slightly embarrassing for everyone equally.
## What the room decided
We decided to act on all three of the proposed actions, each at the altitude it named. The "confirm live branch and PR state before mutating" rule goes into each repo's agent docs, a documentation fix for the eight-session theme. The pre-push hook that runs the CI-equivalent build and tests goes into the repos that got burned by partial checks, an environment fix, so it doesn't depend on anyone remembering. And the testing-convention doc that was "flagged the day before and never written" is being written, with the crash that slipped through as its worked example.
No grand reorganization, no new process: three ticket-sized fixes with owners. The modesty is deliberate: the whole bet of this practice is that small fixes, aimed at the right level and actually checked next cycle, compound. Whether these three stick is precisely what the next brief's adoption check will tell us; the same mechanism that caught us last time will be grading us on it.
It's early days, and we're saying so plainly. But we walked out of that retro more interested in our own working patterns than we've been in a while, and a little competitive with a colleague who doesn't even get tired.
## The honest footnotes
This is our first synthesized brief, weeks of data, not months, so we're treating the rankings as attention allocation, not accounting. The costs in the entries are the agent's own estimates and are marked as such. The practice's harder claims (that labels stay consistent between raters, that the trend line actually bends after fixes land) are experiments we're running rather than assumptions we're making, and we'll publish what they say either way.
But the core payoff already showed up: a set of patterns nobody on the team could see individually, ranked, evidenced, and filed into the ceremony where the people who own the fixes were already sitting. Rahul Garg's [Feedback Flywheel](https://martinfowler.com/articles/reduce-friction-ai/feedback-flywheel.html) includes in its cadence list "an agenda item in the existing sprint retrospective: what worked with AI this sprint?" We can now report that the agenda item is considerably more interesting when your AI teammates file their own items.
## Try it on your own team
Everything we used is free and documented in [the guide](/guides/ai-agent-retrospectives/): how the entries work, the root-cause labels, the never-log rules (no secrets, no customer data, and never anything that identifies a person), and the facilitator's 15-minute agenda item, plus the two skills that implement the capture and synthesis ends. It works with any capable agent and a text file; our product is one place the results can land, not a requirement.
Next cycle, the brief's adoption check will tell us whether we actually wrote that testing doc this time. We'll let you know. So will they.
*Tried it? Disagree with it? We mean it about wanting to be argued with: [ai-discussion@teamretro.com](mailto:ai-discussion@teamretro.com).*
---
# Planning poker decks: which options best accelerate agile team velocity?
URL: https://www.teamretro.com/blog/planning-poker-deck-that-is-best-for-accelerating-team-velocity/
Estimation plays a critical role in agile planning, but it’s not just about assigning numbers or sizes to user stories. At its core, estimation is about building shared understanding, setting expectations, and enabling teams to plan and deliver work more reliably.
It’s a surprisingly human exercise that blends structured guessing with group psychology, with just enough math to keep everyone honest.
Choosing the right deck improves agile story point estimation, team alignment, and boosts team velocity. It can simplify complex work and add structure to abstract ideas during backlog refinement or sprint planning.
It can directly influence how easily you reach consensus, how confident people feel about their estimates, and how accurately you can forecast future sprints. And who wouldn’t want that?
So here’s the crunch.
I’ve got an estimation meeting coming up with my team. – “How do I choose the right deck?”
Here we explore the common choices for planning poker card decks, share our top tips and things you need to think about when choosing a deck, and use a case in point example to compare two common methods. In this case Fibonacci versus T-Shirt size.
> #### Fun origin fact
>
> [Planning poker](https://athena.ecs.csus.edu/~buckley/CSc231_files/Introduction%20to%20Planning%20Poker.pdf) is based on Wideband Delphi, a forecasting method invented by the RAND Corporation sometime between the 1940s and 1968 (even historians can’t agree 😄). It was modernized for Agile teams in 2002 and made mainstream by [Mike Cohn](https://www.mountaingoatsoftware.com/agile/planning-poker).
## Choose your planning poker deck: why the numbers matter?
When it comes to planning poker decks, the numbers are doing more work than you think. (Our estimation guide breaks down each option in [which deck should you use?](/guides/agile-estimation-guide/how-to-run-planning-poker/#which-deck-should-you-use).)
Some of the most common card decks include:
- **Scrum**: Based on the traditional Scrum values (0, 1,2,3,5,8) this deck helps standardize estimates across agile teams following Scrum methodologies.
- **Fibonacci**: A sequence (1, 2, 3, 5, 8, 13…) a sequence that intentionally gets less precise as numbers grow to represent increasing levels of effort and complexity.
- **Sequential**: A linear progression of numbers (e.g., 1, 2, 3, 4, 5…) for teams who want more consistent, evenly spaced estimates. A popular choice where projects have less variations. This can also be used for estimating based on Ideal days or time based.
- **Half card**: Allows for finer granularity between common estimates by including values like (1, 1½, 2, 2 ½, 3) – a more precise estimation sequence that further refines estimations.
- **Power of two**: Exponential sizing (1, 2, 4, 8, 16…) is a variation on the fibonacci sequence that emphasizes uncertainty when it comes to the larger tasks.
- **T-shirt sizing**: Abstract labels like XS, S, M, L, XL that work well for high-level planning, relative ranking or when collaborating with cross-functional teams. It can be a useful discussion point to get a general team definition of each t-shirt size.
There are some other variations out there including weighted averaging and weighted shortest job first, but they tend to over complicate something which cannot be so precisely calculated and leads to an over reliance that the final output must be accurate simply due to its complexity.
## Factors for choosing the right planning poker card deck
When selecting a deck, the goal isn’t perfection; it’s clarity and consistency. The right deck should support productive conversations and fit naturally into how your team already works. A few factors can help guide the decision:
### Workflow alignment
Choose a deck that fits naturally with the tools, ceremonies, and processes your team already uses. The best deck is one your team doesn’t have to think about.
### Team experience
T-shirt sizing is often easier for newer or mixed-discipline teams, while Fibonacci estimation works well for teams comfortable discussing relative complexity and trade-offs.
### Level of precision
Numeric decks support more detailed estimates, while abstract sizing keeps early planning lightweight and avoids false precision.
### Planning goals
T-shirt sizing works well for discovery and roadmap conversations. Fibonacci and similar numeric decks are better suited to sprint planning and tracking [team velocity](/guides/agile-estimation-guide/velocity/) over time.
### Risk and uncertainty
If work items vary widely in unknowns, decks like Fibonacci or Power of Two help surface uncertainty by spreading estimates further apart as size increases.
### Nature of the work
Routine or repeatable tasks may suit linear or time-based decks, while exploratory or creative work benefits from relative or abstract sizing.
### Speed of decision-making
Abstract or bucket-style decks encourage faster consensus and reduce over-analysis when working through large backlogs.
### Cross-team consistency
If multiple teams collaborate or compare estimates, using the same deck can reduce confusion and make shared planning more effective.
### Cognitive load
Simpler decks reduce mental overhead, helping teams focus on discussion and shared understanding rather than debating numbers. The decks that are in our estimation set are chosen for a simpler approach.
### Change tolerance
Switching decks mid-project can disrupt velocity tracking. Consider whether your team values continuity or is comfortable experimenting with new approaches.
### Remote collaboration
For remote teams, decks with fewer options and clearer distinctions often work better, reducing friction and decision fatigue during online sessions.
Ultimately, the best planning poker card deck is the one that encourages meaningful conversations, builds shared understanding, and supports how your team works day to day.
While there are some default or go to – popular models, it’s (excuse the pun) not a one size fits all scenario.
## Planning poker card deck decision matrix
**Legend**:
★★★ = Strong fit
★★☆ = Can work
★☆☆ = Not ideal
| Card deck → / Decision factor ↓ | Scrum | Fibonacci | Sequential | Half card | Power of two | T-shirt sizing |
| --- | --- | --- | --- | --- | --- | --- |
| **Early discovery / roadmap planning** | ★☆☆ | ★★☆ | ★★☆ | ★☆☆ | ★☆☆ | ★★★ |
| **Sprint planning & delivery** | ★★★ | ★★★ | ★★☆ | ★★★ | ★★☆ | ★☆☆ |
| **New or mixed-discipline teams** | ★★☆ | ★☆☆ | ★★★ | ★☆☆ | ★☆☆ | ★★★ |
| **Experienced agile teams** | ★★★ | ★★★ | ★★☆ | ★★★ | ★★★ | ★★☆ |
| **High uncertainty / unknowns** | ★★☆ | ★★★ | ★☆☆ | ★☆☆ | ★★★ | ★★☆ |
| **Predictable, repeatable work** | ★★☆ | ★★☆ | ★★★ | ★★★ | ★☆☆ | ★☆☆ |
| **Needs high precision** | ★☆☆ | ★★☆ | ★★☆ | ★★★ | ★☆☆ | ★☆☆ |
| **Avoid false precision** | ★★☆ | ★★★ | ★☆☆ | ★☆☆ | ★★★ | ★★★ |
| **Fast consensus needed** | ★★☆ | ★★☆ | ★★☆ | ★☆☆ | ★☆☆ | ★★★ |
| **Encourages discussion & alignment** | ★★★ | ★★★ | ★★☆ | ★★★ | ★★☆ | ★★☆ |
| **Remote-first teams** | ★★☆ | ★★★ | ★★☆ | ★☆☆ | ★★☆ | ★★★ |
| **Cross-team consistency required** | ★★★ | ★★★ | ★★☆ | ★☆☆ | ★★☆ | ★☆☆ |
## Case study: Fibonacci vs t-shirt sizing for an internal product team
An internal product division at a mid-sized organization was responsible for building and maintaining several shared tools used across the business. They regularly collaborated with stakeholders from operations, finance, and customer support.
While the work wasn’t customer-facing, the impact was significant: small delivery delays often created ripple effects across the business.
The development team was experienced and stable, working in two-week sprints with a predictable release cadence. However, planning sessions were starting to feel strained.
As the product matured, the team needed a clearer approach to estimation that could support both longer-term planning and day-to-day delivery.
## The challenge
The team faced two distinct planning contexts:
- Early-stage work, where requirements were still evolving and input from non-technical stakeholders was essential
- Sprint-level work, where stories were well-defined and the team needed reliable estimates to track velocity and forecast delivery
To address this, the team compared two commonly used estimation approaches: Fibonacci estimation and t-shirt sizing.
### Option 1: Fibonacci estimation
Fibonacci estimation uses a non-linear number sequence where each value represents a meaningful increase in effort and uncertainty. This helped the team recognize that larger stories were harder to estimate precisely and encouraged deeper discussion when estimates diverged.
The team found Fibonacci particularly effective for:
- Sprint planning
- Tracking velocity across iterations
- Improving forecasting accuracy over time
Once work items were refined and ready for delivery, Fibonacci supported consistent planning and helped the team understand their capacity from sprint to sprint.
**Trade-offs**
- Slower during early backlog discussions
- Less accessible for non-technical stakeholders during planning sessions
### Option 2: T-shirt sizing in agile
T-shirt sizing takes a more abstract approach by using relative sizes instead of numbers. This made it easier for stakeholders outside the development team to contribute during planning and kept conversations focused on relative effort rather than precision.
The team found T-shirt sizing especially useful for:
- Early backlog refinement
- Roadmap planning
- Cross-functional or remote planning poker sessions
By removing numbers from the conversation, the team moved faster through early-stage ideas and avoided overcommitting too early.
**Trade-offs**
- Not detailed enough for sprint-level forecasting
- Required translation into numeric estimates before delivery
## The decision
Rather than choosing a single deck, the team aligned each approach to a specific planning goal:
- T-shirt sizing for early backlog refinement and roadmap planning
- Fibonacci estimation for sprint planning and delivery
This allowed the team to maintain clarity and consistency without forcing precision too early in the process.
## How planning poker card decks influence team velocity
Team velocity isn’t about speed; it’s about consistency. Reliable velocity allows teams to plan with confidence and make better delivery commitments. (More on [how story points roll up into velocity](/guides/agile-estimation-guide/velocity/).)
Numeric estimation decks like Fibonacci support velocity by helping teams:
- Compare completed work across sprints
- Identify delivery trends
- Improve long-term forecasting
T-shirt sizing influences velocity more indirectly. By keeping estimation lightweight, teams often:
- Plan faster
- Spend more time clarifying scope
- Align earlier before committing to detailed estimates
Both approaches can boost team velocity when used consistently and at the right stage of planning.
There’s no universally “correct” way to estimate. The most effective teams choose an approach that supports clear communication, alignment, and predictable delivery.
As teams grow, their estimation practices often evolve too. Revisiting how you estimate (and why) can be a simple but powerful way to improve planning outcomes and long-term team velocity.
## Start estimating in seconds
The planning poker deck your team uses shapes how you plan, collaborate, and deliver. Some teams need numerical precision, while others benefit from fast, lightweight sizing, especially in remote or async planning poker sessions.
Choosing the right deck isn’t just a preference; it’s a strategic decision that affects how clearly your team communicates and how reliably it delivers.
Try [TeamRetro’s free planning poker tool](https://planning-poker.teamretro.com/) today. No sign-up needed, just open your browser and get started.
[Learn more about free planning poker](/free-planning-poker-for-agile-teams/)
Looking for templates, tips, or a walkthrough video? We’ve got more resources coming soon.
---
# Quick but effective icebreakers to launch your next retrospective
URL: https://www.teamretro.com/blog/quick-but-effective-icebreakers-to-launch-your-next-retrospective/
Starting your retrospective with an icebreaker is a great way to help your team focus, engage with each other, and get the most out of the meeting. If you want one ready to go, our [free icebreaker questions game](https://games.teamretro.com/games/icebreaker-questions/) picks a prompt for the team in seconds.
An icebreaker will help your team members –
- focus
- strengthen rapport
- build relationships
An icebreaker will give you the chance to –
- model supportive behavior
- set a positive tone for the meeting
- foster a psychologically safe space
A good icebreaker will follow the [3E Rule](/blog/best-icebreakers-for-starting-conversations-with-online-teams-2021/), and linking it to your retrospective will allow you to leverage the momentum of focus and connection it has established so when you start your retrospective, you’ll hit the ground running.
The best thing is, to save you time, we’ve paired each of our retrospectives formats with 3 quick and easy ice breaker questions that you can use to open up your meeting with flair – just like a good wine to each course at a degustation. Need more prompts? Our full bank of [200+ work icebreaker questions](/icebreakers/icebreaker-questions-for-work/) is grouped by goal.
We’ve also included an example of how you could rehearse the retro with your team. These may take a little more time but can help improve understanding and engagement in the rest of your retro.
Check out each of these icebreakers and retro rehearsals in our retrospectives below.
[Agile Retrospective](/retrospective-templates/agile-retrospective/)
[Anchors and Engines](/retrospective-templates/anchors-engines-retrospective/)
[Drop Add Keep Remove](/retrospective-templates/daki-retrospective/)
[Family Circle](/retrospective-templates/the-family-circle-retrospective/)
[Flap Retrospective](/retrospective-templates/flap-retrospective/)
[Four L’s](/retrospective-templates/4ls-retrospective/)
[Hero’s Journey](/retrospective-templates/the-heros-journey-retrospective/)
[Hopes and Fears](/retrospective-templates/hopes-and-fears-retrospective/)
[KALM](/retrospective-templates/kalm-retrospective/)
[Mad Sad Glad](/retrospective-templates/mad-sad-glad-retrospective/)
[Must Should Could Won’t](/retrospective-templates/mscw-retrospective/)
[Oscar Academy](/retrospective-templates/oscar-academy-retrospective/)
[Pathfinder](/retrospective-templates/pathfinder-retrospective/)
[Personal Growth](/retrospective-templates/personal-growth-retrospective/)
[Roller Coaster](/retrospective-templates/roller-coaster-retrospective/)
[Scrum Values](/retrospective-templates/scrum-values/)
[Seasons of the Year](/retrospective-templates/seasons-of-the-year-retrospective/)
[Snakes and Ladders](/retrospective-templates/snakes-and-ladders-retrospective/)
**[Social Media](/retrospective-templates/social-media-retrospective/)**
[Starfish Retrospective](/retrospective-templates/starfish-retrospective/)
[Stop Start Continue](/retrospective-templates/start-stop-continue-retrospective/)
[Superhero](/retrospective-templates/superhero-retrospective/)
[The Good Gardener](/retrospective-templates/the-good-gardener-retrospective/)
[The Master Baker](/retrospective-templates/the-master-baker/)
[Three Little Pigs](/retrospective-templates/three-little-pigs-retrospective/)
[Vacation](/retrospective-templates/vacation/)
[Weather Report](/retrospective-templates/weather-report-retrospective/)
[Witches and Warlocks](/retrospective-templates/witches-and-warlocks-retrospective/)
[Working, Not Working](/retrospective-templates/working-not-working-retrospective/)
[WRAP Retrospective](/retrospective-templates/wrap-retrospective/)
#### We hope you love trying out some of these ideas with the team.
#### If you had any other ideas you wanted to share, reach out to us at info@teamretro.com.
#### Ready to kick off with an icebreaker?
[Start a Retro Now](https://secure.teamretro.com/login) or warm up the room first with our [free icebreaker games](https://games.teamretro.com/games/).
---
# 100 retrospective questions that actually improve your team (2026)
URL: https://www.teamretro.com/blog/retrospective-questions-sprint-agile-teams/
Tired of asking the same retrospective questions sprint after sprint? Every retro guide tells you to ask "What went well? What didn't? What should we change?" And if you've been running retrospectives for more than a few sprints, you already know the problem: the same questions get the same answers. People go through the motions, the energy drops, and nothing new surfaces.
The questions you ask determine the insights you get. In this guide, you'll find 100 retrospective questions organized by category: opening questions, sprint questions, team health questions, icebreakers, and more. Whether you're running a standard sprint retro, a mid-project pulse check, or a quarterly retrospective, there's something here for every format and team mood. And if you want to shake things up beyond questions alone, TeamRetro's [retrospective template library](/retrospective-templates/) gives you 275+ formats to choose from.
**In this guide:**
- What makes a great retrospective question?
- Opening and icebreaker retrospective questions
- Classic sprint retrospective questions
- Start, Stop, Continue retrospective questions
- Agile retrospective questions for Scrum teams
- Team health retrospective questions
- Retrospective questions for remote and hybrid teams
- Closing retrospective questions
- How to choose the right questions for your retro
- Run better retros with TeamRetro
## What makes a great retrospective question?
The questions you ask shape the conversation you get. And the conversation you get shapes whether anything actually changes. The best retrospective questions share a few things in common:
- They're open-ended: "How did we handle scope changes?" beats "Did scope creep affect us?"
- They invite honesty without creating blame, so [psychological safety](https://hbr.org/2023/02/what-is-psychological-safety) comes first
- They're specific enough to generate action, not just conversation
- They rotate, because using the same questions every sprint breeds autopilot thinking
A quick rule of thumb: if the question can be answered with a yes, a no, or a shrug, rephrase it.
## Opening and icebreaker retrospective questions
The first few minutes of a retro set the tone for everything that follows. These warm-up questions lower defenses, invite participation, and signal that this is a safe space, not a blame session. Use one or two at the start. For more ideas on starting your session well, check out TeamRetro's guide to [retrospective icebreakers](/icebreakers/).
### Check-in questions
- On a scale of 1–10, how are you arriving at this retro? What's your number?
- What's one word that describes how this sprint felt?
- If this sprint were a weather forecast, what would it be?
- What emoji best describes your week?
- What's one thing outside work you're looking forward to this week?
- If you had to give this sprint a movie title, what would it be?
- What's something small that went better than expected this sprint?
- How full is your tank right now, and what's draining it?
### Icebreaker questions
- What's a superpower you wish your team had right now?
- If our team were a sports team, what sport would we be playing?
- What's one thing a teammate did this sprint that you didn't get to thank them for?
- If you could fix one thing about our process overnight, what would it be?
- What's the biggest assumption we made this sprint?
## Classic sprint retrospective questions
These cover the essentials without being prescriptive, leaving room for the team to surface what actually matters. If you want a structured starting point for your session, TeamRetro's [sprint retrospective template](/retrospective-templates/sprint-retrospective/) has you covered.
### What went well?
- What's one thing you're genuinely proud of from this sprint?
- Where did the team perform above expectations?
- What made collaboration easier than usual?
- Was there a moment in this sprint where things just clicked?
- What process or tool saved us time or prevented a problem?
### What didn't go well?
- Where did we feel most blocked or frustrated?
- What slowed us down that we could have anticipated?
- Were there any surprises that derailed our plans? How did we handle them?
- Where did our estimates fall short, and why?
- What's a recurring problem we keep talking about but haven't fixed?
### What should we do differently?
- If we ran this sprint again with the same team, what's the first thing we'd change?
- What experiment could we run next sprint that's low risk but high potential?
- What's one concrete thing we could do to improve team communication?
- Is there a meeting, ceremony, or process we could cut or simplify?
- Who do we need to involve earlier in our work?
## Start, Stop, Continue retrospective questions
The [Start-Stop-Continue format](/retrospective-templates/start-stop-continue-retrospective/) is action-oriented by design. Here are questions that work well within each column.
### Start questions
- What's something we've been avoiding that we know would help?
- Is there a practice from another team we've seen work that we haven't tried?
- What one habit, if adopted next sprint, would make the biggest difference?
- What feedback are we not collecting that we should be?
- Are there conversations we keep postponing that we need to have?
### Stop questions
- What's something we're doing out of habit that no longer adds value?
- Where are we creating unnecessary work for ourselves or each other?
- Is there a meeting we could make shorter, less frequent, or cancel entirely?
- What are we tolerating that we shouldn't be?
- Where are we over-engineering or over-documenting?
### Continue questions
- What's working so well that we need to protect it from change?
- What practice from this sprint deserves to become a permanent team norm?
- Which team behaviors have made the biggest difference to delivery?
- What's something a teammate does that you'd like the whole team to adopt?
- Where have we made a recent improvement that's starting to pay off?
**Tip:** Anchoring bias is real. The first voice in the room shapes everyone else's thinking. TeamRetro lets you control this directly: choose Anonymous mode to hide all names even from the facilitator, Aliases to give each participant a unique avatar and name, or Named if full visibility suits your team. You can also keep ideas hidden during brainstorming and only reveal them in the next step, so everyone contributes independently before the group discusses. It's one of the simplest ways to get more honest, diverse responses from your Start, Stop, Continue retro.
## Agile retrospective questions for scrum teams
These questions are designed to bridge reflection and action within a [Scrum framework](https://www.scrum.org/resources/what-is-scrum), useful for Scrum Masters, agile coaches, and self-organizing teams alike. For a deeper look at where retrospectives sit within the Scrum process, the [official Scrum Guide](https://scrumguides.org/scrum-guide.html) is worth bookmarking. TeamRetro also has a dedicated [Scrum retrospective template](/retrospective-templates/) built around the sprint ceremonies.
### For Scrum Masters and facilitators
- Were our sprint goals clear and achievable at the start of the sprint?
- How well did we protect the sprint from scope changes?
- Did our Definition of Done serve us well this sprint, or does it need updating?
- Were blockers surfaced early enough in daily standups to resolve quickly?
- How effective was our sprint planning, and were estimates realistic?
### For agile teams
- Where did we honor our [agile values](https://agilemanifesto.org/principles.html) this sprint? Where did we slip?
- Did we involve the product owner at the right moments?
- How well did we balance technical debt against new feature work?
- What would make our next sprint planning session more efficient?
- Did we demo work we're genuinely proud of in the sprint review?
## Team health retrospective questions
Sprint velocity matters. But so does the health of the people delivering it. These questions surface the human side of your team's performance: [psychological safety](https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/foster-psychological-safety/), workload balance, trust, and morale. Good to use quarterly, or whenever team energy feels off.
### Psychological safety
- Do you feel comfortable raising concerns without fear of how they'll land?
- When was the last time someone on the team changed their mind based on feedback?
- Is there anything you've been wanting to raise in retros but haven't? What's stopping you?
- Do we disagree well? Can we challenge ideas without it becoming personal?
### Workload and wellbeing
- Is anyone feeling close to burnout right now? What would help?
- Do you feel your workload is sustainable? If not, what would need to change?
- Are we saying yes to too many things? What should we push back on?
- Is your work energizing you or draining you right now?
### Trust and collaboration
- Do you feel you can rely on your teammates to deliver what they commit to?
- Is there anyone on the team you haven't connected with enough this sprint?
- Where do we collaborate well, and where do we work in silos?
- Are there unresolved tensions on the team that are affecting our work?
## Retrospective questions for remote and hybrid teams
The energy and spontaneity of an in-person retro doesn't transfer automatically to video. You have to design for it. These questions work well for distributed teams because they invite openness without relying on body language or room dynamics. If you're looking for a tool built for this, TeamRetro is an [online retrospective tool](/retrospectives/) designed specifically for remote and hybrid teams.
- What's something that's harder working remotely right now, and what would make it easier?
- Are we over-relying on async communication where a quick call would work better?
- Does anyone feel like they're losing visibility or recognition working remotely?
- What's the best virtual collaboration moment we had this sprint?
- Are our meetings well-facilitated for people in different time zones?
- What tools or processes have improved our remote collaboration lately?
- Do you feel connected to the rest of the team? If not, what would help?
- What's something you miss about in-person work, and can we recreate any of it?
## Closing retrospective questions
How you close a retro shapes whether people actually follow through on commitments. These questions help the team leave with clarity, not just conversation.
### Commitment and accountability
- What's the one thing you personally commit to doing differently next sprint?
- Who's owning each action item, and do they have enough context to make progress?
- Is there anything from our action list last retro that we should carry forward?
- What would "done" look like for each action item we've agreed on?
### Retro health check
- How useful was this retrospective, and what would make the next one better?
- Did we spend time on the right things today?
- Was everyone's voice heard? If not, who do we want to hear more from next time?
- How confident are you that we'll actually act on what we discussed?
- What format or structure should we try next time?
**Tip:** Check-in and check-out questions aren't just conversation starters. They're data. TeamRetro tracks how your team answers questions like "How would you rate your energy level coming into this meeting?" and "Was this meeting worth your time?" across every sprint, giving you a visual timeline of team mood and retro effectiveness over months. Spot when energy consistently dips before a retro, or whether your team finds retrospectives genuinely worthwhile, and act on it before it becomes a problem. It's the kind of longitudinal insight most teams never get because they treat check-ins as throwaway warmups rather than signals worth measuring.
## How to choose the right retrospective questions
### Match questions to where the team is at
A team coming off a bruising sprint needs different questions than one that's been coasting. If energy is low, start with lighter icebreakers and move toward actionable themes. If trust is fraying, lean on the psychological safety questions before jumping to process.
### Rotate formats, not just questions
Changing your retrospective format, not just swapping out a few questions, is the most effective way to keep retros fresh. Team Radar, [4Ls](/retrospective-templates/4ls-retrospective/), [Sailboat](/retrospective-templates/sailboat-retrospective/), [Mad-Sad-Glad](/retrospective-templates/mad-sad-glad-retrospective/): each format surfaces different things. Use our [retrospective template library](/retrospective-templates/) to find one that fits your team's current focus.
### Don't ask more than you can act on
A focused retro with five great questions and three strong action items beats a sprawling one with fifteen questions and no follow-through. Pick what's most relevant to this sprint and leave the rest for next time.
### Use anonymous input for sensitive topics
For questions touching on burnout, team dynamics, or trust, anonymity unlocks honesty. When people can respond without fear of attribution, you get the real picture.
## How to use retrospective questions effectively
Having a strong list of retrospective questions is useful, but knowing when and how to use them matters even more. The best Scrum Masters don't simply ask more questions. They choose the right questions for the team's current context, create the conditions for honest answers, and turn the discussion into meaningful action.
### Know when not to ask certain questions
Some retrospective questions are powerful, but only when the team feels safe enough to answer honestly. For example, a question like "Do you feel comfortable raising concerns without fear of how they'll land?" can surface important issues around psychological safety. But if the team does not trust the facilitator, each other, or the wider organization, people may give safe answers instead of honest ones.
For sensitive topics (burnout, conflict, team trust, leadership concerns, workload pressure), consider using anonymous input, private brainstorming, or a lighter question first. The goal is not to force vulnerability. It's to create enough safety that useful truth can emerge.
A good rule of thumb: if the question could make someone feel exposed, make sure anonymity, facilitation boundaries, and follow-up safety are clear before asking it.
### Turn answers into experiments, not just discussion
Better questions only improve the team if the answers lead somewhere. A retrospective should not end with a long list of observations and no clear next step. As Atlassian notes in their [retrospective guide](https://www.atlassian.com/team-playbook/plays/retrospective), the value of a retro comes from insights that actually get implemented. Once the team has identified an issue, turn it into a small experiment, assign an owner, and agree how you'll check whether it helped.
Instead of ending with "We need better communication," turn it into something testable:
- "For the next sprint, we'll add a five-minute dependency check after daily standup."
- "The Scrum Master will review whether blockers are being raised earlier."
- "We'll revisit this in the next retro and decide whether to keep, change, or stop it."
Once the team agrees on an improvement, capture it as a visible action item with an owner and revisit it in the next retrospective. TeamRetro makes it easy to [track retrospective action items](/retrospectives/features/) so nothing slips through the cracks between sprints.
### Use question combinations to avoid overwhelm
With 100 questions to choose from, newer facilitators may wonder where to start. You do not need to use many questions in a single retro. In most cases, five well-chosen questions are better than fifteen loosely connected ones.
To avoid anchoring bias (where the first voice in the room shapes everyone else's thinking), consider structuring your retro so participants submit answers independently before group discussion. The [1-2-4-All method from Liberating Structures](https://www.liberatingstructures.com/1-1-2-4-all/) is a great technique for this: individuals reflect first, then pairs, then groups of four, before the whole team discusses.
Here are a few simple combinations:
**Low-energy sprint**
- 1 check-in question
- 2 workload or wellbeing questions
- 1 improvement question
- 1 closing commitment question
**High-performing sprint**
- 1 celebration question
- 2 questions about what worked well
- 1 question about what to protect or continue
- 1 action question to reinforce the behavior
**Tense or difficult sprint**
- 1 neutral check-in question
- 1 question about blockers or friction
- 1 anonymous psychological safety question
- 1 question about what support the team needs
- 1 small next-step commitment
**Remote or hybrid team retro**
- 1 connection question
- 2 remote collaboration questions
- 1 visibility or communication question
- 1 action question for improving team rhythm
The best retrospective questions are not the most clever ones. They are the ones your team is ready to answer and act on.
## Run better retros with TeamRetro
The right questions are only as good as the space you create to answer them. TeamRetro is an [agile retrospective](/retrospectives/) tool built for agile teams, with 275+ templates, anonymous idea submission, real-time voting, and built-in action tracking so every retro leads somewhere.
Ready to run a retro your team will actually look forward to? [Try TeamRetro free](/). No credit card required.
---
# Return on time invested (ROTI) in agile meetings
URL: https://www.teamretro.com/blog/return-on-time-invested/
We all value our time and the meetings we attend can either be a positive or negative use of that time. Irrespective of whether our meetings are face to face or online with our teams, the time we spend in them can leave us with a sense of whether or not the meeting was worthwhile. The Return on Time Invested, or ROTI for short as suggested by [Esther Derby](https://www.estherderby.com/calculating-meeting-roti-return-on-time-invested/) is a great way to help teams discover how much value is coming out of those meetings.
### What is the return on time invested (ROTI) in agile retrospectives?
A ROTI is an easy way of gauging how much value each meeting participant perceives their meeting delivered. Just prior to the close of the meeting, attendees are invited to rate their experience using a simple 1-5 rating method to assess whether they feel that the time they spent in the meeting was worthwhile.
Just as icebreakers are a great way to open meetings, ROTIs are a great way to close them; they help wrap up the session and draw focus on what could be done better next time.
Generally, it’s best to give participants the opportunity to provide their response anonymously and independently, as this creates a psychologically safe space in which they are more likely to be honest and their feedback is less likely to be influenced by others.
### Why should we rate the ROTI for our retros?
Rating your meeting’s ROTI allows you to monitor [meeting effectiveness](https://www.agileconnection.com/article/roti-method-gauging-meeting-effectiveness) and value.
Time, whether spent or borrowed, is a valuable commodity; it can therefore be frustrating for team members if they feel the time they spend on their retrospectives could be better directed elsewhere – especially when retrospectives are a core practice of agile methodology!
Rating a meeting’s ROTI gives each team member a platform to offer their opinion on the value of the meeting and present ways to improve it. Team members are therefore given a voice and contribute to the continuous improvement of their retrospectives and health checks. This empowers the team and helps them feel more engaged in the current and future meetings creating greater participation and buy-in.
The rating of a meeting’s ROTI provides Scrum Masters with [feedback](https://www.inc.com/john-eades/why-you-should-be-more-worried-about-your-return-on-time-instead-on-investment.html) they may otherwise have missed. That in itself is a great reason to find out your meeting ROTI.
### How do we rate the ROTI of the agile meeting?
TeamRetro offers you the choice to add a ROTI poll at the end of your retrospective or health check.
Each person evaluates the ‘Return’ on their own ‘Time Invested’ in the agile retrospective or health check on a scale of 1 to 5 by responding to a simple question.
**Was this retrospective worth your time?**
**1\. Definitely not.** A waste of my time.
**2\. Not really.** Useful, but not worth all of time.
**3\. Somewhat.** I gained enough to spend my time on it.
**4\. Mostly.** I gained more value than the time spent on it.
**5\. Absolutely.** I gained a lot of value and it was absolutely worth my time.
## Scrum Master tips for using the ROTI
### How do team members rate the ROTI of the meeting?
The value that each team member gets out of their agile retrospective or health check will vary from meeting to meeting, but there are a few decision criteria that can guide the rating.
**Information sharing**
Value can be obtained by receiving answers to questions or hearing information that can help you move forward with a task, avoid rework, improve the way you work or overcome an obstacle.
**Decision making**
There may have been a person, process or piece of information that was blocking progress so having this at the meeting can help move the needle in making a decision.
**Problem solving**
If the meeting highlights, addresses or explores options around improving the meeting, then there can be a clear sign of value.
**Work planning**
Prioritizing, re-prioritizing or even redefining future work may seem like a non-productive exercise but is a value-adding activity if it can create alignment, focus and direction.
**Team building and agreements**
An often neglected aspect of work meetings is building rapport, communication and team spirit. The value may not be as extrinsic as an output or artifact, but more intrinsic in terms of agreeing on the way the team works together.
### How can you introduce ROTI to your agile team?
Here are a couple of key messages worth sharing with the team when introducing ROTI.
- The ROTI is independent and anonymous. Be honest about what value you obtained.
- Results are not tracked. It should reflect the time and space of the meeting rather than an ideal score.
- Ratings should be sincere, fair and honest. This is your opportunity to share now.
- The goal is for continuous improvement rather than using it to pinpoint individuals, create blame, or criticize.
- Use a future-based statement such as, *In future meetings, I would get more value if we did X.*
**As the Scrum Master, you can help guide the quality of the ROTI by saying something like…**
*“I’d like to ask/invite you to indicate the value of the time spent on this meeting, in other words, was this meeting valuable for you? We’ll then look at the group results to see how we can improve the return on our time invested for future meetings.*
*Please be open and honest about how much value there was for you today. We will be doing this anonymously and independently.*
*In considering your score, ask if this meeting has added value by helping us:*
- *move forward with our work*
- *make decisions*
- *create appropriate actions*
- *solve a problem*
- *clear up confusion*
- *improve the way we work as a team*
*…we’ll then come back to review the scores”*
### How do I use ROTI to improve meeting effectiveness?
The results from the team signal the overall perceived value that the group gained from the meeting. Of course this will vary from meeting to meeting depending on the content and relevance, but in any case, the goal is to explore ways to improve the facilitation and meeting outcome process.
**Let’s say scores are in the 4’s and 5’s…**
Congrats! This meeting sounds like a resonating success. It may have been the meeting design, the content, the quality of facilitation or all of the above.
**Let’s say there are a few 2’s and 3’s…**
Okay, there was still some value gained, but certainly not on the positive side. What could we do to improve our ratings?
**Let’s say there are a few 1’s…**
Don’t worry! This doesn’t mean that you have done a poor job. It could have simply been that someone did not care about the topic or whose job was not impacted by it.
*“When people get really negative I’ll say ‘it sounds like you have a vision of how you want things to be’ or ‘if you can imagine a really effective meeting, what would it look like?” – Esther Derby*
### Closing off retrospectives… and this article.
Ready to do a Return on Time Invested with your team? Add it to your TeamRetro retrospective meeting or team health check and it will be displayed at the end of the meeting. You can capture the feedback and reveal the results in real-time or you can review the results later.
Get started with a free trial or [Login Now](https://secure.teamretro.com/), or do a [practice run with our fun robots.](https://secure.teamretro.com/demo/)
---
# Scrum paradigms: chickens vs pigs and the Observer Role in agile meetings
URL: https://www.teamretro.com/blog/scrum-paradigms-chickens-vs-pigs-the-observer-role-in-agile-meetings/
The Scrum framework has long been a beacon for teams striving for increased collaboration and efficiency. One of the most well-known metaphors within Scrum is the tale of pigs and chickens, which serves as a guiding principle for team involvement.
We have introduced a new meeting enhancement feature – the Observer Role – designed to bring a new dimension to your agile meetings. This will now allow you to have people join any meeting as a “view only” participant. This is a really useful feature for agile coaches, new recruits, cross team collaborations or for the supportive and empathetic leader.
You can [find out more about the observer role](https://help.teamretro.com/article/416-observer-role).
## The pigs and chickens story in scrum methodology
Before delving into the Observer Role, let’s revisit the classic metaphor of pigs and chickens in Scrum methodology. This metaphor originates from a simple but profound story illustrating the levels of commitment within a Scrum team.
In the story, the roles of pigs and chickens are used to differentiate between team members. Pigs are considered fully committed – they are the ones “in the game,” responsible for the project’s success. On the other hand, chickens are involved but not committed. They might provide input, but it’s the pigs who have skin in the game. Think of it as Eggs Vs Bacon. To illustrate, here’s a funny ditty:
***Scene:** A cozy barn where Cluckington and Porkington are having a chat.*
**Cluckington (Chicken):** Hey Porkington, I’ve been thinking about this whole pigs-and-chickens thing in Scrum. What’s the deal with that?
**Porkington (Pig):** Ah, Cluckington, it’s quite simple. In the world of Scrum, we’re all on a team, working toward a common goal. But the pigs and chickens metaphor helps distinguish the level of commitment each member has.
**Cluckington:** Commitment, you say? I’m committed to laying eggs every day; isn’t that enough?
**Porkington:** It’s more about being fully invested, Cluckington. You see, in our Scrum team, the pigs are the ones with skin in the game. They’re the folks committed to the project’s success, contributing directly to the end result.
**Cluckington:** So, what does that make me, then? Am I not contributing?
**Porkington:** Of course, you contribute, Cluckington! You’re like a chicken in the metaphor – involved, offering ideas and feedback, but not entirely committed like the pigs. It is not about the quantity of contribution; it is about the level of skin in the game.
**Cluckington:** Fair enough. But sometimes, I feel left out. Is there a role for someone like me who wants to be part of the process but isn’t a pig?
**Porkington:** Funny you should ask, Cluckington. Recently, in our agile meetings using TeamRetro, they introduced an Observer Role. Observers are like chickens – present and contributing by being a fresh set of eyes without actively participating in the discussion.
**Cluckington:** That sounds intriguing. It’s like being part of the process without being in the frying pan, right?
**Porkington:** Exactly!
**Cluckington:** I like the sound of that. It’s like having the best of both worlds – involvement without the pressure.
***End Scene:*** *Cluckington and Porkington continue their barnyard banter, embracing the diversity of roles within their Scrum team.*
## The importance of observers in team meetings
Observers play a vital role in providing fresh viewpoints without actively participating in the discussion. Their outsider perspective can bring new insights, identify blind spots, and foster a more inclusive environment. This is especially important in complex projects where diverse perspectives can lead to better decision-making.
For the safety and acknowledgment of all team members, observers will always be named in TeamRetro. This transparency ensures that everyone understands their role and contribution to the meeting. It also fosters a culture of trust and openness within the team.
## Value for the team, Scrum Master, and the observer
Whichever way you look, inviting a trusted observer into your agile meeting can serve up a buffet of benefits.
- **For the team**
- Improved collaboration: Including observers fosters an open and inclusive team culture, encouraging collaboration beyond the core team.
- Opportunity to get new perspectives: If wanted, the team can have the observer look at their process, their dynamics or ask for any feedback after the meeting.
- **For the Scrum Master**
- Enhanced facilitation: The Scrum Master can leverage the observer role to facilitate more insightful discussions and guide the team toward better outcomes.
- Risk mitigation: Observers can identify potential risks or challenges that the team might overlook, contributing to more comprehensive risk management.
- **For the observer**
- Learning opportunities and onboarding: Observers gain valuable insights into the team’s dynamics, processes, and challenges, providing a unique learning experience.
- Networking and acknowledgment: By being named and acknowledged, observers feel a sense of belonging and appreciation, fostering positive relationships within the organization.
- Bridge gaps: Observers can act as conduits for knowledge transfer between different teams or departments, fostering cross-pollination of ideas and practices.
- Guidance from afar: Seasoned team members can take on the observer role to mentor less experienced colleagues, providing guidance without directly intervening in the discussion. These discussions can happen after the meeting.
- **For the leadership**
- Holistic perspective: While leaders may have a broad strategic view of the organization, they can gain a nuanced understanding of team dynamics and ground level processes in the observer role. This can contribute to more informed decision-making.
- Understanding team challenges: Observing without actively participating allows leaders to empathize with the daily challenges of the team which can lead to more empathetic leadership and breaking down silos.
## Rules and considerations for the observer role
One of the key conditions is that the observer must do just that… observe. So, here are the rules of engagement (or non-engagement as the case may be). This is important for all observers, no matter which level or role you have!
1. **No active participation (Hands-off approach)**
Observers should refrain from actively contributing ideas, comments, or votes during the meeting. Their role is to observe and absorb without influencing the team’s decisions in any way. It might be tough, but resisting the temptation to intervene while still actively observing to make this role work.
2. **Named and acknowledged**
Observers will always be named during the meeting for transparency and accountability. This ensures that their presence is known to everyone, promoting openness and trust.
3. **Respect team dynamics**
Observers should be mindful of the team’s dynamics and avoid disrupting the natural flow of the meeting. They are there to enhance, not detract from, the team’s collaborative process.
4. **Confidentiality and safety**
Observers must adhere to the same confidentiality and safety standards as other team members. Any information shared during the meeting, including discussions and decisions, should be treated with utmost confidentiality.
5. **Limited frequency**
To maintain the integrity of the observer role, team members should rotate through the position to ensure that everyone has an opportunity to benefit from the fresh perspective without becoming a permanent observer.
6. **Feedback channels**
Establish channels for observers to provide constructive feedback if requested, outside of the meeting. This allows them to share their insights and suggestions without disrupting the flow of the team and respecting boundaries.
7. **Clear communication**
Team members and observers should communicate openly about expectations and boundaries. This includes clarifying the purpose of the observer’s presence and any specific areas they should focus on. For example, you could ask the observer to take notes on what behaviors helped to progress the meeting positively or which parts of the process did the team get stuck on.
By sticking to these rules, the Observer Role becomes a powerful tool for enriching team dynamics, fostering learning, and promoting a culture of continuous improvement within agile teams.
So, as you embrace this new feature, remember the essence of the pigs-and-chickens metaphor and how the Observer Role complements it by bringing external insights into your agile meetings. Perhaps it’s the new recruit joining the company and you want to show them how an agile meeting works. Perhaps it is the leadership wanting to be more understanding of how the team operates, or perhaps you have an agile coach whose role it is to help guide and develop the team as they embark on their agile journey.
TeamRetro is here to empower your team with the tools you need to thrive in an ever-evolving agile landscape.
Happy observations!
---
# Sprint retrospective vs. release retrospective
URL: https://www.teamretro.com/blog/sprint-retrospective-vs-release-retrospective/
Retrospectives are like the pit stops of Agile practices — a chance to refuel, check the tires, and maybe even grab a snack. But not all retrospectives are built the same. Two popular types — sprint retrospectives and release retrospectives — each have their own role to play in a project’s journey. In this post, we’ll break down the key differences between the two and share a step-by-step guide to running a great release retrospective. Spoiler alert: no actual snacks provided.
## Sprint retrospective vs. release retrospective: key differences
Both sprint and release retrospectives are designed to promote reflection and improvement, but they differ in their scope, timing, and focus. Here’s a breakdown of the key differences:
| Aspect | Sprint Retrospective | Release Retrospective |
| :-- | :-- | :-- |
| Scope | Focuses on a single sprint (1–4 weeks) | Focuses on the entire release cycle (multiple sprints) |
| Timing | Held at the end of every sprint | Held after a major release or milestone |
| Audience | Development team, Scrum Master, and Product Owner | Broader audience, including stakeholders and clients |
| Goals | Immediate process improvements for the next sprint | Strategic insights for future releases |
| Outputs | Actionable tasks for the next sprint | Comprehensive lessons learned and recommendations |
| Focus Areas | Team dynamics, sprint execution, process efficiency | Product quality, user feedback, team collaboration |
| Formality | Can be formal or casual | Tends to be formal, structured and well prepared |
**Sprint Retrospective:**
Sprint retrospectives are tactical. They emphasize short-term process improvements, collaboration, and delivery within a sprint cycle. These meetings are typically brief and focus on identifying what worked, what didn’t, and what to improve immediately.
**Release Retrospective:**
Release retrospectives are strategic. They look at the broader picture, including the product’s success, alignment with business goals, and long-term process improvements. These sessions involve a wider audience and delve into more comprehensive feedback and outcomes.
## Key steps to run a successful post-release retrospective
Conducting a release retrospective is vital for analyzing a project’s successes and challenges throughout its lifecycle. Below, we outline the main steps to ensure your retrospective is productive and actionable.
### 1. Set the stage
Create a welcoming environment and clearly outline the retrospective’s objectives. Given the audience, duration, and amount of time required, it’s also important that people are comfortable and that the venue or technology is suitable.
- **Welcome Participants**: Introduce all attendees and explain their roles.
- **Define the Goal**: Clearly state the purpose, such as reflecting on the release’s performance, learning from challenges, and planning improvements.
- **Encourage Open Communication**: Set a tone of psychological safety where participants feel comfortable sharing honest feedback.
### 2. Reflect on achievements
Celebrate successes and build a positive foundation for the discussion.
- Highlight key milestones and achievements.
- Showcase metrics or data that illustrate success (e.g., user adoption, performance metrics).
- Recognize individual and team contributions.
**Guiding question**: What were the major wins and outcomes from this release?
### 3. Identify challenges
Pinpoint obstacles and areas for improvement.
- Discuss what didn’t go as planned, using specific examples.
- Explore the root causes of these challenges.
- Gather input from diverse perspectives to uncover blind spots.
**Guiding question**: What difficulties did we face, and how did we handle them?
### 4. Evaluate processes
Examine the effectiveness of workflows and tools.
- Review how well the team followed established processes.
- Identify inefficiencies or bottlenecks.
- Discuss the effectiveness of tools and technologies used during the release.
**Guiding question**: What processes, tools, or methods were useful or not useful?
### 5. Reflect on team dynamics
Assess how well the team collaborated and communicated.
- Highlight instances of strong collaboration.
- Identify areas where communication could improve.
- Discuss team morale and workload management.
**Guiding Question**: How did team dynamics affect the overall success of the release?
### 6. Gather stakeholder and user feedback
Incorporate external perspectives to assess the release’s impact.
- Present feedback from stakeholders, clients, and users.
- Analyze whether the release met their expectations.
- Discuss any gaps between the delivered product and the initial vision.
**Guiding question**: How well did we meet stakeholder and user expectations?
### 7. Identify lessons learned
Extract insights to guide future projects.
- Reflect on both successes and failures.
- Highlight transferable lessons for future releases.
- Document key takeaways.
**Guiding question**: What did we learn that can help us in the future?
### 8. Create actionable improvements
Turn insights into concrete actions for improvement.
- Brainstorm ideas for process, tool, or communication improvements.
- Prioritize actions based on impact and feasibility.
- Assign ownership for each action item.
**Guiding question**: What key actions should we take going forward?
### 9. Close with gratitude
End on a positive note by appreciating the team’s efforts.
- Thank participants for their contributions to the release and retrospective.
- Reinforce the importance of their work and input.
**Guiding question**: What or who are we thankful for?
Sprint and release retrospectives are both powerful tools for fostering continuous improvement, but their effectiveness hinges on understanding their differences and tailoring each session to its purpose.
Sprint retrospectives are focused and tactical, while release retrospectives are broad and strategic. By following the steps outlined above, you can run a successful release retrospective that delivers actionable insights, strengthens team dynamics, and sets the stage for future success.
Need a simple way to share and capture ideas? Check out TeamRetro’s Release Retrospective Template today.
---
# Team Spectrum: a 'Would You Rather' team building game for meetings
URL: https://www.teamretro.com/blog/team-spectrum-icebreaker-game/
Every team has opinions. Strong ones. Quietly held ones. Ones nobody knew existed until someone asked. If your team enjoys "Would You Rather", Team Spectrum is the team-building game that takes the same idea and turns it into a window into how well you actually know each other.
## What is Team Spectrum?
Team Spectrum is a team-building game (sometimes called a *human barometer* or a *"where do you stand"* activity) where a topic is placed on a spectrum and each team member must **guess where their colleagues would place themselves** before the big reveal. Think:
The twist? You're not just sharing where you stand; you're testing how well you actually know your teammates. Surprises are guaranteed.
It works brilliantly for [remote teams](/blog/virtual-icebreakers-for-remote-teams/), in-person [retrospectives](/retrospectives/), or as a warm-up before any meeting where you want people to feel relaxed and present.
## Why Team Spectrum works
Most icebreakers ask people to share something about themselves. Team Spectrum flips that: it asks people to **think about others first**. That small shift creates a completely different dynamic:
- **It sparks genuine curiosity.** Trying to predict someone else's answer means you're actually thinking about them as a person.
- **The reveal is the fun part.** When someone places themselves far from where the group expected, the conversation that follows is priceless.
- **It's low-stakes but high-engagement.** There are no wrong answers, no expertise required, and no pressure, just a fun window into how your team thinks.
- **It builds empathy.** Discovering you misjudged a colleague's view on something opens a door to understanding them better.
## How to run Team Spectrum
### What you need
- A whiteboard, virtual whiteboard (Miro, FigJam, etc.), or the ready-to-play [Team Spectrum game](https://games.teamretro.com/games/team-spectrum/)
- A list of spectrum topics (see below for ideas)
- 5–15 minutes
### Step-by-step
1. **Draw the spectrum.** Create a horizontal line with two opposing labels at each end. For example:
2. **Everyone secretly guesses.** Each team member privately notes (or places a marker for) where they think *each of their colleagues* falls on the spectrum. Give people 60–90 seconds.
3. **Teammates reveal themselves.** One by one, each person places themselves on the spectrum and explains why.
4. **Compare with the guesses.** See who predicted correctly, and celebrate the surprises.
5. **Debrief briefly.** Ask: *"Did anything surprise you? What does that tell us about how well we know each other?"*
Repeat with a new topic, or move into your main meeting with the energy already flowing.
Prefer a ready-made version? The free [Team Spectrum game](https://games.teamretro.com/games/team-spectrum/) does the setup for you: pick a theme, and AI will generate a whole bunch of topics for you, or you can always customize your own. Then everyone guesses where each teammate lands before the reveal. No whiteboard, no prep.
Playing Team Spectrum: each round puts a teammate on a spectrum and the group guesses where they land.
## Team Spectrum topic ideas
The best topics are light-hearted, relatable, and just a little revealing. Here are some to get you started, and if you want more prompts, browse our [icebreaker games](/icebreakers/icebreaker-games/) and [icebreaker questions for work](/icebreakers/icebreaker-questions-for-work/), or run the statement version with these [agree or disagree questions](/icebreakers/agree-or-disagree-questions/).
**Work style**
**Opinions & preferences**
**Fun & personality**
**For new hires & onboarding**
**For retrospective warm-ups**
## Tips for facilitators
- **Go first.** Place yourself on the spectrum before anyone else reveals. It sets the tone and lowers the barrier for others.
- **Encourage the "why".** The spectrum position is interesting; the reasoning behind it is where the real connection happens.
- **Keep topics inclusive.** Avoid anything that could feel political, personal, or divisive. The goal is warmth, not discomfort.
- **Use it regularly.** The game gets richer over time as teams build a shared history of surprising each other.
- **Virtual teams:** Use your cursor or a sticky note to place your position on a shared digital board. It works just as well remote as it does in person.
## Frequently asked questions
**How do you play Team Spectrum?** Place a topic on a spectrum with two opposing labels at each end. Before anyone reveals their own position, each person guesses where their teammates would place themselves. Then everyone reveals their real spot and compares it with the guesses.
**Is Team Spectrum good for remote teams?** Yes. It works just as well remotely as in person: players place a marker on a shared digital board, or use the free online game so everyone can join from anywhere.
**How is it different from Would You Rather?** Would You Rather asks you to pick between two options. Team Spectrum uses a sliding scale instead of a binary choice, and adds a guessing round, so it reveals how well teammates actually know each other, not just their preferences.
**Is Team Spectrum like Wavelength?** They share the spectrum dial, but the goal is different. Wavelength is a party game where one person gives a clue for a hidden target and the group hunts for it. Team Spectrum has you guess where a teammate really stands, so it plays as a get-to-know-your-team round rather than a bluffing game. If you want a work-friendly version, try our [Wavelength alternative](https://games.teamretro.com/alternatives/wavelength-alternative/) built for teams.
**How long does Team Spectrum take?** A single round takes about five minutes. Run one topic as a quick warm-up, or several in a row for a longer session.
## Try Team Spectrum in your next meeting
Team Spectrum takes five minutes and leaves people genuinely more curious about the people they work with every day. That curiosity, that small spark of *"I didn't know that about you"*, is exactly what high-performing teams are built on.
It's free to play, with no sign-up required, so you can run it at your next meeting in minutes.
---
# TeamRetro templates now available in multiple languages!
URL: https://www.teamretro.com/blog/teamretro-templates-now-available-in-multiple-languages/
We’ve got some exciting news to share here at [TeamRetro.](/)
Our standard retrospective templates are now available in multiple languages, including French, Spanish and German.
Thank you to our TeamRetro subscribers who suggested this, upvoted and made our online retrospective tool more accessible. With our platform used in over 100 countries worldwide we will continue to make common translations in TeamRetro in various languages.
For now, let’s look at how to access this new feature.
### Step 1: sign in to TeamRetro
Sign in to your TeamRetro account and then click create team.
### Step 2: create your retrospective in your chosen language
Once you’re in your team space, click on Retrospectives and Create Retrospectives to view all the available templates. On the top right hand corner you will see options for multiple languages that you can choose for your retrospective templates.
### Step 3: start your retrospectives
Conduct your retrospectives like you would normally in the language or multiple languages that you and your team prefer.
This new feature of the TeamRetro retrospective templates is also available on the mobile app version.
We hope that you enjoy this new added feature to TeamRetro.
### Have suggestions for other languages?
If you have any suggestions for other languages, make sure you add them in the request feature in your account.
If you don’t have an account with TeamRetro as yet, the good news is that you can try it out [FREE for 30 days.](https://secure.teamretro.com/login/new?cc=www-blog)
### Have questions about our multiple languages templates?
Please get in touch with the TeamRetro team if you have any questions or suggestions for improvements for this new feature.
Thank you again to our global TeamRetro agile and scrum teams for suggesting this new feature and making our templates more accessible for teams around the world.
We look forward to releasing more languages soon.
---
# TeamRetro’s newest integration with Microsoft Teams
URL: https://www.teamretro.com/blog/teamretros-newest-integration-with-microsoft-teams/
Thanks to our supportive TeamRetro users and Customer Advisory Group who recently requested for “Integration to publish to [MS Teams](https://www.microsoft.com/en-au/microsoft-365/microsoft-teams/group-chat-software),” we’ve been able to make this newest integration possible.
Let’s take a look at what this new integration with Microsoft Teams means and how you can access it for your retrospectives.
### What is the MS Teams integration?
We have deployed our Microsoft Teams integration, which means you can now invite your team and publish action items to your MS Teams Channels.
### Why do we need this new MS Teams integration?
Integrating TeamRetro with your existing workflow and communications means that you can easily use TeamRetro with other popular engagement and task platforms.
Being able to move from one platform to another seamlessly or import data and reports together helps to improve productivity and quality of your operations and, in this case, retrospectives.
In addition to this new integration with MS Teams, [TeamRetro](/) also works with these other existing task management tools so nothing falls off the radar:
- Jira
- [Asana](https://asana.com/)
- [Trello](https://trello.com/)
- [Github](https://github.com/)
### When is a good time to use this integration feature?
With remote working and distributed teams on the rise, we see many more teams meeting virtually, and using Microsoft Teams to facilitate conversations, brainstorming and of course, retrospectives. We’ve made this integration a priority to meet this trend and to support teams all over the world do their retros.
### Who can access this MS Team integration?
Whoever is your TeamRetro facilitator, they will be able to create the TeamRetro activity and get the invite code/link to post in MS Teams chat. Everyone else in the team can then access the TeamRetro activity through and in the chat.
### How does the MS Team integration work?
To access this new integration with MS Team, simply follow these steps:
1. Create your TeamRetro [space or activity](/retrospectives/) and then on the invite team screen click on code/link.
2. Copy the URL for your TeamRetro activity and then post the invite in Microsoft Teams.
3. Once your team members click on the link they will be able to view the TeamRetro activity you have created.
4. You can also then post your team action items into your MS Teams channel so that you can keep on top of your retrospective or [health check action items.](/integrations/microsoft-teams/)
Thank you again to our active TeamRetro users and Customer Advisory Group for suggesting this new integration. We hope this new feature will help all teams run retros successfully in an online or distributed environment.
### Try TeamRetro today!
Want to try TeamRetro for your next team retrospectives?
[View a demo with our fun bots](https://secure.teamretro.com/demo/retrospectives/scrum-retrospective) to check all the features of TeamRetro. Or [Try it FREE](https://secure.teamretro.com/login/new?emailAddress=&cc=www-blog) for 30 days today.
---
# 73 teamwork quotes to motivate and inspire your team
URL: https://www.teamretro.com/blog/teamwork-quotes/
Great work is rarely a solo act. The right words at the right moment (at the start of a standup, in a retrospective, or pinned in a team channel) can remind a group why they are better together. Below are 73 teamwork quotes, grouped so you can grab the right tone fast, followed by a few simple ways to put them to work. Where a famous line is usually credited to the wrong person, we say so.
This list is kept by the team at TeamRetro. TeamRetro is an online retrospective, team health check, estimation, and standup tool built for Scrum Masters, agile coaches, and team leads running remote, hybrid, or in-person agile teams.
## Motivational teamwork quotes
- *"Alone we can do so little. Together we can do so much."* — Helen Keller
- *"Talent wins games, but teamwork and intelligence win championships."* — Michael Jordan
- *"Coming together is a beginning; keeping together is progress; working together is success."* — Often attributed to Henry Ford
- *"None of us is as smart as all of us."* — Popularized by Ken Blanchard
- *"The strength of the team is each individual member. The strength of each member is the team."* — Phil Jackson
- *"The purpose of an organization is to enable common men to do uncommon things."* — Peter Drucker
- *"There is no comradeship except through union in the same high effort."* — Antoine de Saint-Exupéry
## Famous quotes about teamwork
- *"If you want to go fast, go alone. If you want to go far, go together."* — Proverb
- *"Great things in business are never done by one person. They're done by a team of people."* — Steve Jobs
- *"Individual commitment to a group effort — that is what makes a team work, a company work, a society work, a civilization work."* — Often attributed to Vince Lombardi
- *"It is literally true that you can succeed best and quickest by helping others to succeed."* — Napoleon Hill
- *"If I have seen further it is by standing on ye sholders of Giants."* — Isaac Newton
- *"No man is an island, entire of itself; every man is a piece of the continent, a part of the main."* — John Donne
- *"All for one, one for all."* — Alexandre Dumas
- *"We few, we happy few, we band of brothers."* — William Shakespeare
## Quotes about collaboration
- *"Many ideas grow better when transplanted into another mind than in the one where they sprang up."* — Oliver Wendell Holmes Sr.
- *"Cooperation is the thorough conviction that nobody can get there unless everybody gets there."* — Virginia Burden
- *"Unity is strength… when there is teamwork and collaboration, wonderful things can be achieved."* — Mattie Stepanek
- *"Talent is a gift, but teamwork is a decision a team makes every day."* — Anonymous
- *"A boat doesn't go forward if each one is rowing their own way."* — Swahili proverb
- *"He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me."* — Thomas Jefferson
- *"If you have an apple and I have an apple, and we swap apples — we each end up with only one apple. But if you and I have an idea and we swap ideas — we each end up with two ideas."* — Charles F. Brannan
- *"For we are made for co-operation, like feet, like hands, like eyelids, like the rows of the upper and lower teeth."* — Marcus Aurelius
- *"What do we live for, if it is not to make life less difficult to each other?"* — George Eliot
- *"'Men work together,' I told him from the heart, 'Whether they work together or apart.'"* — Robert Frost
- *"Given enough eyeballs, all bugs are shallow."* — Eric S. Raymond
## Quotes about teamwork and unity
- *"We live by each other and for each other."* — Helen Keller
- *"By uniting we stand, by dividing we fall."* — John Dickinson
- *"For the strength of the Pack is the Wolf, and the strength of the Wolf is the Pack."* — Rudyard Kipling
- *"We are caught in an inescapable network of mutuality, tied in a single garment of destiny."* — Martin Luther King Jr.
- *"We might have our differences, but we are one people with a common destiny in our rich variety of culture, race and tradition."* — Nelson Mandela
- *"For harmony makes small states great, while discord undermines the mightiest empires."* — Sallust
- *"That which is not good for the swarm, neither is it good for the bee."* — Marcus Aurelius
- *"A person is a person through other people."* — Zulu proverb
- *"United, there is little we cannot do in a host of cooperative ventures."* — John F. Kennedy
## Leadership and teamwork quotes
- *"No man will make a great business who wants to do it all himself, or to get all the credit of doing it."* — Andrew Carnegie
- *"There is no limit to what a man can do so long as he does not care a straw who gets the credit for it."* — C. E. Montague
- *"Leadership consists of nothing but taking responsibility for everything that goes wrong and giving your subordinates credit for everything that goes well."* — Dwight D. Eisenhower
- *"A manager's task is to make the strengths of people effective and their weakness irrelevant."* — Peter Drucker
- *"The manager's function is not to make people work, but to make it possible for people to work."* — Tom DeMarco
- *"The first responsibility of a leader is to define reality. The last is to say thank you. In between the two, the leader must become a servant and a debtor."* — Max De Pree
- *"Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity."* — George S. Patton
- *"It is better to first get the right people on the bus, the wrong people off the bus, and the right people in the right seats, and then figure out where to drive."* — Jim Collins
- *"The secret is cooperation between components toward the aim of the organization."* — W. Edwards Deming
## Sports quotes about teamwork
- *"The main ingredient of stardom is the rest of the team."* — John Wooden
- *"A player who makes a team great is more valuable than a great player. Losing yourself for the group, for the good of the group — that's teamwork."* — John Wooden
- *"To me, one of the most beautiful things to see is a group of men coordinating their efforts toward a common goal — alternately subordinating and asserting themselves to achieve real teamwork in action."* — Bill Russell
- *"Teamwork is what the Green Bay Packers were all about. They didn't do it for the individual glory. They did it because they loved one another."* — Vince Lombardi
- *"Ball players know that it isn't individuals who count. It's the way a team plays as a whole that determines its offensive power or its defensive strength."* — Babe Ruth
- *"The player has to understand he is part of a team, with 10 other players. If every player plays like a jazz musician, it will be chaos."* — Pep Guardiola
- *"We must all live together and work together no matter what race or nationality."* — Roberto Clemente
## Funny teamwork quotes
- *"Teamwork is important — it helps to put the blame on someone else."* — Anonymous
- *"There is no 'I' in team, but there is a 'me' if you look hard enough."* — Anonymous
- *"Teamwork: simply stated, it is less me and more we."* — Anonymous
- *"A team is a group of people who all blame each other when something breaks in production."* — Anonymous
- *"Together Everyone Achieves More — except, perhaps, on a Monday morning."* — Anonymous
- *"Coming together is a beginning. Staying together through a four-hour planning meeting is a miracle."* — Anonymous
## Short teamwork quotes
- *"Teamwork makes the dream work."* — Popularized by John C. Maxwell
- *"Many hands make light work."* — Proverb
- *"Two heads are better than one."* — Proverb
- *"Unity is strength."* — Proverb
- *"Strength in numbers."* — Proverb
- *"A threefold cord is not quickly broken."* — Ecclesiastes 4:12
- *"A problem shared is a problem halved."* — Proverb
- *"A rising tide lifts all boats."* — Proverb
- *"A chain is only as strong as its weakest link."* — Proverb
- *"There's no 'I' in team."* — Proverb
- *"We're all in this together."* — Proverb
- *"Together we win."* — Anonymous
## Teamwork quotes for remote and distributed teams
- *"Distance means so little when a team means so much."* — Anonymous
- *"You don't need to share a room to share a goal."* — Anonymous
- *"The best remote teams over-communicate the small things so the big things take care of themselves."* — Anonymous
- *"Trust is the bandwidth a distributed team runs on."* — Anonymous
## How to use teamwork quotes with your team
A quote on a slide is forgettable; a quote that opens a conversation sticks. A few easy ways to use them:
- **Open a meeting or standup.** Lead with one quote and ask, "Where did we live this last week, and where did we not?" It turns a platitude into a real check-in. Our [check-in questions](/icebreakers/check-in-questions/) work the same way.
- **Theme a retrospective.** Pick a quote about collaboration or trust and use it as the lens for the session: a light framing that focuses the discussion. See more [icebreaker questions](/icebreakers/) for openers by use case.
- **Recognize good teamwork.** Pair a quote with a specific shout-out ("this is exactly what 'together we are an ocean' looked like this sprint") so praise lands as genuine, not generic.
- **Pin one in your team channel.** A rotating weekly quote is a small, low-effort culture ritual (the same idea as a [question of the day](/icebreakers/question-of-the-day/)).
The point is never the quote itself: it is the moment of reflection it creates. Used well, these few words give a team a shared language for the kind of collaboration that makes good work possible.
---
# Learn about agile principles with the Coin, Paper Airplane, DevOps games and more.
URL: https://www.teamretro.com/blog/the-best-agile-games-for-building-teams-learning-and-creativity/
Agile Games are a great way to get your team familiar with and to practice the key principles of agile software development. They create a safe space for teams to explore their creativity, problem-solving, and communication in a fun way. Want to know more about what makes them tick? [Read more here.](/guides/scrum-masters-retrospective-guide/agile-games-facilitate-team-building/)
Here are some of the best agile games you can run with your Scrum team. There are options for face-to-face, remote, or hybrid teams. Each comes with a recipe set designed to help you facilitate the game and to draw out key learnings from the team. We’ve broken down the games into particular areas to help you better choose the one that best fits your team.
These games are all about practising agile principles. If you’re after broader bonding, energy, and trust activities instead, see our [team building games for work](/icebreakers/team-building-games-for-work/). Games aimed specifically at a retrospective sit in their own guide: [retrospective games](/guides/retrospective-games/), grouped by what each one fixes.
## Best agile games for agile principles
### Ball Point Game
Experiment and play in multiple teams while learning about continuous improvement.
Learning goals: Agile production process and iterative working
Time to play: 60 minutes
In person or Virtual: Both
Number of players: 4+ players
Resources required: Ping pong balls – multicolored can be fun.
How the game works:
The objective of Ball Point is to help the Scrum team navigate agile projects better. By understanding the agile production process, the team can appreciate the importance of self-organization, flow, and iterative working.
**Agile ball game rules**
The goal is to, as one team, get as many balls through the system as possible in 3 sprints.
The rules are as follows
- There are 3 minutes per iteration and 5 iterations
- In between, there is a 1-minute retrospective
- The ball needs to start and end with the same person
- The ball must have passed through everyone in the team
- The ball must have air time
- It can’t be passed to the person next to them.
- If the ball is dropped, it does not count.
Gather the team and provide the goals and instructions.
Ask them to estimate how many balls they will get through each iteration. You can do one estimation at the start of the cycle and another short estimation in between each iteration.
Start the process and time the activity. Let them play it out, and then record the number of balls transferred. Record the score and then time their retrospective, allowing them to change how it is played. They can then come up with new strategies as well as new estimates.
Repeat the above process for as many iterations as possible, recording the score.
Once all iterations are completed, run a debrief. You can ask questions such as
- What was your experience like in the game?
- How did the iterations differ?
- What changes did you make, and what effect did they have?
- How important were the retrospectives? What would have happened if there was none, more or less time to reflect?
- How different was the last iteration from the first?
- Did you experience the concept of flow?
- Which iteration stood out?
- How did you feel like working as a team?
- Did leadership change during the iterations?
- What did you learn from playing this game?
**Variations to the Agile ball point game**
You can add to this challenge by
- Grouping the large groups into smaller ones and creating zones where people can stand.
- Having rules around which colored or numbered balls have to go first
- Creating a little chaos by having a call for people to have to switch positions
### Paper Airplane Game
A good game that explores continuous improvement and Lean workflow.
Learning goals: Lean workflow, value stream mapping
Time to play: 60 minutes
In person or Virtual: Both
Number of players: 4+ players
Resources required: Recycled or scrap paper
How the game works:
The goal of the paper airplane game is to fold as many airplanes as possible in a given timeframe, but only one person can make a fold at a time.
**Paper Airplane game rules**
The goal is to, as one team, make as many paper planes of the same design.
The rules are as follows
- There are 3 minutes per iteration and 5 iterations
- In between, there is a 1-minute retrospective
- The airplanes folded must be of the same design and quality.
- Only one person can fold at any one time. Others can do other things as needed for their design.
Gather the team and provide the goals and instructions.
Ask them to agree on the design of the airplane. It can be a simple design with a few drawings that can fly one meter. This includes an element of design, production, and quality testing.
Start the process and time the activity. Let them play it out and then record the number of airplanes that have met the quality requirements. Record the number of airplanes created.
Now time the retrospective, allowing people to change how they work in the next round. They can provide a new estimate if they wish.
Repeat the above process for as many iterations as possible, recording the number each time.
Once all iterations are completed, run a debrief. You can ask questions such as
- Where did you notice you were waiting (waste)?
- How often was everyone engaged?
- What changes were made, and how did they affect the production process?
- What design aspects could make the flow slower or faster?
- How would this game differ if it was played virtually versus in person?
- How did quality controls play a part in this process?
- Did you experience the concept of flow?
- Which iteration stood out?
- How did you feel like working as a team?
- Did leadership change during the iterations?
- What did you learn from playing this game?
**Variations to the Paper Airplane game**
You can vary to this challenge by
- Timing how long it would take the team to create a set number of planes.
- Increasing or decreasing the complexity of the design of the airplane.
- Introducing quality control at the midpoint of the game rather than at the end.
- Increase the difficulty, e.g., the airplane must fly at least 2 meters to count.
### Chocolate Bar Game
Become a product owner and get feedback on your ultimate chocolate bar.
Learning goals: Product ownership, iterative feedback, customer value
Time to play: 60 minutes
In person or Virtual: Both
Number of players: 3+ people
Resources required: Recycled or scrap paper
How the game works:
The goal of the Agile Chocolate Bar game is to create the most attractive chocolate bar to your customers as possible.
Agile Chocolate Bar game rules
The goal is a Scrum simulation where you have to create a chocolate bar that is the most attractive to your customers within a certain set of constraints.
The rules are as follows
- For each team, there should be a designated Product Owner. Otherwise, for a small group, each person is also a product owner.
- There is an iteration round (3 minutes) and a feedback round (1min) for each phase.
- There are at least 3 phases.
Gather the team and provide the goals and instructions.
Set a timer for 3 minutes and each team or person creates an example of a chocolate bar they think their customers would love. They can draw this out with as much or as little detail as possible for the “Plate of DOD (Definition of Done, or Done and delivered).”
Then they have 1 minute to present what they have on their plate and get feedback from the rest of the group, who will act as customers. Customers can request changes or simply provide feedback.
Based on the feedback, they then redesign the chocolate bar to be presented on the “Plate of DOD”.
Each phase is repeated until the allotted time elapses.
Once all phases are completed, run a debrief. You can ask questions such as
- How did you decide how to design your chocolate bar in each phase?
- How useful was the feedback from customers, and how did you improve the feedback asked for from each round?
- How did you measure the value of the chocolate bar to the customer each time to make improvements?
- If you didn’t measure customer value, why not?
- How did the feedback you received influence the design of the chocolate bar?
- What trade-offs did you have to find in the design?
- What proportion of the customers did you satisfy at the end?
- Would you have personally bought this chocolate bar?
- Were there any features that were added that did not come from customer feedback?
- Were any agile processes applied in the game, such as backlog, dot voting, or prototyping?
- What else did you learn from this activity that you wanted to share?
**Variations to the Chocolate Bar game**
You can vary to this challenge by
- Adding a score from each customer each round on their likelihood to buy the chocolate bar.
- Allowing or not allowing the design team to listen to customer feedback sessions (e.g., just the product owner gets the feedback).
- Adding constraints to the design of the chocolate, such as materials or size.
### Coin Game
Get flipping with a kanban workflow challenge that will help teams stay active.
Learning goals: The first principle of the Agile Manifesto, Continuous deployment
Time to play: 15 minutes
In person or Virtual: Both
Number of players: 3+ people
Resources required: 20 coins – They don’t have to be the same.
How the game works:
The goal of the coin game is to learn about the first principle of the agile manifesto, which is “ Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
**The Coin Game rules**
The goal of this game is to work out the fastest way to deliver value to the customer as a team. Essentially this means comparing agile to traditional approaches and determining the best batch size.
The rules are as follows
- There is a set number of coins representing value to the customer.
- Each coin needs to be flipped by each person along the value chain before it is given to the customer.
- The process is timed to see how long it takes to deliver value to the customer.
- There will be 3+ iterations that are timed.
Gather the team and provide the goals and instructions.
Separate them into teams of 5 or 6 people. They can represent different roles in the value chain.
Have people decide the fastest way they can take turns flipping the coins and stacking them at the end of the process, ready for delivery to the customer.
After a minute of discussion, start the timer and let them play it out. Stop the timer when all the coins have been flipped by each person and stacked.
Allow a one-minute retrospective to see how they might change the strategy and then repeat the activity above.
Re-run the activity, recording the time taken for each iteration.
Once all iterations are completed, run a debrief. You can ask questions such as
- Which batch sizes did the best in terms of time? Why do you think that is?
- Was there anything that surprised you in the game?
- How do you think it would change if the distance between people were increased?
- How do you think things would change if you had to wait 10 seconds each time there was a handover of coins?
- If you introduced a change request during the game, how did that impact the process?
- If you had compared it to the traditional waterfall approach, what differences did you notice?
- How good were the team’s time estimates?
- What else did you learn from this activity that you wanted to share?
**Variations to the Coin Agile Game**
You can vary to this challenge by
- Having the teams start off by completing the task in a traditional waterfall approach where every coin was flipped by one person before it was moved to the next person. This acts as a baseline.
- Introducing one or more change requests to the process – e.g., I only want $2 coins or Coins with a picture of an animal.
- Have teams estimate how long it would take to complete the task at different batch times.
### Marshmallow Game
Explore problem-solving strategies and builds that require learning from failures and timeboxing.
Learning goals: Creativity, problem-solving, collaborative teamwork.
Time to play: 20 minutes to build the tower, then debrief.
In-person or Virtual: Both
Number of players: 3+ people
Resources required: For each team, 1 large marshmallow, 30 dry spaghetti sticks, 1 meter of tape, 1 meter of string, 1 pair of scissors. Measuring tape.
How the game works:
This game allows you to challenge teams to be creative and collaborative. It involves teamwork, listening, and working together to build the best-performing structure.
**The Marshmallow Game rules**
The goal of the marshmallow challenge game is to build the tallest freestanding tower with a marshmallow at the top.
The rules are as follows
- The marshmallow must be intact. No tearing or biting.
- You can break or tear any of the other items.
- Once time is up, everyone must back away from the structure. You cannot hold onto it.
- The structure must be free-standing.
Gather the team and provide the goals and instructions.
Set the time that you have allowed for the exercise and let the teams go.
Once time is up, teams back away from their structure. Now record the maximum height of each of the marshmallow towers.
Celebrate and congratulate all teams as well as the winning team.
It’s now extra important to debrief on the exercise. You can ask questions such as:
- How would you rate the overall performance of the team and your tower?
- What factors contributed to the success?
- What factors contributed to failures?
- What failures did you experience on the way?
- How did your team communicate?
- Were there any aspects of the challenge that you thought helped with the tower’s creation?
- What roles did each person play, and did it change?
- How much planning did you do?
- What was the impact of the resource constraint?
- If you were allowed to double just one of those resources, which one would it be and why?
- Did you use all of your resources? Why or why not?
**Variations to the Marshmallow Tower Game**
You can vary to this challenge by
- Allowing teams to trade resources between teams
- Adding a second marshmallow into the challenge
### How long does it take to make a cup of tea
Enhance and explore estimations and the impact on the team outcomes.
Learning goals: Estimations and task sizing
Time to play: 30 mins
In person or Virtual: Both
Number of players: 3+ people
Resources required: Tea, plus whatever tools, gadgets, and items each person decides to use to make their cup of tea.
How the Make a Cup of Tea game works:
This game helps teams understand estimations of tasks and being able to develop the right ability to ask questions and consider factors that will improve estimations in agile.
**The Make a Cup of Tea Game rules**
The goal is to estimate how long it would take everyone in the team to make a cup of tea and to be ready to drink altogether. There is a round of questions that allows people to guess, and then they then head off to make the cup of tea. The timer stops when the last person returns, and everyone is ready to sip their cup of tea.
The rules are as follows
- You have 1 minute for people to ask questions to the team to allow them to estimate how long it would take to make a cup of tea.
- Each person then writes down their own estimate. (By Minutes and Seconds)
- As a whole, the team then comes up with a final estimate. (By Minutes and Seconds)
- The timer stops when everyone is back and ready to take the first sip of tea.
Gather the team and provide the goals and instructions.
Ask each person to ask questions to the group and listen to the response. After a minute, ask each person to share their estimate. Based on this, ask the team to create a final group estimate and record this. (Minutes and Seconds).
Start the timer and let everyone head off to make a cup of tea. When everyone comes back, they are ready to take their first sip.
Stop the timer and write down the time. Have teams compare their individual, group, and real-time.
The important part of this game is then to debrief this. You can ask questions such as
- How close were your estimates to the real-time?
- How different are your estimates from the group estimates and the real-time?
- What factors caused your estimates to be wrong? Or right?
- What events surprised you and you did not expect or plan for?
- What would have helped you make a better estimate?
- What questions should you have asked that would improve your estimations?
- What do you think is the value of good estimations – why did we just do this exercise?
- What are the impacts of getting estimations too wrong?
- How did it feel being the first person back versus the last person back?
- If you run the same activity again next time, do you think your estimates would be the same or different? Why?
**Variations to the Make a Tea Game**
You can vary to this challenge by
- Keeping personal estimates unknown.
- Using different ways to calculate the group estimate – by average time, most common, by consensus.
### The Multitasking Name Game (Henrik Kniberg)
Which is better, single-focus or multi-tasking? Take the challenge and find out.
Learning goals: Limiting WIP, Kanban, task planning
Time to play: 10 mins
In person or Virtual: Both
Number of players: 5+ people
Resources required: Pen, Paper and timer
**How the multitasking name game works**
This is a short, simple but powerful game that highlights the effects of multi-tasking and context shifting. In a busy world, people are often doing multiple projects, open tabs in the browser, or trying to switch between tasks. This game highlights how effective people actually are at multitasking. This game was introduced by [Henrik Kniberg](http://coach-agile.com/wp-content/uploads/2018/07/Multitasking-Name-Game-agile.pdf).
**The Name Game rules**
The goal is to write down everyone’s names as fast as possible so that all names are written out in full.
The rules are as follows
- There are 2 phases.
- In the 1st phase, you can only write one letter of each person’s name at a time. E.g. all the first letters, then all the seconds and so on.
- Every time a name is completed, record the time of completion.
- When all names are completed, record the time of completion.
- In the 2nd phase, you can only write one name at a time. At the end of each name, complete the time of completion. When all names are completed, record the time of completion.
- Compare the 2 results.
Gather the team and provide the goals and instructions.
Create a list of all the names of the people in the room.
You can either have someone act as a scribe for the team and have someone else time each name and list completion.
Ask teams to estimate how long it would take to write all the names one letter at a time per name versus one name at a time.
Start phase one and record the times.
Run phase two and record the times.
Calculate the difference in times – what was the proportional change?
The important part of this game is then to debrief this. You can ask questions such as
- How close were your estimates to the real-time?
- What made phase 2 easier than round one?
- Would it make a difference if the names were scientific words or uncommon words instead of names?
- What made it easier to uni-task rather than multi-task?
- In reflection, which activities do you multitask?
- Do you think it would be faster to write 2 names at a time rather than one?
- What other learnings did you want to share?
**Variations to the Name Game**
You can vary to this challenge by
- Changing it from names to a set of numbers, scientific terms, or formulas.
- Try having paired scribes in both phases and see if it makes a difference.
### LEGO Flow
Role-based workflow game that will be sure to get a few neurons firing.
Learning goals: Backlogs, Kanban, inspection and adaption.
Time to play: ~60 minutes, based on 3 rounds of 5 minutes
In person or Virtual: Virtual
Number of players: ~5 people per team
Resources required: Lego pieces of any color, sticky tape or 4 pieces of paper. You can download [printable resources](https://www.organizeagile.com/app/themes/organizeagile/assets/uploads/2019/12/OrganizeAgile_LegoFarmAnimal_KanbanGame.pdf) here thanks to Organize Agile under the Creative Commons.
**How the LEGO Flow game works**
This game highlights differences between existing processes and using a kanban system to help optimize workflow and output. It uses assigned roles for each person, a backlog of orders, and other game theories to help teams experiment with ways to optimize their workflow.
**The Lego Flow Game rules**
The goal is to create as many lego animals as possible each round (3). With each round, the process is timed and the teams get to see how long it takes them to construct as many animals as possible. The team should manage their flow (left to right) and create explicit agreements to work together. Points are earned for each completed animal and points are deducted for unused parts or undelivered animals.
The rules are as follows
- This game is played in 3 rounds.
- There are 4 types of animals to be built based on a set of resources.
- In each round, points are earned for each completed animal built and delivered to the right specification. They must be 2 blocks high and the color does not matter.
- The roles are as follows:
- Analyst (Leg builder): gathers the legs.
- Developer (Body builder): puts 2 blocks on top of each other
- Designer (Head builder): builds the head
- Delivery (Transporter): puts the animal in transport for 30 seconds
- Tester (Quality Assurance: checks output, keeps score and takes the animal apart).
- Animals are built and then transported for delivery.
- There is a 30-second delay for transportation. The animal stays in the transport zone during this time.
- There are a maximum of 3 animals transported at the same time. (ie. 1 animal per truck)
- Once the animal is checked, it is then disassembled and put back into a starting pile.
- Points are scored as follows:
- +10 points for each fully delivered animal
- \-1 point for every unused leg
- \-4 points for every unused body
- \-4 points for every unused head
- \-10 points for every completed animal not yet arrived.
**Round 1**
Gather the teams and provide the goals and instructions. Simply give them a pile of lego bricks.
There is no backlog, or visualization of workflow. The team chooses what animals to build.
Set the timer for 5 minutes and ask people to start building.
At the end of the round, record the final score and allow a minute for reflection of the task.
**Round 2**
Now introduce a workflow system. Ask the team to create a visual workflow either with tape on the table or pieces of paper, going from left to right. Unassembled pieces are then pulled from one pile and moved from leg builder to body builder to head builder, then transport/testing.
Set the timer for 5 minutes and ask people to start building.
At the end of the round, record the final score and allow a minute for reflection of the task.
**Round 3**
Keep the visualized workflow and this time introduce the backlog or order of production. E.g Cow Cow, Sheep Sheep, Duck Duck, Horse Horse.
Set the timer for 5 minutes and ask people to start building.
At the end of the round, record the final score and allow a minute for reflection of the task.
Now ask the following debrief questions
- How did your scores change from round to round?
- What went well?
- When and where did the work pile up (bottleneck)?
- What improvements did you introduce and what impact did it have?
- What was the differences between the first and third round?
- Did you experience flow? When did this happen?
- Did your WIP limits change after each round?
- Was there any rework that needed to be done?
- What else would you change to improve the overall results?
**Variations to the Lego Flow Game**
You can vary to this challenge by
- Introducing some limits to a specific type of lego blocks.
- Allowing the teams to come up with their own backlog.
### Lego Retrospective Game
Each team member builds and talks about their experience of the last sprint through their lego design.
Learning goals: Creativity, Retrospective
Time to play: 3-minute build and 1 minute per person
In person or Virtual: Both
Number of players: Any
Resources required: Assorted Lego pieces
**How the Lego Retrospective game works**
This is a free-style, easy game that lets people talk through a lego design about their experience of the last sprint. It can help break down communication barriers by using each piece, or the whole shape for people to use as a talking point.
**The Lego Retrospective Game rules**
The goal is to create a simple Lego design that reflects your experience of the last sprint. There are no right or wrong answers.
Place an assortment of legos or give each person a pile of legos and give them a few minutes to build anything they like that represents their experience of the last sprint.
Then, give each person a turn at describing what they have created. You can ask questions such as
- Why did you use the pieces you used?
- Tell us more about a particular experience?
- What did you love most or think was missing in your design?
**Variations to the Lego Retrospective Game**
You can vary to this challenge by
- Posing a particular scenario and having people build their version of it. Examples include:
- What would good/bad communication look like?
- What is your vision for this team or project?
- How would a perfect user story be represented?
- How would you portray our teams culture?
### Kanban Pizza
Learning goal: Practice using a whole Kanban system including understanding the effects of limiting the team’s [Work in Progress (WIP)](/guides/agile-metrics/lead-time-vs-cycle-time/).
Time to play: 2 to 3 hours
In-person or virtual: In person
Number of players: 4-8 per team
Resources required: Sticky notes in three colors: yellow (mozzarella), pink (pepperoni) and green (herbs), paper (for pizza bases), red markers (for tomato sauce), glue or transparent tape, masking tape, scissors (one small and one large per team), paper plate (oven) and a stopwatch.
**How the Kanban game works**
Players step into the role of pizza chefs. They are divided into teams and given the materials they need to make a version of a pizza. They must create as many of the same pizzas as the one created by the facilitator. At the end of each round, the team counts the number of pizzas delivered and aims to reduce the amount of waste.
**Kanban Pizza game rules**
- The team must create as many pizzas as possible in the allocated time.
- The pizza must be exactly the same as the one created by the facilitator. (5 points)
- Each pizza must be ‘cooked’ for at least 30 seconds.
- The oven can only hold three pizzas at a time.
- Wastage should be kept to a minimum. (- 1 point for each waste item)
- Unused resources created from one round can be used in the next.
**Getting started**
**Round one – Create your own process**
- Have an example ‘pizza’ made up to show the group – A white circular base using the printing paper that is colored red with the marker for tomato sauce. Add six yellow (mozzarella) squares, six pink (pepperoni) squares and three green (herbs) squares.
- Show them the paper plate as the oven.
- After five minutes, count how many pizzas were made, assess the level of wasted food, and calculate scores.
**Round two – Introduce Kanban**
- Introduce Kanban and the core practices of Kanban. (Visualize the Workflow, Limit your Work in Progress (WIP), Manage the Flow, Implement Feedback Loops, Make Process Policies Explicit, Improve Collaboratively).
- Have teams visualize the workflow and make the process explicit by introducing storage for production materials (pizza bottoms, slices of ham, etc.) directly on the table. The teams can use the materials at hand (masking tape, post-its and paper).
- Advise the teams to limit their Work in Progress (WIP).
- Run a new round with the newly established Kanban system. At the end of five minutes run a debrief and calculate scores.
**Round three – Extend the system**
- Introducing a new pizza type. Customer orders can now contain pizzas of two different kinds.
- The team can only count the pizzas when the whole order is fulfilled.
- A team can pull several orders at once.
- Allow the teams five minutes to discuss how they will extend the system.
- Run a new round . At the end of five minutes run a debrief and calculate scores.
**Round four – Iterate and improve**
- Give the teams five minutes to discuss and improve their system. Have them focus on the workflow and different WIP limits.
- At the end of five minutes run a debrief and calculate scores.
- Finally debrief on all four rounds to see what the team learned.
[Agile 42](https://www.agile42.com/en/agile-teams/kanban-pizza-game) offers resources to support their game. Shared under the [Creative Commons Attribution 4.0 International License](https://creativecommons.org/licenses/by/4.0/).
### Agile Battleship
An activity created by [James Scrimshire](https://www.linkedin.com/in/jamesscrimshire/) that takes the classic game of [Battleship](https://anthonycoppedge.medium.com/agile-games-using-battleship-for-demonstrating-pivoting-based-on-learnings-5a982dc63ab6) and gives it an agile twist.
Learning goal: To understand the importance of communication, collaboration, and the benefits of the iterative development process.
Duration: 30 minutes.
In-person or virtual: Both.
Number of players: 4-12
Resources required: Battleship game set
**How the Agile Battleships game works**
Teams play rounds of Battleships. The first is played without any feedback. Subsequent rounds gradually introduce more feedback.
Agile Battleships game rules
Each team can see their own board but not their opponent’s board.
Teams take turns firing at their opponent’s board, calling out the coordinates of their target.
The game ends when one team successfully sinks all of the opposing team’s ships.
**Getting started**
Divide the group into two.
Set up the battleship boards and fleet pieces.
The teams take turns to sink each other’s ships.
**Round one – No feedback**
- Begin the game with teams taking turns to call out coordinates.
- After 5 minutes, stop the game. Count how many hits the team made.
- Debrief by discussing how the players felt, and how their experience could apply to their work.
**Round two – Limited feedback**
- This time, after every five shots, the team is told if they ‘hit’ or ‘missed’ a ship.
- After 5 minutes, stop the game. Count how many hits the team made.
- Debrief by discussing how this iteration differed from the first.
**Round three – Real time feedback**
- This time, after every shot, the team is told if they ‘hit’ or ‘missed’ a ship.
- After 5 minutes, stop the game. Count how many hits the team made.
- Debrief by discussing how this iteration differed from the first.
- Ask teams how they get and receive feedback in their workplace.
**Variations to the Battleships game**
- Watch [a pen-and-paper version of Battleships](https://www.youtube.com/watch?v=1aAQaGxCpCg).
- A virtual version is offered by [BoxUK](https://www.boxuk.com/battleships/)
- Play without timeboxing the rounds. Instead, stop when one team has sunk all of the ships of the other. Use this to inform discussions around the influence of feedback on time management.
- If time allows, additional rounds can be included that more gradually increase the amount of feedback the teams receive.
Shared under the [Creative Commons Attribution 4.0 International License](https://creativecommons.org/licenses/by/4.0/).
### XP Game
A game designed by [Vera Peeters and Pascal Van Cauwenberghe](https://www.agilecoach.net/index.php/about/) to introduce participants to the principles and practices of Extreme Programming (XP) methodology.
Learning goal: Increase understanding of concepts such as velocity, story estimation, yesterday’s weather and the cycle of life of both developers and customers.
Time to play: 2–3 hours
In-person or virtual: In-person
Number of players: 5-12
Resources required: [Pre-filled story cards](https://www.agilebelgium.be/xpgame/download/), planning and scoring sheets, pencils, playing cards, dice, balloons, other small props to perform stories, a timer per team.
**How the XP Game works:**
The XP Game makes the players act as either a developer or customer, so that they understand each other’s role.
**XP Game rules**
- The aim of the game is to earn as many business points by delivering value with a timeframe or budget.
- Value is delivered by completing stories that have been accepted by the customer.
- Stories are found on story cards. These are simple activities to be done.
- Players provide an estimate for each story card and decide what the team should attempt to deliver within an iteration. Not all time needs to be used.
- An iteration is three minutes.
- Teams with the most points are the most successful.
Getting started
Participants are divided into teams and assigned the roles of developers or customers.
**Round one – Determining velocity**
- Allocate each team 12 story cards.
- Players estimate the stories from one to six, or impossible. Players may ask the coach questions about each story.
- Customers choose the stories they think can be implemented by the developers in three minutes and then order the cards.
- Developers implement the stories one at a time, in order.
- Start the timer when a developer starts a story. Stop the timer when they think the story is finished.
- The customer accepts or rejects the story. If rejected, the timer is restarted and the story is done again. If successful, the developer picks up the next story.
- At the end of the round, tally up the business points of all fully delivered stories and add to the score sheet. Calculate velocity based on the time used.
**Round two – Determining business value**
- Have the team debrief the first round.
- Give each team seven more story cards. The team estimates the new cards.
- Customers choose stories to equal the team velocity from round one and orders them.
- Developers implement the stories, in order, until the timer runs out.
- At the end of the round, tally up the business value and calculate velocity.
- Compare it to the first round and debrief.
Run as many iterations as you would like to improve iteration planning.
Shared under the [Creative Commons Attribution 4.0 International License](https://creativecommons.org/licenses/by/4.0/).
### DevOps Dream
A simulation [game](https://devops.games/pages/aboutTheGame.html) from the team at [Mechanical Rock](https://mechanicalrock.io/). It’s designed to introduce participants to the principles and practices of DevOps methodology in a fun and interactive way.
Learning goal: To help participants reflect on how they develop and run software.
Time to play: Flexible
In person or virtual: virtual
Number of players: 1
Resources required: [DevOps Dream](https://dream.devops.games/?utm_source=devops.games_website&utm_content=orangebtn_cta)
**How the DevOps Dream game works**
Players step into the role of the CIO of a company. They need to pick the right combination of initiatives and actions to lead their team to success.
**The DevOps Dream game**
The game offers a guided tutorial.
The steps include –
- Choosing a company
- Deciding on initiatives
- Examining performance metrics
Different scenarios are present along with a choice of steps that can be taken in response.
The player is assessed on four key results over a 3 year period.
- People
- Productivity
- Customer Satisfaction
- Stability
---
# From awkward to awesome: the science to good check-in questions
URL: https://www.teamretro.com/blog/the-science-behind-good-check-in-questions/
Ever started a retrospective with “How’s everyone doing today?” and been met with silence or a shrug?
You’re not alone. While [check-in questions](/icebreakers/check-in-questions/) and check-out questions might seem like small talk, they’re actually powerful tools for creating engagement, psychological safety, and continuous improvement in Scrum teams.
That’s why [TeamRetro](/) has built-in features to help Scrum Masters bring intention to how they open and close every meeting.
In this post, we’ll explore:
- The psychology behind check-in and check-out questions.
- TeamRetro’s built-in options and how to use them.
- How to turn one-off responses into long-term insights.
- Tips for getting more value from your retros.
## The science behind good check-in questions
What makes check-in questions so powerful in Agile retrospectives? It comes down to the science of human behavior and team dynamics.
### 1. Priming for participation
A small early contribution makes people more likely to speak up later. This is known as the **foot-in-the-door effect**, a well-documented psychological phenomenon. Freedman & Fraser, 1966.
### 2. Cognitive framing
The way a conversation starts frames how people think, speak, and respond throughout. A focused check-in sets the tone for constructive dialogue, feedback, and idea generation.
### 3. Belonging and trust
Simple questions that invite open, honest input create space for team members to feel seen, heard, and valued.
Agile thought leaders like [Esther Derby](https://www.estherderby.com/), [Lyssa Adkins](https://www.lyssaadkins.com/), and [Johanna Rothman](https://www.jrothman.com/blog/mpd/) all emphasize the role of team connection and psychological safety in effective retrospectives.
## Check out questions: the counterpart
At the same time, a check-out question also offers its own benefits.
### 1. Closure and cognitive framing
Check-out questions create a clear endpoint, allowing participants to mentally “package” what they’ve learned. According to Gestalt psychology, humans naturally seek closure. Offering a moment to reflect enhances information retention.
### 2. Shared experience and group cohesion
Asking everyone to share a final thought reinforces a sense of belonging and psychological safety. Social identity theory (Tajfel & Turner, 1979) shows that shared rituals like closing rounds can strengthen group identity.
### 3. Reflection and meta-cognition
Check-out questions prompt people to think about their own thinking. This encourages deeper learning and helps participants retain what was discussed. This deepens learning and self-awareness, key principles in Agile coaching as highlighted by [Lyssa Adkins](https://lyssaadkins.com/) and [Jurgen Appelo](https://www.management30.com/).
### 4. Priming for action
A well-crafted check-out can subtly prepare the brain for future behavior. Asking what people will apply or do next builds a sense of accountability and encourages follow-through.
In either case, the key aspects of a good question are that they are:
- Short and to the point – this is not to open up or facilitate deep discussions.
- Fast and quick – we are just collecting some quick data points in order to get a [team pulse check](/health-check-templates/quick-pulse-check/), not an ideation.
- Designed to give feedback – not to solve a problem.
Together, these questions can transform your retrospective from a checklist item to a meaningful team ritual.
> “The most powerful tool we have as leaders is the question.” – Brene Brown
## TeamRetro’s built-in check-in questions, and what they reveal
TeamRetro offers five built-in check-in questions to help you set the tone at the start of your meeting. Each one taps into a different aspect of team health and collaboration.
| **Check-In Question** | **What It Captures** | **Why It Matters** |
| :-- | :-- | :-- |
| **Energy level** | Team’s physical or mental energy coming into the meeting | Helps gauge readiness and informs pacing or tone of the session |
| **Weather Report** | Team’s mood or sentiment about the last sprint | Highlights morale and signals potential issues needing attention |
| **Safety Check** | Comfort in sharing thoughts and concerns openly | Promotes psychological safety – key to open, honest communication |
| **Team Collaboration** | How well the team worked together last sprint | Reflects teamwork dynamics and surfaces process or role gaps |
| **Sprint Happiness** | General satisfaction with the last sprint or iteration | Reveals engagement and flags deeper issues behind delivery work |
## Close the loop: TeamRetro’s built-in check-out questions
At the other end of the meeting TeamRetro includes four built-in check-out questions:
| **Check-Out Question** | **What It Captures** | **Why It Matters** |
| :-- | :-- | :-- |
| **Return on Time Invested** | Whether the meeting was valuable and worthwhile | Tracks **meeting effectiveness** and ROI (shown in TeamRetro’s **Insights**) |
| **Pulse Check** | Emotional or mental state at the end of the meeting | Indicates psychological engagement and overall team sentiment |
| **Delivery Confidence** | Confidence in achieving sprint goals | Surfaces blockers or misalignments in team readiness |
| **Retrospective Process** | Satisfaction with how the retro was facilitated | Direct feedback on facilitation style and structure that supports continuous improvement |
Adding these questions to your retrospective is as easy as toggling them on as a step in your retrospective and then choosing the question you would like to ask the team. [See how.](https://help.teamretro.com/article/395-check-in-check-out-questions)
## Turn once-off responses into insights
By using check-in and check-out questions regularly, you can track the emotional and cognitive pulse of your team over time. For example:
- Monitor **energy levels** at the start of each meeting to detect burnout early.
- Use the **weather report** to correlate mood with **delivery confidence.**
- Track **retrospective process feedback** to improve your facilitation style.
All this data is automatically captured in TeamRetro’s Insights tab, giving Scrum Masters and Agile coaches a clear view into **team engagement trends**.
## Turn insight into action
Use what you learn from your insights to:
- Adjust your facilitation style.
- Acknowledge and refine what works.
- Follow up 1:1 with quiet or outlier voices.
- Change the format or timing of meetings.
- Celebrate wins or address dips in morale.
- Spot recurring blockers impacting team engagement.
## Tips for Scrum Masters
Want to get the most from check-in and check-out questions? Try this:
- Rotate questions weekly to keep them fresh or if you sense a need to change the question.
- Alternatively, use the same question set if your goal is to track one metric over a period of time.
- Create a team health check to dive deeper into a specific area.
- Use the trends or results as a data point for future retrospectives.
Have a new team member? Throw in an [icebreaker question](/icebreakers/) into your retrospective to help open up doors for communication.
## Final thoughts
Check-in and check-out questions aren’t just nice-to-haves. They’re simple but powerful tools that help teams connect, reflect, and grow. Whether measuring energy, morale, or meeting value, TeamRetro gives you the structure and insights to do it with ease.
So next time you launch a retro, don’t skip the opening question. Start strong, finish thoughtful, and watch your team open up.
👉 **Try adding a check-in to your next retrospective in [TeamRetro](/)**. It takes seconds and can spark conversations that matter.
---
# Timeboxing for scrum teams and successful retrospectives
URL: https://www.teamretro.com/blog/timeboxing-for-scrum-teams-and-successful-retrospectives/
We’ve all been in at least one meeting where we come out and say “well that was a waste of time.”
This graph summarizes the truth about human attention span in meetings.
One way we can make sure teams and participants don’t leave meetings unhappy because it runs out of time and ineffective is to use the timeboxing methodology. Scrum teams have used timeboxing as a way to maintain efficiency and productivity, so let’s find out more!
## What is timeboxing?
Timeboxing is a simple time management technique which involves setting a fixed, maximum unit of time to complete an activity. That unit of time is referred to as a timebox. You then work on the activity during the fixed time period and stop working on it once the time is up. Then, you assess whether you’ve reached your planned goals.
Timeboxing was first introduced by James Martin, the author of the book [Rapid Application Developmen](https://www.iro.umontreal.ca/~dift6803/Transparents/Chapitre1/Documents/rad_wp.pdf)t, as part of agile software development.
Scrum teams and many project managers use timeboxing to keep everyone focused on accomplishing the task at hand.
## Let’s see how timeboxing is used by scrum teams
***Sprint**:* timeboxing can be used to define the length of the Sprint for scrum teams to deliver the Sprint goals.
***Sprint planning**:* when a team launches, they establish a timebox for the Sprint Planning meeting. The [Scrum Guide](https://www.scrumguides.org/) suggests that a Sprint Planning meeting should be timeboxed at 8 hours or less for a one-month Sprint.
***Daily scrum**:* a shorter timebox, for about 15 minutes for each day can help scrum teams synchronize activities and make any challenges to achieving the Sprint goal obvious.
***Sprint review**:* during the review, sprint backlog items delivered during the sprint are discussed and inspected. You can timebox the review to make sure you go through the backlogs efficiently and effectively.
***Sprint retrospectives**:* as you would know, retrospectives are our jam! Retrospectives are a time for the team to inspect itself and identify a process improvement that they can implement for a new sprint. Timeboxing retrospectives is important, [to avoid BMWs](/blog/how-to-manage-bmw-in-retrospectives/), to make sure that every team member’s opinions are valued, and to keep discussions constructive.
## Timeboxing with TeamRetro
If you want to keep things moving quickly and on time with your retrospectives, you can set a countdown timer in TeamRetro through the stopwatch in the top right-hand corner of your screen.
When your time is up the timer will go red and pulse to grab your attention.
Or people can click the button functionality to say “I am finished” signaling they are ready to move on. Other ways to do this if you are using Zoom is to click “yes” or “no.”
## TeamRetro timeboxing recipe
TeamRetro has a Timeboxing recipe for synchronous meetings for a 60-minute retrospective (just to make sure you finish on time). Note, you can proportionate this recipe for a longer meeting to suit your team’s needs.
For example if your team health checks show that you need more connectivity, then you might need to allocate more time.
Check it out below.
## More timeboxing tips and tricks
- Allocate a specific time for each person in the team e.g. 1 minute per person
- Roman voting: thumbs up or down if they need more time at the end of the timer
- Think “pair share” – think for 30 seconds, pair with another person for 1 minute, and then share with another pair before final sharing with the whole group.
## Try it for your next retrospective or meetings
Want to try the timeboxing methodology?
[Try TeamRetro for free for 30 days](https://secure.teamretro.com/login/new/?cc=www-blog) and start using our meeting facilitation tool – the TIMER – to facilitate timeboxing easily for your next retrospectives or meetings.
---
# Tips to overcome recency bias in your retrospectives
URL: https://www.teamretro.com/blog/tips-to-overcome-recency-bias-in-your-retrospectives/
Have you and your agile teams heard of the term recency bias?
Even if you haven’t you might be experiencing it when you conduct your retrospectives without even realizing it.
[Recency bias](https://en.wikipedia.org/wiki/List_of_cognitive_biases) is a psychological phenomenon where a person can remember something which has happened to them recently compared to the thing that has happened to them a while back.
Here’s a little test to “experience” recency bias: try to recall the name of the ten or more people that you’ve met in the last week. You will easily tend to remember the names of the people that you’ve met recently compared to the ones you met a long time back, right?
So what role does recency bias play in retrospectives?
### Your feedback is influenced by what happened recently!
If during your sprint you experienced great things at the beginning but nearer the retro time things might have broken down a bit influencing your feedback. This can be detrimental to retros because then you might spend more time going through the “what went less well” rather than “what went well?” and “what do we want to try next?”
OR
If your recent experience was so good that you forget about everything else that you thought “this can be improved for next time,” you might not add anything in the “what went less well” column!
### A hotspot for BMWs
Again, when you are focused on your most recent experience, it might result in the impulsiveness to do more [BMWs](/blog/how-to-manage-bmw-in-retrospectives/) rather than constructive feedback sessions.
How can we mitigate recency bias?
### Make retros asynchronous
One way to make sure we mitigate recency bias is to have a place where team members can add things that they want to suggest, bring up or discuss in retrospectives.
Even better would be if it’s something that can be accessed easily while you’re working, be anonymous if you want it to be, and is recorded directly so that you can view it all in one space when it comes to your retro.
In [TeamRetro](/) you can create asynchronous retrospectives by creating a retrospective or [using one of our templates](/retrospectives/) and then leave the brainstorming page open for team members to add notes whenever they want to during the sprint.
### Encourage sharing, anywhere and anytime!
When you have your retro spot available and accessible for team members during any stage for a sprint, you’d need to remind them, remind them again and many more times to use the available retro board.
You can do this via email, or your internal IM platform such as Slack.
### Avoid the open box!
Much of the unconscious bias in retros stems from the “open box”.
Retrospectives that lack structure and simply provide teams with a few open-ended questions and a large blank space to fill is breeding ground for recency bias.
One way to add structure to your retro is to create a timeline-based retrospective that looks at getting feedback from the start, midway, and end of sprints. You can create this easily using the custom retro feature and here’s one we prepared earlier.
### Look at past retrospectives
By looking at your past retrospective notes and action lists, you and your team can jog your memory on what happened last time and what’s important to follow up on.
### Use data to spot the bias
When it comes to the very human problem of bias, analytics is useful!
It can be easy to spot potential bias from the data, like when teams decide on an action from a previous retrospective as essential but in the current situation don’t even mention it as their recent experiences alter previous experiences.
With TeamRetro, features such as voting to decide on priorities and actions that everyone has suggested and agreed upon can then be emailed or shared to [Trello](https://trello.com/), Jira, [MS Team](https://www.microsoft.com/en-au/microsoft-365/microsoft-teams/group-chat-software), [Slack](https://slack.com/) means that everyone can refresh and re-read before upcoming retros.
### Try TeamRetro today!
Need to keep recency bias out of your retros? We’d be happy to help with our [30 days free trial](https://secure.teamretro.com/login/new?emailAddress=&cc=www-blog) and a [demo](https://secure.teamretro.com/demo/retrospectives/scrum-retrospective) on how our digital tool can help run retros in a coordinated and engaging way.
---
# Top 5 tips for running effective icebreakers
URL: https://www.teamretro.com/blog/top-5-tips-for-running-effective-icebreakers/
Effective icebreakers build safe, positive, collaborative spaces. Better yet, they enhance the productivity of all types of meetings, including [sprint retrospectives](https://games.teamretro.com/use-cases/sprint-retrospectives/).
On the flip side, a bad icebreaker can have the opposite effect. An ineffective icebreaker may make people feel excluded, anxious or frustrated. They may even reduce meeting productivity.
So how do you make sure you’re getting the most out of your icebreaker activity? Here are our top five tips for running effective icebreakers.
1. Be prepared
2. Set the scene
3. Go first
4. Make sure everyone has a go
5. Keep it positive
## Be prepared
A little preparation makes a big difference to the effectiveness of an icebreaker. Taking just a couple of minutes to get things in order before the meeting will deliver big returns.
### Choose a good icebreaker question
Good icebreaker questions follow the [3E Rule](/blog/best-icebreakers-for-starting-conversations-with-online-teams-2021/). They are easy, enjoyable and explainable. They prompt people to share their stories so connections can be formed. Remember, if a question can be answered with a quick yes or no, it’s not a good icebreaker. For a ready-made bank, our [icebreaker questions for work](/icebreakers/icebreaker-questions-for-work/) are sorted by what you want the opener to do.
The great thing about a good icebreaker question is that there are no right or wrong answers. They are inclusive, simple and fun.
To help you get started, we’ve built a [free icebreaker games tool](https://games.teamretro.com/games/) that can generate questions for you! You can even [browse icebreaker questions by category](/icebreakers/) if you wish to focus on a specific aspect of your team. Try a quick favorite like [Two Truths and a Lie](https://games.teamretro.com/games/two-truths-and-a-lie/) or [This or That](https://games.teamretro.com/games/this-or-that/) to get everyone talking.
### Allocate time to the icebreaker
Allocating time for the icebreaker is important for two reasons. Firstly, it lets everyone know what they can expect when they step into the room. Secondly, it helps to manage the flow of the icebreaker activity itself.
A timer has been included on the icebreaker widget. It helps you keep an eye on the time and you can refer to it if you need to move the conversation along. It also helps to make sure your retrospective starts on time.
### Grab a list
Make sure you have a list of participants. It’s always helpful to know who you’re talking to.
[](https://games.teamretro.com/)
## Set the scene
Setting the scene means giving people an overview of the icebreaker before it starts. It will help things run smoothly. This can cover the mechanics of the icebreaker, for example how long it should take, as well as the benefits an icebreaker can deliver.
This time can also help to reduce any anxiety in the room. People can ask any questions they may have and, importantly, this is a chance to remind people that there are no right or wrong answers.
Setting the scene will only take a couple of minutes, but it helps to support the effectiveness of the icebreaker.
## Go first
Going first is especially important if your team is new or if you have new people in the team. It lets you show people how to answer an icebreaker question. It also helps to set the tone of the activity (and the retrospective that will follow). People will follow your lead.
There’s no need to worry who follows you. TeamRetro’s icebreaker widget can be used to nominate who goes next.
## Make sure everyone has a go
This tip is linked to effective icebreakers being inclusive. Nothing makes someone feel less important than being overlooked. The significance of making sure everyone has had a chance to have a turn can’t be stressed enough.
There are three quick ways you can confirm everyone has had a turn. First of all, the list of participants can be checked. The icebreaker widget can also help; each time someone answers the icebreaker question their name can be removed from the list of people still to answer. It’s also perfectly alright just to ask the group if everyone has had a turn.
Bonus tip: Let people ‘pass’. If someone is clearly very nervous or simply can’t think of something, give them the option to ‘pass’. Everyone has good days and bad, and this is a chance to show empathy.
## Keep it positive
A positive icebreaker is a gift that keeps on giving. People are naturally drawn to optimism. They want to connect with something that will make them feel good.
Positivity is also contagious. When you connect with positive people it’s likely you will enjoy making that connection and view that connection in a good light. It will probably put you in a good mood!
Keeping an icebreaker positive is fantastically simple. Thank people for their input. Listen to what they say and celebrate the diversity of input your icebreaker inspires.
For more about icebreakers, you can also head over to our blog where we share [what makes the best icebreakers for teams](/blog/best-icebreakers-for-starting-conversations-with-online-teams-2021/) along with [quick but effective icebreakers to launch your next retrospective.](/blog/quick-but-effective-icebreakers-to-launch-your-next-retrospective/)
---
# Top 7 habits of highly successful Scrum Masters and agile teams
URL: https://www.teamretro.com/blog/top-7-habits-of-highly-successful-scrum-masters-and-agile-teams/
Sometimes, the simplest gestures carry the most profound insights. The heartfelt letter of appreciation from an Agile team to their Scrum Master shared above, illustrates the transformative impact a great Scrum Master can have. It’s these traits that create thriving teams, foster collaboration, and deliver continuous value.
The role of a Scrum Master goes far beyond facilitating meetings and enforcing Agile practices. It’s about creating an environment where teams can thrive, adapt, and deliver value.
Let’s dive into these key habits and explore how you can cultivate them to become an outstanding Scrum Master.
## Habit 1 – Honoring the agile principles
The best Scrum Masters know that living Agile principles matters more than just following practices. Without a shared understanding of Agile principles, even the most meticulously executed practices can become hollow routines. Teams with a strong foundation in principles like collaboration, adaptability, and continuous improvement can consistently deliver value.
**How to Foster Agile Principles:**
- Revisit the Agile Manifesto to emphasize the “why” behind the work.
- Leverage retrospectives to reflect on how principles are being upheld.
- Align team goals with customer and organizational priorities.
**Example in Action:**
An Agile team struggling with prioritization shifted their approach after their Scrum Master facilitated a session on the principle of delivering value early and often by using the ping pong ball game, and refining the sprint planning process. The result? A more streamlined backlog and a noticeable improvement in stakeholder satisfaction.
## Habit 2 – Being a scrum “master of many hats”
A Scrum Master wears multiple hats to meet the evolving needs of their team and organization. Understanding when to shift between these roles is critical to fostering a high-performing team.
**Key Roles of a Scrum Master:**
- **Servant Leader**: Supports team members and stakeholders to achieve common goals.
- **Mentor**: Shares Agile expertise to upskill the team.
- **Conflict Navigator**: Resolves tensions that hinder team collaboration.
- **Coach**: Guides the team in embracing Agile mindsets and aligning behaviors.
- **Facilitator**: Ensures productive collaboration during Scrum events.
**Key practice:**
Balance your involvement by observing when the team can self-organize versus when intervention is needed. Letting teams solve their own challenges fosters ownership and growth, but at the same time, there might be a need to step in to offer guidance. Some opportunities include:
- Involve the team in setting up processes, such as scheduling Scrum events at times that suit everyone.
- Assigning different people to be the Scrum Master so that you can be an observer and guide from the side.
**Example in action:**
A Scrum Master noticed that their team often waited for directives. By gradually delegating planning tasks and asking, “How would you solve this?” the team became more proactive and confident in their decision-making.
## Habit 3- Creating strong sprint rhythms and powerful retrospectives
Successful teams rely on steady rhythms and structured retrospectives to maintain focus and adapt effectively. The retrospective should be a safe space for sharing, exploration and ideation that doesn’t become yet another whinging festival.
**How to Build Rhythm and Improvement:**
- Define the sprint cadence and ensure people adhere to it consistently.
- Ensure clear roles and responsibilities, as well as sprint goals for each cycle.
- Ensure Scrum events occur at consistent times, creating predictability for the team.
- Experiment with new retrospective questions to keep the sessions engaging and productive.
- Identify patterns in feedback to proactively prevent recurring challenges.
**Example in action:**
A Scrum Master established a 2-week sprint cycle for a mobile app team working on a user registration feature by ensuring clear planning, effective daily standups, and proactive issue resolution. During Sprint Planning, the team committed to realistic goals with a clear Definition of Done. Daily standups kept progress aligned, and mid-sprint, the SM resolved a testing delay after a blocker was identified at standup. The sprint ended with a successful demo, incorporating stakeholder feedback for future improvements in the UI/UX. In the retrospective, the team identified actionable steps to optimize their workflow, creating a foundation for consistent, predictable delivery in future sprints.
## Habit 4 – Fostering a culture of continuous learning
A successful Scrum Master and Agile team never stop learning. They understand that growth comes from reflecting on experiences, embracing feedback, and staying updated with industry trends.
**Key Practices**:
- **Regular Retrospectives**: Retrospectives, as mentioned earlier, are also crucial for continuous learning.
- **Training and Certifications**: Invest in professional development for team members, such as Scrum certifications or specialized Agile courses.
- **Knowledge Sharing**: Hold regular lunch-and-learn sessions or internal workshops to share new insights and skills.
**Example in action**:
A team at a mid-sized tech firm struggled with sprint velocity until their Scrum Master initiated a bi-weekly “tech talk.” These sessions boosted cross-functional learning, leading to noticeable improvements in team performance and morale, encouraging both individual and group learning. They would also check in on the effectiveness of the retrospective with a quick check-out question. If the score was 3 or less, instead of general feedback, they would ask retrospective questions like, ‘What small change could have made the retrospective more effective?’ to inspire actionable improvements.
## Habit 5 – Prioritizing outcomes over outputs
Agile teams focus on delivering value rather than merely completing tasks. A successful Scrum Master steers the team toward outcome-based thinking, ensuring that every sprint delivers meaningful results, rather than ticking off tasks.
**Key Practices**:
- **Define Success Metrics**: Use [key performance indicators (KPIs)](/guides/agile-metrics/) such as customer satisfaction or time-to-market rather than task completion rates.
- **Customer Feedback Loops**: Integrate customer feedback into sprint reviews to align deliverables with user needs.
- **MVP Approach**: Prioritize developing a Minimum Viable Product (MVP) to validate ideas early.
**Example in action**:
An Agile team working on a mobile app avoided feature bloat (scope creep) by focusing on user feedback for each sprint. This ensured every release added measurable value to the product.
## Habit 6 – Empowering self-organizing teams
Successful Agile teams take ownership of their work. They thrive in environments where they’re empowered to make decisions, experiment, and solve problems independently. Google’s research on high-performing teams highlights psychological safety as a critical factor. When team members feel safe to express themselves without fear of judgment, they innovate and collaborate more effectively.
**Key Practices**:
- **Delegation**: Allow teams to choose their sprint tasks and decide how to tackle them.
- **Encourage Accountability**: Make team members responsible for achieving sprint goals while providing the necessary support.
- **Create Psychological Safety**: Cultivate a culture where mistakes are seen as learning opportunities.
**Example in action**:
A Scrum Master noticed that their team often waited for directives. By gradually delegating planning tasks and asking, “How would you solve this?” the team became more proactive and confident in their decision-making. Every 2 months, they would also run a Team Health Check on psychological safety and discuss attitudes and behaviors based on the outcome that would help everyone in the team feel like they could participate.
## Habit 7 – Embracing adaptability and resilience
The Agile manifesto emphasizes responding to change over following a plan. Successful Scrum Masters and teams embody this mindset by adapting to challenges without losing focus.
**Key Practices**:
- **Flexible Sprint Planning**: Adjust sprint goals based on changing priorities or unforeseen roadblocks.
- **Risk Management**: Anticipate potential challenges and have contingency plans in place.
- **Experimentation**: Use spikes to explore solutions to complex problems during sprints.
**Example in action**:
When a last-minute regulatory update required changes to an ongoing project, a resilient Agile team quickly re-prioritized their backlog. This adaptability prevented delays and ensured compliance.
## Your call to action: build your own success habits
It’s clear that the best Scrum Masters and Agile teams don’t rely on luck or happenstance — they cultivate habits that drive continuous growth and collaboration. By embracing Agile principles, balancing diverse roles, empowering team ownership, and fostering a culture of improvement, you can unlock your team’s full potential.
Now it’s your turn: Which of these habits will you cultivate next? Whether it’s improving your retrospectives or empowering team ownership, start small and grow from there.
Need a starting point? Why not take this [self-assessment quiz](/scrum-master-self-assessment-quiz/) to identify your strengths and areas for growth.
---
# Transitioning to native AWS services, December 2022
URL: https://www.teamretro.com/blog/transitioning-to-native-aws-services-december-2022/
### Current state
As you may be aware, TeamRetro is currently hosted on the Salesforce Heroku Platform-as-a-Service (PaaS), which in turn is hosted on Amazon Web Services (AWS) Infrastructure-as-a-Service (IaaS) in Amazon’s Northern Virginia (us-east-1) and Frankfurt (eu-central-1) data-centers.
While the Heroku platform has served us well over the last few years, TeamRetro has reached a point where we’ve outgrown it and we are looking to set ourselves up for future growth and to improve our product services and security.
### Migrating to AWS native service
We are planning to transition off Heroku to AWS-equivalent native service platforms (within the same data centers) in late December 2022. This migration will be transparent to you, although we hope you notice the improved performance and availability. As part of this migration:
- **Heroku Server Dynos** will be replaced with **AWS ECS Fargate** services
- **Heroku Postgres** will be migrated to **AWS RDS Aurora Postgres** clusters
- **Heroku Redis** will be migrated to **AWS Elasticache** clusters
To further reduce our data footprint we’ll be replacing a number of current third-party processors with their AWS equivalents.
- **Sqreen (DataDog Inc.)** web application firewall will be replaced with **AWS Web Application Firewall**
- **ImgIX (Zebrafish Labs Inc.)** asset resizing and CDN will be replaced with **AWS S3 + AWS CloudFront**
### Preparation
Over the last two months we’ve been shaking and performance testing the new AWS environments in parallel to maintaining our existing Heroku environments. We have been working with our SOC2 auditors to ensure compliance is maintained during the transition phase.
We’d like to thank our friends at Mechanical Rock Inc, Assurance Lab and Amazon Web Services for their assistance in the planning and implementation of this migration!
### Migration process
Migration will be completed outside of business hours over a weekend, and will involve approximately 2 hours of planned downtime as data is transferred. Advance notice of this scheduled outage will be sent to account owners 48 hours prior to commencement.
### Questions
If you have any questions – please let us know at [info@teamretro.com](mailto:info@groupmap.com)
---
# Understanding team health data and next steps
URL: https://www.teamretro.com/blog/understanding-team-health-data-and-what-to-do-next/
Running regular health checks sets the culture and tone for your team. It signals that you value and want to hear their voice about how they feel about their work. It is a valuable exercise that gives everyone insight into where problems might exist and to become the focus of the sprint retrospective. TeamRetro’s health check comes in either a radar or emoticon formats depending on how you like to collect and visualize data.
### So now you have the data – what do you do?
This blog gives you a starting point to leverage the data you have generated to guide the conversation with the team. While we have used the extreme cases for illustration purposes, the same rules of engagement apply for an individual dimension.
### All signs point to green.
- **Identify what might be the causes of success**– Lessons learned are not limited to just failure. Ask teams what is creating this success, recognize it, then feed the beast.
- **Ask the question**– What would hinder or stop this success going forward? Identify the risks and potential issues that might come up in the future.
- **Challenge the team** – What would happen if you extended the health check to product owners, scaled teams or leadership stakeholders?
- **Change the dimensions** – If these areas seem to be working well over a period of time, experiment with changing one or two dimensions.
- **Don’t rest on your laurels** – Just because you’ve worked out at the gym and the results have shown doesn’t mean you should neglect it. Continue to validate the status of the team even if all is does is allow you to celebrate successes. If over time your team’s health continues to hold true, this becomes a great communication story to share with others in your organization (We’d love to hear about this story too).
### There’s a lot of mellow yellow.
- **Look for variation in responses** – ie. some people are very happy and others not (Use TeamRetro’s sort by mixed responses first to look at the dimensions that have the most mixed responses). Explore what might be causing the divide.
- **Check for psychological safety** – If responses are all very neutral, it could be that people are too scared to speak the truth and have gone for something neutral.
- **Look for opportunities to move the needle** – this is a perfect time to talk through what people think we need to do to shift the needle and to move us into the 5’s and in the greens.
- **Check for understanding of health dimensions**. Clarify with the team that they know what the dimensions mean (or mean to them). Redefine or rescope the dimensions and try again to see if that makes a difference if need be.
- **Watch out for [Unhealthy Peace](https://www.ted.com/talks/priya_parker_3_steps_to_turn_everyday_get_togethers_into_transformative_gatherings?language=en&fbclid=IwAR0Tzh4PBe040JW_umGDGN6-D9judZtmvFEPtkx4Hn6ttfw18p1dYbKPRP8)** – this basically means people are avoiding conflict which in its own right can be detrimental to the overall goals of the project.
### Oh dear the red is here.
- **Call out the elephant in the room.** Find out what is causing the biggest issues and have team members air it out, straight away. If the culture isn’t quite there yet, then try using anonymity to help. Remind people it’s not about placing fault but looking for the way forward.
- **Identify the root cause.** Use the 5 why technique to drill down into what might be causing the issue then ask the team to address the root cause.
- **Use the circle and soups model** (or circles of influence to help address those issues). What can they individually change or control, what can they do as a team, and what is beyond their control.
- **Look for quick wins if possible**. Run a retrospective such as the DAKI or the StarFish retrospective that focuses heavily on actions to take forward so that concerns can be quickly addressed.
- **Talk to people. Be vulnerable**. With signs of bad health it can be cathartic (but also empowering) to be the first to shoulder the blame, take some responsibility or just open up to people to listen as to what is on their minds.
## Some final team health tips for scrum mastery
TeamRetro lets you automatically re order the group’s responses by original order, most positive, most negative or most mixed responses first. Whichever order you choose, make sure you honor each dimension. Only focussing on negatives can make gatherings a glum, moody experience. Looking at the most mixed responses highlights the division in the room so giving each side an opportunity to share their perspective can give insight to others.
Looking at data from one health check is certainly useful for short-term planning and focussing retrospective topics to get the biggest bang for buck. Long-term data shows progress and can be a great way to celebrate and acknowledge team effort and success.
One last note. Data is important. Conversation with people is vital. Taking action and following through, however, is what causes the shift. Knowing which battles to fight as a scrum master, which need to be left to be self-directed by the team, and which requires the wisdom to accept and let go is part of the skill.
Don’t stop listening and keep up the great work! Ready to discover your team’s health?
---
# Beyond the surface: unearthing valuable metrics from retrospective and health checks
URL: https://www.teamretro.com/blog/unearthing-valuable-metrics-from-retrospective-and-health-checks/
Welcome to the Insights feature of TeamRetro. [Insights](/enterprise/) brings metadata from your meetings to the surface, the people side of [agile metrics](/guides/agile-metrics/). This will help identify trends and gaps, give you a sense of team mood, health and sentiment, and understand the rate of continuous improvements through action tracking.
It does something that most other retrospective tools don’t. It shows you everything from the cadence of team meetings and the general themes, through to team happiness and [sentiment over time](/blog/ai-sentiment-analysis-in-retrospectives/).
We really appreciate when our customers share their experiences, so we thought we would do the same. So rather than another blog article on how important agile retrospectives are, this post focuses on how we used the outcomes of our retros and health checks to help support our team.
We share Insights into our own team and how it has helped us to improve. We hope it does the same for you.
—
Hi everyone,
I hope all is traveling well. As promised, here’s a little run down on our own teams based on the new Insights feature we released. It’s always really informative to examine these things through our own lens as our customers do the same.
## Insights into our meeting activity
Over the last year our 4 teams have run 27 retrospectives and 3 health checks, resulting in 102 action items and 29 team agreements. It’s great to see a bit of regularity happening as we improve our agile practice and meeting cadence. For the same measurements taken across every team using TeamRetro, see [the Follow-Through Index](/guides/follow-through-index/).
At each of our retros, we’ve had 13–47 ideas shared and anywhere from 0 to 6 actions that come out of those meetings, based on an 89% participation rate.
For those who have been attending, we see a growing healthy Return on Time Invested which continues to remain steady. Well done to the teams and Scrum Masters for keeping our meetings relevant and meaningful for those attending.
Generally, we run a retro once per month per team and a few times a year for everyone. Sometimes we bring them earlier before a weekend or to account for public holidays, and other times we have had to push them back. 1 team has really consistently met each month.
We tend to have a wide spread of agile retrospective formats from meeting to meeting which means lots of variety and different perspectives being gathered. Our most frequently used template is the standard agile retrospective format, as well as the 4L retrospective. Of course, we continue to support teams trying out different formats and styles that work for you, while we keep our all hands meeting format very consistent each time to make it easier to compare.
Based on the retrospectives, here is a word cloud of our most common themes across all our teams. Team, Working, project, Great, Thank, New, Feedback have been some positive sentiments over the last year. On the negative sentiment side, we are seeing things like Need, Agreements and Deadlines as some common ones which we have reflected on.
- 
- 
- 
Having said that, team sentiments are generally well spread and a relatively balanced approach when reflecting on sprints, although we tend to come from things from a more positive perspective. As a point of note, each of our retrospective formats has questions which have a negative sentiment in nature i.e- what did not go well, or what should we improve, or things that slowed us down. These are still necessary as part of our process so having negative sentiment is not actually an issue.
Now to our team health.
Since we only run these 3 times a year for all of us, we seem to have a relatively good participation rate and overall our team health dimensions are looking very strong.
Looking at the individual health dimensions, it’s really great to see that we have been addressing some issues of communication. It looks like breaking down into smaller teams and having some clear guidelines about how, when and how much we communicate has been a worthwhile investment.
I’m curious though. Does this mean that there are other areas that we should potentially be exploring (maybe a different type of health check)? Or should we simply talk about what we should do to keep these sorts of results positive going forward? More of those lunchtime competitions, hackathons or outcome based meetings perhaps?
When it comes to actions, we’ve certainly been busy. Many of our actions from our September retrospective last year were big ticket and epic style actions which pushed our average days to completion to 77 days. But more recently, we are seeing a pretty good flow from actions created, through to actions published and completed. This means that our open action and action maturity is reasonably good.
Finally, we have our team agreements. This is the “how we do what we do” part of the process.
What was really interesting was how agreements were split up between teams. Using the filter, it looks like marketing focused on Feedback, use of Linear, managing project tasks and scope and becoming an agile marketing team.
The Development team looked more like it was about knowing, sharing ideas, documentation and communicating ideas between people.
Our ops team only had 1 team agreement so there was insufficient data for the word cloud. However our all hands meeting agreements still hold true for us today.
Some of the agreements across all the teams that we thought were worth highlighting are :
- We raise concerns with each other.
- Work hard, have fun and recognize each other.
- If someone is waiting on something from you, communicate where it is at.
- 10%, 70%, 20% feedback rule
- Any feedback is constructive, not an attack or disregarding an idea
- If there is something you see that needs to be done, or something you’d like to do (or learn, or explore!) let the team know!
In closing, we wanted to acknowledge the great work you are all doing. These retrospectives are a great way to see those continuous improvement ideas having a place to be shared and brought to life!
---
# Why virtual icebreakers work for remote teams
URL: https://www.teamretro.com/blog/virtual-icebreakers-for-remote-teams/
Icebreakers are simple activities held at the start of a meeting that can increase productivity and support team wellness. They help build small but powerful connections between people that nurture psychologically safe spaces. They are also a quick and easy way to help a team get to know each other. Best of all, icebreakers help to bring focus to a room and therefore increase the effectiveness of the meeting that follows.
When it comes to remote teams, icebreakers offer even greater value. This is because they help address issues that can sometimes result from working online. They can make the online space feel more human. They can also counteract feelings of isolation.
Here we take a look at [virtual icebreakers](/icebreakers/virtual-icebreakers/), and share those that have worked for our remote team. For the wider set, our [work icebreaker questions grouped by goal](/icebreakers/icebreaker-questions-for-work/) include a group written for warming up a remote call.
## What is a virtual icebreaker?
A virtual icebreaker is one that has been designed to be delivered in an online environment. Like all good icebreakers, they will follow the [3E Rule](/blog/best-icebreakers-for-starting-conversations-with-online-teams-2021/); that is, they are easy, enjoyable and explainable.
Icebreakers that are delivered remotely can include more elements than those in a face to face setting. This is because virtual icebreakers can make the most of the technology that is being used to deliver the meeting.
Virtual icebreakers can, for example, include –
- virtual meeting backgrounds
- digital images, emojis and GIFs
- music and sound effects
- video
- messaging platforms and apps
They can also tap into aspects of remote team members’ home environment.
## How can virtual icebreakers help remote teams?
Virtual icebreakers give remote team members a chance to connect with each other they may otherwise not have. This is important because a feeling of connectedness is important for a team’s wellbeing.
While their colocated counterparts have the opportunity to catch up in a coffee line or chat while walking together to their next meeting, the same cannot be said for remote team members. The great news is that icebreakers are an easy and effective way to offer similar such chances.
The benefits don’t stop there. Icebreakers help to build supportive work environments. They encourage spaces in which people are happy to share. Icebreakers also help teams work better. In fact, there is [research](https://books.google.com.au/books?hl=en&lr=&id=4ITxDwAAQBAJ&oi=fnd&pg=PA293&dq=the+psychology+of+icebreakers&ots=ZiG6p1rp_w&sig=mziSScGDw1Qu-AWEP7BWktNtN8A#v=onepage&q=the%20psychology%20of%20icebreakers&f=false) pointing to icebreakers improving the efficiency of remote teams.
Finally, icebreakers are fun. Not only do fun workplaces support team cohesion and learning, they retain team members for longer.
## Our top 20 icebreakers for remote teams
Our top virtual icebreakers have been built with the benefits of remote work in mind. They leverage the variety of environments from which team members are working, the technology they have at their fingertips, and the shared experience of remote work.
### Quick shares
As the name suggests, these icebreakers prompt remote team members to share something simple that is then explained. The chance to offer an explanation allows people to decide upon the level of insight they present to the team.
1. Share the last emoji you used; explain why you chose it.
2. Share a GIF that represents your current mood; what does it show about how you feel?
3. Share an image that represents what you will be doing in 10 years time.
4. Change your background to reflect an aspect of your personality; what does it show about you?
5. Play a sound grab that lifts your mood; why do you like it?
### Quick tours
Our environment is a reflection of ourselves, and showing what’s around us offers insight into our world. These icebreakers are very effective in gaining focus as they tap into our natural curiosity to learn more about each other.
1. Show us what’s on your desk; what should and shouldn’t be there?
2. Show us around the room; why are you working from that spot?
3. Take us to your favorite spot; why do you like it?
4. Show us your view; what can you see?
5. What’s under your desk?
### Grab it
These icebreakers are a bit like a scavenger hunt. Allow 30 seconds for team members to quickly grab the nominated item. These icebreakers give people the chance to move as well as share. To run this as a game, [Scavenger Sprint](https://games.teamretro.com/games/scavenger-sprint/) does the timing and scoring for you, free in the browser.
1. Show us something you regret buying.
2. What is the most unusual kitchen utensil you have?
3. Grab something blue.
4. What do you own that has no purpose, and yet you still love it?
5. Introduce us to your pet (if you have one), or share a photo of a pet you wish you had.
### Celebrating our remote work experience
There are quite a few advantages to working remotely and from home. Asking icebreaker questions that prompt people to identify those benefits are a great way of fostering connections while setting a positive tone for the meeting that will follow.
1. What does working remotely allow you to do that couldn’t happen if you were working face to face?
2. What do you do instead of commuting to and from work?
3. Be honest – how often do you work in your pajamas?
4. What have you learned about yourself by working remotely?
5. Describe your ideal remote work space.
## Want more?
If you’re keen to get started but don’t know how, head over to our post on [how to run an icebreaker](/blog/how-to-run-an-icebreaker/).
Ready to run your icebreaker?
[Try our free online icebreaker games](https://games.teamretro.com/games/) — including [Two Truths and a Lie](https://games.teamretro.com/games/two-truths-and-a-lie/), a [guess-the-emoji game](https://games.teamretro.com/games/emoji-guess/), and [Team Spectrum](/blog/team-spectrum-icebreaker-game/), built for [remote teams](https://games.teamretro.com/use-cases/remote-teams/).
Designed with agile teams in mind, you can pick a question, randomize who goes next and even keep an eye on the time!
---
# Warm-up or icebreaker. Which one should you use?
URL: https://www.teamretro.com/blog/warm-up-or-icebreaker-which-one-should-you-use/
If you’re working with a new team, or you have a new team member, use an icebreaker. If you’re working with an established team, it’s likely a warm-up will be more effective.
When it comes to kicking off a meeting, icebreakers help connect people to each other, while warm-ups help connect people to the topic at hand. When deciding which one you should use, it all boils down to one simple question: how well do you know each other?
So if it’s so simple, why are the two so often confused with each other? Well, this is because they have a number of things in common –
- They are both great activities to [kick off a team meeting](https://games.teamretro.com/use-cases/team-meetings/).
- They both help set the stage for productive, focussed sessions.
- They both can help build a group’s energy.
- They are both an opportunity to model supportive behavior.
Importantly, both icebreakers and warm-ups can help build psychologically safe spaces. It’s no wonder they are often used by Scrum Masters to help kick off retrospectives.
Now, having things in common doesn’t mean they are the same. In fact, understanding the differences between the two will help you deliver more effective meetings for your team.
## What is an icebreaker question and what makes it good?
An icebreaker is a simple activity that helps connect people. They foster tiny, but important interactions that build rapport.
[Research](https://research.com/careers/productivity-meeting-icebreakers) has confirmed that the connections icebreakers help build are valuable. They help lay the foundation for more effective meetings. They remove barriers that come from a lack of familiarity. They nurture psychological safety. The fewer such barriers, the greater the level of trust, safety and, therefore, productivity.
Good icebreakers follow the [3E Rule](/blog/best-icebreakers-for-starting-conversations-with-online-teams-2021/), they are Easy, Enjoyable and Explainable. They give everyone in the room a chance to say something without the pressure of having to be right.
Icebreakers are a chance to have fun. They do not have to be connected with the meeting at all. They can be creative, clever, silly or any combination of the three. The main thing is, they are inclusive so everyone in the group is invited to contribute and could easily respond.
Icebreakers are the perfect activity to help people get to know each other. They are really valuable for people who’ve not worked together before. They are a great way to start retrospectives for new teams, or teams with new members, and our [ice breakers for team meetings](/icebreakers/icebreakers-for-meetings/) work for standups and kickoffs too.
Icebreakers can be the difference between a good meeting and a great one. That’s why we’ve shared all sorts of examples of [Quick But Effective Icebreakers to Launch Your Next Retrospective.](/blog/quick-but-effective-icebreakers-to-launch-your-next-retrospective/)
## What is a warm-up and what makes it good?
A warm-up is an activity that helps people focus on the task at hand. They help people direct their full attention to the topic of the meeting. They also help them to switch off from other thoughts and tasks.
A warm up can be a co-operative task, a challenge or even a game. They can help build teamwork and camaraderie while focussing the group. They help people limber up before the meeting which leads to the session being faster, more focussed and efficient.
Generally speaking, a warm-up is used for a team that already knows each other, and where good relationships exist between participants.
Warm-ups tend to connect people to the meeting rather than with each other. Instead of finding common ground between participants by encouraging personal reflections, they aim to connect people to their common purpose at a shared moment in time. People could, for example, be asked what people think of the task. They could be asked what they need to stop thinking about in order to actively engage. Participants could simply be asked how they feel at that moment in time.
A more creative example of a warm-up is Countdown. The aim of the activity is to count down from 20 with each person taking a turn to say one number out loud. No one is nominated to coordinate the order in which people speak. No one can speak at the same time (or the group starts again). This exercise requires everyone to pay attention to what’s happening in the room. They need to listen and carefully observe in order to deliver success.
[](https://games.teamretro.com/)
## Run your own icebreaker now!
Need help choosing the right ice-breaker?
We’ve got you covered! Find the [best icebreaker questions for your next team meeting.](/icebreakers/icebreaker-questions-for-work/) Or jump straight into a [free online icebreaker game](https://games.teamretro.com/games/) — try [This or That](https://games.teamretro.com/games/this-or-that/) for a fast, low-effort warm-up.
---
# We used TeamRetro’s health check as a mood meter and safety check: this is what we found.
URL: https://www.teamretro.com/blog/we-used-teamretros-health-check-as-a-mood-meter-and-safety-check-this-is-what-we-found/
If you are anything like us, you value the happiness of the team of people you work with. Ensuring everyone can grow and feels supported is essential. Fostering a safe and fun environment is key to this. However, monitoring a team’s mood and safety levels can be a challenge.
We recently held our annual work retreat. Our core team members from four countries come together to reflect, plan and get to know each other better. Understanding the sentiment of individual team members was vital. It helped us plan sessions to address concerns and explore areas of interest and opportunity.
This post shares how we used the [Team Health Check,](/health-check-templates/team-health-check/) the data we captured and what that data meant to us.
## Using our health check as a mood meter
We love our team. They are the people who help build, deliver and improve TeamRetro.
A health check allows us to check in with them from time to time, and over time. It provides people the opportunity to share how they feel. It’s a quick survey that lets them easily indicate how happy they are across various health dimensions.
As a Scrum Master or leader, it gives us insight into areas of concern that we want to address as a team. As a team, the data points allow people to get a sense of how everyone else is and what they can do to support as needed.
We run our health checks every quarter. It means we get a regular [team pulse check](/health-check-templates/quick-pulse-check/) throughout the year. It’s also far less demanding than a daily or weekly mood check.
Beyond just having a mood check, the TeamRetro health check also provides statistical insight into the data. Beyond the pretty graphs, it acts as an enabler for encouraging discussion.
## How we define team happiness and safety
Every organization will define team happiness differently. For us, these dimensions cover a range of team dimensions that impact on the culture or mood of the team. In summary these are:
- **Ownership**: how much ownership someone feels they have over their task or job.
- **Value**: whether or not someone feels they are delivering value that can be measured.
- **Goal Alignment**: whether their goals match those of the team and the wider company.
- **Communication**: whether conflict is minimal and communication is easy, open and smooth.
- **Team Roles**: how well roles are defined and understood.
- **Velocity**: the efficient delivery of agreed outputs at the right quality.
- **Support and resources**: the level of support and resources available.
- **Process**: whether or not processes support or hinder workflow.
- **Fun**: whether there is engagement and fun.
We ran our team health check asynchronously over two weeks, allowing people to input their responses (happy, neutral or sad emoticons) at any time. They could also provide specific comments if they wanted to.
## Keeping psychological safety in check
One of the key considerations was safety. There were a few ways we did this.
The first was to be open at meetings about the purpose of the surveys. We wanted the engagement to be high, but also honest. We made sure to let people know that they should indicate things that bother them and that it is okay. At the same time, we mentioned that we would not share comments but would follow up individually to address concerns.
We also ran the check semi-anonymously in order to build a sense of safety, giving people space to say how they feel with far less pressure. This meant that their score was anonymous, but that we could follow up on their comments to ensure they were not ignored.
Finally, the scores were discussed in aggregate and no one was pin-pointed. Unless they volunteered, there was no disclosure about individual responses, just that of the team.
## Evaluating team mood data
We posted the survey on Slack, which we already integrated. Results were encouraged and reminded a few times and we had a 100% response rate.
Here’s what came out on the radar.
This radar shows the mean and range. While most of the scores were predominantly positive, the minimum range was still neutral in other dimensions, and negative in communications.
This can also be seen if we overlay individual scores, the thicker lines represented where there were more of the same responses. E.g. Goal alignment through to process.
The standard deviation showed that there was less deviation in process and ownership but that it was wider in communication and velocity. This suggests greater alignment in the responses around process through to team roles which gets wider as you go around the radar.
The mode shows the most common response. So in other words, the vast majority of the team had positive responses and maybe just a few individuals may have issues that required personal attention.
This is also reflected in the median (the middle score).
While presenting statistical data can stimulate a lot of questions, discussion and deliberations, it is just as important to look at the trends over time.
## Looking at team mood and safety over time
While a snapshot of a team’s health is valuable, so is looking at trends over time. Each column below represents a 6 monthly health check with the team.
In essence, our overall team’s mood was upbeat and strong, but it was clear that communication, value and velocity had room for improvement. Or at least it did in this cycle.
On a positive note, it was great to see that velocity and process issues previously addressed were sustaining, and that no one dimension had a high number of concerns. We previously dedicated a [Goldilocks Retrospective](/retrospective-templates/goldilocks-retrospective/) to our process flow to streamline everything from customer service to internal provisioning requests.
Having said that, it was still important for us to look at the areas of communication, velocity and value. This ensures that they don’t slowly develop into issues later on down the track. Some insights did come through via comments, in addition to a good old fashioned chat.
## The follow-up actions
Here’s what we did based on what we saw:
- We looked at specific comments and reached out to the individuals who shared their thoughts. We invited them to discuss and share solutions and to alleviate concerns. Some of this was very simple and easily fixed. Others just said they were having a bad day. Finally, others required further process changes.
- We shared the results with the team. Velocity, value and communication is not just down to management, or just the team but with everyone. Sharing the results openly and honestly was done to create visibility around the problem and having people think about what they can do to help improve the situation.
- We played some [agile games](/blog/the-best-agile-games-for-building-teams-learning-and-creativity/) . Specifically, these were the Agile Ball Point Game and Agile chocolate game. These games were designed to create a safe space where the team could experiment with ideas in a time-boxed way. Special thanks to [Alexandrina Danifeld](https://www.linkedin.com/in/alexandrinadanifeld/), for facilitating one of our sessions.
- We made changes to our kanban. For example, addressing value and velocity through a co-designed kanban workflow. By agreeing on process and deliverables, this helped to improve the smoothness and speed of output.
## Final thoughts on team mood and safety checks
Our modus operandi aims to have a happy and productive workforce. One certainly feeds into another.
Running surveys and health checks can be confronting, especially when results are not perfect. However, without these [data points](/blog/understanding-team-health-data-and-what-to-do-next/) generated from a culture of safety, there is little opportunity for improvement.
Would we do another health check in the future? Absolutely.
The only thing we would change is to ask people to suggest improvements, and why they feel a certain way. At a whole group level, we’d certainly like to understand what made people give positive feedback and responses. Knowing what elements make people happy means that we can repeat, replicate and reward going forward.
How do you gauge the health of your team’s mood and safety? What questions would you have asked, or what actions would you have taken?
We would love to hear your thoughts or questions. Reach out to us at [info@teamretro.com](mailto:info@teamretro.com)
---
# We’ve made choosing the right retrospective format for your agile team easy
URL: https://www.teamretro.com/blog/weve-made-choosing-the-right-retrospective-format-for-your-agile-team-easy/
We all know we’re meant to use the right tool for the job. We all know it can make the difference between getting the job ‘done’, and getting the job ‘done right’. Most of all, we all know just how easy it is to ignore this pearl of wisdom.
For some reason, we’ll find ourselves doing something like reaching for a knife to open a can. Sure, we may get the job done, but when we use the wrong tool we may end up breaking the tool, damaging the goods or even ourselves.
The same can be said of retrospective templates. Using the right retrospective template will help you deliver the outcomes you hope to achieve more effectively. Using the wrong template may –
- undermine its effectiveness
- cost the team valuable time, or even
- negatively impact the engagement of the team
The great news is, we’ve made it much easier for you to pick the right template for your next retrospective meeting! The templates are all remote friendly for distributed teams and just as useful for face-to-face sprint retrospective meetings. They can help focus your team on the product, the process, and they can even help make the meeting fun.
## How have we made choosing retrospective templates easy?
The short answer is we’ve built a [widget](/retrospective-templates/) that overcomes the main barrier to making that choice; finding time.
When it comes to choosing a retrospective format, a lack of time can often mean you don’t explore the other templates and the benefits they deliver. Instead, you stick with the same format or the one that is most familiar.
This means that your team doesn’t get to benefit from the value changing retrospective templates can bring. Even worse, it could actually be helping antipatterns to take hold. This includes meeting fatigue, repetition and boredom, or asking the wrong questions.
The widget helps you to quickly hone in on the template most likely to help your team. It has been designed to align the focus, context or behavior you wish to address to the best template for the job. It offers a quick summary of the template, along with the dimensions it includes. Of course, you can test drive that template with our team of friendly bots, and get more detail on it and how we’ve used it in the past.
## How have we sorted the retrospective templates?
We have categorized each of the templates based on their purposes and intended outcomes. While a retrospective does not have to be solely focussed on just one aspect, each has a major theme it will support. Here’s the rundown.
### Check-ins
As well as supporting the retrospective itself, these can also be used to bring the team into the meeting headspace. They can help warm up the team, help to build rapport, and they can make sure everyone’s focus is on the meeting at hand. It’s easy to get distracted by emails and other work items, so a check-in that uses an easy, round robin style of questions helps people focus on the retrospective. They tend to be simple questions that have no right or wrong answer, so they build safety by giving each person a chance to chime in.
### New to retros
These are designed for a Scrum Master who may be new to Agile, or for a team who are just starting to dip their toes into the Agile water. They are tried and true formats that have become industry standards, and offer a solid array of questions to help the team learn and grow.
### Team building
Have a new team? Maybe just a new team member? These team building retrospectives aim to help people work more collaboratively on a particular issue or theme. They can help to create [social contracts](/blog/create-social-contracts-with-team-agreements-that-improve-culture/). They can help grow understanding as to how each person works, thinks, and solves problems. There are no high rope courses here. Instead, it’s a discovery of the way your team members think and how they might work together.
### Product management
These retrospectives templates help the team focus on the elements that will deliver the best possible product. They include dimensions that keep sprint and product goals in mind based on feedback from product owners, data and overall user stories. They look at the features of the product. They also look at how the team coordinates and is supported while delivering their goals.
### Process
These templates focus on how a team works. They examine the environment in which they work and the stage they find themselves in the development life cycle. The goals of the templates might be to remove impediments, increase productivity and throughput, or simply to ensure that the team has a shared understanding of the process. Whether it’s continuous delivery or paired work, the process focus means that you can more easily examine what the team needs by way of support.
### Futurespectives
These templates support the delivery of [futurespectives](/blog/everything-you-need-to-know-about-futurespectives/). While it is generally known that retrospectives are based on the last sprint cycle, a futurespective takes a different tack. They help teams shape a high-level strategy that supports the smooth delivery of their goal. They do this by having a team draw on their past experiences to shape a shared vision that will guide them forward.
### Fun and novel
Is your team suffering from meeting fatigue? Can you sense their disengagement? Is there a chorus of groans when it comes to your retros? These fun and novel agile retrospective formats encourage people to think differently by offering them a fresh perspective. They bring smiles, energy and vibrancy to the meeting. Warning: It may lead to laughter or a wild idea that just might work!
### Deep dives
These are the agile formats to use when it’s time to get deep and meaningful. The questions here help you delve further into a topic. The conversations themselves may be more intrinsic or personal in nature. Some of them require a little soul searching while others may require an analytical approach to solving a problem or issue.
## How to find a retrospective template for your next agile meeting
Finding the right template can be done in three easy steps.
1. Head over to our [widget](/retrospective-templates/).
2. Pick the category that applies to your theme or purpose.
3. Choose the retrospective template you want, and start brainstorming.
Want to know more about choosing a retrospective template? Check out [Chapter 8](/guides/scrum-masters-retrospective-guide/retrospective-templates/) of our [Scrum Master’s Retrospective Guide](/guides/scrum-masters-retrospective-guide/).
In it, we offer more detail on how a team’s focus, context and behavior can shape the template you choose, as well as sharing some of our favorite templates.
Do you have another idea for a retrospective format? We’d love to hear about it and to add it to our community library of templates. [Get in touch.](/contact-us/)
---
# What is a Scrum Master and why is their role so important in a retrospective?
URL: https://www.teamretro.com/blog/what-is-a-scrum-master-and-why-is-their-role-so-important-in-a-retrospective/
Retrospectives play a vital part in Agile; the opportunity they provide for a team to adapt and improve is core to the delivery of value through continuous improvement.
The [Scrum Guide](https://scrumguides.org/scrum-guide.html) states that the purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
“The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved. The Scrum Team identifies the most helpful changes to improve its effectiveness.”
Given the critical nature of the retrospective, it seems eminently sensible to allocate resources to ensure its effectiveness is maximized.
Enter the Scrum Master.
## What is a Scrum Master?
When it comes to building agile teams that deliver value using the Scrum framework, a Scrum Master is fundamental to the mix. They act as a servant leader as well as an influencer and change agent, facilitating meetings and removing obstacles to help the team succeed. They serve as a bridge between product management and development.
Along with the Product Owner, the Scrum Master is a member of the leadership group, and is generally responsible for creating an environment in which their team operates.
From planning to retrospectives, the Scrum Master facilitates the sprint. They guide, coach and lead the team, keeping them on-track and focused, while managing the process, culture and overall vibe of the team.
## The Scrum Master’s responsibilities
So what does a Scrum Master actually do?
In broad terms, the Scrum Master –
- Sets up and facilitates agile meetings
- Coaches and encourages the Scrum principles and values
- Solves logistical and meta problems
- Supports the team and addresses team dynamics
- Works as an interface between the team and the product owners as well as others outside the team
- Protects the team from outside interruptions and distractions
- Reports on team progress
Besides the retrospective, they also facilitate daily standups, sprint planning meetings, sprint reviews and team member 1 on 1’s.
A great Scrum Master should be just as comfortable discussing the team’s priorities and processes with senior management as they are ordering the team pizza for a tough final push.
## How does a Scrum Master differ from a Product Owner?
The Scrum Master can be thought of as an intermediary. They can insulate the team from minor changes, revisions or confusion that could derail the sprint.
What this means is that the purview of the Product Owner is external to the organization (product value, the market, customers and the competition); that of the Scrum Master is internal.
Additionally, with the Scrum Master’s focus on enabling the Team to *do* work, the Product Owner may better focus on the big picture rather than the day-to-day.
Ultimately, the Product Owner has the final say over the product direction and strategy but will work closely to manage the backlog, understand the trade off and to find ways to deliver value.
## Does every team need a Scrum Master?
When it really boils down to it, Scrum isn’t possible without the Scrum Master. Without one, you are doing something like a watered down version, often called scrum-but.
They foster the required environment and serve as a buffer between the team and the rest of the organization. At its core, Scrum works well because of the clear focus it gives to each member of the team; without the Scrum Master, that focus is compromised.
With that said, it *is* possible for a Scrum Team to be self organizing once things are rolling. This is also one of the goals of a scrum master. With the initial foundations laid and appropriate environment created, the team can get by without a Scrum Master if absolutely necessary. Some teams also rotate the Scrum Master role within their team, or have access to a community of practice (group of Scrum Masters), external consultants or independent agile consultants.
## Does the Scrum Master actually do the work?
Generally speaking, no.
Unless you are in a small team where one person simply acts as Scrum Master for the team, the actual development and tasks fall under the mandate of the agile scrum team. They don’t and should not interfere with the technical issues of the team.
The Scrum Master on the other hand helps to solve problems and provide assistance, guidance and seek clarification as needed. If the sprint is progressing smoothly, they should never *need* to do work. The role of the Scrum Master is to help every member of their team realize some serious gains by ensuring they are free to focus on what they do best.
Strategy is left with the Product Managers, writing the best code is left to the developers and Jason from sales can focus on getting those leads!
## What is the Scrum Master’s role in the sprint retrospective?
### Facilitate and moderate agile meetings
There’s a reason orchestras have conductors; they ensure each group of musicians play in such a way so as to deliver a harmonious performance.
Similarly, the Scrum Master conducts the retrospective to ensure it stays on track, remains unbiased, free of groupthink and is a psychologically safe space.
Scrum Masters ensure the meeting is organized from choosing a [retrospective template](/retrospectives/) based on a theme or area of focus, ensure cadence and also run the meeting to ensure that the team stays focused.
They move the team through the processes of brainstorming, prioritizing key discussions items, then generating actions for continuous improvement that are followed through. This ranges from hosting the daily standup meetings all the way through to the sprint retrospective.
### Encourage transparency and honest communication
For a [Sprint Retrospective](/retrospective-templates/sprint-retrospective/) meeting to work well, there needs to be open, unbiased and clear communication and feedback. The Scrum Master ensures this happens, and makes sure all voices are heard equally.
Meetings are often prone to groupthink and bias, and a Scrum context doesn’t magically solve this. The entire Scrum Team needs to be aware of this potential, with the Scrum Master actively supporting them so they deliver honest, critical feedback for the benefit of the team.
It’s common for people to have different opinions. When those opinions clash, it’s the Scrum Master’s responsibility to ensure both sides are heard, issues are resolved and the meeting continues. This can be a complex, delicate task and one with which the Scrum Master needs to be highly adept.
### Coach team members
For organizations that are new to Scrum, a key part of the role is to ensure that team members understand and employ Agile processes on a day to day basis. They help to create self-managed teams and to promote a sense of ownership and utility.
This could be mentoring new team members to teach them about the Scrum Values and principles and how to integrate this into their daily practice.
### Document, capture and follow through on actions
Appropriately documenting the retrospective ensures –
- feedback, issues, and action items are captured and tracked
- notes are available for those unable to attend the retrospective
- notes can be referenced throughout the sprint to ensure shared understanding
- memory does not distort facts
Ensuring accountability could be a follow up after the meeting or going through the list from previous meetings at the start of the retrospective. Those are the two habits [our first-party data on retrospective follow-through](/guides/follow-through-index/) finds separating teams who finish what they decide from teams who don't. Helping remove impediments during the sprint will help the team be more successful when it comes time to reflect at the retro.
### Keep time
Timeboxing is widely acknowledged to be an effective technique to increase productivity. With the big picture in view, tasks are prioritized, in order to make the most out of the time allotted to them.
The retrospective is the perfect opportunity for the Scrum Master to model timeboxing; not only is it important to lead by example, it ensures time isn’t wasted and team members remain engaged with the task at hand.
A useful end of meeting evaluation is the [Return on Time Invested or ‘ROTI’](/blog/return-on-time-invested/) available in all of TeamRetro’s templates. In under a minute, you can quickly gather whether or not there was value gained by the team in the meeting.
### Act as the intermediary with the rest of the organization
Outside of the retrospective, the Scrum Master can report on actions that the team has generated and can bring ideas and suggestions to the relevant stakeholders. They may create visuals such as Scrum Boards to communicate progress, or simply share feedback from the Team Health Checks to highlight potential blockages for the team.
They work with others to ensure that the team members are not in too many unimportant meetings and work with product owners and other stakeholders to redistribute the workload. Ultimately their goal is to remove distractions and blockages in order to help the team focus.
## In summary
An effective Scrum Master can significantly enhance the value delivered by a retrospective. By employing strong facilitation skills, acting as the intermediary between the product owner and the development team, and focusing on the processes, environment and culture of the team, the scrum master can set the team up for success. The value they bring to the organization through outcomes, continuous improvement and helping to create self organizing teams is just some of the reasons why Scrum Masters are such a valued team member.
Using an [online retrospective tool such as TeamRetro](/retrospectives/) allows the Scrum Master to focus on the needs of the team rather than the mechanics of the retrospective. Ideas and comments can be captured instantly and prioritized for discussions. Actions can be tracked, shared or integrated and followed up at the next meeting. Each person in the team has an equal opportunity to contribute in a psychologically safe space and can be time boxed to ensure everyone stays on task.
---
# What is an agile team health check and why are they important?
URL: https://www.teamretro.com/blog/what-is-an-agile-team-health-check-and-why-are-they-important/
A team health check is a simple tool that helps you measure and track team health and happiness over time; the data they capture can inform actions that drive continuous improvement.
Team health relates to the factors that contribute to team success.
There’s been considerable effort dedicated to defining those factors thereby paving the way to enhancing them.
[Google’s research](https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/?utm_source=google&utm_medium=cpc&utm_campaign=team-health-checks&utm_content=agile-health-check&utm_term=team%20health%20check&gclid=CjwKCAjw-sqKBhBjEiwAVaQ9ayhjwYxHbWSTo4NAHiLYFt5PozZy_j4R8p6qpdiK1bn5fNAxU45gXBoCo2gQAvD_BwE), cites five factors that are pivotal to team success.
Spotify’s work in this space informed their [Squad Health Check](/health-check-templates/squad-health-check/). Having evolved over time, the ten or so dimensions of their check reflect the factors they perceive as key to team health.
The great thing is, you don’t have to launch a research program to measure and nurture your team’s health: our [guide to running a team health check](/guides/team-health-check/) covers which questions to ask, how often to ask them, and what to do with the scores.
Agile team health checks are exceptionally valuable mechanisms for two key reasons –
- The information they capture can help inform data-driven actions designed to improve team health.
- The effectiveness of those actions can be tracked over time.
TeamRetro *offers a number of health check models from which you can choose. Each model has different question sets that can be tailored to suit the needs of your team. TeamRetro also lets you create your own team health check model to help ensure the individual needs of your team are met.*
### Why is team health important?
A healthy, happy team can benefit –
- Employers
- Employees
- An employee’s family
We know our health is important.
We know our health relates not only to our physical selves and what we can do, but also our emotional selves and how we feel.
We know if we feel good, we can do more.
Well, the same can be said of team health.
The health of the team is a culmination of the quality of their communication, culture and camaraderie which then impacts upon productivity, velocity, and ease of collaboration when it comes to hitting team goals.
Taking some time to understand and measure the health of your team can therefore lead to insights regarding what might be impacting their systems and what drives continuous improvement.
TeamRetro *quickly and meaningfully collates health check data to help you identify areas of improvement and strength. This spider chart, for example, offers an easy-to-understand snapshot of responses to a health check, that can be used to support data-driven conversations with your team.*
### Team health is important to employers
Healthy teams are happy teams. Much has been written regarding the direct link between team happiness and productivity; pointing to the fact that the happier the team, the more productive they are. The largest evidence base on that link is summarized in our [statistics on what engagement is worth](/guides/agile-statistics/#what-engagement-is-worth), which reports it as a gap between the most and least engaged teams rather than a before-and-after.
The way a team feels can strongly influence what that team can do; this is particularly relevant for the organization that has employed that team.
The organizational benefits don’t stop there!
- Healthy teams are resilient
- Healthy teams are innovative
- Healthy teams contribute to a healthy workplace culture
What, there’s more – the great news is organizations aren’t the only ones to benefit from healthy teams.
### Team health is important to employees
Members of healthy teams benefit from their positive team traits.
Members of healthy teams are more likely to –
- Be supportive of each other
- Trust each other
- Embrace opportunities to learn
- Have an optimistic outlook
- Have fun at work
Just like pot plants that thrive in the right conditions, if we are part of a healthy team, we are more likely to thrive.
Additionally, people who demonstrate the above-mentioned characteristics are more likely to attract others with similarly positive traits.
The positive momentum of healthy teams keeps going!
TeamRetro *is here to support you as you help your team in their pursuit of continuous improvement. Features such as our heat maps (above) are designed to reflect your team’s health over time. We focus on tracking your team’s health data so you can focus on your team.*
### Team health is important to the families of employees
The benefits of healthy teams extend beyond the workplace.
The pay check you take home isn’t the only thing that can make a difference to your family. The ripples of the experiences that you had at work can also have an impact.
Kansas State University’s [research](https://www.sciencedaily.com/releases/2009/08/090824115911.htm) found that people who have positive experiences at work, carry that positivity over to their home life.
If you are a member of a healthy happy team, it’s likely some of that health and happiness will go home with you!
## How can you improve your team’s health?
The first step to improving team health is to measure it, and [TeamRetro's team health checks](/health-checks/) are built to do just that.
### Decide on your dimensions
It’s important to determine what matters most to you and your team (within your context), as this will inform the dimensions you choose to use in your health check. A great way to define these dimensions is to speak with key stakeholders – this includes your team.
TeamRetro offers a range of models with preloaded dimensions to get you started. From Remote Team Happiness, Spotify or [Atlassian's Team Health Monitor](/health-check-templates/team-health-monitor/), through to the Scrum Values health check, you can use these models as they are or edit them to suit your team’s needs.
TeamRetro lets you apply your dimensions to build your own health check models. You can, in fact, create multiple models and set a default model.
Most importantly, TeamRetro helps you track your team’s response to those dimensions over a period of time thereby capturing the evolution of your team’s health.
### Create a cadence
You could set a health check schedule that could range from daily through to annually but it’s important to set some sort of regular cadence that informs how you want people to respond and share.
Keep in mind that faster, shorter health checks will let you see trends and validate team health in a more timely and relevant way.
You can run your health checks synchronously or asynchronously.
If you choose to facilitate asynchronous checks, it’s a good rule of thumb to ensure –
- That the health dimensions are understood
- You have set the tone for how you want people to respond to health checks
- What happens with the data is known and understood
Making team health checks a regular occurrence and with the right message, helps build trust and psychological safety, thereby creating a space in which –
- Feedback is embraced as constructive rather than perceived as a criticism
- Issues are identified and quickly addressed
- The positive relationships between team members are reinforced
- Conversations are open, honest and supportive
### Measure and manage
The last step is all about connecting your team and transparency is key.
1. Share the results of that first health check with your team.
2. Acknowledge and celebrate successes.
3. Explore any issues the health check may have identified.
4. Ask your team for their input as to how team health could be improved.
5. If relevant, use the artifacts of your health checks as the theme for your next retrospective.
6. Capture actions or team agreements that the team would like to take going forward.
For more help, check out our 5 handy hints for running team health checks.
If you think it’s valuable to explore the health and happiness of your teams, test-drive our health checks with our team of friendly bots.
[Try Health Check Live Demo](https://secure.teamretro.com/demo/health-checks)
Happy health checking!
TeamRetro
---
# Which of the scrum values is most demonstrated by your team?
URL: https://www.teamretro.com/blog/which-of-the-scrum-values-is-most-demonstrated-by-your-team/
Scrum Values are the **“how we work together”** side of agility. When they show up as day-to-day behaviors, teams deliver more consistently and learn faster. The challenge then? How do we get each person in a team to demonstrate more of the Scrum Values and create more happiness, productivity and common ground in our daily interactions.
In this post, we explore how we can get team members to reflect on the values, pick one value to strengthen and plan an action item.
## What makes scrum values essential for agile teams?
The Scrum Values of **Commitment**, **Focus**, **Openness**, **Respect** and **Courage** keep teams aligned when work becomes complicated. They guide how teams work under pressure, how conflicts are resolved, and how goals are achieved. When lived daily, they reduce friction, surface blockers earlier, and make tough conversations easier.
Think it’s a little corny to talk about values? Imagine the opposite. What would it be like working with an uncommitted, directionless, siloed, rude and avoidant team? Nobody speaks up. You can’t rely on others and soon you lose direction and your own drive.
Moving teams from paper based values to lived practice therefore remains a goal for Scrum Masters, Agile Coaches and Agile Teams.
## The five scrum values in practice
So what do the values look like in practice?
### 1. Commitment
**“*The Scrum Team commits to achieving its goals and to supporting each other*.”**
What does it look like? Keeping promises every sprint.
E.g. Aligning around a one-sentence sprint goal and adapting together when things slip.
### 2. Focus
**“*The primary focus is on the work of the sprint to make the best possible progress toward these goals*.”**
What does it look like? Protecting what matters most.
E.g. Prioritizing work and reducing noise so the sprint goal stays on track and the product backlog is managed and groomed.
### 3. Openness
**“*The Scrum Team and its stakeholders are open about the work and the challenges*.”**
What does it look like? Sharing early and often.
E.g. Being transparent about progress, challenges, and blockers at daily standups.
### 4. Respect
**“*Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work.*”**
What does it look like? Valuing others.
E.g. Respecting teams to self manage and to determine how they do the work to achieve the Sprint Goal and following the prime directive.
### 5. Courage
***“The Scrum Team members have the courage to do the right thing, to work on tough problems.”***
What does it look like? Speaking up for the Sprint Goal.
E.g. Raising issues early, challenging scope creep and pushing back to stay aligned.
## Scrum values health check
Getting a picture of where your team measures up is the next step in moving forward. A **[Scrum Values health check](/health-check-templates/)** in TeamRetro makes them visible, measurable, and actionable. It’s a quick pulse check that can provide some quick data points, independent /anonymous commenting and a way to get new ideas from the team, or from context driven AI that can suggest some actions based on the results.
It provides an easy way to identify low hanging fruit, lowest individual and team scores and to then discuss ways to address some of those issues individually or as a team. These can all be done in a psychologically safe way, yet reflect how individual perceptions and responses contribute to the team as a whole. Seeing the spread of responses in this case is just as insightful as aggregated scores.
## Turning data into action
Here’s a quick cheat sheet on some generic action improvements for each value. However, we suggest that you use actual scores and feedback from your team and their survey responses to come up with actions, team agreements and takeaways that are valuable to you. Using TeamRetro’s AI feature, you can get more context driven action suggestions for your team to discuss.
| **Value** | **Action Improvements** |
| :-- | :-- |
| **Commitment** |
- Keep the Sprint Goal visible on the board and review progress daily.
- Each team member states their commitment to their tasks during sprint planning.
- Log an action for mid-sprint check-ins to ensure alignment with the Sprint Goal.
- Rotate a **“goal champion”** role to remind the team of the goal.
- Capture learnings about missed commitments and agree on process adjustments.
|
| **Focus** |
- Set and maintain a team WIP limit, revisiting its impact in the next retro.
- Block out **“focus time”** slots on the shared calendar.
- Limit unplanned work by requiring explicit trade-off discussions.
- Agree on clear daily priorities (e.g. top 3 tasks to unblock first).
- Use sprint board filters to highlight items closest to completion.
|
| **Openness** |
- Log blockers as retro items with owners for follow-up.
- Introduce regular **“demo-in-progress”** sessions for transparency.
- Add uncertainties as backlog refinement items.
- Rotate facilitation so all members lead discussions at least once.
- Document key decisions in a shared space (wiki, board).
|
| **Respect** |
- Enable anonymous input or round-robin speaking to ensure all voices are heard.
- Give and receive constructive feedback using a structured framework.
- Actively acknowledge contributions during daily standups.
- Enforce a **“no-interruptions”** rule in meetings.
- Celebrate small wins or improvements at the end of each sprint.
|
| **Courage** |
- Challenge scope creep by requiring team agreement before adding work mid-sprint.
- Create a visible risk register with owners and due dates.
- Use **“spike”** tasks to explore unknowns rather than deferring them.
- Raise impediments early, even if solutions are unclear.
- Review failed experiments in retrospectives as learning opportunities.
|
At the end of the health check, ask each team member to identify which one they’d most like to strengthen. This creates personal ownership without overwhelming people. Have them come up with one action that they can commit to and share with the team.
By combining TeamRetro’s Scrum Values health check with practical team behaviors, those values shift from abstract ideals into measurable habits that drive continuous improvement.
Whether you run it once just to get a baseline and to create a set of team agreements, or something that you want to monitor and track as your team changes or evolves, coming up with a list of agreed behaviors sets the vibe for your team.
## From scrum values into scrum habits
If you are running your health check in TeamRetro, you can capture, track and keep account of the action items and team agreements from your team. You can then refer to these at the next retrospective or health check. It’s a good reminder, improves accountability and can continue to motivate good habits with the team.
You could integrate this into your one on one discussions, pop it onto a poster on the office wall, or run it as part of your retrospectives to keep it on everyone’s radar.
For example, at the end of your retrospective or icebreaker question, you could ask ***“How did you demonstrate one of the Scrum Values this sprint? How did it help us?”*** This reinforces progress and normalizes experimentation. You could even take this further by running a **[Scrum Values retrospective](/retrospective-templates/scrum-values/)**.
Finally, don’t forget to acknowledge and celebrate small wins. Highlight when values do show up in practice. Use the kudos feature in TeamRetro to **[give team members a shout out](/blog/giving-kudos-with-kudo-cards-in-retrospectives/)** when they have demonstrated one of the Scrum Values. It’s not just a warm cozy feeling you give, it’s a way to build resilience and examples of how values appear in your team.
Scrum Values aren’t just posters on the wall — they are the daily habits that make teams resilient, aligned, and effective. By reflecting on the values, choosing one to strengthen, turning it into a micro-behavior, checking in on progress, and celebrating wins, teams create the conditions for trust, learning, and sustainable delivery. Small, consistent actions compound into big cultural shifts.
👉 Ready to see where your team stands? Run a **[Scrum Values health check](/health-check-templates/)** in TeamRetro to get a baseline, spark meaningful discussions, and capture practical action items that turn values into habits.
---
# The power of regular retrospective meetings in agile teams
URL: https://www.teamretro.com/case-studies/alchemer/
It’s always appreciated when we get feedback from our clients; it’s their input that helps guide us as we learn, grow and evolve TeamRetro. Their stories are why we do what we do.
That’s why we are delighted to share with you this piece written by [Mel Fox](https://www.linkedin.com/in/mel-fox-01587323/), Digital Product Manager, entrepreneur and TeamRetro user. She shares tips and tricks she uses with her team when conducting retrospective meetings that are engaging and productive.
## Impactful retrospectives
In the fast-paced world of agile development, it’s crucial for teams to continuously improve their processes, communication, and overall performance. One of the most effective ways to achieve this is through regular and productive retrospective meetings. These gatherings provide a chance for the team to reflect on their work, celebrate successes, address challenges, and make actionable improvements.
Unfortunately, some teams find themselves dreading their post-Sprint retrospective and are trapped in a cycle of creating stale bullet points without ever revisiting them. As someone who takes pride in running and managing impactful retrospectives, I wanted to highlight the importance of hosting impactful retrospectives, emphasizing the significance of tools like TeamRetro that enable intentional and effective retrospective sessions.
## Create a safe space for emotions with your retrospective
While it’s no secret that engineers are highly analytical and logical individuals, it’s essential to acknowledge that they also have emotions. A productive retrospective encourages team members to express their feelings openly and honestly.
By providing a safe space for emotional discussions, teams can address any frustrations, concerns, or conflicts that may be hindering their progress. Recognizing and validating these emotions fosters empathy, understanding, and a stronger team bond.
## Establish actionable insights and ownership
A successful retrospective not only provides a platform for open dialogue but also results in tangible outcomes. By identifying and discussing areas for improvement, teams can generate actionable insights. These insights can then be translated into concrete action items that are assigned to relevant stakeholders on the team. As a Product Manager, I put a lot of the action items on my shoulders, but there is just as much accountability for the Engineering Manager and team leads, as well. This clear assignment of responsibilities ensures that the team’s concerns are heard and acted upon, driving real change and continuous growth.
> #### Quick Tip!
>
> #### At the beginning of each retrospective, address the open action items from the last retro — what was done, what still needs to be addressed, and what could have been done differently. Oh, and guess what, you can add those items right into your current retrospective.
>
> #### Boom!
## Select the right tool for your retrospective meetings
To maximize the effectiveness of retrospective meetings, leveraging appropriate tools can be immensely valuable. TeamRetro, in particular, is a powerful tool designed to enhance the retrospective experience. With its user-friendly interface and comprehensive features, TeamRetro enables teams to conduct intentional and productive retrospective sessions. Here are some key aspects of TeamRetro:
### Customizable templates
TeamRetro offers a wide range of pre-designed [retrospective templates](/retrospective-templates/) tailored to different goals and objectives. These templates provide a structured framework for discussions and help teams focus on specific areas such as process improvement, team dynamics, or individual growth. I, personally, enjoy selecting a different template for each meeting to spice things up a bit.
### Collaboration and remote accessibility
In today’s distributed work environments, TeamRetro facilitates collaboration regardless of team members’ physical locations. The tool allows participants to contribute their ideas and feedback asynchronously, ensuring that all voices are heard and considered.
### Action item tracking
TeamRetro streamlines the process of capturing action items by providing a centralized platform for tracking and monitoring progress. This feature ensures that the outcomes of retrospective meetings are not lost or forgotten but rather integrated into the team’s workflow. Our team has the [Asana integration](/integrations/asana/) turned on, as well, as that is where the Product Team manages their action items.
> #### Quick tip!
>
> #### TeamRetro allows retrospectives to be anonymous or you can leave your team members’ names on the cards. Our team finds that anonymity is actually less productive for our team, but that’s because we have built up a significant amount of internal trust. To start earning your team’s trust, try out the anonymous feature.
## Run better retrospectives and build a healthy team culture
Regular and productive retrospectives play a vital role in nurturing a healthy team culture. By encouraging open and honest communication, retrospectives help foster psychological safety within the team. When difficult topics can be discussed in a healthy manner, trust and collaboration flourish. This positive team culture, supported by retrospectives, leads to improved morale, increased innovation, and a stronger sense of shared ownership over the team’s success.
Want to check out TeamRetro for yourself? They offer a [30-day free trial](/pricing/).
**Thanks to our writer – [Mel Fox](https://www.linkedin.com/in/mel-fox-01587323/)**
Mel Fox is currently the Principal Product Manager at SalesRabbit, where she manages both iOS and Android Mobile applications.
With 5+ years of Product Management experience, Mel has managed both B2B & B2C Mobile apps. She is passionate about creating a customer-obsessed culture while focusing on nurturing her product development team.
---
# Appsfactory turns to online retrospectives for engaging distributed teams
URL: https://www.teamretro.com/case-studies/appsfactory/
## Introducing Appsfactory
[Appsfactory](https://appsfactory.de/en/) is one of Germany’s leading agencies for software development. The agency has over 15 interdisciplinary teams consisting of developers, QA and design staff as well as project managers.
The company provides end-to-end [software development services](https://www.appsfactory.de/en/services/development), including:
- implementing individual software
- creating responsive websites
- implementing individualized back-end solutions for the real-time transmission of machine data
- chatbots implementation
- cloud services and hosting with Azure
- internet of things to control various devices via an app
- machine learning
- design thinking
- VR and AR development and many more
Appsfactory was founded in 2009 by Dr. Alexander Trommen (CEO), Dr. Roman Belter (COO) and Dr. Rolf Kluge (CTO).
Jan Nowak, the VP Projects and Technology, is leading the Project Department as well as the AI Department within Appsfactory. The team consists of more than 200 team members, who are distributed across [four offices](https://appsfactory.de/en/contact/) around Germany – Hamburg, Leipzig, Munchen and Erfurt.
## Face to face vs online retrospectives
With four offices and sites across Germany, and most of the team members working with multiple clients at the same time, Appsfactory has found it challenging to find the right time and place where everyone can meet together for an engaging and regular retrospective.
With COVID-19, this challenge has escalated even more as teams work remotely and face to face gatherings are more restricted.
## Finding the right online retrospective tool
CTO Rolf Kluge decided to look for options to run online retrospectives so that all team members can get involved wherever they are located or working from. They came across [TeamRetro](/) as one of their options for an enterprise-ready online retrospective tool for remote teams.
The Appsfactory team [trialed TeamRetro](https://secure.teamretro.com/login/new?emailAddress=&cc=www-case-studies) before deciding to continue with the platform to run their subsequent online retrospectives.
***“Retrospectives are an important part of our team’s culture and work methodology. We recognize retrospectives as enablers for change for the better, improvements to the way we work and stronger collaboration with each other and our clients.”***
***“We are pursuing the goal of making retrospectives in all teams more efficient by using the TeamRetro tool.”***
## Using TeamRetro for agile retros & team health checks
The Appsfactory team enjoyed the easy to use interface of the TeamRetro platform, with both the [agile retrospective](/retrospectives/) and [team health check](/health-checks/) functionalities being stand out features that helped them run successful and efficient online retrospectives.
***“The feedback from our evaluation was quite impressive. All participants were amazed by the easy to understand design and the significance of time being saved by running the entire process digital from the beginning to the end.”***
***“The agile retrospective feature is amazing, when it comes to fast collaborative retrospectives.”***
***“The team health check is a very insightful tool for our team leads, so that they can monitor the team happiness level closely.”***
## Online retrospectives increase productivity & satisfaction
Jan Nowak commented that the standout benefits of using TeamRetro have been the ability for the AppsFactory teams to reduce the time spent on their online retrospectives vs. conducting a face-to-face format. Of course, with time savings also comes cost savings as team members are able to be part of the online retrospectives wherever, whenever they need to join, eliminating elements such as travel costs and time away from doing client work.
This in turn helps to create more satisfied and engaged teams throughout the organization.
***“We could reduce our average time spent on retrospectives by more than 50%, while increasing the satisfaction level of the team at the same time.”***
***“We are also very happy about the very supportive sales team and the flawless on-boarding procedure.”***
## Try TeamRetro
If you are also looking to solve issues of distributed teams or remote working when it comes to running engaging and effective retrospectives, why not give TeamRetro a go?
We offer a [FREE 30 days trial and demos](https://secure.teamretro.com/login/new?cc=TeamRetroBlog) to help make your online retrospectives a success for you, your teams and the whole organization.
---
# How Attus transformed team engagement with better retrospectives
URL: https://www.teamretro.com/case-studies/attus/
[Attus](https://www.attus.ai/), a Brazil-based legal-tech company, offers a specialized platform designed to streamline operations for public sector legal departments. Powered by artificial intelligence and automation, Attus manages petitions and court rulings, classifies and distributes cases, drafts documents, monitors deadlines, and integrates with government systems like tribunals, Receita Federal, SEI, and debt collection services. By adapting to each institution’s unique workflows, Attus enables legal teams to focus on strategic decision-making rather than repetitive administrative tasks.
As Development Coordinator, [Clávison Zapelini](https://www.linkedin.com/in/clavison-zapelini/) leads the orchestration of multiple development squads. His responsibilities include task prioritization, sprint planning, KPI tracking, and perhaps most importantly, keeping teams engaged and motivated.
## The challenge of creating standardized, high-impact retrospectives across 8 development squads
While many agile ceremonies such as daily standups and reviews were running smoothly, retrospectives were proving inconsistent and less impactful. “Each tech lead used a different tool, some took more time and others less, and I didn’t see the results of this very important ceremony,” Clávison explains. Attempts to formalize retrospectives with other tools hadn’t helped, resulting in low engagement and fragmented outcomes.
### The turning point: trialing TeamRetro
Looking for a better approach, Clávison introduced TeamRetro to one squad during a two-sprint trial. The difference was clear from the start. “We immediately noticed much higher engagement, thanks to the methodology the tool allows,” he recalls.
> *“We immediately noticed much higher engagement, thanks to the methodology the tool allows.”*
Team members echoed the sentiment in surveys, describing them as the best retrospectives they had experienced. Encouraged by the feedback, Clávison expanded the use of TeamRetro to all eight development squads, covering around 40 developers. “The engagement fostered by the various facilitation methods and the available templates were the main reasons for choosing it,” he confirms.
> *“The engagement fostered by the various facilitation methods and the available templates were the main reasons for choosing it.”*
## How TeamRetro supports the Attus process
Attus runs bi-weekly sprints across its development teams, and TeamRetro quickly became a staple for their retrospective ceremonies. Its pre-designed templates made preparation significantly easier for tech leads and helped standardize the experience across squads. What was once a challenge became a strength.
> *“Our sprints are bi-weekly, and we have 8 development squads. We use TeamRetro for the retrospective ceremony. It greatly facilitates the management of this ceremony by providing well-designed templates, which significantly help the tech leads prepare an effective retrospective.”*
## Measurable outcomes: engagement, agreement, and alignment
According to Clávison, the biggest win was team engagement. With everyone contributing meaningfully, retrospectives became an opportunity to surface important insights and turn them into clear, actionable agreements. Using TeamRetro, the team could also monitor progress on those agreements over time, improving accountability and follow-through.
- 
- 
## Features that made a difference
Two features made the biggest impact.
Firstly, the structured templates are tailored to our different retrospective goals.
Secondly, the built-in agreement-tracking capabilities. “It provides peace of mind knowing that the agile methodology is being implemented correctly and consistently across all squads,” Clávison shares.
Leadership feedback was equally positive. “The request to acquire the tool was unanimous after the tests were conducted,” he continues, “The technical leadership noted that both engagement and team relationships improved.”
> *“It provides peace of mind knowing that the agile methodology is being implemented correctly and consistently across all squads.”*
## Advice to fellow Scrum Masters
Reflecting on his experience, Clávison offers a few words of advice to others facilitating retrospectives. “Use open-ended questions to encourage reflection and identify concrete actions for improvement. Value diverse opinions and consistently strive for process and team enhancement.”
What started as a need for consistency evolved into a more engaged, aligned, and empowered development culture. TeamRetro helped turn retrospectives into a high-impact, high-participation ceremony across the organization.
> *“Use open-ended questions to encourage reflection and identify concrete actions for improvement. Value diverse opinions and consistently strive for process and team enhancement.”*
## Make the switch to TeamRetro today
Attus Procuradoria Digital’s experience shows how TeamRetro can revolutionize retrospectives, boost team engagement, and streamline agile processes across multiple squads. Whether you’re looking to unify teams, surface meaningful insights, or implement agile best practices more effectively, TeamRetro provides the tools to make it happen.
[Try TeamRetro today](https://secure.teamretro.com/login/new?cc=www-case-studies) to transform your retrospectives!
---
# How Big Give runs smarter, more impactful retrospectives with TeamRetro
URL: https://www.teamretro.com/case-studies/big-give/
At Big Give, small means mighty. [Big Give](https://www.thebiggive.org.uk/) is the UK’s largest match funding platform, helping thousands of UK-registered charities raise millions of pounds through match-funded campaigns. With just 12 people driving that outsized impact, every process, every conversation, and every lesson learned counts. For a team this size, finding the right online retrospective tool wasn’t a nice-to-have, it was essential to staying sharp. We’re genuinely proud to support Big Give and the work they do, and even prouder that they’ve trusted us to share their story here.
This case study was contributed by [Dominique Standring](https://uk.linkedin.com/in/dominique-standring-91940749), Chief Operating Officer (COO) at Big Give, who has over 12 years of experience designing systems and processes in the charity sector. Dominique shares how TeamRetro helped transform Big Give’s retrospective practice from a fragmented, time-consuming exercise into a reliable engine for continuous improvement.
## The challenge: lost data and no central home for reflections
For a team that prizes learning and constant improvement, running effective retrospectives wasn’t optional; it was baked into the culture. Big Give uses the retrospective format not just for sprint reviews, but for structured reflection after each of their match-funded campaigns.
The problem? Their tooling wasn’t keeping up.
As a charity, keeping costs low is a real constraint, but that couldn’t come at the expense of quality. Big Give needed a solution that was both affordable and genuinely fit for purpose.
## Why Big Give chose TeamRetro
A straightforward Google search led Dominique to TeamRetro. After running a few trial retrospectives, the decision was clear.
The combination of a clean user interface, strong functionality, and Jira integration made TeamRetro stand out from the alternatives. What clinched it was actually using it: the trial experience gave the team enough confidence to commit.
## How Big Give uses TeamRetro
Big Give now runs two distinct retrospective rhythms with TeamRetro: every four weeks for the development team, and after each of their six annual campaigns for the whole organization.
One of Dominique’s top tips for anyone learning how to run retrospectives remotely? Set up the board well in advance.
> ***“The ability to set up a board and invite participants long in advance of a retro is great because it means we can capture reflections directly on the board while they are still fresh.”***
That head start transforms the quality of the conversation. Instead of asking people to recall how they felt three weeks ago, reflections are captured in the moment and ready to explore when the team gathers.
*Image provided by Big Give – reproduced with permission*
## Benefits the team experienced
### A richer, more connected conversation
Working mostly from home, Big Give relies on TeamRetro as their retrospective tool for remote team collaboration. The asynchronous features (commenting and emoji reactions) let team members engage with each other’s reflections before the live session even begins.
> ***“This allows for a much richer conversation when we’re holding discussions about each reflection.”***
### One central home for every retro
One of the most tangible wins has been having all retrospectives in one place. No more lost data, no more hunting through old tools or documents. For a professional, fast-paced team running continuous improvement retrospectives across multiple campaigns and development cycles, that consistency is invaluable.
> ***“Efficiency and central data storage have made our retros more productive and helpful.”***
### A Jira integration that closes the loop
The retrospective tool’s Jira integration was a key reason Big Give chose TeamRetro, and it continues to be one of its most valued features. Actions don’t get lost between tools. They flow straight into the team’s existing workflow, keeping accountability tight without adding friction.
### A format the team actually enjoys
When it comes to the live discussion, the team appreciated TeamRetro’s presentation mode, which keeps the conversation focused and structured. Combined with the ability to comment on individual tickets, it makes the discussion feel purposeful rather than scattered.
> ***“The team liked the interface, the fact that you can comment on tickets and the presentation mode for the discussion.”***
## Outcomes for a team with an outsized impact
For an organization of 12 people, continuous improvement isn’t a nice-to-have. It’s how Big Give punches above its weight.
> ***“TeamRetro is helping us become more efficient while maintaining high quality and a good work-life balance for everyone — not only in the fact that we now have all of our retros in one place but also in the ease of use and integration with other platforms.”***
## Dominique’s tip for running remote retrospectives
Dominique’s advice is simple, practical, and easy to implement:
> ***“Set up the boards in advance so people can add things as they come up.”***
It’s one of the most underrated techniques for anyone figuring out how to run retrospectives remotely. Reflections captured in the moment are more honest, more specific, and more useful than memories reconstructed days later. If you’re not already opening your boards early, start there.
Want more than what a free agile retrospective tool can offer? Try [TeamRetro](https://secure.teamretro.com/login/new?cc=www-case-studies) and see what a difference the right choice makes.
---
# How an agile coach saves time and effort with a better health check and retrospective tool
URL: https://www.teamretro.com/case-studies/blablacar/
What would you do if you started a role as ScrumMaster, Agile Coach or Program leader with 40 teams to lead? How would you manage their happiness, get a sense of what is motivating the team, while keeping admin low? We’re pleased to share Marion’s story here about how she did just that.
[BlaBlaCar](https://blablacar.com/) is a marketplace and carpooling platform that connects drivers and travelers from one city to another around the world. They allow users to share rides, split travel costs and reduce the environmental impact of long distance ride shares.
—
Hey there Agile enthusiasts! Marion here, Senior Agile Coach leading the charge at [BlaBlaCar](https://blablacar.com/).
I’m passionate about exploring the world, meeting diverse people, and adding a sprinkle of animal love to my travels. If you’re curious about my journey, feel free to check out my LinkedIn profile: [www.linkedin.com/in/marionbenard](https://www.linkedin.com/in/marionbenard/).
Now, let’s dive into the thrilling world of Agile coaching and how I, along with my fantastic team, navigated the challenges of Health check processes at BlaBlaCar.
## The challenge: tackling tedious health checks
In 2021, I joined the BlaBlaCar family, and one of my initial tasks was to support 30 software engineer teams through their Health check process. Picture this – a jungle of documents and spreadsheets, loads of manual tasks, and a high risk of errors.
The pain point?
The crucial part of analyzing results and defining actions was getting buried in the chaos. The most important work was being rushed.
## Seeking solutions: embracing tools for efficiency
We chose to continue with a health check model we had been using in spreadsheets before we started using TeamRetro.
Our health check model was a version of the Spotify health model that we adapted to our very own culture.
Eager to bring order to this chaos, I reached out to peers and scoured the internet for solutions. Several tools were tested to find the perfect match that would save time and allow us to focus on what truly mattered.
Enter TeamRetro – a game-changer that streamlined our health check processes. With the ability to create and duplicate templates effortlessly, sending links for participant answers, and managing discussions about improvements, we could now breathe easy. Action follow-ups became a breeze, even if we weren’t entirely efficient with email reminders (not really our internal culture).
## Benefits unveiled: time savings and global insights
Managing health checks for 40 teams in the same timeframe became a reality. The tool’s user-friendly interface allowed us to appreciate a global view of results and trends for all our teams. A single page showcased our strengths and highlighted areas needing our focus.
An interesting discovery during my occasional dives into the activity overview was a strong correlation between the frequency of retrospectives and team health. This revelation led us to provide more support to teams lacking regular retrospectives. We didn’t actually force people to use TeamRetro for tools, but we now have over 90% of our retrospectives used by teams, so it was adopted very quickly!
## Efficiency in action: agile coaches and catalysts in sync
As Agile coaches, we saved precious time, enabling our Agile Catalysts within teams to have a centralized hub for improvement action items. The tool’s simplicity and quick usage, as well as the ‘auto-grouping’ feature was a wow factor for us.
## Format freedom: fun retrospectives for your terms
While some comments surfaced about missing more fun retrospective formats, TeamRetro’s flexibility allowed teams to choose their preferred formats. This avoided the dreaded boring effect while still centralizing actions seamlessly.
## The stats speak: TeamRetro in action
Approximately 90% of our retrospectives now happen within TeamRetro, and a whopping 100% of our health checks are efficiently managed through this tool. It translates to centralized data, easy analysis, and a simplified user experience.
(Provided by BlaBla Car for illustrative purposes only)
## Pro tip: enable participation for dynamic events
Don’t forget to unleash the mode where every participant can create groups or add comments and actions. It injects dynamism into the event and keeps things lively!
In a nutshell, TeamRetro saves us time, provides insights, and ensures our health checks and retrospectives are a breeze.
Happy retrospecting!
Marion 🚀🔍
## What is a team health check?
An Agile [Team Health Check](/health-check-templates/team-health-check/) is like a checkup for a team to see how well they’re working together. It looks at things such as how they talk to each other, collaborate, and follow their Agile practices. The main goal is to help the team get better over time and make sure they’re on the same page with Agile values.
This checkup helps find and solve problems early, improves how the team communicates, and supports the growth of team members. Overall, it boosts team morale, engagement, and ability to adapt. It creates a culture of openness and flexibility, so the team can handle changes in the project and keep a positive and effective work environment.
---
# How Culture Amp uses TeamRetro to unify agile feedback and boost visibility
URL: https://www.teamretro.com/case-studies/culture-amp/
At Culture Amp, building a better world of work starts from within. [Culture Amp](https://www.cultureamp.com/) is a leading employee experience platform that helps companies take action to improve employee engagement, performance, and development. With a strong focus on creating a culture-first company, their mission centers on helping organizations use data to drive performance while fostering care and connection. With teams building products to support employees and managers alike, agile feedback is at the heart of how they work.
This case study was contributed by [Ibrahim Abram](https://www.linkedin.com/in/abrahimabram), Procurement Specialist at Culture Amp. He shared how TeamRetro has helped him as a Team Lead to ensure that teams are “high performing, but happy at the same time.”, by giving him insights as to where to focus as a team improves and stays happy and productive.
## The challenge: disparate retrospectives, limited visibility
With many teams running retrospectives using different tools, there was no unified way to gain insight across departments. Culture Amp needed a solution that could offer a centralized, consistent view of retrospective outcomes and team health.
> “There was no way of going into one place to see how things are going in different teams across specific areas of the company. TeamRetro made this possible for us.”
Using built-in features like [team tagging within TeamRetro](https://help.teamretro.com/article/309-team-tagging), Culture Amp unlocked high-level visibility.
> “We started using tags (for departments, teams etc) which could give us an overarching view of retros and health checks. This is a very helpful tool for directors as they can view their team’s health and actions”.
## Choosing TeamRetro to simplify and scale agile feedback
Drawn to TeamRetro’s intuitive design and insightful features, the team began by running Spotify-style squad health checks. The positive response led to wider adoption by teams, which then expanded into running team retrospectives as well.
> “I love the simplicity of the interface to run retrospectives and health checks. Particularly for health checks, I love the graph that shows the trends.” says Ibrahim.
*Image provided by Culture Amp*
## Supporting agile feedback through health checks, values, and Jira
Culture Amp runs fortnightly retrospectives and health checks that vary from fortnightly to quarterly depending on team needs. With TeamRetro, they can conduct these sessions seamlessly while tracking follow-up actions over time.
A core Culture Amp value is to “Learn faster through feedback”. As Ibrahim shares, “TeamRetro is one of the key tools that enables us to live this value within our engineering organization. It provides us a way to run these effectively and track actions that come out of these sessions.”
*Image provided by Culture Amp*
One of the standout features for the Culture Amp team is TeamRetro’s integration with Jira, helping to make sure actions from retrospectives are captured and remain accountable.
> “TeamRetro’s integration with Jira for action items has been invaluable for driving follow-through. By tracking retro actions in the same place as our project work, they stay visible and prioritized.”
Another aspect that has created more engagement, novelty, and incited new ideas is the range of retrospective templates and health check styles.
As Ibrahim explains, “Out of the box templates to run retros and health checks allowed teams to use different formats that helped them think about their teams from different perspectives.”
## Benefits for teams and leaders: visibility, voice, and well-being
TeamRetro has helped foster a stronger sense of engagement and ownership among Culture Amp’s teams. Regular retrospectives ensure that everyone’s voice is heard, and the visible follow-through on feedback has reinforced a culture of responsiveness and trust.
“The most significant impact is a clear sense of being heard, with visible follow-through on feedback. TeamRetro provides me and the team insights that help us understand where we should focus as a team to improve and be more happy.”
## Advice for Scrum Masters using TeamRetro
Culture Amp’s tip for turning retrospectives into results?
> “Make sure your teams focus on actions explicitly and hold each other accountable if they are not taken in time. Running these sessions is just the first step. But the real improvement is achieved from taking the actions that come out of these sessions.”
Ready to reflect and improve? Run your own [TeamRetro](/) session with this tip in mind now.
---
# Tips on running effective retrospectives for team feedback
URL: https://www.teamretro.com/case-studies/dedalus/
Managing an agile team is much like conducting a symphony – it requires harmony, rhythm, and listening to each other in the group. Effective management of agile teams requires more than just meetings – it’s about fostering an environment where candid feedback thrives.
Damian Obalka, a Software Developer and Scrum Master at Dedalus HealthCare, knows this all too well.
Since 2019, he’s been steering his team through the choppy waters of software development, seeking ways to keep everyone engaged and the feedback flowing. Cue TeamRetro! With this tool in hand, they’ve turned retrospectives into a playground for ideas, criticisms, and everything in between.
Damian highlights some of his tips that he uses in running successful retrospective meetings with TeamRetro.
## Introduction
Hi, I’m Damian Obalka from Dedalus HealthCare and I have been working as a Software Developer and Scrum Master for the company since 2019.
We first started to use TeamRetro early in 2020, so that we could continue our retrospectives even in a remote setup.
Quickly, we started to enjoy the tool and the benefits it brought and still brings to us.
Overall, it has been a terrific addition to our meetings!
## Getting honest feedback from your team
To solve issues that prevent your team from performing at its best, you will need an environment in which your colleagues feel safe to share their honest thoughts, feelings and worries about their daily working experience.
Consequently, a tool for [retrospectives](/retrospectives/) and health checks that is both fun to use and adds features where you can write down your ideas, observations and criticism anonymously is a perfect match to establish such an environment.
You can decide for every new retrospective and [health check](/health-checks/) that you will start in TeamRetro, whether you want it to be anonymous or not.
Doing this occasionally has proven to be very insightful for us. Sometimes your team members might not feel confident enough to voice all their concerns for several reasons. However, this feedback often proves to be the most vital one to improve your workflows and team happiness.
*An example of creating an anonymous agile retrospective meeting*
## Create the ideal retrospective format for your team
Another feature of TeamRetro that we have been enjoying is the customizability of its templates.
While you do have a [large library of standard and community templates](/retrospective-templates/) to choose from, you can also decide to create a new custom template for your specific needs in your next meeting.
This flexibility is greatly appreciated by us. Since you probably don’t want your retrospectives to become predictable and stale, you might want to [try something new](/retrospective-templates/sailboat-retrospective/).
If you are looking for more inspiration to achieve that, then the community (and AI) templates can be a great source to start your search.
If you already have a highly specific topic in mind for your team/participants, TeamRetro will have you covered so that you can create a matching template.
## Add an icebreaker to your meeting
It is also worth mentioning that your options for customization and planning do not stop with your templates. In fact, you can additionally include several options such as a dedicated “welcome” or [“icebreaker-slide”](/icebreakers/) to start your health check/retrospective.
On top of that, you can assign a duration for most sections during your meeting if you want the tool to assist you in keeping track of the elapsed time.
This can be adjusted for each new meeting that you start even if you use the same template!
As you can see, there is an abundance of customization choices for you to choose from depending on your needs.
So, there you have it! Managing an agile team is no walk in the park, but with tools like TeamRetro, the journey becomes a bit smoother. Damian’s story shows us the importance of creating a space where everyone feels heard and valued. TeamRetro’s [customizable templates](/retrospective-templates/) and planning features make it a breeze to tailor each retro to fit your team’s vibe.
## Run the same retro with your team
Damian’s setup takes about ten minutes to reproduce. Pick a format, switch anonymous input on for the topics that need it, add a check-in question, and send the board link before the meeting rather than after. The link is the part that matters: a board with two people on it behaves nothing like a board with one.
**[Start a retro and invite your team](https://secure.teamretro.com/login/new?cc=www-retro-tips)**, or [browse retrospective templates](/retrospective-templates/) to pick a format first.
## Who is Dedalus Health?
Dedalus is a leader in healthcare software, offering ways for seamless care and value across the healthcare ecosystem with innovative solutions.
They are one of the largest Global Health Software Companies globally.
In 2016, Dedalus decided to accelerate its expansion strategy by focusing on the growing demand for innovative and comprehensive solutions to support the digital transformation of the healthcare ecosystem.
Working across the whole continuum of care and offering Open Standards-based solutions, Dedalus helps healthcare organizations to deliver new models of care.
They have over 40 years' experience of delivering healthcare software and services to over 6,700 healthcare organizations.
Their software is used widely across the world, managing each year more than 3 billion diagnostic results, serving 540 million people, 28 million inpatient and 35 million emergency admissions, and in primary care, serving more than 120 million citizens.
---
# Helping nonprofits thrive through agile grant writing
URL: https://www.teamretro.com/case-studies/dh-leonard-consulting/
[Beth Archer](https://www.linkedin.com/in/elizabeth-archer-b5368791) wears two hats at [DH Leonard Consulting & Grant Writing Services, LLC](https://www.linkedin.com/company/dh-leonard-consulting-&-grant-writing-services-llc/) – as both a Registered Scrum Master (RSM) and a Grant Professional Certified (GPC) strategist. DH Leonard Consulting helps nonprofit organizations competitively apply for, receive, and manage grant funding so they can better serve their communities and drive meaningful impact. Using an Agile approach, the firm breaks down the grant writing process into iterative steps that promote faster delivery, open communication, and continuous improvement.
Beth’s passion lies in helping her remote team leverage the Scrum framework to streamline internal workflows and enhance outcomes for their clients.
> *“**I love how using the Scrum framework has made it possible for us to serve our clients more efficiently and effectively,**”* she says.
## The challenge: managing retrospectives in a fully remote team
As a fully remote organization, DH Leonard Consulting needed tools that supported distributed collaboration without adding friction. Their previous method relied on a virtual whiteboard for retrospectives, but setting it up required outside help.
> ***“A challenge for our team is that we are all remote, so we need tools that help, not hinder, our virtual work environment. Additionally, as someone who wears both the Scrum Master hat and the team member hat, it is challenging to balance my time and ensure that I’m managing each of my roles effectively. We had a system that was working well for our team’s Retrospectives using a virtual whiteboard tool, but due to capacity constraints, we were actually utilizing a colleague outside of our team to set them up for us each week.”***
## Choosing TeamRetro to support agile ceremonies
When the team discovered TeamRetro, it quickly became the perfect solution.
> ***“It is the exact kind of tool we need as a remote team. It allows us to do some of the work asynchronously, while also supporting live discussions. Because it is so easy to set up and run each Sprint, we have also been able to keep the work within our team and not have to rely on our other colleagues.”***
With its ease of use and autonomy, TeamRetro allowed the team to fully own their agile ceremonies, with no more relying on outside support.
## Weekly retrospectives with structure, flexibility, and fun
DH Leonard Consulting runs weekly retrospectives at the end of each sprint. Using TeamRetro templates as a base, the team customizes them with questions tailored to their process, including metrics on team happiness and stress.
> ***“We do weekly Retrospectives at the end of each Sprint. I love the templates, we use them each week; however, we are also able to edit them and add our own questions (e.g., we measure team happiness and team stress each Sprint). We also use the icebreakers, which have helped to get people warmed up and engaged.”***
## More engagement, less setup
Beth notes that retrospectives now run more smoothly, with less time spent on logistics and more time focused on meaningful reflection and outcomes.
> ***“We have spent less time setting up our virtual Retrospectives and have been able to keep the work within our team, instead of asking a colleague outside of our team for support. We have regularly started Retrospectives with an icebreaker (something we previously did intermittently), which has improved the tone of and engagement during Retrospectives.”***
This structured approach has enabled better follow-through and greater accountability on team actions.
## Easy transition and positive feedback
> ***“The Retrospectives, and particularly the templates. This has made our Retro setup so easy!”***
The feedback from the team has been overwhelmingly positive. They appreciate the streamlined setup, consistent format, and the ability to centralize everything in one platform. Icebreakers and customizable templates have added an extra layer of engagement.
> ***“It is easy to use and was straightforward to transition from our previous system to TeamRetro. The team also appreciates the templates and icebreakers, as well as the fact that everything is in one place.”***
## A tool that empowers remote teams
For Beth and her team, TeamRetro has done more than just simplify retrospectives. It’s made their agile process more impactful.
> ***“TeamRetro has been a great addition to our team. It has made things easier and faster!”***
## Advice for Scrum Masters and agile teams
Beth’s top tip for teams starting out with TeamRetro?
> ***“Know that there is so much room for customization! You can truly make it into exactly what you need/want.”***
TeamRetro continues to support agile practices at DH Leonard Consulting, helping them deliver value to clients while building a stronger, more engaged remote team.
[Try TeamRetro today](https://secure.teamretro.com/login/new?cc=www-case-studies) and bring structure, flexibility, and energy to your retrospectives, no matter where your team is.
---
# Eurowings Digital empowers teams with remote retrospectives
URL: https://www.teamretro.com/case-studies/eurowings-digital/
## Eurowings turn digital
[Eurowings](https://www.eurowings.com/en.html) is part of the [Lufthansa Group](https://www.lufthansa.com/), one of the leading airlines in the European market. In 2018, the airline established a subsidiary called [Eurowings Digital](https://eurowings-digital.de/) to support the transformation of the Eurowings brand from an airline to a holistic digital travel companion for the entire travel chain.
Since its inception, Eurowings Digital has been tackling some crucial challenges within the travel industry, including:
- Customer needs are continuously changing and becoming more and more digital. Eurowings Digital has a strong focus on customer experience to enable the group to offer quick solutions for any change in this area.
- The airline and travel market are complex and changing significantly. By having a focus on new trends through Eurowings Digital, Eurowings wants to take advantage of its leading position in the European airline market to become a strong player in this new market.
- To create the best digital services, Eurowings needs the best tech talents. Eurowings Digital wants to offer an environment that attracts these talents.
Rebecca Graf is the Scrum Master at Eurowings Digital and her work focuses on being a key driver and problem solver in Eurowings agile environment, working within a team and supporting the entire organization.
***”In my role I help our Squad teams to live the agile values and also support them to remove blockers or to solve other dependencies, allowing the Squad teams to work at 100% capacity without issues.”***
Image credit: Rebecca Graf
## Remote retrospective challenge for the scrum team
Image credit: Eurowings Digital
Eurowings Digital follows a scrum methodology for its team’s sprints. While the team has worked in a partially remote environment before, they have always conducted their sprint change face to face, when every team member is in the office.
When COVID-19 hit, the Eurowings team moved to complete remote work and were not able to continue the normal face to face component of their scrum methodology.
***“Suddenly I could not create flipcharts for retrospectives, distribute Post-It and have dots voting on them anymore,”** commented Rebecca.*
***“I had no previous experience in remote retrospective work and needed to find a way to handle the retrospectives in a structured and efficient way, particularly at this difficult time.”***
***“The important criteria for me was for the remote retrospectives to remain diverse and the team should have fun still with it.”***
## An online solution to run remote retrospectives
Remote retros with TeamRetro
To support her team and the Eurowings Digital organization to continue their retrospectives, Rebecca went in search of a remote retrospective solution.
***“I asked around, researched and tried out different options for remote retrospectives. These ranged from simple* [*Google Doc*](https://www.google.com.au/docs/about/) *to* [*Confluence Templates*](https://www.atlassian.com/software/confluence) *and various tools, some explicitly made for this purpose like* [*TeamRetro*](/)*****, others a bit more universally applicable,”** explained Rebecca.*
Rebecca signed up for the [30 days free trials of TeamRetro](https://secure.teamretro.com/login/new/?cc=www-case-studies) to gauge its suitability for her team and organization. The trial helped Rebecca decide to use TeamRetro for Eurowings Digital.
***“In this trial phase, TeamRetro convinced me because it is easy and intuitive to use, offers a* [*HealthCheck*](/health-checks/) *in addition to the functionality for the* [*retrospective*](/retrospectives/) *itself and also offers other pleasant features like tool integrations for* [*Slack*](https://slack.com/intl/en-au/) *as well as a nice documentation.”***
## Benefits of going remote with your retrospectives
Rebecca explains that with TeamRetro, her team and organization are now supported to conduct their remote retrospectives effectively.
Every remote retrospective now starts with a follow up on the action items which can be done really easy within the team dashboard in TeamRetro. This allows for the team to quickly discuss each action item and check it off if it’s done.
Then the team would move on to the [HealthCheck](/health-checks/) and they use the Custom Health Check here. The set of questions and the choices are the same for all teams, to allow a comparison of the results.
***“As the HealthCheck is meant to get a quick overview it really suits our need as it can be filled out in just seconds.”***
Team health check with TeamRetro
Rebecca also explains that the various templates in TeamRetro help to create a good structure to the remote retrospectives, keeping teams focused and the retros highly productive.
TeamRetro ready to use templates
***“We use Retrospectives in various versions. Depending on what is required, we use the ready-made templates or create our own retrospective. We like the given process of Brainstorm > Group > Vote > Discuss > Review > Share very much. It’s easy to follow and gives the whole meeting a good structure.”***
***“The collection of topics can be done really easily, the grouping works quite well, the voting helps to focus on the most important topics and the timer ensures that you don’t lose track of time.”***
## Remote retrospective gets the tick of approval!
By using TeamRetro, Rebecca was able to support her squad team to continue to run one of the most important parts of the scrum methodology – retrospectives – remotely.
Through the experience, Rebecca and her team have also provided many valuable pieces of feedback to enhance the TeamRetro experience so the platform continues to help teams around the world to run remote retrospectives and deliver every sprint effectively and productively, in the face of a global pandemic.
***“Teamretro helped us massively to run efficient and well-structured remote retrospectives. Furthermore, I can save myself the trouble of documenting the results afterwards, as everything is automatically available in TeamRetro.”***
TeamRetro Health Check
## Try TeamRetro
Are you and your team or organization looking to conduct remote retrospectives and team health checks? Whether you have a partially remote, fully remote or hybrid work environment, TeamRetro can help to make sure that your important retros run efficiently and in an engaging manner.
[Try it FREE today for 30 days!](https://secure.teamretro.com/login/new?cc=TeamRetroBlog)
---
# Go.Compare builds a culture of continuous improvement with TeamRetro
URL: https://www.teamretro.com/case-studies/go-compare/
[Go.Compare](https://www.gocompare.com/) is one of the UK’s most recognizable and trusted comparison websites, helping millions of consumers find better deals on insurance, utilities, broadband, and financial services. Known for its iconic TV adverts and focus on simplifying complex decisions, Go.Compare is part of Future PLC, a global multi-platform media company.
We are honored to introduce [Dan Evans](https://www.linkedin.com/in/danevans/), VP of Technology who leads the PCW-Tech organization, overseeing critical technology functions that include customer journeys, partner integration, renewals, and strategic initiatives. Passionate about building high-performing teams and delivering resilient, scalable technology, Dan focuses on aligning engineering outcomes with business value while fostering a culture of continuous improvement.
## The challenge: aligning retrospectives across growing teams
As Go.Compare’s engineering teams scaled, so did the complexity of managing agile ceremonies across squads. In a growing, innovative organization it was still important to provide direction and leadership when leading agile processes around continuous improvement.
Dan shares, **“*Our teams were growing in size and complexity, with multiple squads working across interconnected journeys. Retrospectives were inconsistent across teams, with variable depth of insight and a lack of standardization. We needed a structured, engaging way to capture feedback, drive actionable improvements, and ensure alignment across squads.*”**
## Choosing TeamRetro to support scalable agile practices
Faced with the need for a more unified and effective approach, Dan and his team evaluated several tools before selecting TeamRetro.
**“*We evaluated a range of tools, but TeamRetro stood out for its balance of structure, flexibility, and ease of use. It enabled distributed teams to collaborate effectively, supported multiple templates and health checks, and gave us a single consistent platform to embed a culture of continuous improvement.*”**
## The process: regular retros and monthly health checks
Go.Compare uses TeamRetro to run agile ceremonies that are both scalable and actionable. Empowering teams to be disciplined in their practices while making it straightforward, easy and interactive meant that everyone could participate in the meetings.
***“We run regular retrospectives and monthly health checks at both the squad and organizational level”***, Dan says.
> *“TeamRetro provides templates we can adapt, anonymous input to encourage candour, and reporting to track themes over time. It supports a cycle of reflection, prioritization, and follow-up, helping us close the loop on improvements.”*
## The outcomes: consistency, visibility, and psychological safety
By adopting TeamRetro across squads, Go.Compare achieved several measurable improvements. Dan shares some of the key benefits he has seen with his team as well as individual people in the organization.
- *Improved consistency and quality of retrospectives across squads.*
- *Clearer visibility of recurring themes (e.g., tooling, deployment, cross-squad alignment).*
- *Increased psychological safety, with more honest feedback from team members.*
- *Actionable insights that feed into our engineering OKRs and performance measures.*
The transition to TeamRetro didn’t just benefit leadership — it positively impacted the entire team experience. This can only lend itself to boosted productivity and improved return on time invested in meetings.
> *“Easier participation, especially for quieter voices in the team. A more engaging format compared to traditional retrospective boards. Confidence that feedback would be seen, tracked, and acted upon.”*
## Team feedback and broader organizational impact
The reception from both teams and stakeholders has been overwhelmingly positive. “*Teams have highlighted that retrospectives feel more valuable, structured, and productive. I appreciate the ability to surface organizational themes and to see how actions are being followed through.*”
And what does TeamRetro mean to Go.Compare as a whole? – Dan summarizes
*“For me, it has been a key enabler in building a culture of continuous improvement. For teams, it means their voices are heard and acted upon. It provides assurance that teams are reflecting, adapting, and continuously improving against delivery and quality goals.”*
## Advice to agile leaders and Scrum Masters
Dan shares three hot tips to help transform culture and build team spirit.
1. Make retrospectives part of your cultural rhythm, not just a process.
2. Use health checks to get ahead of issues.
3. Most importantly, ensure that insights lead to visible action. Teams need to see that their feedback creates change. We integrated Retro actions into ADO so they become items on the backlog that the team can address.
We’d like to thank Dan for his contributions here and for sharing his experiences from his team and leadership.
## Empower your teams with TeamRetro
Go.Compare’s experience shows how TeamRetro can create consistency, elevate team engagement, and ensure agile ceremonies lead to real outcomes. Whether you’re scaling squads or strengthening feedback loops, TeamRetro helps turn reflection into results.
[Try TeamRetro today](https://secure.teamretro.com/login/new/?cc=TeamRetroBlog) and bring continuous improvement to life across your organization.
---
# Herman Miller's remote agile team achieves new goals with TeamRetro
URL: https://www.teamretro.com/case-studies/herman-miller/
### Herman Miller adopts agile practices
[Herman Miller](https://www.hermanmiller.com/en_au/) is a well-known producer of high-quality office furniture and equipment and home furnishings.
They are a global organization, with a head office in Zeeland, Michigan, USA and resources across the world – including a technology center based in Bangalore, India and regional offices in Europe, Asia and South America.
Herman Miller has been slowly adopting Agile practices for developing software and technical teams in general for several years, to support the design, creation and production of their award-winning products.
Tim Stayman is the Java Services Manager and Agile Coach for Herman Miller.
> ***“I am a Work Team Leader for 6 Java developers who all work on Agile Product Teams. I am a SCRUM Master for two Product Teams. I am also one of 4 agile coaches at Herman Miller.”***
### Remote retrospective for an agile team
Herman Miller Innovation Lab
Tim explained that Herman Miller’s agile adoption was “grassroots” in nature, which resulted in a less-than-coordinated approach for conducting effective retrospectives.
> ***“Teams were going about it in different ways and using different tools, including various retrospective tools.”***
> ***“We tried several ‘free’ tools but they all fell short in terms of supporting remote teams and delivering features and functions required to run a valuable retrospective.”***
> ***“As a result, some teams were either conducting poor retrospectives or not having retrospectives at all.”***
In addition, the COVID19 global pandemic resulted in all of Herman Miller’s teams working remotely. This added to the issue of conducting poor or no retrospectives that already existed.
### A solution to run remote retrospectives
Remote retros with TeamRetro
Tim and his team were using a free version of an Agile Retrospective tool before requesting Herman Miller’s Agile Guild – the group that provides guidance on the recommended use of tools – to create a team to evaluate available, best option retrospective tools.
> [***“TeamRetro***](/) ***was a highly recommended tool that a colleague has used at a different job. The features and capabilities of TeamRetro seemed to also meet our set goals to choose a tool.”***
Tim explained that his team’s guiding goals for choosing the right Agile Retrospective tool included:
1. Simple to use;
2. Reasonably priced or free;
3. Supports remote workers;
4. Deliver results to drive improvement.
### Effective retrospectives with TeamRetro
Tim indicated that TeamRetro is primarily used to [run retrospectives](/retrospectives/) across Herman Miller’s 12 or so product teams. Having an easy-to-use tool that is especially designed for Agile Retrospectives has provided many positive results that Tim and the product teams noticed.
The [ready-to-use and customizable templates](/retrospectives/) also contribute greatly to making sure Agile Retrospectives can happen quickly and in a focused manner.
> ***“The most noticeable effect is that all of our product teams are conducting effective retrospectives and sticking with it.”***
> ***“In fact, most teams look forward to attending the retrospective.”***
> ***“Our Product Teams particularly enjoy the use of Agile Retrospectives templates and custom templates for problem solving and ideas generation.”***
> ***“We also rate highly the ability to record feedback in real time, have actions in one spot that can be tracked on week to week and downloaded at a click of a button.”***
TeamRetro Agile Retrospectives Templates
TeamRetro’s continued integration with popular task management and communications tools has also been a favorite among all users.
> ***“Continued integration into Teams is important as we are a Teams environment.”***
### Higher engagement and increase in velocity with TeamRetro
Tim indicated that by using TeamRetro there have been noticeable improvements in engagement and productivity.
> ***“Having TeamRetro manage our retrospectives has been vital in keeping our Product Teams focused and engaged.”***
> ***“On one product team that I am the SCRUM Master for, we have implemented over 100 improvements in the past year, resulting in higher engagement and a 10% increase in velocity.”***
Herman Miller teams have now used TeamRetro for over a year and Tim indicated that it has really helped support the Agile way of working at the organization.
### Try TeamRetro for remote retrospective with your agile team!
Are you and your team or organization looking to conduct effective remote Agile retrospectives and team health checks? Whether you have a partially remote, fully remote or hybrid work environment, TeamRetro can help to make sure that your important retros run efficiently and in an engaging manner.
[Try it FREE today for 30 days!](https://secure.teamretro.com/login/new/?cc=www-case-studies)
---
# Hogar Sí: ending homelessness with agile methodologies
URL: https://www.teamretro.com/case-studies/hogar-si/
As part of their agile adoption and software development process, Hogar SI needed to run effective retrospectives across all of their teams. To do this, they looked to TeamRetro.
Scrum Master Fernando Baghe shares how they used TeamRetro to create actions that lead towards positive change and continuous improvement.
## Who we are
[Hogar SI](https://hogarsi.org/) is a non-profit organization with a mission to end homelessness by providing affordable housing for those in need.
Our team has been working tirelessly to make this goal a reality. However, coordinating and executing effective retrospective meetings has been a challenge for our decentralized team. That’s why we decided to implement TeamRetro as part of our agile adoption process.
> ***With TeamRetro, our team has been able to improve communication and collaboration, leading to more effective adoption of agile methodologies and a greater impact on our mission to end homelessness.***
## Our TeamRetro experience
Before TeamRetro, each team member was using different tools and methods to conduct retrospectives. This resulted in inconsistent and less effective reviews.
With TeamRetro, we now have a consistent and easy-to-use platform for conducting retrospectives. The ready-to-use and customizable templates have also made it easier for our team to focus on the most important issues and come up with actionable solutions.
> ***One of the most significant benefits of using TeamRetro is the ability to record feedback in real-time and track progress on a week-to-week basis.***
This has allowed our team leads to closely monitor the team’s progress and satisfaction levels, making it easier to identify and address any issues that may arise.
TeamRetro’s integration with popular task management and communication tools has also been a hit with our team. This has allowed us to seamlessly integrate retrospectives into our daily workflow, saving us time and increasing productivity.
## Why we recommend TeamRetro
In summary, TeamRetro has been instrumental in our agile adoption process and has helped us achieve our mission of ending homelessness.
> ***Our team is more engaged and productive, and we look forward to conducting retrospectives each week.***
We highly recommend TeamRetro for any organization looking to improve their agile adoption process.
Thanks to our writer –
[Fernando Baghe](https://es.linkedin.com/in/fernandobaghe/en) – Agile coach and certified scrum trainer.
---
# Agile retrospectives and team health: expert insights
URL: https://www.teamretro.com/case-studies/industrial-logic/
Conversations around agile can often be centered on the Scrum framework, with its scheduled meetings and defined roles. However, as agile philosophy continues to mature, is this spotlight shifting? In this interview, Full-Stack Agile Coach [Jon Fazzaro](https://www.industriallogic.com/people/fazzaro/) addresses that question and more.
Things kick off with a bang as Jon challenges relying solely on Scrum as a launchpad for agility. Instead, he advocates for a more organically agile approach.
As the discussion unfolds, the retrospective takes center stage, and the role of the coach is examined.
Last of all, insights into agile team health are shared along with invaluable advice when it comes to supporting your team.
Let’s dive in!
## An evolving perspective on scrum
*I’ve read your piece on Medium* [*The Retrospective is the Heartbeat of the Project*](https://medium.com/yesterdays-weather/the-retrospective-is-the-heartbeat-of-the-project-45a8aa2027bd)*. Do you still think that’s the case or would you say that there’s something that’s more important that should be considered now?*
Since writing that piece, I’ve definitely moved past thinking Scrum is the best way to start being agile if you’re not already.
I’m going to steal a metaphor that the head of our company, [Joshua Kerievsky,](https://www.industriallogic.com/people/joshua/) shared a while ago in a talk that he did.
When you’re learning to ride a bike, you have training wheels. At least, that’s the way most kids do it; they have little training wheels bolted onto the side of their bike. What they learn to do first is to pedal. So, when you take the training wheels off, the first thing they do is fall down. They don’t realize that they have to pedal forward. They haven’t learned to balance.
There’s an alternative way of teaching kids to ride a bike. It’s called a balance bike. It’s very simple. It doesn’t even have pedals. It’s bike-shaped, with two wheels and a seat. And you just tell them to walk; walk their way along and see if they can scoot and maintain their balance.
That’s the better way to teach a kid to ride a bike. Balancing is the thing that’s hard, not pedaling.
In the same way, Scrum is the most common way for teams to say ‘OK, we need to get agile, let’s go ahead and adopt Scrum’. Then they go ahead and bolt their Scrum training wheels on. They say ‘these are the meetings, these are the roles, and this is what we do’.
Unfortunately, in practice, Scrum doesn’t do enough.
Don’t get me wrong. On paper the guide is very good. It’s got a lot of very good ideas. But Scrum doesn’t tend to do enough to teach a team what it really needs to be agile.
## The role of retrospectives in agile teams
*With your position on Scrum and its relationship to agile having evolved, what about the retrospective?*
I still believe it’s important to stop working and talk about how you’re doing the work. I think that’s the most important thing. I like the idea of having more frequent retrospectives. To turn the heartbeat up.
The team doesn’t have to do an intense, two-hour retrospective every day. Instead, maybe if you took a half an hour each day at a certain point that remains, a heartbeat. You might discover things sooner that are important. Rather than waiting two weeks to fix ‘the thing’ and amassing a backlog of ‘other things’ to cover, the team can address it almost immediately.
Frankly, that’s more agile. Rather than batching it up and waiting.
*What could that regular, possibly faster heartbeat mean to the management team of an organization?*
Ostensibly that they care about the fact that the team is healthy, and performs at a predictable rate. As the people minding the business that teams serves, they want to be able to rely on that team to produce what they need in order to meet their business goals.
If a team is not regularly meeting and tuning itself in, that team might become unpredictable. They might have had a stellar week because everybody put in extra hours, but they are burned out. Then they just create bugs and nonsense for the three weeks following.
So that’s what I would care about in a management position. I think that there is a really great deal of value in knowing that.
## The agile coach and effective retrospectives
*What indicators, not necessarily data, could a Scrum Master be looking for given not all of them have a development background?*
Well, in the retrospective, a Scrum Master is fundamentally their coach.
If we apply a sports metaphor, usually a coach is somebody who is an expert in the game. Maybe a former player. To be useful, they have to take the stance that they can’t help the players by playing themselves.
The person running the retrospective has to step outside the content of the conversation. They have to look more at the contour of the conversation.
So, it could actually be of benefit if they don’t understand certain things being discussed because those things could be a distraction. It could take their focus away from watching how the team is interacting. Let’s say somebody keeps getting talked over. That’s where the coach could step in. They can help to try and adjust the conversation.
While the content of the conversation belongs to the people having it, sometimes the mechanics of it go wrong. You need somebody there who’s only watching how it’s happening. They can be nudged into ‘playing’ better with each other.
*They are helping to make sure that ‘play’ is optimized?*
Yes.
*If they want to take things up a notch, what could the coach be doing?*
Well, the phrase that comes to mind is ‘holding space’ from Open Space Technology.
Holding Space is its own job. That’s what a facilitator of retrospective would be doing whether they are a coach or a Scrum Master, whatever their title. That role of facilitating the conversation. You’re not in the content, but you’re creating the container, and watching the contour of the conversation.
That entails communicating how you’re going to have the conversation. You’ve arranged for the prompts for that conversation. You’ve set the boundaries. It takes a lot of design work.
In my experience, when a retrospective doesn’t go well, usually the thing that’s lacking is that the person facilitating it hasn’t taken the time to design it. They are just kind of winging it.
That’s not useful.
What’s useful is for them to establish a time box, say 10 minutes. When that time box is up, they’re not fluffy about it, they’re firm. ‘OK, we’re done talking about that, it’s time to make a decision and move on’.
*So those parameters are really quite important to make it an effective space. What have you observed go wrong that a simple fix could have addressed?*
In terms of retrospectives, the common mistake is to say, ‘let’s have a wide-open conversation’. Then the group goes on to talk about whatever is on their mind. While that’s an important thing to do in some spaces, you really want to get punctuated value out of the time that’s put aside for a retrospective.
Remember, we’re not working on the work. We’re working on the team. We’re working on how we work.
The thing that often gets skipped, on the way to discussing how we felt about what happened, is establishing *what actually happened*. Making sure that everybody in the room has a similar mental model of what we’re talking about.
So, an alignment. A calibration of ‘do we agree on the facts?’
Often, for me, a handy device to help do this is to take a few minutes and have the team establish a timeline of what happened. Draw a horizontal line on a board and start putting down notes on it. ‘Early in the sprint this happened, then there was this’.
This works against any recency bias. They’re not just going to think about the things that have happened in the last day or two, or hour or two. This is important especially if it’s a two-week iteration, or one month or longer. There are a lot of things you won’t remember.
Giving them time to actively remember is really helpful.
There might be parts of the team that didn’t feel the same or didn’t remember things as strongly. They might have heard about something, but they weren’t involved. So it paints a picture for them that’s a little more holistic and shared.
From that point, once the team agrees on what happened, then they can talk about what that means and how they feel about it and what could be better.
*Amnesia can be addressed first.*
Or just completely different points of view. Completely different mental models of what happened can be addressed before the retrospective starts.
So, imagine the alternative. Going right into talking about, ‘was that good or was that bad?’ You have people with their own versions of what happened in their head. Those stories are all completely different. It means the words that they use to describe things are going to be completely inappropriate from the other person’s point of view. There’s going to be no connection. No insight can come from that.
## Agile teams as living systems: exploring the metaphor
*Now to tap even further into your mastery of the metaphor. If the retrospective is the heartbeat, what’s the team?*
It’s a system. A body of organs working together. Doing different jobs. It’s trying to keep going, to grow, to learn. It’s trying to be healthy.
*That does segue, really nicely, into the topic of team health. Have you ever encountered a team that is dysfunctional but effective? There are high functioning people who have real issues.*
Sure, they are getting through their day. That’s the phrase though, ‘getting through it’. If you get through something, you know there’s probably something that’s difficult that healthier people don’t find difficult. There are missed opportunities.
This takes us back to predictability. I would think that one of the most devastating things about having a serious health condition is how unpredictable that would make my life. I couldn’t, really reliably, make any plans because I don’t know if I’m going to suddenly fall over. I might need an ambulance and go to the hospital. There goes my week.
I think that’s the thing about health and the health metaphor. You are putting in this extra effort to improve things so that the world becomes easier.
In my own, personal experience, I’m kind of terrible when it comes to exercising and maintaining a routine. But there have been periods in my life where I’ve been good at it for a few months. I would do something kind of minimal. Say, 10 push ups every day. And I’ve been good at that for a long stretch.
When I’ve been good at that, my keenest observation about how I feel is that not that I feel bigger or stronger. But I feel like the world got easier. Difficulty is turned down.
That smoothness. That ease of movement when you’re healthy. That’s why I think that’s what you’re going for with a team when you tune it up properly. The effect that has on the people that the team is doing work for is that team is predictable, like a clock, it’s reliable, you know?
There’s an idea from Tim Ferriss’ The 4-Hour Body of minimum effective dose. You don’t have to be in Olympic shape, it’s the minimum to have a positive effect. What’s the minimum that we can do to have an effect, a positive effect on the team. Which is enough in many cases.
## Symptoms of a healthy agile team
*What could someone facilitating a retrospective look for to gauge the health of their team?*
Well, they should definitely see decisions being made. The scenery changes on the healthy team. They are tweaking. They are adjusting. They are experimenting freely.
Responsibility doesn’t lie at an individual level. It lies with everybody. There’s sort of this blameless atmosphere of, ‘hey, that didn’t go so well’. They might identify that somebody did something and it caused a problem, but you wouldn’t say ‘when you did that, that really screwed everything up, and what are you going to do to fix that? It’s more, ‘what can we do better to react to that?’ You know the responsibility belongs to the whole team, even when it’s one person’s actions that might have caused something to go wrong.
In general, there’s a notion of blamelessness.
They handle conflict well.
A go-to symptom of a good team is that they are not quiet — they complain. Because they have a bedrock-safe atmosphere in which they feel able to bring up the things that bother them.
## A final pearl of agile wisdom
*With 30 seconds to go and no forewarning, what’s your ultimate pearl of wisdom for any person embarking on an agile endeavor?*
Stop to retrospect before you need to.
A lot of teams will only meet about the thing once it becomes a problem, and well, it’s easy to skip the retrospective when it feels like everything is fine. If you have done that, you haven’t inspected closely and discovered the thing that might cause us a problem. Weeks from now or days from now.
## Thank you!
A huge thank you is extended to [Jon Fazzaro](https://www.industriallogic.com/people/fazzaro/) for participating in this interview.
Jon is a Full-Stack Agile Coach, and has been in software development for over twenty years. He is a hands-on advocate for modern agile practices like ensemble programming, test-driven development, and daily collaboration with stakeholders. He is also a strong proponent of Lean Product Management and Systems Thinking.
Jon has been a regular speaker at software conferences since 2015. You can head to [“Oh! The Humanity.”](https://youtu.be/qYV_eWNl8vQ?feature=shared) a close-up of his current professional thinking.
---
# Making team health visible to create transparency in agile teams
URL: https://www.teamretro.com/case-studies/infi/
A happy and healthy agile team can impact their ability to deliver high-quality software and meet customer needs. The question of course is how do you know if your team is happy? How do you keep on top of this and how can you track team happiness over time?
An agile team health check can be a simple tool that lets you pick the key dimensions (or criteria) of health that matters most to the organization. Spotify, Atlassian, Google are just some of the companies that share their health check models and help to popularize this concept.
[Infi](https://infi.nl/), a Dutch software company, used TeamRetro to shape their own health check model that used a range of dimensions specific to their values, culture, team goals and organizational requirements.
Based on this set of criteria, this crew of developers initially ran verbal meetings in which each person responded to their model each week.
However, this can be hard to track efficiently so they went to the next level. Capturing this information with an agile team health check tool meant that they could capture that data quickly. They then used TeamRetro’s API to build their own API that displayed their health check data on their office TV screens. This meant that the data was always visible and highlighted the organization’s commitment to supporting happy, productive teams.
Here, Software Developer Martijn Groeneveldt, shares their story… and their link to Github so you can try out the dashboard for yourself.
## Why does your software development team use health checks?
Our team runs health checks because we are a company that truly believes in caring for our employees.
We believe that in the software development and consultancy business, human factors can make the difference between ‘okay’ and ‘awesome’. That’s why we run weekly check-ins. They are a good way to check whether there are things we can do, or do differently, so individuals are able to do their jobs to the best of their ability.
## What health check dimensions did you use to measure team happiness?
We chose to continue with a model we were using for verbal check-ins before we started using TeamRetro.
Our health check model consists of the following six factors – (translated from Dutch)
### Stress
Do you experience stress or busyness in your life?
### Fun
Do you have fun in what you do?
### Impact
Do you have the feeling that you’re making an impact for the client or Infi?
### Colleagues
How does the collaboration with colleagues and clients go?
### Technology
Is the technology you are working with (still) fun and interesting?
### Process
Are the processes that should make everything run smooth working as intended, or do they get in your way?
## How does TeamRetro support your health checks?
By using the TeamRetro health checks to have weekly team meetings, team members consistently respond to the same prompts. This way they don’t accidentally forget or leave things out.
Using TeamRetro also means team members can write down their thoughts ahead of the weekly team meeting. We also can produce a nice statistics graph of all health checks done the previous periods.
We then display this on our screens so that our team can see it as needed.
*(Example as shown – data is for illustrative purposes only and is not reflective of Infi)*
- 
- 
## What are the benefits of making your agile metrics visible?
Having the data visible means you also have the ability to make better decisions, reduce decision latency and ensure that any issues are addressed as soon as possible. This suggests that transparency is [crucial to agile](https://www.linkedin.com/pulse/what-transparency-why-crucial-agile-khojiforagile/).
While most teams can focus on the quantitative aspect of burn down charts, velocity points and error rates, having your team’s health check clear and upfront is a great way to put people in the picture too.
With special thanks to [Martijn Groeneveldt](https://github.com/dutchmartin), software developer at Infi, you can access their code for the dashboard here: [TeamRetro Health Dashboard](https://github.com/dutchmartin/TeamRetroHealthDashboard).
Want to run your own health check? Here are a [few models ready to go](/health-check-templates/), or you can create your own.
---
# Mitrais Software Development — supporting sprint retrospectives with TeamRetro
URL: https://www.teamretro.com/case-studies/mitrais/
Having everyone in a team be able to think about ways to improve and contribute is essential for any successful agile project. This is just as true of the humble retrospective. It’s at this point in time that having a team being able to reflect on the last sprint, feel like they are being heard, and contribute to delivering value to the next sprint can help deliver value to the project.
We share the experience of software development services company Mitrais and how they provide both value to clients and to their team when they tried out TeamRetro.
Rommy Rempas, the Competency Development Manager at Mitrais, emphasizes the importance of open collaboration in his team’s sprint retrospectives. He notes that “it is the time for their voice to be heard,” and that using a tool like TeamRetro has helped his team feel more comfortable sharing their thoughts and ideas. By fostering an environment of open collaboration, Rommy’s team has been able to identify issues and improve their processes more effectively.
The Competency Development Group have been implementing Scrum at Mitrais since 2014 and took about a year before teams were familiar enough with the transition in order to implement projects without waiting for requirements to be baselined.
With this in mind, Rommy shared that success meant that ”the team is able to improve their skills while delivering the product and meeting the expectations of the stakeholder”. He went on to say that the teams have found more success through Scrum. The short iteration to release gives the team more opportunity to grow and learn based on periodic feedback, improving productivity and the team being able to better adapt to dynamic requirements.
## Adding value with sprint retrospectives
The role of the sprint retrospective is important to Rommy’s team. The event gives his team the chance to reflect, learn from both their failures and successes, and then shape improvements. Rommy has found the action items generated through the meeting particularly useful.
Rommy’s tip when encountering a team who are not engaging with the retrospective is to focus on the benefits it offers. “I would coach the team. After all, without the retro, the benefit of having an incremental release could be lost. With each release, the team usually improves its capability and performance. The retro gives them this opportunity to reflect and improve.”
In addition to open collaboration, it is important to use tools that support a safe and engaging meeting. This can help ensure that all team members are able to participate fully in the retro and contribute to its success. Tools like TeamRetro provide a predefined workflow that helps guide the team through the retro process and ensure that everyone is on the same page.
### “My team members enjoy doing the retro. It is the time for their voice to be heard. Using a product like TeamRetro helps a lot, especially since it has a predefined workflow that helps the team with their retro process.”
## Engagement leads to buy-in and overall team happiness
When team members are engaged and feel like their opinions and ideas are being heard, they are more likely to be invested in the success of the project and their work.
Rommy notes that his team members enjoy participating in retrospectives because it gives them the opportunity to be heard. By creating an environment of open collaboration and using tools that support engagement, Rommy’s team has been able to improve their experience of a team running a retrospective. This increased engagement has also led to improved team happiness, which has had a positive impact on the overall success of the project.
## Tips for better retrospectives
If a team is struggling to follow through on their actions, Rommy’s advice is that support is the key. “Proper management support could be necessary to help the team to improve”. While ideally each team should feel empowered to get things done, sometimes there is still a need for management to provide the tools, or the nudge to get things done.
Having a clear outcome and a shared definition of done is also important. A team needs to understand that work in progress does not bring value and that the goal is to deliver value in a timely manner at the right quality.
“We may also coach the team. It is important, for example, for everyone to commit to a Definition of Done (DoD) that is shared by the team. A DoD that is outside of team capability will become an issue.”
In terms of inviting people outside the team to sprint retrospective, Rommy has an inclusive approach. “If it’s relevant, why not?”. Having people outside the team from time to time provide useful insight, feedback and perspectives that can add to the team’s energy and bring new ideas to the retrospective.
His final piece of advice when it comes to sprint retrospectives?
### “Just enjoy the process, retrospectives are fun.”
## Who is Mitrais?
Mitrais has two lines of business – software development and software product services. Based in Indonesia, they offer a full range of software development capabilities including Microsoft, mobile, web, Java and more. Their product services cover the deployment and support of leading software products targeting the mining sector. These activities are backed by best-in-class human capital management systems and an integrated engagement model.
---
# How Moneybox boosts squad health, performance and happiness
URL: https://www.teamretro.com/case-studies/moneybox/
A squad health check is a regular survey of critical areas that make a team efficient, proficient, and happy. By creating an opportunity for members of the squad to safely reflect on those critical areas and provide their feedback, the health checks support their continuous improvement. They identify areas in need of development, and track the success of the treatments that are applied.
[Moneybox](https://www.moneyboxapp.com/) is a UK-based fintech company offering an award-winning app designed to help people achieve their financial goals. To date, their app has over a million users who have the option to invest, save or plan for their retirement.
When Moneybox implemented a system of squads to optimize their value delivery to users, they also introduced a way to optimize their health and performance. They did this with squad health checks.
Moneybox needed a way to deliver their customized squad health checks simply, efficiently and effectively; they chose TeamRetro.
Head of iOS, Valerio Bettini, shares their TeamRetro story.
## Who we are
At Moneybox, we value our company culture. We strive to ensure that our team members enjoy their work and that they have the necessary tools and processes to deliver the best features.
We recently reorganized our cross-functional teams into Squads. These are dedicated delivery teams focused on specific feature areas.
It became apparent that we needed a tool to monitor and assess the health of each Squad. One that would evaluate the different aspects that make the team happy, efficient, and proficient.
## Our TeamRetro experience
To address this need, we developed customized templates that cover a range of areas critical to Squad health.
We quickly realized that using TeamRetro would provide the ideal platform to conduct health checks and assess the success of each squad.
### “We found that organizing health checks was easy.”
TeamRetro allowed us to customize the assessment to monitor the aspects that were most important to our company.
These areas include:
- Mission
- Ownership
- Velocity
- Delivering value
- Suitable processes
- Communication
- Team roles
- Support and resources
- Work in harmony
- Technology
***Team health radar using random data created for illustration purposes only***
After just one iteration of the squad health checks, we began to see positive results.
We recognized the need to revisit some of the processes in use and better define the roles within the Squads.
Specifically, we noticed a lower score on two particular dimensions identified by using TeamRetro. This allowed us to take proactive action and support the team.
We now hold a health check every two months. We organize an interactive session to discuss the anonymous feedback received.
This provides an opportunity to create action points that can be assigned to people directly using the interface provided by TeamRetro.
Overall, using TeamRetro to conduct Squad health checks has been a game-changer for us at Moneybox.
## Using health checks to support our squads
The history of health checks is also valuable. We can make comparisons with past assessments and understand if our actions and changes brought an improvement in scores.
The reports allow us to compare the different squads with one another, identifying similarities and differences.
### “By using this platform, we have been able to identify areas where improvements are needed and take the necessary steps to ensure that each Squad is performing at its best.”
We now have a system in place that allows us to regularly assess the health of each Squad and take action to improve any areas that need attention.
By doing so, we are creating a culture of continuous improvement that ensures that our team members enjoy their work and that our customers receive the best features and products possible.
Thanks to our writer – [Valerio Bettini](https://www.linkedin.com/in/vbettini/?originalSubdomain=uk), an iOS developer since 2009. Valerio is a product-minded, user-focused, accomplished team leader with a vast portfolio of published iOS apps. He is currently the Head of iOS at Moneybox, the company that has delivered a multi-award-winning app of the same name.
---
# Inside Planted: how retros power purpose-driven teams
URL: https://www.teamretro.com/case-studies/planted/
[Planted](https://www.planted.green/) is the Sustainability Transformation Platform for mid-sized companies. Founded in 2021 in Germany, the fast-growing team of 50+ employees across Cologne, Berlin, and remote locations helps organizations make ESG transformation simple, measurable, and impactful.
At its core, Planted believes sustainability doesn’t begin with CO₂ reports or ESG strategies. It starts with people. When teams collaborate effectively, share feedback openly, and reflect together, they can accelerate the change our planet urgently needs.
Co-founder and COO [Heinrich Rauh](https://www.heinrichrauh.de/), who brings years of experience leading cross-functional teams across Europe, helps guide Planted’s mission to connect collaboration with sustainability.
## The challenge: growing teams, growing complexity
As Planted scaled, so did the complexity of its work. With employees spread across multiple cities and working remotely, the company faced three big questions:
1. How to create a clear feedback loop between Product, Sales, and Sustainability teams?
2. How to make sure remote employees feel included and heard?
3. How to ensure retrospectives don’t turn into routine checkboxes, but drive real change?
## The solution: retrospectives with TeamRetro
Since 2024, Planted has been using TeamRetro to structure retrospectives in a way that is efficient, inclusive, and motivating. The platform has helped the company professionalize its feedback culture and strengthen collaboration across borders.
What Planted values most about TeamRetro:
- Structured workshops: Every retrospective follows a clear flow – saving time and creating focus.
- Inclusive feedback: Remote and introverted team members contribute equally.
- Actionable outcomes: Insights are turned into concrete tasks immediately – no more “lost notes.”
> ***“TeamRetro has been a real game-changer for us. Our retros are not only more productive but also enjoyable. Most importantly, we can see how feedback translates directly into product improvements and better processes.”***
> ***– Heinrich Rauh, COO & Co-Founder of Planted***
## Measurable results
Using TeamRetro, [Planted](https://www.planted.green/) has already seen tangible improvements:
- Faster product development: Feedback from retros feeds directly into the backlog – reducing time from idea to implementation.
- Higher team satisfaction: Anonymous surveys show a consistent team happiness score above 8/10.
- Greater transparency: Challenges are surfaced early, long before they become blockers.
## Sustainability meets new work
For [Planted](https://www.planted.green/), retrospectives aren’t just a team ritual. They are the foundation of its sustainability mission. By ensuring collaboration, inclusion, and accountability, TeamRetro helps Planted align people with purpose and make ESG transformation scalable.
Both Planted and TeamRetro share a common belief: that lasting transformation starts with effective collaboration, whether in tackling climate change or improving daily teamwork.
## Building sustainable growth through collaboration
With TeamRetro, Planted found not just a tool but a trusted partner that strengthens feedback culture, builds alignment, and lays the foundation for sustainable growth. Because only when teams stay aligned can a mission like *“securing the future of all life on Earth”* truly succeed.
Just as sustainability isn’t a one-time project but a continuous journey, effective retrospectives build habits that sustain teams through growth and change.
Join teams like Planted who are building a better future. [Run your next retrospective with TeamRetro](/) and see how better retrospectives drive sustainable growth.
---
# How Reward Insight uses TeamRetro to measurably increase their agile maturity
URL: https://www.teamretro.com/case-studies/reward-insight/
[Reward Insight](https://rewardinsight.com/) is a London-based company specializing in loyalty technology and marketing solutions, helping businesses enhance customer engagement and drive growth. Founded in 2001, the company uses advanced analytics to deliver personalized offers and loyalty programs for leading retailers and financial institutions across 20 countries. With a strong focus on innovation and customer connection, Reward Insight continues to shape the future of loyalty programs globally.
[Rick Collins](https://uk.linkedin.com/in/rick-collins-a435141b3) is a seasoned Scrum Master and Agile Coach with over 15 years of experience in team facilitation, release coordination, and agile transformation. Currently serving at Reward, he supports global expansion initiatives and system modernization. Previously, Rick spent over a decade at Allstate Northern Ireland, honing his expertise in release management and technical leadership. With a background in architectural technology, Rick combines a unique blend of technical and collaborative skills to drive team success and deliver impactful results.
As a Scrum Master at Reward, Rick’s focus is on fostering an environment that maximizes productivity and team well-being. Reward specializes in delivering innovative loyalty solutions for sports and retail industries, underpinned by Agile methodologies that promote adaptability and continuous improvement. TeamRetro has become an invaluable tool in their journey to optimize teamwork processes.
As Rick shares “*As a Scrum Master at Reward, I’m deeply committed to optimizing teamwork processes. My focus is on fostering an environment that maximizes both productivity and team well-being. To continuously improve is paramount, and TeamRetro has been an invaluable tool in this journey.*”
Here’s their story…
## Challenges faced before TeamRetro
Prior to adopting TeamRetro, Reward faced several challenges.
Rick explains, “*Company-wide, our Continuous Improvement initiatives faced challenges due to a lack of consistency in how we gathered and implemented improvements. Each team adopted its own unique process, resulting in a fragmented approach and inconsistent outcomes.*
*At the team level, driving engagement and ensuring all team members’ feedback was considered proved challenging. The use of anonymous whiteboards in remote meetings often led to passive participation, as some individuals felt less inclined to actively contribute*.”
> *Driving engagement and ensuring that all feedback is received has proved challenging across teams.*
## Discovering TeamRetro
The recommendation to trial TeamRetro came from a Development Manager with prior experience using the platform.
Not relying on hearsay alone, Reward wanted to conduct their own due diligence.
“*The Agile Delivery Group conducted thorough research and were highly encouraged by many aspects of TeamRetro, as it demonstrated strong potential to complement and enhance our existing Agile practices*.” Rick explains.
## How TeamRetro supports Reward’s agile framework
Reward’s Agile framework incorporates elements of Scrum, Kanban, and Scaled Agile, all rooted in the principle of continuous improvement.
Rick describes how TeamRetro supports this, “*The platform’s ability to facilitate the rapid creation of retrospectives and health checks enables us to establish baselines and drive incremental improvements with greater efficiency.*”
## Outcomes achieved with TeamRetro
Using TeamRetro, Reward has achieved several significant outcomes. By establishing a baseline at the start of the year and re-evaluating using the same health checks, Reward gained a clear understanding of its progress, demonstrating an increase in Agile maturity. Scheduled generation of boards ensures retrospectives are aligned with team cadence, enabling live feedback without delays. Real-time board updates remove the need for screen-sharing in meetings, promoting openness and anonymity. AI-driven grouping of feedback saves time and adds efficiency, while themed retro boards add an element of fun and engagement.
“*With the assistance of TeamRetro, we have achieved a measurable increase in our Agile maturity. By establishing a baseline at the beginning of the year and then re-evaluating using the same Health Check at the end, we gained a clear and quantified understanding of our progress.” Rick says.*
Reward’s team members appreciated the simplicity of the platform and its engaging features, such as emojis and GIFs, which made retrospectives enjoyable and interactive. Real-time updates encouraged honest and anonymous feedback, fostering an open and collaborative environment.
*“We have found the recent enhancements to the embedded AI to be highly beneficial. Being able to quickly and intuitively group feedback live in a retrospective saves a lot of time. Team Members also appreciate the fun brought via the themed retro boards”, Rick elaborates.*
## Advice for running effective retrospectives
Rick emphasizes the importance of consistency by using recurring templates to keep retrospectives a regular part of the workflow. Having retro boards always available encourages teams to reflect and contribute continuously. Customization of settings ensures sessions remain engaging and prevents them from becoming stale. Reviewing action items at the start of each session helps close feedback loops and ensures accountability.
Rick’s Retro Tip –
“*Create a recurring template from your favorite Retro Board and use this to generate a new board at the end of every retrospective period. This means a retro board is always available for thoughts and feedback. Having continual access to a retro board, then encourages the team to give feedback and reflect continuously.*
*With a plethora of customizable settings, you can tweak each board to stop your retrospectives from becoming stale and uninteresting.”*
## Transform your retrospectives today with TeamRetro
Reward’s experience highlights how TeamRetro can empower teams to enhance Agile practices, boost engagement, and achieve measurable improvements. Make your team’s retrospective meetings become even more effective and insightful.
**[Join TeamRetro today and discover the difference!](https://secure.teamretro.com/login/new?redirectUrl=https%3A%2F%2Fsecure.teamretro.com%2F&cc=www-case-studies)**
---
# Introduction to RoleModel Software: pioneers in custom software solutions
URL: https://www.teamretro.com/case-studies/rolemodel-software/
[RoleModel Software](https://rolemodelsoftware.com/), with over 25 years in custom software development, serves industries like healthcare and manufacturing. Known for their dedication to quality and craftsmanship, their team includes skilled developers and designers at all experience levels. Guided by values of character, collaboration, and craftsmanship, [RoleModel Software](https://www.linkedin.com/company/rolemodel-software) is committed to excellence as it builds solutions that enhance client operations and stand the test of time. Their commitment to continuous improvement drove them to seek tools that enhance their processes and empower their teams to deliver high-quality software.
Mitch Fernandez is an executive leader with over 25 years of experience in strategic planning, technology management, and innovation across diverse sectors, including technology, government, and biotechnology. Known for driving operational excellence and strategic growth, Mitch excels at leading large, complex organizations and fostering a culture of continuous improvement. With a forward-thinking approach and a talent for bridging technical and non-technical communication, he is recognized for his integrity, vision, and collaborative leadership.
Here is their story…
## The challenges of a growing, innovative agile team
Before adopting TeamRetro, we faced several challenges that prompted us to seek out a better solution for our retrospectives and team health tracking. First, we wanted to ensure consistency across all our projects by conducting regular retrospectives, ideally one every two weeks. Retrospectives are critical to our process, as they allow us to reflect, learn, and improve, but ensuring this cadence across all teams was a challenge.
In addition, we were looking for a way to gather meaningful metrics about project health. Collecting team feedback through a structured, reliable, and insightful process was key for us, and we needed something that could handle this systematically.
> ***TeamRetro’s Team Health Check feature allowed us to run quick surveys, providing a pulse on how our teams felt about aspects like communication and workload.***
Another significant factor was cost. We wanted a solution that provided all the features we needed but at a more competitive price compared to other tools we had evaluated. Finding a tool that was cost-effective without sacrificing functionality was important for us as a company with multiple projects and team members.
**Moreover, we wanted a tool that was engaging and enjoyable to use, not just another checkbox in the process.** Retrospectives should allow teams to express their thoughts openly; a dull or cumbersome tool could inhibit participation.
> ***TeamRetro’s interactive and intuitive design made the retrospective process both fun and insightful, enhancing team engagement.***
Finally, **ease of use (both internally and with our customers) was a top priority**. We needed a tool that was simple enough for our internal teams to adopt without extensive training, but also easy for our clients to interact with during joint retrospectives. TeamRetro struck that balance by offering an interface that was accessible to all, from project managers to external stakeholders. This user-friendly experience encouraged full participation and made our retrospectives more effective overall.
In summary, our primary challenges were maintaining consistent retrospectives, collecting valuable team metrics, finding a cost-effective and user-friendly solution, and ensuring the tool was fun and easy to use for both internal teams and customers. TeamRetro addressed all of these challenges seamlessly.
## Discovering TeamRetro: a feature-rich, cost-effective solution
We discovered TeamRetro through a simple Google search. At the time, we were using another tool for our retrospectives, but we found that it didn’t align with our budget over the long term. We needed a solution that offered similar functionality but at a more affordable price, especially as our team scaled. This led us to TeamRetro, which immediately stood out due to its more cost-effective pricing plans.
Cost wasn’t the only factor, though. One of the things that really impressed us was how TeamRetro matched, and in some cases exceeded, the features we were accustomed to. We were pleased to find that TeamRetro offered the same key capabilities for running retrospectives, including structured templates, anonymity options, and easy-to-use interfaces. It gave us everything we needed without having to sacrifice any of the functionality we had come to rely on.
Beyond the tool itself, *TeamRetro’s customer support played a big role in our decision*. From the very beginning, their team was responsive, attentive, and willing to listen to our specific needs. In fact, after we started using the tool, we made a feature request, and not only did TeamRetro take it seriously, they actually implemented it. This level of customer care and responsiveness is rare and was a significant factor in solidifying our decision to not only stick with the tool but also to upgrade our plan to take advantage of even more features.
> ***We chose TeamRetro because it was cost-effective, packed with all the features we were used to (and more), and backed by excellent customer support.***
The responsiveness of their team, especially in implementing customer feedback, made us feel like we were more than just users. We were partners in the development of a tool that continues to help us improve our retrospectives.
## Tailoring TeamRetro to the RoleModel way of working
Our process for retrospectives is structured, methodical, and designed to ensure that we get the most out of every session. While we already had a process in place before adopting TeamRetro, the tool has not only supported this process but has also enhanced it in meaningful ways.
We begin each retrospective with a custom 10-question health check. This has become a crucial part of our process because it allows us to take a snapshot of team morale, project challenges, and general well-being at the start of each session. The health check results are seamlessly transformed into project metrics that align with the historical data we’ve collected, giving us a way to track progress over time and identify areas that may need attention. TeamRetro’s built-in health check feature has been an invaluable tool for collecting this information efficiently.
While we initially enjoyed using the icebreaker feature to help team members feel comfortable and ease into the retrospective, we’ve recently opted to streamline our meetings and have paused using this feature. That said, we found the icebreakers to be excellent, and we may consider reintroducing them in the future as time permits.
The core of our retrospective is where TeamRetro really shines. We like to mix things up, so we regularly switch between different retrospective templates to keep things fresh and engaging for the team.
> ***The flexibility of rotating through different templates keeps retrospectives fresh and engaging, tailored to our team’s evolving needs.***
TeamRetro offers a wide variety of retrospective templates, so it’s easy to find something that fits the specific needs of each session. Whether we want to focus on what went well, opportunities for improvement, or even more creative approaches, the tool provides plenty of flexibility.
Once we’ve selected a template, we begin by spending 5 minutes allowing each team member to write down their comments, with anonymity maintained to ensure everyone feels comfortable sharing openly. TeamRetro’s anonymity feature is crucial for fostering honest feedback and participation.
Afterward, we move into a comment-grouping phase. While the team is free to group comments manually, ***we often take advantage of the AI-driven feature that helps organize related comments quickly and accurately*** This has been a huge time-saver for us.
Next, we spend a few minutes voting on which topics to prioritize for discussion. The voting feature in TeamRetro allows us to quickly identify the most pressing issues.
Once the voting is complete, we focus on the top three topics, discussing each for around five minutes. The built-in timer helps us stay on track, but we allow flexibility if the team agrees that a particular topic requires more time.
While some team members find the timer a bit loud and obnoxious, we’ve taken a lighthearted approach to this. We’ve turned it off for the most part but occasionally use it when we want to gently nudge people into finishing quickly. It’s become more of a running joke within the team, and we’ve adapted our use of it to suit our style.
During these discussions, we use reactions and comments to engage further and add action items in real-time. This way, we can immediately begin to address the issues raised during the retro.
At the end of the retrospective, we review the action items we’ve created and then rate the retrospective itself using TeamRetro’s built-in rating feature. We conclude by downloading the session summary as a PDF and sharing it directly to the project’s Slack channel, ensuring that everyone stays informed and accountable.
Something we’ve recently identified as an area for improvement is reviewing open action items at the start of each retro. While we haven’t been consistent in doing this, we plan to experiment with it to close the feedback loop more effectively.
> ***TeamRetro provides a structured yet flexible framework that aligns perfectly with our process, making our retrospectives smoother and more productive.***
The tool’s customizable templates, AI-driven features, and integration with our communication channels have made our retrospectives smoother, more productive, and more engaging for everyone involved.
## Results: improved team dynamics, cost savings, and client transparency
Our team has experienced several key benefits from using TeamRetro that have improved both the retrospective process and our overall workflow.
One of the most important benefits we’ve seen is the consistency in how we collect project health metrics. By using the health check feature at the start of each retrospective, we now have a clear and regular way to track key indicators across all of our projects. This has made it easier to spot trends, identify potential issues early, and ensure that we stay on top of the overall health of our teams and projects.
> ***Rather than just identifying problems, we’re now consistently coming up with ways to address them, which has increased the effectiveness of our retrospectives.***
Next is the ease of use. This means that no time is wasted figuring out the tool, and everyone can focus on sharing valuable insights and feedback.
The fact that TeamRetro serves as a shared platform has also been a significant advantage. It creates a central hub for our retrospectives, where all team members can contribute, see each other’s feedback, and stay aligned on action items. This shared space ensures consistency and keeps everyone on the same page, both during the retrospectives and afterward, as we review progress.
Retrospectives have also become a powerful platform for problem-solving. We frequently use these sessions to identify challenges, brainstorm potential solutions, and then put those solutions into action. This proactive approach has led to measurable improvements in our projects and processes. Rather than just identifying problems, we’re now consistently coming up with ways to address them, which has increased the effectiveness of our retrospectives.
Additionally, TeamRetro has had a positive impact on team dynamics. Although our team doesn’t typically have a lot of grievances or complaints, the retrospectives have created a safe and open environment where everyone feels comfortable sharing their thoughts and challenges. Team members know their voices will be heard and that their concerns will be taken seriously. This has fostered a culture of trust and transparency, which is vital to maintaining a healthy and productive work environment consistent with our core values.
> ***The ability to identify and address problems in real-time has been a standout benefit with TeamRetro, making our retrospectives proactive and action-focused.***
Having a dedicated space for tracking and referencing action items means that nothing is forgotten or overlooked. Team members can easily revisit these items in subsequent retrospectives, ensuring accountability and follow-through.
> ***The feedback from both team and leadership on TeamRetro has been overwhelmingly positive, especially for its cost-effectiveness and user-friendly experience.***
We have encountered a few minor technical issues, such as when two people try to update the title for a group of topics simultaneously, this creates a conflict. That said, these issues are rare and haven’t significantly disrupted our workflow. TeamRetro’s robust features have allowed us to navigate these minor hiccups with ease, and we’re confident that future updates will only improve the experience.
The platform has also helped to enhance team camaraderie. We use retrospectives not just to tackle problems but also to celebrate our successes. TeamRetro gives us the opportunity to congratulate ourselves when things go well, and we even engage in some friendly teasing, which lightens the mood and makes the retrospectives something the team looks forward to. This balance between addressing serious topics and having fun has made the retros more engaging and has brought our team closer together.
On the more positive side, one feature that everyone loves is the ability to use reactions. It’s a simple but effective way for the team to engage during discussions, adding a layer of fun and interactivity to the retros. It’s these small touches that make the retrospectives more engaging and dynamic, helping to break up the more serious discussions with moments of levity.
Leadership, in particular, has been pleased with the results. They are glad to see that we’re conducting retrospectives on a regular basis and that we’ve been able to do so in a cost-effective manner. The consistency of the retros, enabled by TeamRetro, has provided valuable insights into our projects and teams that leadership appreciates.
From a customer perspective, TeamRetro has given them insight into how we work and has provided a valuable opportunity to address any problems they’ve encountered.
> ***Including customers in our retrospectives through TeamRetro has strengthened our client relationships by fostering a collaborative and transparent atmosphere.***
This level of transparency has strengthened our relationships with clients and has fostered a collaborative atmosphere where both parties work together to continuously improve the project.
Looking ahead, we aim to build on these successes by continuing to refine our process and deepen our engagement with both our teams and our customers. We’re excited about the possibilities that TeamRetro offers and are confident that it will continue to play a crucial role in helping us achieve our goals of consistent improvement, stronger collaboration, and a more engaged team.
Overall, TeamRetro has helped us streamline our retrospectives, promote transparency, and ensure that problems are addressed promptly, all while keeping the process simple and efficient for everyone involved.
## Advice for teams
When it comes to running retrospectives and health checks, my top piece of advice is to establish consistency. Teams may initially resist frequent retros, but once it becomes a habit and part of the standard approach to project management, people not only get used to them, they sometimes even start looking forward to them. Retros become an opportunity for team members to share their thoughts openly and get things off their chest, knowing they’ll be heard.
One area of mixed feedback has been the frequency of the retrospectives. Some team members question whether having retros every two weeks is necessary, especially when there isn’t much to discuss. However, leadership and I agree that the regular cadence is valuable. Even on quieter weeks, having the retrospective on the calendar ensures that we’re ready to address issues when they do arise, and it creates a sense of preparedness across the team.
The key is to make retrospectives a regular occurrence, not something you run only when issues arise. If you’re always waiting for a reason to hold a retro, you’ll end up reacting to problems rather than proactively managing your projects. Having a consistent cadence helps you stay ahead of potential issues and fosters continuous improvement.
To keep things fresh, take advantage of the features that TeamRetro offers. Using Icebreakers and reactions adds an element of fun, which helps teams engage more fully. Respect team members’ privacy by keeping comments anonymous; this encourages more open and honest feedback. At the same time, make sure to guide the team on the purpose of the retrospective: it’s not just for addressing problems but also for celebrating wins and accomplishments.
Don’t be afraid to mix things up by rotating through different retrospective templates. If you have a specific reason to use a particular template, go for it, but also familiarize yourself with the options so you can keep the retros interesting and aligned with your team’s needs. Creating custom templates and health checks tailored to your organization is another way to ensure the retros are meaningful. By asking the right questions, you can generate insights that matter and help your teams grow.
It’s also essential to stay consistent with health checks. By using the same set of questions across projects, you’ll be able to compare results over time, identify trends, and truly gauge how your teams and projects are evolving. And don’t forget about the importance of internal and customer-facing retrospectives; both play a valuable role. For internal retros, consider setting up a separate team to keep sensitive discussions private. We use one team for all of our internal retros to save on costs, but this setup works well for us, as we can still maintain confidentiality.
Lastly, take full advantage of TeamRetro’s integrations, like Slack, to share results efficiently. Always share the findings from each retro and health check with the team. It keeps everyone informed and accountable. If you ever need to close a team, be sure to export and download your results for historical reference, so you don’t lose valuable insights.
> ***Consistency, engagement, and variety are the keys to running successful retrospectives with TeamRetro, leading to meaningful improvements in our projects.***
## Make the switch to TeamRetro today
RoleModel Software’s experience demonstrates how TeamRetro can help teams enhance their retrospective process, engage participants, and streamline project health tracking, all while staying budget-friendly. If you’re ready to see how TeamRetro can make a difference for your team, start your journey with TeamRetro today.
**[Try TeamRetro today to transform your retrospectives!](https://secure.teamretro.com/login/new?cc=www-case-studies)**
---
# How Sympower charged ahead with TeamRetro as their preferred retrospective tool
URL: https://www.teamretro.com/case-studies/sympower/
[Sympower](https://sympower.net/ "Sympower website") is a transformative company that empowers commercial and industrial energy users to build sustainable energy systems. As a B-certified company, its goal is to increase sustainability, cost reduction, and grid stability around the world.
Sympower is a company defined by its people and culture, with a shared vision of a truly sustainable world.
Specializing in demand response and energy flexibility solutions, Sympower helps balance the grid and integrates renewable energy sources. As part of its commitment to continuous improvement, Sympower has adopted TeamRetro to streamline processes and foster a culture of collaboration and growth.
Fred Puistaja is an accomplished Engineering Manager at Sympower where he has demonstrated his expertise and leadership for over 6 years, moving up through pivotal roles.
His previous manager and teammate described him as having a keen eye for data quality, with continuous improvement embedded in his heart and brain, and as a cool life hacker!
Fred shares why TeamRetro is the preferred retrospective tool.
“We are a software team and company. We were looking for tools to help us better run our retrospectives and needed features that would help improve the way our meetings were run.”
For us, this meant things like:
- You didn’t need to mess with stickies
- You could write down action items and track them
- You could hide all ideas before discussing
- You could color ideas by the author
- You could generate a summary of the retro
We found that TeamRetro had these features and also a well-structured way of doing retros. The other tools didn’t have all of these features in one. We run our bi-weekly retrospectives in our Scrum teams, so having the right agile retrospective meeting tool is important. Some of our non-engineering teams also use TeamRetro on occasion.
Having good retrospectives means we can get fast feedback from our sprints. Small improvements each time help us fine-tune our processes. One of the aspects that we really enjoy is that it also allows us to have retrospectives with minimal effort from the facilitator. It allows the team to focus on the task at hand because it is just easier.
It’s great that it also allows us to share the summary easily with other teams and team members. It reduces the facilitator’s workload, which means they can be more effective and helpful for the team.
Team members could also fill in their ideas beforehand, and privately – without showing them to everyone else already. This means the input is unbiased and can be in their own time. You can also schedule recurring retros.
One of the benefits of using TeamRetro is that it allows you to create and track actions right next to the retro (and idea) itself, so you can see where the reason for the action came from.
One of the cons or areas for improvement would be that during the presentation stage, when we are going through ideas, those ideas can be sorted by topic, and by person. This would allow us to go through topic areas first, rather than by most voted which is the default.
**TeamRetro Feature Update:** Great feedback Fred. And good news! This feature is now live so you can sort by topic and person in the presentation phase!
Overall, our team says our retros are now more organized, which allows us to have fast feedback cycles on how we are working.
As a piece of advice for teams, it’s important to always aim to create a safe environment to share feedback in order to get the most out of your retrospectives.
—
Thanks for your feedback Fred. We hope to help you and your teams continue to run amazing and worthwhile retrospectives!
---
# Scrum Master creates happy, empowered agile teams through health checks and AI-powered retrospectives
URL: https://www.teamretro.com/case-studies/trendminer/
It’s always appreciated when we get feedback from our clients; it’s their input that helps guide us as we learn, grow and evolve TeamRetro. Their stories are why we do what we do.
We are delighted to share with you this piece written by Caitlin Whittaker, Scrum Master who shares her experience of supporting and empowering happy, productive and engaged agile teams.
Overcoming the challenges of a global team, building consistency and cadence and having happy team members which boosts productivity are all part of the success points of this Scrum Master (and new mum!).
Whether it’s using AI features to create engagement, having a consistent tool to run health checks to get a sense of how the team is tracking, through to goal setting and running futurespectives, Caitlin helps her teams continuously engage, improve and feel good about the work that they do.
## Choosing an online retrospective tool for global teams
The path leading to TeamRetro started when I needed a way to consolidate retros when my teams started expanding globally.
I was also looking for a way to easily implement a team Health Check on a regular basis so that we could monitor how the teams were feeling as we evolved as a company and product.
*“Developers are some of the most highly intelligent problem solvers you will ever be fortunate enough to work alongside, and my one goal for all my teams is their contentment.”*
As I was also about to take leave to deliver a mini human being, I wanted a solution that would allow my teams to maintain consistency and continuity.
I am not a fan of disruptions so having a solution where the teams could continue with all the prior history and action points already available and accessible was invaluable.
## Creating happy, healthy and productive teams
Developers are some of the most highly intelligent problem solvers you will ever be fortunate enough to work alongside, and my one goal for all my teams is their contentment.
This may sound cheesy but it is the key to unlocking the greatest productivity in teams.
Happy, motivated teams are productive teams and also as a result long-term employees. Individuals and teams are most productive when they feel heard, understood and motivated which is why we hold retrospectives on a regular basis at the end of each sprint cycle.
Essentially the impact of retros in an Agile framework should lead to continuous improvement but this is hard to measure on a broader scale.
This is where I have found TeamRetro invaluable both as a tool to consolidate the retros from my teams and monitoring sentiment and the feelings of the team.
## Using team feedback to improve team health
With TeamRetro, pain points can easily be identified. We can also see if this is a common theme across the teams and consequently a deeper underlying issue which needs resolving or specific to a certain team.
Improvements can then be monitored in the future to make sure that we’ve really made a change that is valuable or if we are not quite there yet.
As companies and processes evolve, there will always be areas which require attention and with TeamRetro we can consolidate all feedback and allow the teams to also be involved in constructive action points to move forward on.
## Adaptable, fun, and open retrospectives and futurespectives
Because TeamRetro is so adaptable, I have also used it for goal-setting and ‘futurespectives’ for the teams.
Setting goals for what teams want to achieve in a certain time frame and keeping the action points visible so that we can focus on achieving, looking forward and committing to making it happen.
## Using AI to generate retrospective themes
The new AI feature has also been fantastic in keeping retrospectives fun and open. Teams really enjoy coming into a retro where it is based on current affairs.
I have used themes such as Wimbledon, NFL and Barbie. Using this to create a more relaxed atmosphere has led to some very insightful retros and consequently positive change and improvements for the teams.
—
Thanks Caitlin. We wish you and your teams, and the new bub all the best. Thanks for sharing your story.
---
# Making retrospective meetings productive: Trigama's success story
URL: https://www.teamretro.com/case-studies/trigama/
## Introduction to Trigama: a leader in custom IT solutions
Trigama International s.r.o. is a dynamic IT company specializing in developing custom-made applications for its diverse clientele. With a commitment to creativity and technological excellence, Trigama leverages advanced methodologies to deliver innovative solutions that meet specific client needs.
Václav Nidrle serves as the Managing Director and CTO of Trigama. With a keen eye for innovation and a strategic approach to leadership, Václav has been instrumental in steering the company toward growth and adapting to new challenges, particularly in the realm of remote work.
## Challenges of remote scrum retrospectives at Trigama
Trigama’s development teams operate using the Scrum methodology, necessitating regular retrospective meetings. Initially, these meetings were conducted on-site, but the onset of COVID-19 and the company’s growth led to an increase in remote work. This transition posed challenges, including lack of preparation for retrospectives and inefficiencies during meetings. “Our development teams are working using Scrum methodology. We used to do retrospective meetings on-site in our office, but the growth of Trigama and the onset of COVID-19 caused much more remote workers in our team,” says Václav.
## Finding the perfect tool: why Trigama chose TeamRetro
In search of a user-friendly tool to streamline their retrospectives, Trigama found TeamRetro. “We were looking for an easy-to-use tool that will help us with organizing retrospectives,” explains Václav. The platform’s intuitive interface, pre-meeting preparation features, and capability to drive actionable steps made it an ideal choice for the company. “We liked TeamRetro being intuitive, its help with preparation of points to discuss in advance, and also that it pushes the team to make action steps about each problem being discussed.”
TeamRetro became integral to Trigama’s retrospective meetings, allowing the teams to prepare discussion points in advance and manage the meeting agendas effectively. This tool supported the teams in maintaining structured and productive retrospectives, crucial for continuous improvement. “As said before, the retrospective meeting is the crucial process. We have used TeamRetro to prepare and manage retrospective meetings for our development teams,” Václav adds.
## Key benefits of using TeamRetro for Scrum Masters and teams
The implementation of TeamRetro led to significant improvements in meeting efficiency and team confidence. The ability to prepare points beforehand and the tool’s ease of use meant that even without a Scrum Master, the teams could conduct retrospectives smoothly. “It helps the team to go through the retrospective process even without Scrum Master presence, it gives confidence to the team and even new team members in going through the process,” Václav highlights. This resulted in more focused discussions on team and project issues, rather than on meeting logistics.
- Enhanced meeting efficiency and time management.
- Increased team confidence, even among new members.
- Structured and standardized outcomes from each retrospective.
- Reduction in the dependency on the Scrum Master for facilitating meetings.
The team at Trigama found TeamRetro to be an intuitive tool that significantly improved their retrospective meetings. “Intuitive tool,” Václav says simply but effectively.
> By leveraging TeamRetro, Trigama successfully navigated the challenges of remote work, enhancing their retrospective meetings and overall team productivity. Explore TeamRetro to see how it can benefit your organization.
## Advice for Scrum Masters
“Try TeamRetro to see the benefits it can bring to your teams,” recommends Václav Nidrle.
Ready to transform your retrospective meetings? Discover how TeamRetro can help your team work more efficiently and effectively.**[
Get Started with TeamRetro Today!](https://secure.teamretro.com/login/new?cc=TeamRetroBlog)**
---
# Supporting Typewise's distributed team with online retrospectives
URL: https://www.teamretro.com/case-studies/typewise/
## Introducing Typewise’s smartphone keyboard app
Typewise logo
[Typewise](https://typewise.app/) is a Switzerland based tech startup company focused on a vision of enabling a digital world that respects user privacy. The company has developed a next generation AI-powered smartphone keyboard app for [iOS](https://apps.apple.com/us/app/typewise-keyboard/id1470215025) and [Android.](https://play.google.com/store/apps/details?id=ch.icoaching.wrio&hl=en) Janis Berneker is the CTO and Co-Founder of Typewise. He leads the product development with three distributed team sections – design, app development and AI development.
***“The smartphone keyboard is today’s most important human-machine interface, used 76x per day on average across all kinds of apps. However, 70% of users are dissatisfied with many typos on their smartphones.”***
***“Over 1 billion people have installed third-party keyboard apps that promise to make typing easier. The caveat: these apps require the permission to transmit everything the user types on their phones. Consequently, 77% of users are concerned that their keyboard records everything they type.”***
***“Typewise solves this problem through its revolutionary, patented hexagon layout, making the keys wider and easier to hit. Typewise also learns where the user exactly hits the keys and adapts itself automatically thanks to AI.”***
## The challenge of a distributed team
Typewise smartphone keyboard app
Typewise began full-time work on their app in October 2019. The startup recently completed a successful fundraising campaign which allowed them to build their team. Typewise’s team of ten people – including its CEO, CTO, UX designer, marketers, app developers and AI engineers – are located in Zurich but many of them work partially or remotely on this project.
***“Since we’re a start-up I have several roles with the most important being product manager but also many other roles like scrum master and part-time developer.”***
***“In my previous job I learned how powerful Scrum and Retros in particular can be. There the whole team worked on-site though.”***
***“However, at Typewise part of our team works completely remotely. So communication and regular feedback loops are even more important.”***
To ensure that regular, engaging and effective retrospectives happen, Janis started looking for an online retrospective tool that would complement the distributed team working environment at Typewise.
## Online retrospectives for Typewise’s distributed team
In trying to find an online retrospective solution for his distributed team, Janis tried many different solutions available. However, he found that most of them lacked a good user experience (UX).
***“Since online retros are already less convenient than offline ones, UX was a crucial factor for us.”***
***“When we tried*** [***TeamRetro***](/)***, it worked much more smoothly than other online retrospective solutions we tried.”***
***“That is why we decided to go for TeamRetro.”***
## TeamRetro’s Health Check and agile retro tools
Typewise started using the [Team Radars and Health Check](/health-checks/) feature of TeamRetro to track the satisfaction of its whole team.
Team health check results, courtesy of Typewise.
The team would then conduct a [full online retrospective](/retrospectives/) with one of the available templates. TeamRetro templates range from [Agile Retrospectives,](/retrospective-templates/agile-retrospective/) [Anchors and Engine](/retrospective-templates/anchors-engines-retrospective/), [Four Ls](/retrospective-templates/4ls-retrospective/), [Start, Stop, Continue](/retrospective-templates/start-stop-continue-retrospective/) or create your own custom online retrospective.
FLAP retrospective activity template format example
***“My experience is that it’s good to change between the templates because they often provide different perspectives, which can be very helpful.”***
***“Online retrospective with TeamRetro helps people to communicate issues early and also to learn to think about how to improve the product or processes proactively.”***
## Positive work and culture outcomes for a distributed team
By using TeamRetro for their online retrospectives, Janis has indicated that it has helped develop a positive team and work culture at Typewise. The Team Radars and Health Check has also empowered Janis and his management team to assess the level of happiness within the startup.
***“TeamRetro has helped us establish an open feedback culture where everyone is at eye level, and increased happiness.”***
Being able to run online retrospectives has also meant that Typewise’s distributed team members don’t feel like they are missing out on one of the important team activities of providing feedback, assessing performance and creating actions for improvements.
***“TeamRetro has also helped to encourage exchange between the different teams, as all team members participate in the same Retro.”***
## Try TeamRetro
Are you and your team or organization looking to conduct remote retrospectives and team health checks? Whether you have a partially remote, fully remote or hybrid work environment, TeamRetro can help to make sure that your important retros run efficiently and in an engaging manner.
[Try it FREE today for 30 days](https://secure.teamretro.com/login/new/?cc=www-case-studies)
---
# University of Wollongong used TeamRetro as an agile training tool
URL: https://www.teamretro.com/case-studies/university-of-wollongong/
[The University of Wollongong](https://www.uow.edu.au/) (UOW) is known for its commitment to excellence in education, research, and innovation. With a focus on equipping students with practical skills and real-world experience, UOW integrates innovative technologies and evidence-based practices to elevate student learning and foster real-world problem-solving skills.
One such initiative involved integrating TeamRetro, an agile retrospective tool, to help students improve collaboration and address group challenges early in their projects.
[Dr. Sie](https://scholar.google.com/citations?user=zzNuaB8AAAAJ), a senior lecturer at UOW, shared how TeamRetro has supported his teaching practices. His work focuses on the practical application of Generative AI and large language models (LLMs), with a particular interest in tackling challenges like scalability, reliability, cost-efficiency, and security in AI deployment. He also supervises capstone group projects, guiding students as they collaborate on real-world solutions and gain hands-on experience.
Here’s his story…
## The challenge: addressing group dynamics in student projects
Before using TeamRetro, Dr. Sie observed a recurring issue in group projects: students were unfamiliar with reflecting on their group process. This lack of structured reflection meant group challenges only became apparent at critical moments — usually when assignment deadlines loomed or after submission reviews.
By the time these challenges surfaced, resolving them became difficult, often affecting group performance and outcomes. Dr. Sie realized the need for a tool to help students reflect and address issues earlier in their group work.
## Discovering TeamRetro: bridging education and industry practices
Dr. Sie was already familiar with TeamRetro from his previous role, where it had proven highly effective for the teams he supervised. Confident in its value, he decided to introduce the tool to his students at UOW.
“I thought it could work for students as well, and it gave them an opportunity to utilize a tool that is widely used in the industry,” Dr. Sie explained. By incorporating TeamRetro, he provided students with a practical learning experience while helping them adopt a reflective mindset essential for collaboration and problem-solving.
*”We used TeamRetro on a large scale at my previous employer and it worked great for the teams that I supervised. I thought it could work for students as well, and it gave them an opportunity to utilize a tool that was being used in industry.”*
## Implementing agile practices with TeamRetro
Dr. Sie adopted an agile approach in supervising group projects, incorporating TeamRetro’s group retrospectives to help students reflect on their progress and processes. The retrospectives encouraged open discussions and action-oriented thinking, allowing students to identify challenges and solutions early in the session.
> *“By using TeamRetro, students were able to reflect on group processes and identify actions early, helping them solve group challenges quickly.”*
Starting early allows teams to uncover insights and set a strong foundation for collaboration and continuous improvement.
Dr. Sie shared a practical tip for those facilitating retrospectives: *“Run retrospectives as quickly as possible after you form a new team or group, so you can quickly identify opportunities to improve the team process.”*
## Key outcomes and benefits of using TeamRetro as a training tool
By using TeamRetro, students at UOW achieved several significant outcomes:
**Early Problem Identification**: TeamRetro helped students reflect on their group dynamics and identify potential challenges early.
**Collaborative Problem-Solving**: Students worked together to define clear actions for improvement, fostering teamwork and accountability.
**Self-directing groups**: Dr. Sie found that students became more self-sufficient in resolving group challenges, reducing the need for his direct intervention.
**Real-World Experience**: Students gained exposure to industry tools and practices, preparing them for future careers.
The feedback from students was positive, with many noting how helpful the tool was in improving their group process and collaboration.
## The impact of TeamRetro
The University of Wollongong’s experience with TeamRetro demonstrates how agile retrospectives can transform group collaboration in an educational setting. By introducing TeamRetro, Dr. Sie provided students with a structured approach to reflection, enabling them to solve challenges early and improve their overall experience in group projects.
For educators and team leaders looking to enhance group dynamics and promote continuous improvement, TeamRetro offers a practical, user-friendly solution that delivers meaningful results.
[Try TeamRetro today](https://secure.teamretro.com/login/new?cc=www-case-studies) and see how it can empower your team to reflect, adapt, and grow.
---
# WWE Smackdown Showdown Retrospective
URL: https://www.teamretro.com/retrospective-templates/wwe-smackdown-showdown-retrospective/
The WWE Smackdown Showdown Retrospective turns your sprint review into a wrestling card. The wins are signature moves, the setbacks are body slams, new ideas get tagged in, and someone walks away with the belt. It's a good change of pace for a team with retro fatigue.
The board has four areas. Signature Moves is for what went well and should keep happening. Body Slams covers what knocked the team down or slowed it, kept blameless. Tag-Team Plays is for new tactics and experiments to try next sprint, and Championship Belt is where people recognize the teammates who carried the load.
The theatrics make it easier for quieter people to join in and for everyone to talk about setbacks without blame. Underneath, it's a standard retro: TeamRetro handles anonymous ideas, grouping and voting, and you finish by turning the best Tag-Team Plays into actions with owners.
## Topics
- **Signature Moves**: What went well and what should we keep doing?
- **Body Slams**: What knocked us down or slowed us this sprint?
- **Tag-Team Plays**: What new ideas or experiments should we try next?
- **Championship Belt**: Who deserves recognition and a shoutout this sprint?
## When to use
- When your team has retro fatigue and a themed format would get people talking again.
- After an intense, high-pressure sprint, when the team has earned some recognition.
- For team-building sessions where you want everyone to speak up.
- When you want a light way to raise blockers without anyone feeling blamed.
## Tips and tricks
- Use entrance music or wrestling visuals to set the mood, but don't let the gimmick crowd out real takeaways.
- Keep Body Slams blameless. Talk about situations and systems, not individual wrestlers.
- Timebox each round so the session doesn't go into overtime.
- Use anonymous entries in TeamRetro so quieter team members get a turn in the spotlight.
- Turn the best Tag-Team Plays into actions with owners, so good ideas don't get left on the mat.
- Don't skip the Championship Belt. Recognition is often the part people remember.
## Icebreaker questions
- If you had a wrestling entrance, what song would play and what would your finishing move be called?
- Which fictional or real character would you tag in to help with your hardest task this sprint?
---
# Working, Not Working Retrospective
URL: https://www.teamretro.com/retrospective-templates/working-not-working-retrospective/
The Working, Not Working Retrospective asks your team two questions: what is working, and what isn't? Everything goes into one of two columns, so the meeting is quick to explain and quick to run, and the discussion stays on what the team actually does.
The What is working? column is for practices and habits going to plan, the things worth keeping or doing more of. What is not working? is for the obstacles and frustrations getting in the way. Ask for specific examples in both: "code reviews now catch bugs before release" tells you more than "reviews are good."
It suits teams that want a fast, practical retro, teams new to retrospectives, and moments when a more elaborate format would feel like too much. With only two columns, most of the meeting can go on choosing which problems to fix and agreeing who owns each action.
## Topics
- **What is working?**: What is going to plan?
- **What is not working?**: What is not going to plan?
## When to use
- When you need a quick, clear read on how the team's processes are going
- During a period of change, to see which new approaches are paying off
- When the team feels overloaded and a more elaborate retro format would be too much
- To get straightforward feedback on a recent change or rollout
## Tips and tricks
- Ask for specific, actionable notes. "Reviews are slow" is a complaint; "reviews wait two days for a second approver" is something you can fix
- Invite quieter team members to share first so the loudest voices don't set the agenda
- Use dot voting to pick which Not Working items to tackle first
- Turn the top Not Working items into actions with owners before you close
- Write down what's working so the team can repeat it and share it with other teams
- Check progress on last time's actions at the start of the next retro
## Icebreaker questions
- What's one thing that made your work easier this week?
- If you could instantly fix one thing about our current process, what would it be?
---
# Quarterly Retrospective
URL: https://www.teamretro.com/retrospective-templates/quarterly-retrospective/
The Quarterly Retrospective is a team review built around a three-month cycle. Sprint retrospectives look closely at a couple of weeks of work; this one steps back to look for patterns across several sprints: what's been working, which blockers keep coming back, and whether the team's goals still line up with what the organization needs. Some problems only become visible at that distance.
The board has four questions: What went well?, What didn't go well?, What did we learn? and What will we do differently next quarter? Because the time span is longer, the answers tend to be about systems instead of single events, like a release process that finally stopped causing rollbacks or technical debt that slowed every sprint. That makes it a better place for lasting changes than for quick fixes. The idea of regular reflection comes from the [Agile Manifesto](https://agilemanifesto.org/), and a quarterly session applies it at a longer range.
It works for product teams, engineering squads and leadership groups alike, and lines up naturally with quarterly planning or OKR reviews. In TeamRetro, everyone adds ideas privately, the team votes on what to discuss, and action items carry over so you can check them at the start of next quarter's session.
## Topics
- **What went well?**: What achievements or practices made this quarter a success?
- **What didn't go well?**: What obstacles, frustrations, or failures held the team back this quarter?
- **What did we learn?**: What insights or lessons has the team gained this quarter?
- **What will we do differently next quarter?**: What concrete changes or experiments will the team commit to next quarter?
## When to use
- At the end of each three-month cycle, to look at trends and patterns that sprint retrospectives miss
- When you want your team's improvements to line up with quarterly planning or OKR reviews
- When the same issues keep coming up in sprint retros and never get fully resolved; the longer view helps find the cause
- After an intense or difficult quarter, to acknowledge the effort and reset before the next one
- For distributed or remote teams that need a dedicated moment to step back and reflect together
## Tips and tricks
- **Review your sprint retros first.** Spend a few minutes before the session scanning themes from the past sprints, so you arrive with evidence instead of relying on memory.
- **Timebox each topic.** A quarter is a lot of ground and conversations run long. Give each topic a fixed slot (10–15 minutes works for most teams) and use TeamRetro's timer to stay on track.
- **Prioritize hard.** A quarter generates a lot of material. Have the team vote and spend the discussion on the top 3–5 themes instead of trying to cover everything.
- **Make it safe to be candid.** Quarterly retros can bring up bigger, more sensitive issues. Set ground rules at the start, keep it blame-free and consider anonymous idea submission.
- **Give every action an owner.** Over a longer horizon, actions are easy to forget. Make sure each one has a named owner and a target date, and review them at the start of next quarter's retro.
- **Don't skip the wins.** It's tempting to go straight to the problems, but a full quarter of good work deserves recognition. Start with what went well before moving to the challenges.
## Icebreaker questions
- If you had to describe this past quarter as a weather forecast, what would it be and why?
- What's one word that sums up how you're feeling heading into next quarter?
---
# Baby Steps Retrospective
URL: https://www.teamretro.com/retrospective-templates/baby-steps-retrospective/
Big improvements rarely happen in one go. The Baby Steps retrospective is built on the idea that change sticks when it's small enough to finish. If your team keeps committing to ambitious action items that never quite get done, this format breaks improvement into pieces you can complete in a sprint, and each finished piece builds momentum for the next.
The board has four questions. The first sets an honest baseline of where you are now. The second asks for the smallest step: one tiny change the team could realistically make. The third names the people and resources that will help, and the fourth defines a simple signal that shows whether the step made a difference. Instead of debating large structural changes, the team spends its time on low-effort actions with results it can see quickly, and over several sprints those small steps add up.
Anyone can contribute, because no idea is too small. The format fits agile and Kanban teams, and it works especially well for newly formed teams, teams with change fatigue, or anyone who wants retrospectives that end in actions people actually complete.
## Topics
- **Where are we now?**: What is our current situation or starting point?
- **What's the smallest step?**: What is one tiny change we could realistically make?
- **What support do we need?**: What or who will help us take this step?
- **How do we measure growth?**: What signal will tell us this step made a difference?
## When to use
- Your team has struggled to follow through on large action items and needs something it can finish.
- A newly formed team wants to start improving without feeling overwhelmed.
- The team has change fatigue and needs a few small wins to rebuild confidence.
- You want retrospectives to end with concrete, low-effort next steps.
- The team is adopting agile or Kanban practices and wants regular, incremental improvement built into its routine.
## Tips and tricks
- Keep it small. If a step feels big, break it down until the team could finish it within one sprint.
- Limit the team to one or two baby steps per retrospective so commitments stay realistic.
- Give each step a clear owner so it doesn't slip through the cracks.
- Start each session by checking the last baby steps and celebrating the ones that landed.
- Use dot voting in TeamRetro to choose which step to take first, so the loudest voice doesn't decide.
- Remind the team that no step is too small. A finished small step beats an unfinished big one.
## Icebreaker questions
- What's the smallest habit change you've made that ended up having a surprisingly big impact on your life?
- If you could take one tiny step toward a personal goal this week, what would it be?
---
# SCOR Futurespective
URL: https://www.teamretro.com/retrospective-templates/scor/
The SCOR Futurespective is a planning session that looks forward. Your team examines its Strengths, Challenges, Opportunities and Risks for the work ahead, so you can prepare for situations before they happen. Most retrospectives review what already happened. This one is about the next project, quarter or change.
It follows the shape of a SWOT analysis, with Challenges in place of Weaknesses. Strengths covers the skills, relationships and tools the team can count on. Challenges is for the difficulties you expect to face, Opportunities for what you could take advantage of given those strengths, and Risks for what might go wrong and how to reduce it.
Run it before a new project starts, during strategic or quarterly planning, or when the organization is about to change. The output is a short list of actions: a way to use each major opportunity and a mitigation for each serious risk, each with an owner.
## Topics
- **Strengths**: What major strengths do we have?
- **Challenges**: What difficulties or threats could we face?
- **Opportunities**: What can we capitalize on based on our strengths?
- **Risks**: What risks lie ahead and how can we reduce them?
## When to use
- Before a new project or initiative starts, to check readiness and spot challenges early
- During strategic planning, to agree on where the team is heading and what could get in the way
- Before a significant organizational change, to work out its impact and what to prepare
- In quarterly planning, to adjust strategy as new trends and challenges appear
## Tips and tricks
- Start with strengths so the team has some confidence before it gets to challenges
- Use dot voting to pick the most important items in each category
- Ask people to think past the next sprint to longer-term effects
- Create a specific action for each major risk and opportunity
- Keep past SCOR boards and review them to see how your predictions played out
- Spend your time on things the team can act on, not circumstances it can't change
## Icebreaker questions
- If you could time travel five years into the future, what's one thing you'd want to know about our team/project?
- What's one skill you think our success will depend on in the coming year?
---
# Marketing Team Retrospective
URL: https://www.teamretro.com/retrospective-templates/marketing-team-retrospective/
Marketing moves fast. Campaigns launch, content ships, metrics roll in, and the next quarter has started before anyone has looked back. The Marketing Team Retrospective gives your team a set time to do that: to work out what landed with your audience, which channels earned their budget and where effort was wasted.
The board has four columns. Campaigns that delivered is for the wins worth repeating, tied to numbers like engagement, conversions or pipeline. What slowed us down covers approvals, unclear briefs, late changes and other friction, kept to process and not people. Experiments and learnings captures what you tested and what the results taught you, including the tests that failed. Ideas for next cycle turns all of it into a few changes with owners.
Marketing spans content, brand, demand generation, social, design and analytics, so invite all of them, since each sees a different part of the customer's path. A campaign retrospective reviews one campaign. This format looks at how the team worked across a whole cycle, so it suits a monthly or quarterly rhythm.
## Topics
- **Campaigns that delivered**: Which campaigns or content performed best, and why?
- **What slowed us down**: What blockers, bottlenecks, or friction held the team back?
- **Experiments and learnings**: What did we test, and what did the results teach us?
- **Ideas for next cycle**: What should we start, prioritize, or improve going forward?
## When to use
- At the end of a major campaign or product launch, to capture what worked while it's fresh.
- As a regular monthly or quarterly check-in for the marketing team.
- When collaboration between content, design, demand generation and analytics needs a closer look.
- After a period of missed targets or process friction, to find the bottlenecks and agree on fixes.
- When starting a new marketing initiative or rhythm and you want a shared view of priorities.
## Tips and tricks
- Share key campaign metrics and dashboards before the session, so the conversation starts from data.
- Invite people from across marketing (content, brand, design, demand gen and analytics) so you see the whole customer journey.
- Keep feedback on campaigns, processes and channels, not individuals.
- Timebox each column so you leave time to agree on actions, not just collect observations.
- Use anonymous brainstorming in TeamRetro to get honest input, especially about what slowed the team down.
- Give every action an owner and a due date, and check them at the next retro.
## Icebreaker questions
- What's the best piece of marketing you've seen from another brand this month (an ad, campaign, or post)?
- If our team had a tagline that summed up this quarter, what would it be?
---
# State of Nirvana Futurespective
URL: https://www.teamretro.com/retrospective-templates/state-of-nirvana-futurespective/
The State of Nirvana Futurespective looks forward instead of back. Your team first agrees what its ideal state would look like, its own version of nirvana, then works backward to decide what has to happen by month 1, month 3, month 6 and month 10 to get there.
The board has five columns. Our definition of Nirvana holds the vision: zero incidents on deploy, a sustainable pace, customers who recommend you unprompted. The four time columns turn that vision into steps, starting with quick wins in the first month and building to the bigger changes that take most of a year.
Working backward from an end state (a planning technique often called backcasting) makes long-term goals feel reachable, because each column only asks what's next. Use it at the start of a planning cycle, before a major initiative, or when the team feels stuck repeating the same sprint and needs a direction to aim at.
## Topics
- **Our definition of Nirvana**: The ultimate state we want to be in.
- **1 month**: Things to do by month 1
- **3 months**: Things to do by month 3
- **6 months**: Things to do by month 6
- **10 months**: Things to do by month 10
## When to use
- When the team needs to agree on long-term goals and a shared picture of where it's heading
- At the start of a planning cycle or a major new initiative
- When the team feels stuck and needs a direction to aim at
- Before a large change program, to map the steps in order
## Tips and tricks
- Treat the vision phase as a space where no idea is too ambitious, so people say what they actually want
- Timebox each column so the later time periods get as much attention as the first
- Write each step as a concrete, measurable action rather than a vague aspiration
- Revisit the plan every month or two and adjust the timeline as things change
- Keep the nirvana definition somewhere the team sees it, so day-to-day choices can point back to it
- Note any outside dependencies that could push a step back
## Icebreaker questions
- If you could instantly master one skill or technology, what would it be and why?
- What's one thing you wish you could automate away in your daily work?
---
# Easter Retrospective
URL: https://www.teamretro.com/retrospective-templates/easter-retrospective/
The Easter Retrospective draws on the Easter themes of renewal and hope. It gives your team a reflective way to look back at a stretch of work: what has changed for the better, and what you're hoping for next.
The board has four columns. New Life is for signs of renewal and growth, in your processes, your relationships or your own skills. Victory covers the obstacles and challenges the team overcame. Hope looks ahead to opportunities you want to pursue. Easter Eggs collects the unexpected discoveries and pleasant surprises from the period.
It suits the Easter season or the end of a hard stretch, when the team could use a session that's more about recovery than fault-finding. Use the themes as a light seasonal metaphor so everyone can take part comfortably, whatever their beliefs, and finish by turning the Hope column into a few concrete actions.
## Topics
- **New Life**: What signs of renewal and transformation have you observed?
- **Victory**: What obstacles or challenges have we overcome?
- **Hope**: What opportunities for growth and improvement do you see ahead?
- **Easter Eggs**: What unexpected discoveries or pleasant surprises have we encountered?
## When to use
- Around Easter, when your team wants a seasonal retro about renewal and fresh starts.
- After a hard period, when the team needs to focus on what's ahead.
- When you want to celebrate wins and growth while planning the next improvements.
## Tips and tricks
- Make it clear people can share professional or personal growth, whichever they're comfortable with.
- Use the Easter themes lightly to frame the discussion about renewal and change.
- Give past challenges and future hopes roughly equal time.
- Present Easter as a seasonal theme so everyone can join in, whatever their religious beliefs.
- Finish with a few practical actions from the Hope column, each with an owner.
## Icebreaker questions
- What's something in your work or life that has recently been renewed or transformed?
- When did you last overcome a significant challenge and come out stronger?
---
# Fostering an Inclusive Workplace Retrospective
URL: https://www.teamretro.com/retrospective-templates/fostering-an-inclusive-workplace/
The Fostering an Inclusive Workplace retrospective gives your team a structured way to talk about diversity, equity and inclusion (DEI) in how you actually work together. Instead of reviewing a sprint, people look at whose voices get heard, how opportunities are shared out and what makes it safe, or unsafe, to speak up.
The board has five topics: Diversity Perspectives, Equitable Opportunities, Inclusive Practices, Psychological Safety, and Allyship and Advocacy. Each prompt points the conversation at one part of inclusion, so the discussion moves from general goodwill to things your team can change. Anonymous contributions matter here, because some experiences are hard to share with your name attached.
The aim is a short list of actions with owners, like rotating who leads meetings or writing down promotion criteria, that you check on at the next retro. Agreeing that inclusion matters is easy. The point of this format is to agree on what changes next week.
## Topics
- **Diversity Perspectives**: How well does our team draw on its different perspectives?
- **Equitable Opportunities**: How can we make opportunities fair for everyone?
- **Inclusive Practices**: What inclusive practices can we adopt or improve?
- **Psychological Safety**: How can we make it safer to speak up?
- **Allyship and Advocacy**: How can we become better allies and advocates?
## When to use
- When you want to check and improve how inclusive your team's everyday practices are.
- After noticing bias, microaggressions or a lack of representation in the team.
- As a regular check-in, for example once a quarter, to keep inclusion on the agenda.
- When new people join the team and you want them to feel welcome from the start.
- After an organizational change or DEI initiative, to hear how it's landing with your team.
## Tips and tricks
- Agree on ground rules at the start so people know their experiences will be treated with respect.
- Listen without interrupting or dismissing views that differ from your own.
- Watch for your own assumptions, and ask questions before drawing conclusions.
- Offer anonymous contributions and respect confidentiality, since some people will only share sensitive experiences privately.
- Keep the focus on actions and fixes, not blame.
- Follow up on the actions at your next retrospective so people can see that something changed.
## Icebreaker questions
- If you could invite any historical figure to dinner, who would it be and why?
- What's a skill or talent you possess that might surprise others on the team?
---
# Weather Report Retrospective
URL: https://www.teamretro.com/retrospective-templates/weather-report-retrospective/
The Weather Report Retrospective asks each person to describe the last sprint or work period as weather. Calling a week stormy is easier than saying it went badly, so people share how things felt as well as what happened, and hard topics come up without anyone sounding confrontational.
The board has four areas. Stormy is for turbulent, high-impact problems like outages or conflict. Rainy covers interruptions that slowed the team down but were worth it, such as training or a migration. Cloudy is for uncertainty that could go either way, and Sunny is for what clearly went well.
The Rainy column is what sets this format apart: it gives the team a place for disruptive work that paid off, which a plain good-and-bad split tends to lose. If you run it every few sprints, the weather pattern also shows how team mood is trending.
## Topics
- **Stormy**: Turbulent
- **Rainy**: Interruptive
- **Cloudy**: Promising
- **Sunny**: Cheerful
## When to use
- When you want people to talk about how the work felt, not only what happened
- During a period of change or uncertainty, to check how the team is coping
- With teams that find direct feedback hard, since a weather word is an easier way in
- When the usual format has gone stale and you want a quick read on team morale
## Tips and tricks
- Ask each person why they picked a particular kind of weather; the reason is where the conversation is
- Follow up with "what would improve the weather here?" to move from feelings to actions
- Track the weather over several retrospectives to spot trends in team mood
- Let people use more than one kind of weather when a situation was mixed
- Accept every weather report without judgment, so people keep reporting honestly
- Use the metaphor for the wider organizational climate too, not only the team's own work
## Icebreaker questions
- If your perfect workday was a type of weather, what would it be and why?
- What's your favorite kind of weather for being productive?
---
# Air Travel Journey Retrospective
URL: https://www.teamretro.com/retrospective-templates/air-travel-journey-retrospective/
Picture your last sprint or project as a flight. There's preparation on the ground, a takeoff, some turbulence along the way and, with luck, a smooth landing. The Air Travel Journey retrospective uses that familiar sequence to help your team look back at the whole project, from the first day to the last, and find what carried you forward and what shook things up.
Each column is a phase of the flight. Takeoff is about how you started and what built early momentum. Turbulence covers the obstacles and surprises. Cruising Altitude is for what kept things running smoothly, and Landing looks at how you finished and what you delivered. Because the phases follow the order of the project, people remember the early weeks as well as the last few days, and quieter team members get a clear, low-pressure structure to contribute to.
It suits agile teams, project groups and anyone who wants a change from the standard retro. The flight gives the team a shared story to tell, and it ends where a retro should, with concrete actions to make the next trip smoother.
## Topics
- **Takeoff**: What gave us a strong start and momentum?
- **Turbulence**: What disruptions or obstacles shook us up?
- **Cruising Altitude**: What kept things running smoothly along the way?
- **Landing**: How did we finish and what did we deliver?
## When to use
- At the end of a sprint or project, to look back on the whole thing from start to finish.
- When you want a metaphor-based alternative to a standard went-well, needs-improvement retro.
- After a bumpy or eventful delivery, to work out what caused the turbulence and how to avoid it next time.
- When you're introducing a team to retrospectives and need a framework that's easy to pick up.
- To celebrate a successful launch while still capturing honest lessons.
## Tips and tricks
- Set the scene by asking the team to picture the project as a flight. People find it easier to contribute once they can see the picture.
- Timebox each phase so the conversation moves from takeoff to landing without getting stuck in turbulence.
- Ask for specifics in Turbulence, so each blocker becomes a clear improvement instead of a vague complaint.
- Keep the tone blameless: talk about the journey and the system, not individuals.
- Use grouping and voting in TeamRetro to find the themes that matter most before you agree on actions.
- Capture concrete action items for the next flight so the retro leads to real change.
## Icebreaker questions
- What's the most memorable flight you've ever taken, and why?
- If your last sprint were a flight, would it have been smooth, bumpy, or a white-knuckle ride?
---
# Four Ls Retrospective
URL: https://www.teamretro.com/retrospective-templates/4ls-retrospective/
The 4Ls retrospective asks your team four questions about the last sprint: what you Liked, what you Learned, what you Lacked and what you Longed for. Mary Gorman and Ellen Gottesdiener developed the format, and it's a common pick for Scrum Masters because it's easy to explain and covers facts and feelings in one session.
Liked and Learned bring out the good news: the practices worth keeping and the lessons the team picked up along the way. Lacked and Longed for point at what was missing and what people wish they'd had, which is usually where your next actions come from.
Giving Learned its own column means lessons get written down instead of getting lost among the wins. And because Longed for is framed as a wish, people can raise a gap without it sounding like a complaint.
## Topics
- **Liked**: What did we like about the last sprint?
- **Learned**: What did we learn from the last sprint?
- **Lacked**: What do we think was missing from the last sprint?
- **Longed for**: What could we have done better in the last sprint?
## When to use
- When you want a balanced look at what went well and what needs work
- In regular sprint retrospectives, when you want feedback on both the work and the way the team worked
- When new team members are joining their first retrospectives, since the four categories are easy to follow
- When the team needs some structure to sort its thoughts before discussing them
## Tips and tricks
- Start with Liked to warm the room up before moving on to what was missing
- Timebox each L so one category doesn't take over the session
- Ask for specific examples, since a named problem is easier to act on than a general complaint
- Look for patterns across the four columns, such as a Lacked item that explains something people Longed for
- Write actions that close the gaps in Lacked and Longed for, and keep doing what people Liked
- Use dot voting to decide which items to tackle first
## Icebreaker questions
- If you could instantly master one new skill that would help the team, what would it be and why?
- What's one thing you learned recently that surprised you?
---
# Mission: Agile Possible Retrospective
URL: https://www.teamretro.com/retrospective-templates/mission-agile-possible-retrospective/
Mission: Agile Possible turns your sprint review into a mission debrief. Team members report back like field agents: what went to plan, where they ran into resistance, what intelligence they picked up and what the next operation should be. The spy framing gives a familiar meeting some energy, and every column still asks a standard retrospective question.
The board has four columns. Mission Accomplished collects the objectives the team completed. Enemy Encounters covers the threats, blockers and obstacles you ran into. Classified Intel holds what you learned or discovered, and Next Mission Briefing is where you plan actions for the next sprint. Calling problems "enemy encounters" makes them easier to raise than calling them failures, so risks that might otherwise go unsaid end up on the board.
Use it for a regular sprint retrospective or whenever the team wants a change from its usual format. Scrum Masters and facilitators get a structure that takes a minute to explain, and the meeting ends the way a good debrief should: with owned actions for the next mission.
## Topics
- **Mission Accomplished**: What objectives did we successfully complete this sprint?
- **Enemy Encounters**: What threats, blockers or obstacles did we run into?
- **Classified Intel**: What did we learn or discover during this mission?
- **Next Mission Briefing**: What actions and improvements should we plan for next time?
## When to use
- When your sprint retrospectives have become routine and the team needs a new format to get people talking again.
- At the end of a sprint or project milestone, when you want to cover both the wins and the blockers.
- When problems feel tense to discuss and a playful, blame-free frame makes them easier to raise.
- For teams that enjoy themed meetings and respond well to a bit of story.
- With a new agile team that needs an approachable retrospective that still covers the essentials.
## Tips and tricks
- Open with a short mission briefing to set the tone and get everyone into character.
- Let the theme be fun, but check that every item links back to something real the team can act on.
- Timebox each column so you keep a steady pace and leave enough time for action planning.
- Remind quieter team members that every agent's intel counts, and give them space to add it.
- Group similar ideas before voting so the discussion goes to the biggest threats and lessons.
- Close with clear actions from Next Mission Briefing, each with an owner, so something changes before the next debrief.
## Icebreaker questions
- If you were a secret agent, what would your codename and signature gadget be?
- What's the most 'mission impossible' task you've ever managed to pull off at work?
---
# Budget Planning Futurespective
URL: https://www.teamretro.com/retrospective-templates/budget-planning-futurespective/
The Budget Planning Futurespective is a planning session for the start of a budget cycle. Instead of looking back at the last sprint, your team looks ahead: where should money and effort go next, and what should you stop paying for? Getting those ideas on the board before the numbers are locked in means the budget reflects what the people doing the work think matters.
The board has four sections. Strategic Initiatives is for new projects worth funding. Revenue Streams looks at where growth will come from, whether existing or new. Cost Optimization covers savings and simpler ways of operating. Growth Investments is for longer-term bets such as technology, training and research. Everyone adds ideas privately, then the team groups them and votes so the strongest ones rise to the top.
The format pairs a futurespective, which imagines a future and plans back from it, with ordinary budget planning. Bring the data people need to judge each idea, such as current spend and revenue figures, and agree on your decision criteria before anyone votes.
## Topics
- **Strategic Initiatives**: What new initiatives or projects should we prioritize in the upcoming budget cycle?
- **Revenue Streams**: What existing or new revenue streams should we focus on to drive growth?
- **Cost Optimization**: Where can we cut costs or simplify operations to improve profitability?
- **Growth Investments**: What investments should we make to fuel long-term growth and competitiveness?
## When to use
- When preparing for a budget cycle and you need agreement on priorities.
- During long-term planning, to look at the opportunities and challenges ahead.
- As part of a periodic review of how resources are allocated.
- When you're weighing a major investment, expansion or change in strategy.
- When a budget decision affects several departments and you want them in the same conversation.
## Tips and tricks
- Ask people to think beyond the current fiscal year.
- Share relevant data, such as current spend and revenue trends, before the session so ideas rest on facts.
- Invite people from different roles and departments so you see the whole organization's needs.
- Prioritize ideas by impact, feasibility and fit with your overall strategy.
- Agree on decision criteria, and on who makes the final call, before you start voting.
- Write down the reasoning behind each budget decision so you can revisit it later.
## Icebreaker questions
- If you had an unlimited budget for one year, what would be your top priority for investment?
- Share a time when a strategic investment paid off significantly for your organization or team.
---
# 4th of July Celebration Retrospective
URL: https://www.teamretro.com/retrospective-templates/4th-of-july-celebration-retrospective/
The 4th of July Celebration retrospective borrows Independence Day as the theme for a summer retro. Your team celebrates recent wins, names the habits and blockers it wants to be free of, and puts forward a few new ideas to try. It's a seasonal change from your usual format, and it fits the week around the holiday.
The board has four columns. Fireworks is for the wins worth celebrating. Declaration of Independence is for the processes, habits and blockers the team wants to drop. Sparklers holds new ideas worth experimenting with, and Picnic Plans is where you agree on the actions you'll carry forward. The theme keeps the mood light, but each column asks a real question, so the conversation stays honest.
Coming at the end of the first half of the year, it's a natural point to reset priorities and lift morale before the second half. Run it in TeamRetro to collect ideas privately, vote on what matters most and turn the top items into action items with owners.
## Topics
- **Fireworks**: What wins are worth celebrating with a bang?
- **Declaration of Independence**: What should we free ourselves from going forward?
- **Sparklers**: What new ideas could light up our future?
- **Picnic Plans**: What actions will we commit to next?
## When to use
- Around Independence Day or early summer, when you want a themed retro for the season.
- After a major release or milestone the team should celebrate.
- When morale needs a lift and a lighter format would help people open up.
- As a mid-year checkpoint to look at progress and reset priorities for the second half of the year.
## Tips and tricks
- Use the holiday to set the mood, with red, white and blue on the board if you like, but keep the discussion on real issues.
- Start with Fireworks so the team builds some positive energy before it moves to what needs to change.
- Use TeamRetro's anonymous brainstorming so quieter people contribute as freely as everyone else.
- Timebox each column. Holiday weeks are busy, and a session that drags loses people.
- Vote on the ideas before discussion so the team spends its time on the ones that matter most.
- End with a few actions, each with an owner, so the celebration leads to real change.
## Icebreaker questions
- What's your favorite way to celebrate the 4th of July?
- If your last sprint were a firework, what would it look like and why?
---
# Big & Small Perspectives Retrospective
URL: https://www.teamretro.com/retrospective-templates/big-and-small-perspectives-retrospective/
Some of the most useful things a team learns sit at opposite ends of the scale. The Big & Small Perspectives retrospective asks your team to switch deliberately between the wide view and the close-up, so strategic themes and everyday frictions both get a hearing. Teams that stay at one altitude tend to miss patterns that only show up when you move between the two.
The board has four topics: Big Wins, Big Challenges, Small Wins and Small Annoyances. The split keeps the team out of two common traps, getting lost in minor grievances or talking only in abstractions that never turn into action. In TeamRetro, everyone adds ideas at the same time, then the team groups similar themes, votes on what matters most and turns the discussion into action items you can track.
The result is an honest conversation about both the forest and the trees. Use it to reflect on a sprint, a project milestone or a quarter of work. Your team gets to celebrate the big achievements, raise the nagging issues early and decide where to focus next.
## Topics
- **Big Wins**: What major successes or achievements stood out?
- **Big Challenges**: What major obstacles or risks need our attention?
- **Small Wins**: What little victories or improvements made a difference?
- **Small Annoyances**: What minor frustrations or niggles slowed us down?
## When to use
- When your team tends to focus on big-picture themes and overlooks the small frictions in daily work.
- At the end of a sprint, project or quarter, when you want a view of both strategic outcomes and everyday details.
- When morale is low and you want to celebrate small wins alongside major achievements.
- When minor annoyances are quietly building up and you want a structured way to surface and fix them.
## Tips and tricks
- Define the scales at the start: big means strategic or systemic, small means everyday or tactical. That way contributions land in the right topic.
- Timebox each perspective so the team doesn't spend the whole session in one quadrant. Moving between scales is the point.
- Use anonymous contributions in TeamRetro so people name the small annoyances they'd otherwise keep quiet about.
- Group similar ideas before voting to spot patterns that cross both scales.
- Turn the top-voted items into action items with owners. Small annoyances are often quick wins worth fixing right away.
- Rotate the facilitator so different people get practice balancing the two scales.
## Icebreaker questions
- If you could zoom out to see your whole year so far, what's the one big highlight that stands out?
- What's a tiny thing, like a coffee or a shortcut, that made your day better recently?
---
# Studio Ghibli Journey Retrospective
URL: https://www.teamretro.com/retrospective-templates/studio-ghibli-journey-retrospective/
The Studio Ghibli Journey retrospective borrows the shape of a Hayao Miyazaki film, the kind of story told in Spirited Away or My Neighbor Totoro. A hero sets out, meets strange spirits and hard trials, finds unexpected helpers, and comes home changed. Your team tells the story of its last sprint or project the same way.
The board has four columns. Magical Moments is for the wins and breakthroughs that gave people energy. Spirits & Obstacles holds the blockers and frustrations. Friendly Companions recognizes the people, tools and habits that helped. The Road Ahead turns the story into lessons and owned actions for the next sprint.
The gentle tone of the theme makes it easier to name a struggle kindly, and the Friendly Companions column gives thanks a proper place on the board instead of a rushed minute at the end. Use it after a long or hard sprint, or when your regular format has gone stale and quieter people have stopped contributing. Nobody needs to have seen the films; each column has a plain prompt.
## Topics
- **Magical Moments**: What brought joy and wonder this journey?
- **Spirits & Obstacles**: What challenges or blockers did we face?
- **Friendly Companions**: Who or what helped us along the way?
- **The Road Ahead**: What lessons will we carry into the next adventure?
## When to use
- When your team needs a creative break from the standard retrospective format and still wants actions at the end.
- At the end of a long or difficult sprint or project, when people need to look back with some kindness.
- When quieter team members have stopped contributing and a relaxed, story-based format might bring them back in.
- When you want to celebrate a milestone alongside an honest look at what was hard.
## Tips and tricks
- Set the mood at the start with a Ghibli still or some quiet film music as people join.
- Keep the story light so people who don't know the films can still join in.
- Timebox each column so you leave time for actions in The Road Ahead.
- Use anonymous brainstorming for Spirits & Obstacles so people feel safe naming hard problems.
- Give every action in The Road Ahead an owner.
- Don't rush Magical Moments. Taking time over the wins keeps people motivated.
## Icebreaker questions
- If you could live in any Studio Ghibli world for a day, which one would you choose and why?
- Which Ghibli character best represents how you felt during this sprint?
---
# Captain America's Agile Mission Retrospective
URL: https://www.teamretro.com/retrospective-templates/captain-america-agile-mission-retrospective/
Captain America's Agile Mission retrospective treats your last sprint or project as a mission. The theme borrows from the comic-book hero known for leading a team and carrying a shield, and it asks your team to look at what it won, what protected it, what fought against it and what the plan is for next time.
The board has four areas. Mission Victories is for wins, big and small. The Shield covers the practices and habits that kept the team safe, such as test coverage or a good incident playbook. Enemy Forces collects the blockers, from unclear requirements to flaky pipelines. Next Mission turns the discussion into a short plan of attack with owners.
Casting obstacles as enemies the whole team fights together keeps the conversation blameless, and the theme gives a routine retro some energy. Use it to close a sprint or project, or when a newly formed team needs a sense of shared purpose.
## Topics
- **Mission Victories**: What battles did we win this mission?
- **The Shield (What Protected Us)**: What strengths and practices kept us safe?
- **Enemy Forces (Obstacles)**: What threats slowed our advance?
- **Next Mission (Plan of Attack)**: What's our strategy for the next mission?
## When to use
- When morale needs a lift and you want a themed way to celebrate wins.
- At the end of a sprint or project, to review victories, defenses and obstacles.
- When the team has faced serious blockers and you want to treat them as shared enemies to tackle together.
- For newly formed or cross-functional teams that need a sense of shared mission.
## Tips and tricks
- Use the mission theme to keep energy up, but tie every discussion back to something the team can act on.
- Frame obstacles as enemy forces the team fights together, which keeps feedback blameless.
- Use dot voting to prioritize the victories, threats and next actions that matter most.
- Give each Next Mission action an owner and a due date so it doesn't get lost after the session.
- Make room for quieter team members to add their wins and concerns.
- Timebox each topic so you have enough time left to agree on your plan of attack.
## Icebreaker questions
- If you could have one of Captain America's qualities (strength, leadership, or that unbreakable shield), which would help your team most right now?
- What's a superhero team-up (real or fictional) that reminds you of how this squad works together?
---
# Idea Storm
URL: https://www.teamretro.com/retrospective-templates/idea-storm-retrospective/
Idea Storm is a brainstorming session for generating a lot of ideas in a short time. Use it when you're stuck on a tricky problem, exploring new product features or just need fresh thinking. Everyone contributes without judgment first, and the sorting comes later, so people build on each other's ideas instead of shooting them down.
The board gives you six different angles on the problem. Wild Ideas removes every constraint, Tiny Tweaks looks for quick fixes and Opposite Thinking flips your usual approach. Borrowed Brilliance takes ideas from other industries and products, One-Sprint Experiments turns ideas into tests you can run straight away, and Future Us looks back from a successful year ahead. Generating first and then grouping and voting keeps early criticism from shutting ideas down. That principle of deferring judgment comes from Alex Osborn, the advertising executive who popularized brainstorming.
In TeamRetro everyone adds ideas at the same time and anonymously, so the loudest voice doesn't set the direction and quieter team members get an equal say. You finish with a long list of possibilities, a short list of favorites and clear next steps.
## Topics
- **Wild Ideas**: What bold, no-limits ideas could we imagine if anything were possible?
- **Tiny Tweaks**: What small improvements could we try quickly and easily right now?
- **Opposite Thinking**: What if we reversed our usual approach? What would we do instead?
- **Borrowed Brilliance**: What great ideas could we borrow from other teams, industries, or products?
- **One-Sprint Experiments**: What safe experiments could we test within a single sprint?
- **Future Us**: Looking back from future success, what ideas got us there?
## When to use
- When your team faces a problem with no obvious solution and needs a fresh set of ideas.
- At the start of a new project or feature, to gather possibilities before narrowing down.
- When the same few voices keep dominating and you want everyone's ideas on the board.
- Ahead of planning sessions, to build a backlog of options to prioritize.
- Whenever the team needs to break out of its usual way of thinking.
## Tips and tricks
- Hold all criticism until the grouping and voting stages. No idea gets dismissed while people are still generating.
- Start with a clear, focused prompt so everyone knows which problem they're solving.
- Go for quantity early on. More ideas give you more raw material to build on later.
- Use anonymous contributions so quieter team members and junior staff feel safe sharing bold ideas.
- Timebox each phase to keep the energy up and stop the session from dragging.
- Close with concrete next steps and owners so good ideas don't disappear after the meeting.
## Icebreaker questions
- If you could instantly master any skill to solve a problem at work, what would it be?
- What's the most creative solution you've ever come up with for an everyday annoyance?
---
# Soccer Retrospective
URL: https://www.teamretro.com/retrospective-templates/soccer-retrospective/
The Soccer Retrospective reviews your sprint the way a coach reviews a match. Soccer (or football, depending on where your team is) gives everyone a shared language for what happened: the goals you scored, the penalties you gave away, the saves that kept you in it and the walls you couldn't get past.
The board has four areas. Goals is for achievements, big and small. Penalties covers what didn't go to plan, and Saves is for the problems the team caught before they caused damage. Walls is for the obstacles that blocked progress, especially the ones outside the team that need escalating.
Saves is what sets this format apart: it gives credit for prevention, which usually goes unnoticed. Use it after a milestone or release, or whenever a sports-minded team needs a change from its usual retro. Keep the theme light and finish with a few specific actions, each with an owner.
## Topics
- **Goals**: What achievements are we proud of?
- **Penalties**: What did not go to plan?
- **Saves**: What issues did we prevent?
- **Walls**: What things got in our way?
## When to use
- When you want a livelier retrospective for a team that follows sports
- After a major milestone or release, to look back at how the team performed
- When team morale needs a lift and a more playful format would help
- When your usual format has gone flat and the meeting needs some energy
## Tips and tricks
- Keep the soccer metaphor fun, but don't let it crowd out the reflection
- Use 'passing the ball' to take turns, so everyone gets a chance to share
- Set a timer for each section to keep a good match pace
- Use real soccer or football terms where they fit the discussion
- Give Goals and Penalties similar time, so celebration and criticism stay in balance
- Make each action as clear as a set piece: who does what, and by when
## Icebreaker questions
- If our team were a soccer/football team, what would be our team name and why?
- What's your most memorable moment as part of a team (sports or otherwise)?
---
# What? So What? Now What? Retrospective
URL: https://www.teamretro.com/retrospective-templates/what-so-what-now-what-retrospective/
What? So What? Now What? is a reflection model set out by Rolfe et al. (2001) that splits a retrospective into three questions. Your team describes what happened, works out why it matters, and then decides what to do about it. Taking the questions in order stops the group from jumping to solutions before it agrees on the facts.
In the What? column, people describe events and observations without judging them: velocity dropped, three people were pulled onto support, the release shipped with 15 bugs. So What? is where the team interprets those facts and talks about their impact. Now What? turns that analysis into specific actions with owners.
It works best for complex or messy situations, such as a difficult release or a period of change, where people see the same events differently. Agreeing on the facts first gives the later discussion a common starting point.
## Topics
- **What?**: How would you describe the situation?
- **So What?**: How does this affect us?
- **Now What?**: What do we need to do to move forward?
## When to use
- After a big milestone or release, to look at what actually happened before deciding what to change
- When a problem is complex and the team keeps jumping to fixes before agreeing on the facts
- During organizational change, to help the team make sense of a new situation and decide how to respond
- When retros stay at surface-level observations and you need to get to causes and concrete actions
## Tips and tricks
- Keep the What? column to facts and observations. Save interpretation for So What?
- Timebox each stage so So What? doesn't eat the time you need for Now What?
- Use round-robin or written notes so quieter team members get heard
- Link each action in Now What? back to an observation in What?, so you know what it's meant to fix
- Give every action a specific owner and a deadline
- Dot-vote on the So What? notes to pick the two or three worth acting on
## Icebreaker questions
- What's the most surprising thing you learned last week?
- If you could instantly master one new skill, what would it be and why?
---
# Dog Day Demo Retrospective
URL: https://www.teamretro.com/retrospective-templates/dog-day-demo-retrospective/
The Dog Day Demo Retrospective uses dogs as a light metaphor for how your team worked this sprint. Some sprints feel like a walk in the park, others like a chase after a squirrel, and the theme gives people an easy way into talking about both.
The board has four columns. The first is for the wins that deserve a pat on the head. Bad Habits covers the frustrations and patterns that keep tripping the team up. Fetch More is for the things you want more of. New Tricks is where you pick small experiments to try next sprint.
The theme keeps the mood light, but underneath it's a standard retrospective that ends in agreed changes. Use it when your usual format has gone stale or the team needs a lift after a hard sprint, and make sure New Tricks ends with actions that have owners.
## Topics
- **Good Boy**: What did the team do brilliantly this time?
- **Bad Habits**: What behaviors or issues kept tripping us up?
- **Fetch More**: What should we go get more of next time?
- **New Tricks**: What new approaches should we try next sprint?
## When to use
- When morale needs a lift and the usual retrospective format feels stale.
- After an intense or stressful sprint, when a lighter theme makes it easier for people to open up.
- For teams that enjoy a themed retro and still want real outcomes from it.
- Around a company dog day, a team celebration or another special occasion.
- When new team members might find it easier to speak up in a relaxed setting.
## Tips and tricks
- Use the theme to keep things light, but make sure every column leads somewhere useful.
- Timebox each column so the jokes don't crowd out the discussion.
- Have everyone add ideas before the discussion starts, so quieter people aren't drowned out.
- Group similar ideas and vote on the most important ones, so the team spends its time on what matters.
- Close by turning New Tricks into actions with owners. Otherwise the experiments never happen.
- Invite people to share a photo of their pet at the start. It's an easy icebreaker for remote teams.
## Icebreaker questions
- If your last sprint were a dog, what breed would it be and why?
- What's the best trick you've ever taught yourself (or your pet)?
---
# Agile Retrospective
URL: https://www.teamretro.com/retrospective-templates/agile-retrospective/
An agile retrospective asks four plain questions: what went well, what went less well, what you want to try next, and what still puzzles you. Together they get your team talking about how the last sprint went and which actions to focus on in the next one.
The format is simple on purpose. Running it tells your team you're listening and that you intend to act on what they say. The retrospective practice itself is described in *Agile Retrospectives*, the book by Esther Derby and Diana Larsen (with a foreword by Ken Schwaber), and it works like a regular tune-up that keeps your team running well.
Held every sprint, the retro surfaces problems in how you build and ship software while they're still small, and gives your team a set time to fix them together.
Short, regular retros with documented actions let you change course before it's too late. Steering a big ship works the same way: small corrections along the route are easier than finding out at the end that you've docked in the wrong port. A post-mortem looks back once a project is over. An agile retrospective looks ahead to the next sprint, so the tone stays positive and practical.
## Topics
- **What went well?**: Things we are happy about.
- **What went less well?**: Things we should improve.
- **What do we want to try next?**: Things we should do differently.
- **What puzzles us?**: Unanswered questions we have.
## When to use
- At the end of each sprint or iteration to reflect on the past cycle.
- When your team wants to pin down specific things to improve.
- After a major project milestone or release to discuss lessons learned.
- Whenever your team feels stuck and needs to get back on track.
- During an agile transformation, to make regular reflection a habit for every team.
## Tips and tricks
- Set a blame-free tone at the start so people speak openly.
- Timebox each section so the retro stays focused.
- Get input from everyone, not only the vocal few. A few minutes of silent brainstorming helps.
- Capture action items and give each one an owner who follows up.
- Don't try to solve every issue. Pick the top one or two and run small experiments.
- Rotate the facilitator role so you get fresh perspectives.
## Icebreaker questions
- If you could add one tool or process to help our team, what would it be?
- What's one small thing that could have a big positive impact on our team?
---
# Lost in the Matrix Retrospective
URL: https://www.teamretro.com/retrospective-templates/lost-in-the-matrix-retrospective/
Lost in the Matrix borrows the setup of the 1999 sci-fi film: a choice between a comfortable illusion and an uncomfortable truth. In this retrospective, your team uses that choice to talk about the gap between how you say you work and how you actually work. It's good at surfacing the assumptions nobody has questioned in a while.
The board has five columns. The Blue Pill is for the comforting stories the team tells itself, like promising to fix the tech debt next sprint. The Red Pill is for the truths people have been holding back. Glitches in the System collects the disruptions that keep coming back, and The Agents names the outside pressures and constraints working against you. The Exit is where the team turns all of that into small, owned actions.
The metaphor gives people a step of distance, so it can be easier to call something a blue pill than to admit the team has been kidding itself. Use it when retros feel repetitive, or when you suspect something important is going unsaid. A one-minute intro to the red pill and blue pill idea is all the background anyone needs.
## Topics
- **The Blue Pill**: What comfortable illusions are we choosing to believe?
- **The Red Pill**: What uncomfortable truths do we need to face?
- **Glitches in the System**: What recurring disruptions keep pulling us off course?
- **The Agents**: What obstacles or forces are blocking our progress?
- **The Exit**: How do we escape and move toward a better reality?
## When to use
- When your retrospectives feel repetitive and you want a fresh format.
- When you suspect hidden assumptions or unspoken truths are affecting the team's work.
- After a hard sprint or project phase, when how things look and how they are seem out of step.
- When you want to surface recurring problems and systemic blockers that standard formats tend to miss.
- For teams that enjoy themed sessions and respond well to a strong metaphor.
## Tips and tricks
- Open with a short intro to the red pill and blue pill idea so everyone understands the metaphor.
- Make it safe to speak. Naming a red-pill truth only works if nobody gets blamed for saying it.
- Keep the focus on systems and patterns, not individuals, especially in The Agents.
- Timebox each column so you don't spend the session debating illusions and run out of time for The Exit.
- Group similar glitches and agents before voting, so recurring themes stand out.
- Close with specific actions that each have an owner, so what you uncovered leads to change.
## Icebreaker questions
- If you could download one new skill instantly like Neo learning kung fu, what would it be?
- Red pill or blue pill: do you prefer the comfortable illusion or the uncomfortable truth, and why?
---
# Minecraft Quest Retrospective
URL: https://www.teamretro.com/retrospective-templates/minecraft-quest-retrospective/
The Minecraft Quest retrospective borrows the world of the block-building game to frame your sprint review. Your team mines the wins, looks at what it crafted, faces the creepers that got in the way and picks the treasure worth digging for next. People who play Minecraft get the references straight away, and people who don't can still follow, because every column has a plain-language prompt.
The board has four columns. Resources Mined holds the wins and achievements. Crafted & Built covers what the team improved and wants to build on. Creepers & Mobs is for the blockers and risks that threatened progress, and Treasure to Seek is where you set goals for the next sprint. The theme keeps the mood light, but each column still asks a real retrospective question, so the feedback you collect is honest and usable.
By the end of the session you have a shared map of where the team has been and a short list of prioritized actions for the next sprint. It works well when your regular format has gone stale, or when a hard sprint calls for a lighter tone without losing the substance. Building software, like building in Minecraft, goes better when the whole team is working on the same map.
## Topics
- **Resources Mined**: What wins and resources did we gather this sprint?
- **Crafted & Built**: What did we build on or improve to level up?
- **Creepers & Mobs**: What blockers or risks threatened our progress?
- **Treasure to Seek**: What goals and treasure do we want to dig for next?
## When to use
- When your team likes themed retrospectives and the usual format has started to feel routine.
- After a hard or intense sprint, when a lighter tone helps people talk honestly about what went wrong.
- With teams that include gamers, or anyone who enjoys a story and a bit of play.
- When new team members join and a low-pressure theme makes it easier for them to speak up.
## Tips and tricks
- Set the scene before anyone writes a note: frame the session as a shared quest so the metaphors land.
- Enjoy the jokes, then steer each playful note back to something specific the team can act on.
- Use Creepers & Mobs to model blameless discussion. Talk about situations, not people.
- Start with private, anonymous brainstorming so quieter team members get their ideas on the board.
- Timebox each column so you reach Treasure to Seek with enough energy left to agree on real actions.
- Vote on the items that matter most so the team leaves with a short, prioritized list for the next sprint.
## Icebreaker questions
- If you could craft any one item from Minecraft to use in real life, what would it be and why?
- Are you more of a careful builder, a fearless explorer, or the one who always falls in the lava?
---
# Olympics Retrospective
URL: https://www.teamretro.com/retrospective-templates/olympics-retrospective/
The Olympics retrospective uses the Olympic Games to frame your team's review. Your team hands out medals for its achievements, recognizes the teammates who showed real Olympic spirit, talks honestly about the stumbles and picks the lessons to carry forward.
The board has four columns. Medals is for achievements. Olympic Spirit is a shout-out to team players. Stumbles covers the things that didn't go to plan, and Olympic Torch holds the lessons to take into the next sprint. Like an athlete reviewing a race, your team looks at the wins and the stumbles side by side.
It suits a milestone, a big release or any time the team needs a morale lift that still includes an honest look at what went wrong. The recognition column also makes it easy to thank the people whose help doesn't show up in the sprint metrics.
## Topics
- **Medals**: Our achievements
- **Olympic Spirit**: Shout out to team players
- **Stumbles**: Things that did not go to plan
- **Olympic Torch**: Learnings to take forward
## When to use
- After a major milestone or release, to celebrate achievements and find what to improve
- When the team needs a morale lift but still wants to talk about where it can grow
- As a team-building session that puts recognition and appreciation first
- When your regular retrospective needs a fresh format, especially while the Olympic Games are on
## Tips and tricks
- Open with a memorable Olympic moment or story to set the tone
- Make sure everyone gets a chance to share their medal-worthy moments
- Use the Olympic spirit theme to keep the mood positive when discussing setbacks
- Run a timer for each column to keep the session moving
- Hand out virtual medals or certificates to recognize standout contributions
- Finish by agreeing on a 'training plan' of specific actions for improvement
## Icebreaker questions
- If you could compete in any Olympic sport, what would it be and why?
- What's your most memorable Olympic moment or inspiration?
---
# Vital Signs: Team Health Check
URL: https://www.teamretro.com/retrospective-templates/vital-signs-team-health-check-retrospective/
The Vital Signs team health check borrows the checks a doctor runs at the start of an appointment. Instead of pulse and temperature for one patient, your team takes four readings on itself: Pulse for energy and morale, Breathing for collaboration and communication, Temperature for trust and psychological safety, and Reflexes for clarity of goals, priorities and roles.
Each person shares where things feel strong and where they feel strained, and the team then looks at why. The medical framing gives people a less personal way to raise sensitive topics, such as stress or a lack of trust, because they're describing a symptom instead of making a complaint.
Run it regularly and you get a baseline to compare against. You can see when a reading improves after an action, and spot early signs of burnout or confusion before they show up in delivery. Each session ends with a short list of treatments: the specific actions the team will take before the next check.
## Topics
- **Pulse (Energy & Morale)**: How energized and motivated does the team feel right now?
- **Breathing (Collaboration & Communication)**: How smoothly are we communicating and working together?
- **Temperature (Trust & Safety)**: How safe do we feel to speak up and take risks?
- **Reflexes (Clarity & Direction)**: How clear are our goals, priorities and roles?
## When to use
- At regular intervals, such as monthly or quarterly, to track team health and catch warning signs early.
- When morale, energy or collaboration seems to be dipping and you can't pin down why.
- After an intense delivery period, a reorganization or a change in team members, to see how people are coping.
- Alongside your delivery-focused sprint retrospectives, to make room for how the team itself is doing.
## Tips and tricks
- Run it on a consistent schedule so you can compare results over time instead of reacting to a single reading.
- Keep ratings anonymous where you can, especially for Temperature, where honesty is hardest.
- Spend most of the time on the reasons behind the scores, and finish with concrete actions.
- Watch for outliers. A wide spread in responses often tells you more than the average.
- Don't turn the results into a performance scorecard, or people will stop being honest.
- Review the previous actions at the start of each check so the team sees that the diagnosis leads to treatment.
## Icebreaker questions
- If your current energy level was a weather forecast, what would today's report say?
- On a scale from 'hospital gown' to 'marathon-ready', how is the team feeling this week?
---
# Lead Generation Strategy Planning
URL: https://www.teamretro.com/retrospective-templates/lead-generation-strategy-planning-retrospective/
Lead Generation Strategy Planning is a session for looking back at your recent lead generation work and deciding what to do differently next. It uses the four questions most teams know from retrospectives and points them at your campaigns, your channels and the hand-off to sales.
Start with the data: leads by channel, conversion rates and what sales said about lead quality. In the first two columns, people add the tactics that worked and the ones that underperformed, like a webinar that filled the pipeline or a paid search campaign that spent a lot and converted little. What did we learn? is where you look for the patterns behind those results, such as content that doesn't match the buyer's stage or a lead scoring model that needs updating. What should we do next? turns those patterns into a short plan with owners and due dates.
Run it at the end of a quarter or campaign, or whenever the market or your product changes enough that last quarter's tactics might not hold.
## Topics
- **What went well?**: Which lead generation tactics were most successful?
- **What didn't go well?**: Which lead gen initiatives underperformed or had challenges?
- **What did we learn?**: What patterns did we notice this period?
- **What should we do next?**: What are our priorities for optimizing lead gen efforts?
## When to use
- At the end of each quarter or campaign, to review performance and adjust your strategy.
- When you launch a new lead generation initiative, to set a baseline and spot opportunities.
- After a major change in your market, product or business that affects how you find leads.
- When stakeholders need to agree on changes to how leads are managed and handed over.
## Tips and tricks
- Bring lead generation metrics and performance data so the discussion starts from facts.
- Invite everyone involved in lead gen, from content and paid media to sales development.
- Capture ideas on the board as you go, so nothing raised in discussion gets lost.
- Give every action an owner, a due date and a measure of success.
- Book a follow-up session to check progress on your updated plan.
## Icebreaker questions
- If you could generate leads from any celebrity endorsement, who would you choose?
- What's the craziest lead generation idea you've ever heard of or tried?
---
# Product Development Process
URL: https://www.teamretro.com/retrospective-templates/product-development-process/
The Product Development Process retrospective looks at how your organization builds products from end to end, not at the last sprint. It covers the whole lifecycle, from requirements and design through development, testing, release and what happens after, and asks whether that process still serves the product you're trying to build.
The board has five areas. Process Alignment asks whether the way you work supports your product vision and goals. Process Efficiency looks for bottlenecks, such as slow handoffs between design and engineering or a testing phase that always gets squeezed. Cross-Functional Collaboration covers how product, design, engineering and other groups work together. Data-Driven Decisions asks whether you have the metrics to judge your process and whether anyone uses them. Innovation and Growth asks whether the process leaves room to experiment.
Run it every quarter or after a major release, with people from every function that touches the product. The useful output is a short list of process changes, each with an owner, that the next quarter's review can check on.
## Topics
- **Process Alignment**: How well does our current process support our product vision and goals?
- **Process Efficiency**: What bottlenecks or inefficiencies exist in our current process?
- **Cross-Functional Collaboration**: How effectively do teams collaborate across functions and disciplines?
- **Data-Driven Decisions**: How well do we use data and metrics to inform our process?
- **Innovation and Growth**: How well does our process make room for new ideas and improvement?
## When to use
- When you want to judge how well your product development lifecycle works as a whole
- When the same bottlenecks keep showing up and sprint retros haven't fixed them
- Before you introduce a new development methodology or make a big change to your current process
- Every quarter or after a major release, as a regular process review
- When product, design and engineering see the development process differently and need a shared picture
## Tips and tricks
- Ask for candid feedback from everyone, whatever their role or seniority
- Make sure every team and function involved in product development is represented
- Help the team see the forest, not just the trees: think about the process over months, not only the last sprint
- Keep it blame-free so people can talk openly about challenges and failures
- Pick the few improvements that matter most and agree on a clear plan for each
- Use TeamRetro's propose ideas feature so people can suggest changes, and get the team's buy-in before committing to an action
## Icebreaker questions
- If our product development process were an animal, what animal would it be and why?
- Share a funny or memorable experience from your time working on product development.
---
# Support Tools and Resources Retrospective
URL: https://www.teamretro.com/retrospective-templates/support-tools-and-resources-retrospective/
The Support Tools and Resources Retrospective is for teams that support customers or colleagues. It looks at the help desk, the knowledge base, the processes and the people around them, and asks what's making support work easier and what's getting in the way.
The board has four columns. Support Tools Evaluation covers the ticketing system, live chat, self-service portal and anything else agents use every day. Resource Availability asks whether the team had the documentation, training and subject matter experts it needed. Process Efficiency looks at triage, escalation and handoffs between shifts. Collaboration and Communication covers how the team works together and with product and engineering.
Support teams feel a tool's gaps long before anyone else does, and this format gives those gaps a structured place to land. Run it after you roll out a new tool or process, before a change that will affect support, or every quarter or two so problems get fixed while they're still small. Bring ticket data if you have it, so the discussion rests on numbers as well as experience.
## Topics
- **Support Tools Evaluation**: How effective were the tools used for support?
- **Resource Availability**: Did we have access to the necessary resources?
- **Process Efficiency**: How well did our processes support effective operations?
- **Collaboration and Communication**: How well did we collaborate and communicate as a team?
## When to use
- When you want to check how well your support tools are working and where they fall short.
- After rolling out a new support tool or process, to see how it's landing with the team.
- Every quarter or two, so small problems in support get fixed before they grow.
- When new team members join, so they hear how the tools and processes really work.
- Before a change that will affect support, such as a product launch or a new channel.
## Tips and tricks
- Ask for honest feedback from everyone, from new agents to team leads.
- Invite people from product, engineering and customer success so you hear what support looks like from their side.
- Bring ticket volumes, response times and satisfaction scores to back up what people say.
- Pick the top two or three improvements and give each an owner.
- Repeat the session every quarter or two and check whether last time's fixes worked.
- Share what's working with other support teams so good practices spread.
## Icebreaker questions
- If you could invent a new support tool, what would it do?
- What's a memorable customer interaction from the last few weeks, and what made it stick?
---
# Agile Games Retrospective
URL: https://www.teamretro.com/retrospective-templates/agile-games-retrospective/
Agile games and simulations, such as the Ball Point Game or a paper airplane factory, teach agile ideas by letting a team feel them: a sprint that runs out of time, a plan that falls apart when requirements change. The game itself is only half the exercise. The Agile Games Retrospective is the debrief afterward, where your team talks through what happened and what it means for real work.
The board has four columns. Key Takeaways is for the lessons people took from the game. Challenges Faced covers what was hard, and why. Collaboration Insights looks at how the team worked together under pressure, and Real-World Applications is where you decide what to carry back into your projects. Working through them in order takes the team from "that was fun" to a specific change it can try next sprint.
Run it straight after the game, while the moments are fresh. The debrief is where ideas like iterative delivery and fast feedback become concrete, because people can point to the moment in the game when they saw them work, or fail.
## Topics
- **Key Takeaways**: What were the main lessons or insights you gained from the game?
- **Challenges Faced**: What were the most significant challenges you encountered during the game?
- **Collaboration Insights**: What did you learn about effective collaboration and teamwork?
- **Real-World Applications**: How can you apply the lessons from the game to your actual projects?
## When to use
- Straight after your team plays an agile game or simulation at a workshop or team day.
- When you've used a game to teach agile principles and want the lessons to stick.
- When training a new team, to link what they experienced in the game to how you'll actually work.
- After an agile training course that included hands-on exercises.
- When you want to connect agile theory to the problems in your current projects.
## Tips and tricks
- Run the retro right after the game, while people still remember the details.
- Keep linking the game back to real situations the team faces. That's where the lessons stick.
- Record insights and action items as you go, so there's something to follow up on next sprint.
- Invite anyone who watched the game from outside, like a coach or stakeholder, to share what they saw.
- Keep the board visible to everyone so the discussion stays anchored to what people wrote.
- Recognize what went well in the game as well as what didn't, and keep the criticism constructive.
## Icebreaker questions
- If the agile game you played was a movie, what would its title be and why?
- What's a funny or memorable moment from the game that showed an agile principle in action?
---
# Snakes and Ladders Retrospective
URL: https://www.teamretro.com/retrospective-templates/snakes-and-ladders-retrospective/
The Snakes and Ladders retrospective borrows the classic board game: ladders take you up the board, snakes send you back down. Your team uses the same idea to map what could speed up its next stretch of work and what could set it back.
The board has four areas. Start is for new initiatives or changes the team should begin. Snakes covers the risks and pitfalls that could slow you down, technical or interpersonal. Ladders is for the accelerators, from quick wins to longer-term advantages, and Finish is where the team describes what success looks like at the end.
Because it looks forward as much as back, it suits the start of a project or a milestone check-in as well as a regular retro. Vote on the snakes that most need dealing with and the ladders most worth climbing, then turn the top ones into actions with owners.
## Topics
- **Start**: What things should we start?
- **Snakes**: What pitfalls should we be aware of?
- **Ladders**: What will help take us to the next level?
- **Finish**: What do we expect at the end?
## When to use
- When planning a new project or initiative, to spot risks and opportunities early
- At project milestones, to check progress and adjust course
- When the team is stuck in a rut and needs a different way to think about solutions
- For teams that enjoy game-based formats
## Tips and tricks
- Keep the game metaphor light, and keep the discussion on what the team can act on
- Ask about the short-term and long-term effects of each snake and ladder
- Vote to pick the snakes most worth tackling and the ladders most worth climbing
- Keep a visual board to track progress on the snakes you're dealing with and the ladders you're building
- Give risks and opportunities similar time so the session doesn't turn gloomy
- Follow up on the previous retrospective's items at the start
## Icebreaker questions
- What was your favorite board game as a child and why?
- If you could instantly master one skill that would help our team, what would it be?
---
# Process Improvement Retrospective
URL: https://www.teamretro.com/retrospective-templates/process-improvement-retrospective/
A Process Improvement Retrospective is a meeting where your team reviews one specific process, such as onboarding, code review or procurement, and decides how to make it work better. Where a sprint retro covers everything that happened recently, this one stays on a single process from start to finish.
The board has five columns, worked through in order. Process Overview gets everyone describing the same process, step by step. Process Purpose asks why it exists and what it's meant to achieve, which often shows that some steps no longer serve that goal. Pain Points collects the delays, rework and frustrations people run into. What's Working Well names the parts worth keeping, so you don't throw them out with the rest. Improvement Ideas is where the team suggests changes and picks the ones worth trying.
Because people from different roles see different parts of a process, the review works best with everyone who touches it in the room. Run it when the same problem keeps recurring, a few weeks after a new process goes live, or on a regular schedule for the processes your team depends on most.
## Topics
- **Process Overview**: What is the current process we're reviewing?
- **Process Purpose**: Why does this process exist? What is its intended goal?
- **Pain Points**: What challenges or issues are you currently facing with this process?
- **What's Working Well**: What aspects of the process are effective and should be retained?
- **Improvement Ideas**: What changes would make the process work better?
## When to use
- When the same issues or delays keep showing up in an existing process
- A few weeks after you introduce a new process, to check it's working and decide what to adjust
- On a regular schedule for the processes your team relies on most
- When people disagree about how a process is supposed to work, or why it exists
## Tips and tricks
- Make it clear you're reviewing the process, not the people who run it, so feedback stays honest
- Invite people from every role that touches the process; each one sees a different part of it
- Sketch the process as a simple map or flowchart before the session so bottlenecks are easy to point at
- Rank improvement ideas by likely impact and effort, and pick the top one or two
- Give each agreed change an owner and a date
- Book a short follow-up to check whether the changes worked and adjust if they didn't
## Icebreaker questions
- If you could redesign the process from scratch, what would be your first step?
- Share a humorous or frustrating experience you've had with the current process.
---
# An Unexpected Journey Retrospective
URL: https://www.teamretro.com/retrospective-templates/an-unexpected-journey-retrospective/
Projects rarely follow the plan you started with. The Unexpected Journey retrospective treats your sprint or project as a quest and walks your team back along the route: where you set out to go, what knocked you off course, what you found on the way and what you'll take into the next one. Telling it as a story makes it easier to talk about the twists and the dragons without anyone feeling blamed.
The board has four topics. Where We Set Out records the original goals and assumptions. Unexpected Detours covers the blockers and surprises that changed the path. Treasures Discovered is for the wins and good practices you picked up along the way, and Wisdom for the Next Quest turns all of it into actions. Because each person tells their own part of the story, quieter team members get a natural way in, and you often hear about problems a standard checklist would miss.
Use it for an end-of-project review, after a milestone, or when your usual format has gone stale. You'll finish with a clear picture of how far the team came and a short list of things to do differently next time.
## Topics
- **Where We Set Out**: What were our original goals and expectations?
- **Unexpected Detours**: What surprises or obstacles knocked us off course?
- **Treasures Discovered**: What good things or wins did we find along the way?
- **Wisdom for the Next Quest**: What lessons will we carry into our next adventure?
## When to use
- At the end of a long or complex project, to compare how it actually unfolded with the plan.
- After a major milestone, when you want to mark the wins and capture what you learned.
- When your usual retrospective feels stale and the team needs a different way into the conversation.
- After a turbulent stretch full of surprises or scope changes, to talk it through without blame.
## Tips and tricks
- Open with a short story framing so everyone understands the quest before they add notes.
- Give quieter team members their own turn to tell their part of the journey.
- Treat detours as part of the story. Ask what caused them, not who.
- Group similar notes to see which detours and treasures keep coming up before you vote.
- Timebox each topic so you leave enough room for the Wisdom for the Next Quest actions.
- Give every lesson an owner and a due date so it turns into a real change.
## Icebreaker questions
- If this project were a movie adventure, what genre would it be and why?
- What's the most unexpected detour you've ever taken on a real-life trip?
---
# Alice in Wonderland Adventure Retrospective
URL: https://www.teamretro.com/retrospective-templates/alice-in-wonderland-adventure-retrospective/
Some sprints feel like falling down a rabbit hole. The Alice in Wonderland Adventure Retrospective, based on the story by [Lewis Carroll](https://en.wikipedia.org/wiki/Lewis_Carroll), maps four scenes from Alice's adventures onto prompts for your team. You start with the surprises you tumbled into, move through the chaos of the Mad Hatter's tea party, stop for the Cheshire Cat's wisdom and finish with the Queen of Hearts handing down decrees for next time.
The playful framing helps people lower their guard and raise problems that might otherwise feel awkward to mention. Down the Rabbit Hole is for surprises, good or bad. The Mad Hatter's Tea Party covers what felt chaotic or out of order. The Cheshire Cat's Wisdom captures what the team finally saw clearly, and The Queen of Hearts turns it all into decisions with owners. A familiar story makes it easier to say what felt disorienting and which way to go next.
It suits agile teams, project teams and anyone who wants a break from the standard retro without losing the outcomes. The theme brings some energy back to the meeting, and the last column makes sure you leave with real actions.
## Topics
- **Down the Rabbit Hole**: What unexpected surprises did we tumble into this sprint?
- **The Mad Hatter's Tea Party**: What moments felt chaotic, confusing, or out of order?
- **The Cheshire Cat's Wisdom**: What did we learn or finally see clearly this sprint?
- **The Queen of Hearts**: What decisions or actions should we decree for next time?
## When to use
- When your retros feel repetitive and you want a themed format to get people involved again.
- After a sprint full of surprises and sudden changes that left the team feeling disoriented.
- When you want people to share more openly, and a playful story will help them relax.
- For team-building sessions where reflection and connection matter as much as action items.
- When you're onboarding a new team and want a memorable, low-pressure first retro.
## Tips and tricks
- Open with a short story intro so everyone knows how each column maps to Alice's adventures.
- Enjoy the theme, but make sure each column still produces something concrete.
- Timebox each stage so no single column takes over the meeting.
- Remind everyone that curiosity matters more than polish here. Quieter people contribute more when they hear that.
- Group similar ideas before voting so discussion goes to the themes that matter most.
- Close by turning your Queen of Hearts decrees into owned actions with due dates.
## Icebreaker questions
- If you could shrink or grow like Alice to solve one work problem, which would you choose and why?
- Which Wonderland character best matches your mood after this sprint, and what would they say?
---
# Rugby Retrospective
URL: https://www.teamretro.com/retrospective-templates/rugby-retrospective/
The Rugby Retrospective lays your team's reflection out on a rugby pitch. You start at the halfway line and work toward the try line, so the conversation moves from what will get the team going, through the challenges in front of it, to the long-term goals it's playing for.
The board has five areas. The Halfway Line is for quick wins that build momentum. The 10M line covers the immediate obstacles, and the 22M line is for the processes and tools that would help the team go faster. The Try Line holds the long-term goals, and the Deadball line is for the practices and habits the team should take out of play.
Because it covers today's blockers and next quarter's goals on one board, it suits quarterly planning as well as a regular sprint retro. Sports fans will pick up the metaphor straight away, and everyone else only needs to know that the try line is where you score.
## Topics
- **Halfway Line**: What will help us start moving forward?
- **10M line**: What are the immediate challenges?
- **22M line**: What will help us accelerate?
- **Try Line**: What will help us reach our goal?
- **Deadball line**: What should we take out of play?
## When to use
- When your team enjoys sports metaphors and a change of format would lift the energy
- When you need to balance immediate challenges with long-term goals
- During quarterly planning, to map improvements from quick wins to bigger goals
## Tips and tricks
- Show the rugby field so everyone can see how each area moves the team toward the try line
- Ask for short-term fixes and long-term improvements, so the board covers both
- Use rugby terms during the session to keep the metaphor alive
- Set a timer for each position to keep the session moving
- Finish with a game plan: specific actions, each with an owner
## Icebreaker questions
- If your team were a rugby team, what position would you play and why?
- What's your most memorable sporting moment that taught you about teamwork?
---
# Sitcom Sprint Retrospective
URL: https://www.teamretro.com/retrospective-templates/sitcom-sprint-retrospective/
Every sprint has its plot twists, running jokes and a cliffhanger or two. The Sitcom Sprint retrospective asks your team to look back on the sprint as if it were an episode of a TV comedy. Calling a recurring bug a "running gag" takes some of the sting out of it, so people talk about the frustrating stuff more openly.
The board has four areas. The Laugh Track is for the moments that made the team smile, from wins to small reliefs. The Running Gag covers the problems that keep coming back sprint after sprint. Breakout Star is for the people, tools or decisions that stood out, and The Cliffhanger captures the unresolved work and risks heading into the next sprint.
Use it when your team has retrospective fatigue, after an eventful sprint, or with new team members who'd find a lighter format easier to join. The Running Gag and The Cliffhanger give you the material for actions, so the fun doesn't come at the cost of follow-through.
## Topics
- **The Laugh Track**: What moments made the team smile or laugh this sprint?
- **The Running Gag**: What problems or annoyances kept popping up again and again?
- **Breakout Star**: Who or what stood out and deserves recognition this sprint?
- **The Cliffhanger**: What's unresolved and carrying over into next sprint?
## When to use
- When your team has retrospective fatigue and needs a change of format.
- When you want to celebrate wins and still leave with improvement actions.
- After an intense or eventful sprint, when a lighter tone would help people talk.
- When onboarding new team members, as a low-pressure way to get everyone talking.
## Tips and tricks
- Lean into the theme at the start: ask people to name the episode so everyone gets into a playful mindset.
- Keep the humor inclusive. Jokes are about situations, never aimed at a person.
- Timebox each topic so the fun doesn't crowd out the next steps, and turn running gags and cliffhangers into actions.
- Start with The Laugh Track so quieter members have an easy way in before the challenges.
- Group similar ideas, then vote to pick the running gags and cliffhangers that matter most.
- Close by giving each action an owner and a due date, so the next 'episode' starts with momentum.
## Icebreaker questions
- If this sprint were a sitcom, what would the episode title be?
- Which TV character best represents how you felt during this sprint, and why?
---
# Ancient Greek Odyssey Retrospective
URL: https://www.teamretro.com/retrospective-templates/ancient-greek-odyssey-retrospective/
The Ancient Greek Odyssey retrospective borrows the shape of Homer's Odyssey: a long voyage home, with storms, monsters and temptations along the way. Your team retells its sprint or project as that kind of journey, so setbacks become storms weathered and distractions become sirens resisted. The story gives people a way to talk about what went wrong without it sounding like an accusation.
The board has four topics. The Departure records the goals you set as you left the harbor. Storms & Sirens covers the challenges that knocked you off course and the distractions that pulled focus away. Heroic Feats is for the wins and the moments when someone came through for the team. Course Home turns what you've learned into actions for the next voyage.
Nobody needs to know the original story to take part, because the facilitator can set the scene in a sentence or two. Use it when your team wants a creative change from the standard agile retrospective but still needs to leave with clear next steps. The shared metaphor also gives quieter people an easy way into the conversation.
## Topics
- **The Departure**: What goals did we set as we left the harbor?
- **Storms & Sirens**: What challenges and distractions knocked us off course?
- **Heroic Feats**: What moments of brilliance and resilience should we celebrate?
- **Course Home**: What will we do differently to navigate the next voyage?
## When to use
- When your team wants a creative alternative to the standard sprint retrospective.
- After a long or difficult project, when telling it as a story helps the team work through the highs and lows.
- When quieter team members tend to hold back and a shared metaphor would give them an easier way in.
- For a team-building session where you still want a few concrete actions at the end.
## Tips and tricks
- Set the scene in a minute or two so everyone knows the metaphor before they add notes.
- Let people tell stories, but watch the clock so the narrative doesn't crowd out Course Home.
- Group and vote to find the storms and feats that matter most to the whole crew.
- Give every Course Home action an owner and a date.
- Use the theme to take the sting out of hard feedback. A storm is something that happened to the crew, not one person's failing.
- Rotate the captain (facilitator) role between retrospectives so different people steer the voyage.
## Icebreaker questions
- If your team were a crew on Odysseus's ship, which mythical role would you play and why?
- Which Greek monster best represents the biggest obstacle you faced this sprint?
---
# Team Mood and Health Retrospective
URL: https://www.teamretro.com/retrospective-templates/mood-and-health-retrospective/
Signs of burnout, stress and disengagement are easy to miss until they turn into real problems. The Team Mood and Health retrospective gives your team a regular, judgment-free check-in on how people are actually doing, emotionally, physically and at work, so you can spot early warning signs and protect what keeps people going.
The board has four columns. Feels Good collects what made people feel positive or proud. Felt Heavy is for what left them flat or deflated, Felt Frustrating for what stressed or irritated them, and Feels Hopeful for what they're looking forward to. When this becomes a normal part of your team's rhythm, people learn that how they're doing matters as much as what they deliver. As facilitator, you can use the results to guide supportive conversations, adjust workloads and back the habits that help.
Run it weekly, at the end of a sprint or during a demanding stretch. It works alongside your usual sprint retrospective: that one looks at the work, and this one looks at the people doing it.
## Topics
- **Feels Good**: What made you feel positive or proud this sprint?
- **Felt Heavy**: What left you feeling flat or deflated?
- **Felt Frustrating**: What stressed or irritated you?
- **Feels Hopeful**: What are you genuinely looking forward to?
## When to use
- When you want to check on team well-being regularly and catch burnout before it escalates.
- During an intense delivery period or after a hard sprint, to see how people are coping.
- As a weekly or every-other-week ritual that builds trust and psychological safety.
- When you sense disengagement or low morale and need a structured way to open the conversation.
- Alongside a sprint retrospective, to balance a review of the work with a check on the people.
## Tips and tricks
- Go first with your own honest check-in. When the facilitator is open, others feel they can be too.
- Allow anonymous responses so people can be truthful about stress and mood.
- Look for patterns across the team instead of singling people out, and follow up privately if someone signals they're struggling.
- Close with concrete actions or commitments so the team sees its input lead to real support.
- Keep it short and regular. A quick recurring check-in builds more trust than an occasional long one.
- Don't turn well-being into a performance metric. The point is care and connection, not a score.
## Icebreaker questions
- If your current mood was a weather forecast, what would today's report say?
- What's one small thing that made you smile this week?
---
# World of Warcraft Raid Review
URL: https://www.teamretro.com/retrospective-templates/world-of-warcraft-raid-review-retrospective/
Whether your guild just downed a Mythic boss or spent the night wiping on the same mechanic, a short review afterward is how the next night goes better. The World of Warcraft Raid Review takes the format of an agile retrospective and reskins it for raid nights, so officers and members can talk through encounters, coordination and morale without it turning into a blame session.
The board has four areas. Epic Loot is for what went well: clean pulls, clutch saves, good callouts. Wipes & Mechanics covers where the raid struggled, framed as data to learn from. Strats & Assignments is where the team agrees on changes to positioning, cooldowns and roles, and Guild Morale checks how people are feeling and whether raid night is still fun.
Keeping the talk on mechanics and encounters, not individual players, makes people more willing to admit what went wrong. Run it after a progression night, at the start of a new tier or after a rough wipefest, and end with clear assignments so everyone knows their job for the next pull.
## Topics
- **Epic Loot**: What went well in our raid this week?
- **Wipes & Mechanics**: Where did we wipe or struggle with mechanics?
- **Strats & Assignments**: What should we change in our strategy or roles?
- **Guild Morale**: How is the team feeling and how can we keep it fun?
## When to use
- After a progression night on a new boss, to refine the strategy before the next attempt.
- After a new raid tier launches, to agree on assignments, consumables and expectations across the roster.
- When a string of wipes is causing frustration and you want to turn it into feedback the raid can use.
- At the end of a raid lockout, to look back on performance and morale and decide what to improve next reset.
## Tips and tricks
- Keep feedback about mechanics and encounters, not individual players, to avoid blame and keep the guild together.
- Run the review shortly after raid night while the pulls are still fresh in everyone's memory.
- Give quieter members a chance to contribute by collecting ideas anonymously before discussing them.
- End on the strategy and assignment changes so everyone leaves with a clear plan for the next pull.
- Celebrate at least one win every session, even after a rough wipefest.
- Timebox the review so it stays snappy and doesn't eat into rest time before the next night.
## Icebreaker questions
- If your raid team were a boss encounter, what would our signature mechanic be?
- What is the most memorable wipe you have ever been part of and what did you learn from it?
---
# Remote Team Retrospective
URL: https://www.teamretro.com/retrospective-templates/remote-team-retrospective/
Time zones, home offices and a dozen chat channels create problems a standard retrospective doesn't ask about. The Remote Team Retrospective is built for distributed and hybrid teams that want to look at how they communicate and stay connected when they're not in the same room, and to fix the friction that builds up quietly.
The format has four topics: how well you're communicating, how connected you feel, what's helping you work well remotely and what's getting in the way. It runs online in TeamRetro, so everyone adds ideas privately and anonymously, whether they're at a kitchen table or a co-working space, and quieter people and those in other time zones get the same say. Grouping, voting and action tracking can happen live or asynchronously, so follow-up doesn't depend on who made the call.
Run it regularly and you'll notice the slow drift toward isolation and burnout early, while it's still easy to fix. Use it after a sprint, at a project milestone or on a recurring schedule, and leave each session with one or two changes the team will try.
## Topics
- **How well are we communicating?**: Is information flowing clearly across channels and time zones?
- **How connected do we feel?**: Are we building trust and rapport despite the distance?
- **What's helping us thrive?**: Which tools, habits or rituals are making remote work better?
- **What's getting in our way?**: What friction or blockers are making remote work harder?
## When to use
- After moving to a fully remote or hybrid model, to see how the team is adapting.
- On a recurring schedule, to keep trust and communication healthy across a distributed team.
- After a project or sprint where working across time zones felt strained, or went unusually well.
- When onboarding new remote team members, to find gaps in process, tools or culture.
- If you sense growing disconnection or burnout on a distributed team.
## Tips and tricks
- Use anonymous brainstorming so quieter team members and people in other time zones feel safe to be honest.
- Run the brainstorm asynchronously over a day or two so every time zone can contribute, then meet briefly to discuss and vote.
- Keep cameras on for the discussion where you can, but watch for video fatigue and make it optional.
- Pick one or two high-impact actions instead of trying to fix everything at once.
- Rotate the facilitator so no single voice shapes every session.
- Give every action an owner and a due date in TeamRetro so it isn't lost between sessions.
## Icebreaker questions
- What's the best thing about working from your current setup, and the one thing you'd change?
- If your team could meet in person anywhere in the world for a day, where would you go?
---
# Start Stop Retrospective
URL: https://www.teamretro.com/retrospective-templates/start-stop-retrospective/
The Start Stop Retrospective asks your team two questions: what should we start doing, and what should we stop doing? That's the whole board. With only two columns, the discussion goes straight to changes, and the meeting ends with a short list of things to try and things to drop.
Start is for new practices, habits or processes the team wants to adopt. Stop is for the ones that waste time or cause frustration: meetings without an agenda, skipped documentation, workarounds that never get fixed. Every note is a behavior, so turning the top-voted items into actions with an owner is quick.
It's a trimmed-down version of Start Stop Continue, without the Continue column. Use it when you need decisions more than reflection, such as after a project phase, during a process change, or when a short retro is all the time you have. If the team also needs to name what's working, run the three-column version instead.
## Topics
- **Start**: What should we start doing?
- **Stop**: What should we stop doing?
## When to use
- When your team needs to make quick, clear changes to how it works
- After a project phase, when you know some adjustments are needed
- When you have little time and want the retro to end in decisions
- During a period of change, to decide which practices to drop
## Tips and tricks
- Keep each note to something the team could act on in the next sprint or two
- Go round the room so everyone adds at least one note to each column
- Give Start and Stop roughly equal time so the session doesn't turn into a list of complaints
- Turn the top items into actions, each with an owner and a deadline
- Check on the last retro's actions before starting new ones
## Icebreaker questions
- What's one positive change you've seen in our team recently?
- If you could instantly implement one improvement to our process, what would it be?
---
# Ramadan Reflection Retrospective
URL: https://www.teamretro.com/retrospective-templates/ramadan-retrospective/
The Ramadan Reflection Retrospective takes its themes from Ramadan, the Islamic month of fasting, which for many people is a time of reflection, patience, gratitude and community. It asks your team to look at its work in the same spirit: slowly and honestly, with attention to how people treat each other as well as what got delivered.
The board has four areas. Mindful Reflection asks what the team has learned about itself, such as becoming more patient during hard problem-solving sessions. Community Support is for the specific ways people have helped each other grow, from mentoring to pitching in before a deadline. Purposeful Improvement asks which changes would make the most difference, and Gratitude & Celebration closes the session by recognizing achievements, large and small.
The pace is deliberately calmer than a standard retro. Give people time to think before they write, and ask the team to listen fully before jumping to solutions. You don't need to be Muslim or fasting to take part; explain the inspiration briefly at the start so everyone shares the context.
## Topics
- **Mindful Reflection**: What have we learned about ourselves?
- **Community Support**: How have we supported each other's growth?
- **Purposeful Improvement**: What specific changes would create the most value?
- **Gratitude & Celebration**: What accomplishments should we acknowledge and celebrate?
## When to use
- During or after Ramadan, when your team wants a retro with a reflective, values-based tone
- After a stretch of heavy delivery pressure, when the team needs to slow down and refocus on its purpose
- When you want people to think more carefully about how they work together
- When the team wants to recognize how its members support each other
- When you want to look at personal growth and team improvement in the same session
## Tips and tricks
- Start by explaining the link between Ramadan's themes and a retrospective: both make time for honest reflection
- Keep the session calm by cutting distractions, and give people quiet time to think before they write
- Ask the team to listen fully to each other before jumping to solutions or judgments
- Balance reflection on the past with forward-looking actions, so the session leads to real change
- End with each person sharing one thing they're grateful for about the team
- If your team comes from many backgrounds, briefly explain the principles of Ramadan that inspired the format so everyone understands the context
## Icebreaker questions
- If you could develop one new habit that would improve our team's effectiveness, what would it be and why?
- What's one small act of kindness from a team member that made a significant difference to you recently?
---
# Pokémon Trainer's Journey Retrospective
URL: https://www.teamretro.com/retrospective-templates/pokemon-trainers-journey-retrospective/
The Pokémon Trainer's Journey retrospective borrows the shape of a trainer's adventure from the games. Your team sets out on a sprint or project, catches some wins, fights its way through a few tough battles, picks up new skills and then decides where to head next. Most people know the structure already, which makes it quick to explain and easy to play along with.
The board has four stages. Pokémon We Caught is for wins and achievements, from small bug fixes to major releases. Gym Battles We Fought covers the challenges and obstacles the team battled, like unclear requirements or flaky tests. Badges We Earned is for the skills and lessons gained, including the ones that came from setbacks. The Next Route turns all of that into a few specific actions with an owner.
It suits teams that enjoy a bit of gaming nostalgia and want a break from their usual format, at the end of a sprint, a milestone or a release. Framing problems as battles to win makes them easier to name, and the Badges stage gives the team a moment to see how much it has learned.
## Topics
- **Pokémon We Caught**: What wins and achievements did we capture this time?
- **Gym Battles We Fought**: What challenges or obstacles did we battle along the way?
- **Badges We Earned**: What new skills, lessons or insights did we gain?
- **The Next Route**: Where do we go next and what actions will get us there?
## When to use
- When your team wants a themed break from its standard retrospective format
- At the end of a sprint, project milestone or major release, to celebrate progress and plan ahead
- For gaming communities, hackathon teams or any group that enjoys a game-style session
- When you want the team to see setbacks as part of how it learns
- When a difficult topic needs a lighter frame so people will talk about it
## Tips and tricks
- Set the scene at the start by reminding everyone they're trainers on a shared adventure
- Timebox each stage so celebrating wins doesn't crowd out the actions and goals
- Keep Gym Battles We Fought constructive and blame-free: talk about the obstacle, not the person
- Invite shout-outs in Pokémon We Caught so quieter team members get recognized
- Limit The Next Route to a few achievable commitments, each with a clear owner
- Not everyone will know Pokémon, so keep the metaphors light and explain what each stage means
## Icebreaker questions
- If you could have one Pokémon on your team this sprint, which would it be and why?
- What's your team 'starter Pokémon', the strength you always rely on to get going?
---
# Taskmaster Trials Retrospective
URL: https://www.teamretro.com/retrospective-templates/taskmaster-trials-retrospective/
The Taskmaster Trials retrospective takes its idea from the comedy game show Taskmaster, where contestants tackle odd, often impossible tasks and get points for effort and ingenuity as much as success. Your team scores the last sprint, project or spike the same way.
The board has four trials. The Impossible Task is for the blockers and challenges that felt unfair or overwhelming. Best Use of Initiative credits the clever workarounds, like a quick script that saved hours or a mocked API that kept the front-end team building. Points on the Board celebrates wins of any size. Claim Your Prize turns the discussion into the improvements the team wants to win next time.
Giving creative problem-solving its own column is what sets this format apart: the workarounds people improvised under pressure get recognized, and the best ones become shared practice. Use it after an intense sprint, when you've just finished an experiment or spike, or when your team is tired of standard retros and could use a few laughs along with its actions.
## Topics
- **The Impossible Task**: What challenges felt impossible or unfair this sprint?
- **Best Use of Initiative**: What clever solutions or creative workarounds did we pull off?
- **Points on the Board**: What wins, big or small, deserve to be celebrated?
- **Claim Your Prize**: What improvements do we want to win for next time?
## When to use
- When you've finished an experiment, trial run or spike and want the team to reflect on how it went.
- When morale needs a lift and a few laughs would help the team talk openly.
- When quieter team members need a lower-stakes format to feel comfortable sharing.
- After a tough or intense sprint, when recognizing effort and creativity matters as much as finding improvements.
## Tips and tricks
- Introduce each trial with a bit of game-show flair to get the team relaxed.
- Make sure Claim Your Prize turns the laughs into concrete actions with owners.
- Timebox each trial so no single one takes over the session.
- Ask everyone to add to every trial so quieter people are heard, not just the most vocal contestants.
- Keep The Impossible Task on the obstacle, not the person.
- Rotate who hands out points or runs each round so the session feels shared.
## Icebreaker questions
- If you were given a bizarre Taskmaster challenge right now, what hidden talent would help you win?
- What's the most creative workaround you've ever used to solve an everyday problem?
---
# Energy Levels Retrospective
URL: https://www.teamretro.com/retrospective-templates/energy-levels/
The Energy Levels Retrospective uses battery levels to talk about how much energy your team had last sprint. Each person sorts the sprint's activities by what they did to their charge, which makes it easier to discuss sustainable pace and burnout without anyone having to make a speech about how tired they are.
The board has four columns. Full Battery is for what energized people. Medium Battery covers work that took the right amount of energy, the steady habits worth keeping. Low Battery is for what drained them. Re-charge is where the team agrees what would restore its energy next sprint.
Look for patterns. If several people put the same meeting under Low Battery, that's your first action. Medium Battery is easy to skip, but it shows the routines that work and shouldn't be cut when you trim the calendar.
## Topics
- **Full Battery**: What energized you in the last sprint?
- **Medium Battery**: What took up the right amount of energy in the last sprint?
- **Low Battery**: What drained you in the last sprint?
- **Re-charge**: What will re-energize you for the next sprint?
## When to use
- When team morale seems low or varies a lot from sprint to sprint.
- After a particularly intense stretch of work, to check for burnout.
- During organizational change, to keep an eye on how people are coping.
- When you're trying to set a more sustainable pace.
- As a regular check on the team's energy, before burnout shows up.
## Tips and tricks
- Share your own energy level first so others feel safe being honest.
- Look for patterns in what consistently energizes or drains the team.
- Spend as much time on fixes as on naming problems.
- Talk about both individual energy and what affects the whole team.
- Use what you learn when planning the next sprint and sharing out the work.
- Check at the next retrospective whether the changes made a difference.
## Icebreaker questions
- What's one thing at work that always gives you energy?
- If you could eliminate one energy-draining task from your day, what would it be?
---
# Wu Kong Retrospective
URL: https://www.teamretro.com/retrospective-templates/wu-kong-retrospective/
The Wu Kong Retrospective borrows from Journey to the West, the classic Chinese novel about Sun Wukong, the mischievous Monkey King, and a long pilgrimage full of demons and trials. Your team looks back on its own recent work as an adventure of the same kind.
The board has four areas. Mischievous Moments is for the surprises and bits of chaos that turned out useful or funny. Formidable Foes covers the big obstacles: tight deadlines, hard technical problems, conflict. Enlightening Experiences is for the lessons and realizations people took away, and Sacred Sanctuaries names the practices and people that gave the team somewhere safe to recover.
The story gives people a lighter way into hard topics, which helps after a demanding project with plenty of ups and downs. Finish by deciding which sanctuaries to protect and which foes to tackle first.
## Topics
- **Mischievous Moments**: Like the Monkey King's playful antics, what unexpected events or 'mischief' did you encounter?
- **Formidable Foes**: What daunting challenges or 'demons' did you face along the way?
- **Enlightening Experiences**: What insights or 'wisdom' did you gain along the way?
- **Sacred Sanctuaries**: What practices, processes or 'havens' provided strength and refuge?
## When to use
- When you want a story-based format to talk about challenges and what the team learned.
- After a demanding project with plenty of ups and downs.
- When your team needs a lighter way into difficult topics like setbacks or conflict.
- When you want to talk about adapting to change, a theme that runs through the Monkey King's story.
## Tips and tricks
- Invite people to tell their notes as short stories; the theme makes that easier than in a standard retro.
- Use an image of the Monkey King or a few props to set the tone at the start.
- Give Mischievous Moments real attention, because the surprises are often where the useful lessons are.
- When someone shares a setback, ask what the team learned from it, not only what went wrong.
- End on Sacred Sanctuaries and Formidable Foes: agree which practices to protect and which obstacle to tackle first.
## Icebreaker questions
- If you could have a magical cloud like the Monkey King to travel anywhere, where would you go?
- What supernatural power or ability would you want to have on an epic adventure?
---
# Shout Out Spectacle
URL: https://www.teamretro.com/retrospective-templates/shout-out-spectacle-retrospective/
Recognition tends to get lost in the rush of day-to-day delivery. The Shout Out Spectacle sets aside a whole retrospective for it, so your team can thank the people and moments that made a difference, including the work that usually goes unnoticed.
The board has four areas. Individual Shout Outs comes first: who deserves a public thank you, and for what? Team Wins moves to what you achieved together. Lessons in Generosity looks at how people helped each other and what made that help work, so you can do more of it. Future celebrations closes the session with goals the team would be glad to celebrate next time.
Naming the exact behavior behind a thank you shows everyone what good work looks like. Use it at the end of a sprint or project, after a hard stretch, or with a remote or hybrid team where contributions are easy to miss. Run it alongside your problem-solving retros, not in place of them.
## Topics
- **Individual Shout Outs**: Who deserves a public thank you this time?
- **Team Wins**: What did we achieve together worth celebrating?
- **Lessons in Generosity**: Where did support, sharing, or kindness make a difference?
- **Future celebrations**: What should we commit to and celebrate next?
## When to use
- At the end of a sprint or project, when you want to finish on a high.
- When team morale needs a lift or recognition has been thin in recent weeks.
- For distributed or hybrid teams, where contributions are easy to miss.
- After a challenging period, to thank the people whose effort and support got the team through.
- On a regular cadence, so appreciation becomes a habit and not a one-off.
## Tips and tricks
- Ask for specifics. Naming the exact action behind a shout out means more than generic praise.
- Check that recognition is spread fairly, and prompt the group to thank quieter or behind-the-scenes contributors.
- Read shout outs aloud and let people add reactions or votes to the standout moments.
- Keep it from becoming a popularity contest by focusing on behaviors and their effect, not personalities.
- Timebox each section so the celebration stays lively and doesn't drift into a general catch-up.
- Close by turning the goodwill into commitments with clear owners.
## Icebreaker questions
- If you could give yourself a fun award for this sprint, what would it be called?
- Who is someone outside this team who deserves a shout out, and why?
---
# Halloween Retrospective
URL: https://www.teamretro.com/retrospective-templates/halloween-retrospective/
The Halloween Retrospective uses trick-or-treat to review your team's recent work. Treats are the wins and good moments worth celebrating, and tricks are the challenges that caught you out. Two more topics turn the conversation toward what happens next.
The board has four topics. Sweet Treats is for successes. Tricky Situations is for obstacles and problems. Magic Spells is where the team brainstorms fixes, and Costume Party asks what new roles or ways of working you could try on, like rotating who leads standup or shadowing a colleague in a different role.
The theme takes some of the tension out of difficult conversations, because a "trick" is easier to name than a failure. Run it around Halloween or at an October sprint end, or any time your team could use a lighter retrospective that still finishes with actions.
## Topics
- **Sweet Treats**: What successes or positive moments should we celebrate?
- **Tricky Situations**: What challenges or obstacles did we encounter?
- **Magic Spells**: What solutions or improvements could we implement?
- **Costume Party**: What new roles or perspectives should we try?
## When to use
- Around Halloween, when you want a seasonal change from your usual retrospective
- When the team needs a less formal way to talk about challenges and improvements
- When you want more open and honest feedback, and a playful theme might help people speak up
- When the team is stuck in old habits and you want to try new roles or ways of working
## Tips and tricks
- Invite people to use Halloween metaphors when they share, but don't insist on it
- Keep the mood light while still dealing with the serious problems
- Hand out small Halloween-themed recognition for the most useful ideas
- Timebox each topic to keep the meeting moving
- Check the actions from your last retrospective before adding new ones
## Icebreaker questions
- What's the scariest bug or technical challenge you've encountered in your career?
- If you could dress up as any famous tech personality for Halloween, who would it be and why?
---
# Monthly Milestone Map Retrospective
URL: https://www.teamretro.com/retrospective-templates/monthly-milestone-map-retrospective/
A sprint retrospective looks at a couple of weeks. The Monthly Milestone Map steps back to look at a whole month, so your team can see how far it has come and what to aim for next. It picks up the patterns a single sprint is too short to show: the obstacle that came up three times, or the habit that quietly made everything easier.
The map has four stops: the milestones you reached, the obstacles you worked through, the lessons you learned and the goals for the month ahead. As people add notes, recurring themes become visible, which makes it a good fit for teams that plan on a monthly rhythm or want a regular checkpoint to adjust course. Lessons connect back to the obstacles that taught them, and goals build on both, so the conversation stays tied to real outcomes.
Run in TeamRetro, each month's map becomes a record of what the team achieved and learned, and you can open last month's goals at the start of the next session. Product teams, cross-functional squads, community groups and volunteer teams all use it to mark progress and leave with a short list of goals for the month ahead.
## Topics
- **Milestones Reached**: What key achievements and milestones did we hit this month?
- **Obstacles Navigated**: What challenges did we face and how did we work through them?
- **Lessons Learned**: What insights or learnings can we carry forward?
- **Goals Ahead**: What do we want to achieve in the month ahead?
## When to use
- Your team works on a monthly cadence and wants a regular checkpoint to review progress and plan ahead.
- You want to look past individual sprints to see longer-term progress and challenges that keep coming back.
- You lead a community group, volunteer team or cross-functional squad that likes to mark milestones together.
- You want to turn a month's lessons into a few concrete goals and keep momentum from month to month.
## Tips and tricks
- Gather a few metrics or milestones before the session so the team has a shared reference point.
- Keep the milestones section celebratory. Recognizing wins gives the team energy for the month ahead.
- Treat obstacles as things to learn from, not failures, so people talk about them openly and without blame.
- Limit the number of goals so the team stays focused and the commitments stay achievable.
- Start with anonymous brainstorming so quieter voices and dissenting views are captured before group discussion.
- Open the session by revisiting last month's goals, so the team sees what got done and what slipped.
## Icebreaker questions
- If this past month were a movie title, what would it be called?
- What's one thing you're personally proud of from the last month, work or otherwise?
---
# Among Us (Agile Edition) Retrospective
URL: https://www.teamretro.com/retrospective-templates/among-us-agile-edition-retrospective/
The Among Us (Agile Edition) retrospective borrows the social-deduction game, where a crew tries to find the impostors hidden among them. Here the impostors aren't people. They're the hidden blockers, small inefficiencies and unspoken tensions that quietly slow your team down. The theme keeps the stakes low, which tends to get quieter team members talking.
The board follows the game. Tasks Completed is for what the team did well, the crewmate work that kept the ship running. Suspicious Activity collects anything that felt off or slowed you down. Spot the Impostor digs past those symptoms to the root cause doing the damage, and Vote to Eject turns the top impostors into actions for next sprint. Because the blame lands on the impostor and never on a person, it's easier to raise uncomfortable issues.
It works well when retro fatigue has set in and the team needs a theme most people recognize. Scrum teams, DevOps squads and remote groups can all run it in TeamRetro and come away with a short list of root causes and a plan to deal with them.
## Topics
- **Tasks Completed**: What did we accomplish and do well this sprint?
- **Suspicious Activity**: What felt off, slowed us down or raised red flags?
- **Spot the Impostor**: What is the real root cause secretly sabotaging us?
- **Vote to Eject**: What actions will we commit to next sprint?
## When to use
- When your regular sprint retros have gone stale and the team needs a game-style format to get involved again.
- When you want to find hidden blockers and root causes without anyone feeling blamed.
- When the team enjoys playful themes and you want quieter members to open up.
- When you're onboarding a new team and want a light first retro that still produces real action items.
## Tips and tricks
- Aim the impostor framing at processes and root causes, never at individuals.
- Timebox each column so the theme doesn't crowd out the actions.
- Dot-vote on which impostor is doing the most damage before you agree on actions.
- Enjoy the theme during the icebreaker, then bring everyone back to focus when it's time to commit.
- Limit how many impostors you eject so the team can deliver the actions next sprint.
- Start with last retro's actions to check whether the previous impostors were really ejected.
## Icebreaker questions
- If you were the impostor on our team this sprint, what task would you have faked doing?
- Which fictional crewmate (cautious, chaotic, or always-doing-tasks) best matches your work style this sprint?
---
# Buddy Boost Retrospective
URL: https://www.teamretro.com/retrospective-templates/buddy-boost-retro-retrospective/
The Buddy Boost Retrospective is a retro about people. Instead of working through processes and problems, your team names who made a difference: the colleague who stayed late on a production bug, or the one who explained the deployment pipeline twice without complaint. It's a good way to close a sprint or milestone, and it puts thanks that usually stays private in front of the whole team.
The board has four sections. Shout Outs is for thanking specific people for specific things. Helping Hands covers the support and collaboration that got work done, including help from other teams. Feel-Good Moments captures what lifted people's energy. Boost Forward turns it into commitments, such as a kudos channel or a shout-out at the start of each standup, so the habit outlasts the meeting.
Use it to balance a run of problem-focused retrospectives, to lift morale during a demanding stretch, or to help new members learn what their teammates are good at. In TeamRetro the team groups the notes, votes on the themes that matter most and records its commitments as actions.
## Topics
- **Shout Outs**: Who made a positive difference for you recently?
- **Helping Hands**: Where did support or collaboration help us succeed?
- **Feel-Good Moments**: What moments lifted your spirits or energy?
- **Boost Forward**: How can we keep the appreciation and support going?
## When to use
- After an intense sprint or crunch, when the team needs a lift and a chance to recognize each other's effort.
- As a regular ritual between problem-focused retrospectives, so appreciation becomes a habit.
- When new members join, to help the team learn each other's strengths.
- After a major milestone or launch, to credit the people and behaviors behind it.
## Tips and tricks
- Ask for shout-outs that name a person and what they did. Vague praise is easy to forget.
- Make sure quieter and behind-the-scenes contributors get recognized, not only the most visible people.
- Set a positive tone at the start and tell everyone no contribution is too small to mention.
- Keep the session to 30–45 minutes so it stays light.
- Capture commitments under Boost Forward so appreciation turns into a habit instead of a one-off.
- Rotate who facilitates so recognition belongs to the whole team, not only the manager or Scrum Master.
## Icebreaker questions
- If you could give your teammate a fun award title for this sprint, what would it be?
- Who in the team would you want on your side in a zombie apocalypse, and why?
---
# Sales Team Retrospective
URL: https://www.teamretro.com/retrospective-templates/sales-team-retrospective/
Sales teams rarely stop to ask what's actually driving or stalling their results. The Sales Team Retrospective gives your account executives, SDRs and managers a set time to step back from calls, demos and quotas and talk about what's working and what to change next cycle. Stories about one lost deal or one big win become patterns the whole team can act on.
The board has four areas. Wins to Celebrate is for the deals, tactics and moments that went well. Lost Deals & Roadblocks covers the deals that slipped and what got in the way. Process & Tools looks at the CRM, handoffs and admin that eat into selling time, and Ideas to Test turns the discussion into experiments for next cycle. Everyone adds ideas on their own first, then the team groups them, votes and agrees on actions with owners.
Sales results are easy to measure, so bring the numbers: win rates, conversion and quota attainment give the team something to test opinions against. Run it after a monthly close, at the end of a quarter or after a major campaign, and check last cycle's actions at the start so reps stop repeating the same mistakes deal after deal.
## Topics
- **Wins to Celebrate**: Which deals, milestones, or moments went really well?
- **Lost Deals & Roadblocks**: What deals slipped away or what got in our way?
- **Process & Tools**: How well are our workflows, CRM, and tools supporting us?
- **Ideas to Test**: What should we try or improve next cycle?
## When to use
- At the end of a monthly or quarterly close, to review performance and reset goals.
- After a product launch, campaign or pricing change, to see how it affected selling.
- When win rates or pipeline velocity are dropping and the team needs to find out why.
- After onboarding new reps, to refine the sales playbook and share what experienced reps know.
- During a tough quarter, when the team needs to see its wins to keep going.
## Tips and tricks
- Bring the data: pull up win rates, quota attainment and pipeline metrics so opinions can be checked against the numbers.
- Keep the discussion of lost deals blame-free and treat each loss as something the whole team can learn from.
- Have everyone add ideas on their own in TeamRetro before the discussion, so quieter reps get heard and louder voices don't take over.
- Limit actions to two or three experiments per retrospective so the team can follow through before the next cycle.
- Rotate the facilitator between reps and managers so more people own the retro.
- Review last cycle's actions at the start of each session so every change gets checked.
## Icebreaker questions
- If your sales month were a weather forecast, what would it be and why?
- What's the best 'no' you received this cycle, and what did it teach you?
---
# Company Culture Retrospective
URL: https://www.teamretro.com/retrospective-templates/company-culture-retrospective/
A company culture retrospective asks your team to look at how the company actually works day to day and compare it with the culture it says it has. The board covers six topics: core values, communication and collaboration, leadership and management, innovation and growth, employee engagement, and diversity and inclusion.
People add specific examples under each topic, such as a decision made behind closed doors or a mentoring program that works, so the discussion is about things that happened instead of general impressions. Anonymous input matters more here than in most retros, because culture feedback often touches on leadership.
Close by picking one or two gaps to work on and giving each an owner. Culture changes slowly, so running the retro every quarter or twice a year is enough to see whether those actions made a difference.
## Topics
- **Our Core Values**: How well do our actions match the values we say we hold?
- **Communication and Collaboration**: How effective is our communication and collaboration across teams and departments?
- **Leadership and Management**: How effective is our leadership in setting the right tone and direction?
- **Innovation and Growth**: How well does our culture support new ideas and professional growth?
- **Employee Engagement**: How engaged and motivated are employees in their work?
- **Diversity and Inclusion**: How inclusive and welcoming is our culture for diverse perspectives and backgrounds?
## When to use
- For a periodic review of company culture, to find what's working and what isn't.
- During organizational change, to hear how people are experiencing it.
- As part of strategic planning, to check whether the culture supports where the company is heading.
- When onboarding new employees, to show them how the company talks about its own culture.
- After a major event, such as a merger or leadership change, to see how it affected the culture.
## Tips and tricks
- Make it safe to be honest. Say up front that no one will be asked to defend a comment.
- Invite people from different levels and departments; a culture review run only by managers sees half the picture.
- Use anonymous input so people can criticize leadership without worrying about repercussions.
- Leave with one or two actions and an owner for each, not a list of everything that could be better.
- Call out the parts of the culture that work, so they're kept on purpose.
- Repeat the retro every six to twelve months and compare the results.
## Icebreaker questions
- If our company culture were an animal, what animal would it be and why?
- Share a moment that showed our company culture at its best.
---
# Ticket Resolution Retrospective
URL: https://www.teamretro.com/retrospective-templates/ticket-resolution-retrospective/
A Ticket Resolution Retrospective looks back at a batch of recent tickets to find out what helped and what got in the way. It suits support, service desk and IT teams, and any team that works through a queue of requests.
The board has four columns. Ticket Highlights is for the tickets that stood out, good or bad. Process Challenges covers blockers and missing steps, such as approval delays, misrouted tickets or an outdated knowledge base article. Communication Gaps is for the moments when someone wasn't told something they needed to know, and Improvement Ideas is where the team proposes fixes.
Working from real tickets keeps the conversation specific. Instead of agreeing that escalations are slow, you can point to the high-severity ticket that sat overnight because nobody knew who to escalate to. The result is a short list of process changes, like SLA alerts or a triage step, each with an owner.
## Topics
- **Ticket Highlights**: What tickets stood out, and why?
- **Process Challenges**: What process issues impacted ticket resolution?
- **Communication Gaps**: Where did communication break down?
- **Improvement Ideas**: How can we improve our ticket processes?
## When to use
- After a major incident or outage, to review how tickets were handled.
- When customer satisfaction scores for ticket handling start to drop.
- After moving to a new ticketing system or making a big process change.
- On a regular schedule, such as monthly or quarterly, to catch recurring problems.
- When the same bottlenecks keep slowing down ticket resolution.
## Tips and tricks
- Invite everyone involved in the ticket lifecycle, including support agents, developers and managers.
- Review a mix of tickets that went well and tickets that went badly.
- Focus on the process, not on who handled a ticket.
- Prioritize the action items and give each one an owner so the changes actually happen.
- If you can, invite a customer or stakeholder to describe their side of a ticket.
- Call out the tickets that went well so the team sees what's working.
## Icebreaker questions
- If you could instantly resolve any one type of ticket, which would it be and why?
- Share a humorous or memorable experience from a recent ticket interaction.
---
# Drop Add Keep Improve Retrospective
URL: https://www.teamretro.com/retrospective-templates/daki-retrospective/
The Drop Add Keep Improve (DAKI) retrospective is a quick way to review a process, a project or how your team works together. It asks what you should drop (stop doing), add (start doing), keep (continue) and improve (do better).
Four plain categories make it easy for anyone to contribute, and each one leads to a decision. Drop and add cover the bigger changes. Keep protects what's working, and improve catches the practices that are worth keeping but need fixing, which a simple start/stop format has no place for.
Use DAKI at the end of a sprint, a project or a milestone. It isn't tied to software, so any team that wants to review how it works can run it.
## Topics
- **Drop**: What practices should we stop or discontinue?
- **Add**: What new practices should we adopt?
- **Keep**: What's working well that we should continue?
- **Improve**: What could we do better?
## When to use
- At the end of a project, sprint or major milestone, to review what worked and what to change.
- When your team is struggling with a process, tool or way of working and needs to decide what to change.
- As a regular check-in, monthly or quarterly, to keep adjusting how your team works.
## Tips and tricks
- Make it safe to be honest and keep the session blame-free.
- If people are hesitant to raise concerns, use private brainstorming and anonymous voting.
- Pick the top item in each category and turn it into a concrete next step.
- Check on agreed improvements at the next retrospective.
- Rotate the facilitator so you get fresh perspectives and share the work.
- Start and end with the 'Keep' column so people see what's going well.
## Icebreaker questions
- If our team was a vehicle, what kind would it be and why?
- What's one thing you've learned or improved on since our last retrospective?
---
# Fishbone (Ishikawa) Retrospective
URL: https://www.teamretro.com/retrospective-templates/fishbone-ishikawa-retrospective/
The Fishbone (Ishikawa) Retrospective helps your team find the root causes of a problem instead of treating its symptoms. It's built on the cause-and-effect diagram that Kaoru Ishikawa popularized in the 1960s, which lays out possible causes in a shape that looks like a fish skeleton.
In this template your team works through six cause categories: System, Process, Forms, People, Policies and Place. Going category by category makes people look past the first explanation that comes to mind, so causes outside anyone's own area still get raised.
It's most useful for problems with several contributing factors, where one obvious fix hasn't worked. Sorting causes into categories shows how they connect, and that points you to the change that will make the biggest difference.
A fishbone diagram (also called an Ishikawa diagram or a cause-and-effect diagram; all three names mean the same tool) puts the problem at the "head" of the fish and draws the major cause categories as bones branching off the spine. In its original manufacturing and quality-management form, those categories are the "6 Ms": Manpower (people), Method (process), Machine (equipment), Material (inputs), Measurement (data and metrics) and Mother Nature (the surrounding environment). The team brainstorms possible causes under each bone, then keeps asking "why?" to follow each branch down to its root cause.
This template's categories adapt the 6 Ms for software and knowledge-work teams. The technique is the same; only the labels change to fit the work you do. If the problem at the head of the fish is "releases keep slipping," a People cause might be "key reviewer is a bottleneck," a Process cause might be "no definition of done," and a System cause might be "flaky CI pipeline." Mapping causes this way stops your team fixing a symptom and missing what's actually driving it.
## Topics
- **System**: What technology, software, or tools might be affecting our team's performance or outcomes?
- **Process**: What workflows or sequences of activities are causing delays or inefficiencies in our work?
- **Forms**: What issues with our templates or documentation could be impacting clarity or accuracy?
- **People**: What factors related to individual or team skills, communication, or roles are affecting our success?
- **Policies**: What guidelines or rules might be misaligned with our actual practices or creating challenges?
- **Place**: What aspects of our physical or virtual workspace might be impacting our collaboration or productivity?
## When to use
- When a problem probably has more than one cause
- After a significant issue that needs a structured look before anyone proposes a fix
- When the team keeps fixing symptoms and the problem keeps coming back
- In project post-mortems or incident reviews, to stop the same failure happening again
## Tips and tricks
- Write a clear problem statement at the head of the fish before anyone adds a cause
- Make sure everyone adds causes to every category, including the ones outside their own role
- Hold off on solutions until the causes are mapped
- Use the Five Whys inside each category to dig past the first answer
- Record every cause, even ones that seem minor at first
- Allow 90–120 minutes so you can cover all six categories properly
## Icebreaker questions
- If our team were a machine, what part would need the most maintenance right now?
- What's the most surprising solution you've discovered to a recurring problem?
---
# Cross-Team Collaboration Retrospective
URL: https://www.teamretro.com/retrospective-templates/cross-team-collaboration-retrospective/
The Cross-Team Collaboration Retrospective is for teams that depend on each other and feel the friction: handoffs that drop details, requests that sit unanswered, priorities that clash. Instead of each team complaining about the other in its own retro, people from both sides look at how they work together and agree on what to change.
The board has five columns. Collaboration Enablers names what already works, such as regular cross-team meetings or clearly defined roles. Communication Challenges covers where information gets lost or delayed. Synergy Opportunities looks for places where working together would save effort, like shared process improvements or joint planning. Trust and Psychological Safety asks what would make people comfortable raising a problem with another team. Ideal Outcomes describes what good collaboration would look like, so your actions have a target.
Run it after a cross-functional project, during a reorganization, or as a regular check-in between teams that share work. Get every team and role involved into the session, and make sure the actions have owners on each side.
## Topics
- **Collaboration Enablers**: What factors or practices have enabled effective collaboration across teams?
- **Communication Challenges**: What communication barriers or breakdowns have hindered cross-team collaboration?
- **Synergy Opportunities**: Where could our teams work together more effectively?
- **Trust and Psychological Safety**: How can we build trust and create a psychologically safe environment for cross-team collaboration?
- **Ideal Outcomes**: What are the potential benefits and ideal outcomes of effective cross-team collaboration?
## When to use
- When several teams are working on a shared project or initiative.
- When communication breakdowns, silos or low trust are getting in the way of joint work.
- When teams want to find where they could share expertise or effort.
- During organizational change or restructuring that affects how teams work together.
- As a regular check-in on how well your teams are working together.
## Tips and tricks
- Make it safe for people to speak frankly about working with another team, without fear of repercussions.
- Make sure every team and role involved is represented.
- Use a diagram or process map to show the handoffs and dependencies between teams.
- Have a dedicated facilitator manage time and make sure every participant gets a turn.
- Follow up on the action items at the next session to check what changed.
- Involve a leader or stakeholder who can back the changes the group agrees on.
## Icebreaker questions
- If you could collaborate with any team or department in the organization, which one would it be and why?
- Share a memorable experience where cross-team collaboration led to a significant achievement or breakthrough.
---
# Silicon Valley Startup Sprint Retrospective
URL: https://www.teamretro.com/retrospective-templates/silicon-valley-startup-sprint-retrospective/
The Silicon Valley Startup Sprint Retrospective runs your retro the way a startup team would. It's built on the build-measure-learn loop from lean startup thinking, popularized by Eric Ries in [The Lean Startup](https://theleanstartup.com/): treat each sprint as an experiment, look at what the results actually showed, and decide what to do next based on that evidence.
The board has four areas. Shipped & Won is for what the team shipped and what it moved for customers. What Slowed Us Down covers the blockers and friction that cost you velocity. What We Learned records what you assumed and what the data said. Pivot or Persevere is the decision point: what to double down on, what to change and what to cut.
It suits product teams, founders and innovation teams who want to keep moving without losing direction, and any team facing a call about whether to keep going with a piece of work. Finish with clear decisions and an owner for each, so the next sprint starts with a direction.
## Topics
- **Shipped & Won**: What did we ship that created value this sprint?
- **What Slowed Us Down**: What blockers or friction killed our velocity?
- **What We Learned**: What new insight or validated learning did we gain?
- **Pivot or Persevere**: What should we double down on, change, or cut?
## When to use
- At the end of a product sprint, when you want a quick review that looks forward.
- For startup teams, founders and innovation teams who want to move fast and stay focused on customers.
- When the team faces a decision about whether to pivot, persevere or cut a piece of work.
- When your retrospectives have become routine and a build-measure-learn framing would change the conversation.
## Tips and tricks
- Set the tone up front: this is about learning fast, not assigning blame. People share more when it's safe to be wrong.
- Use hypothesis language: what did we assume, and what did the results actually show?
- Timebox each topic to keep the pace up. A short list of real points beats an exhaustive one.
- In Pivot or Persevere, push for clear decisions with owners, not vague intentions.
- Use anonymous input in TeamRetro so the loudest voice doesn't decide the wins and the calls.
- Track recurring blockers across sprints to find the problems worth a bigger fix.
## Icebreaker questions
- If your team were a startup pitching at a demo day, what would your one-line elevator pitch be?
- Which famous tech founder's mindset would you want to channel for this sprint, and why?
---
# Meme Madness Retrospective
URL: https://www.teamretro.com/retrospective-templates/meme-madness-retrospective/
The Meme Madness Retrospective takes the classic Stop, Start, Continue format and gives each column a meme your team probably already shares in chat. The humor gives people a softer way into feedback that might otherwise feel awkward to raise, and it makes the session easier to remember.
The board has three columns. Stop uses the "This is fine" dog sitting in a burning room: what are you putting up with that's quietly causing damage? Start uses the "Distracted Boyfriend" meme for the new practices the team keeps eyeing but hasn't adopted. Continue uses "One Does Not Simply" for the habits that are working so well it would be a mistake to drop them. People can reference other memes in their notes too, as long as there's a real point underneath.
It suits teams that already share memes in Slack or Teams, and teams tired of running the same retro. Close each column with at least one concrete action, so the laughs lead somewhere.
## Topics
- **Stop (The "This is Fine" Meme)**: What should we stop doing that's quietly burning us down?
- **Start (The "Distracted Boyfriend" Meme)**: What shiny new ideas or practices should we finally commit to?
- **Continue (The "One Does Not Simply" Meme)**: What's working so well it would be chaos to stop?
## When to use
- After a sprint or project phase with a mix of highs and lows. The humor helps the team talk about both without getting defensive.
- For remote or hybrid teams that already share memes in team channels, so the format feels familiar.
- When team morale needs a lift and you want a retro people look forward to.
- When the team has run the same format for a while and needs a fresh way to surface the same important feedback.
- When onboarding new team members to your retros. The light tone makes it easier for everyone to contribute.
## Tips and tricks
- Share a relevant meme in your intro. It signals that humor is welcome.
- Encourage people to reference real meme formats in their notes, such as Drake pointing or Expanding Brain, but remind them the feedback underneath should still be genuine and actionable.
- Watch for a session that's all laughs and no actions. Close each column by agreeing on at least one concrete next step.
- If some people don't follow meme culture, share a few examples beforehand or do a two-minute primer at the start, so no one feels left out.
- Use dot voting to pick the most important items in each column.
- Keep the session to 60 minutes or less. The format keeps energy up, but it fades fast if the meeting drags.
## Icebreaker questions
- If your last sprint were a meme, which one would it be and why?
- What's a meme that perfectly describes your current relationship with your to-do list?
---
# Team Work Makes the Dream Work Retrospective
URL: https://www.teamretro.com/retrospective-templates/team-work-makes-the-dream-work-retrospective/
The Team Work Makes the Dream Work retrospective puts collaboration at the center. Instead of reviewing tasks and deliverables, your team looks at how it worked together: whether everyone was chasing the same goal, what made teamwork flow and where it broke down.
The board has four columns. Dream Goals checks that everyone has the same picture of success, and surfaces it when they don't. Working Together is for the habits and moments that made collaboration easy, like people jumping in unasked or shared docs that smoothed a handoff. Out of Sync holds the friction: decisions made in side conversations, unclear ownership, rushed handoffs. Make the Dream Work turns all of that into two or three commitments.
Most retros spend their time on the work itself, so problems in how people work together can go unmentioned for months. This format gives those problems a name and a column. Use it with a newly formed team finding its rhythm, with an established team that senses silos or friction, or after a big project to look at how the team held up.
## Topics
- **Dream Goals**: What shared goals are we chasing together?
- **Working Together**: What helped us collaborate effectively as a team?
- **Out of Sync**: Where did teamwork break down or cause friction?
- **Make the Dream Work**: What will we do to strengthen teamwork going forward?
## When to use
- When a newly formed team is finding its rhythm and wants good collaboration habits from the start.
- When an established team senses friction, silos or communication problems slowing it down.
- After a major project or milestone, to look at how well the team worked together.
- As a periodic team-building check-in on trust and shared goals.
- When new members join and you want everyone to agree on how the team collaborates.
## Tips and tricks
- Set a blame-free tone from the start so people feel safe being honest about teamwork.
- Use anonymous brainstorming before grouping and voting, so quieter members contribute.
- Talk about behaviors and situations rather than individuals when you discuss friction.
- Limit actions to two or three commitments so the team can follow through.
- Open by checking the previous retrospective's actions.
- Call out good collaboration when you see it. Recognition gets you more of the behavior you want.
## Icebreaker questions
- If our team were a sports team, what position would you play and why?
- What's the best team you've ever been part of, and what made it work?
---
# Cowboy Roundup Retrospective
URL: https://www.teamretro.com/retrospective-templates/cowboy-roundup-retrospective/
The Cowboy Roundup retrospective gives your team review a Wild West theme. Cowboys round up the herd, chase down the strays and pick a route across rough country, and your team does the same with its sprint. The light framing lowers the stakes of giving feedback, so people speak up more readily.
The board has four topics. Best Rides is for the wins and the moments people are proud of. Stray Cattle covers what wandered off course, such as scope creep or a messy handover. Rough Terrain is for the obstacles that slowed the team down, like slow reviews or approvals stuck in another department. Next Trail is where you decide where to head and what to try next. Calling problems strays to round up, instead of failures to blame, keeps the conversation constructive.
Run it at the end of a sprint, a project milestone or a quarter. It works for distributed teams in TeamRetro as well as for teams in one room, and you still finish with action items that have owners.
## Topics
- **Best Rides**: What went well and made you proud on the trail?
- **Stray Cattle**: What wandered off course or caused trouble?
- **Rough Terrain**: What obstacles slowed the team down?
- **Next Trail**: Where should we head and what should we try next?
## When to use
- At the end of a sprint, when the team wants a change from the standard retrospective format.
- After a major project or release milestone, to celebrate wins and round up lingering issues.
- When retrospectives feel stale and you want to re-engage a tired team.
- For quarterly reviews, when you want both a look back and a clear plan for the trail ahead.
- With distributed or hybrid teams that would enjoy a playful theme to break the ice.
## Tips and tricks
- Use a bit of Wild West language, and maybe a themed background, to set the mood.
- Keep Stray Cattle blame-free by focusing on issues and systems, not individuals.
- Timebox each topic so celebrating Best Rides doesn't crowd out the planning in Next Trail.
- Vote on the most important strays and obstacles before discussing them in depth.
- Turn the top Next Trail ideas into action items with owners and due dates so the improvements happen.
- Give everyone silent time to add their thoughts before discussion, so quieter team members contribute.
## Icebreaker questions
- If you were a cowboy or cowgirl, what would your trusty sidekick animal be and why?
- What's one 'wild frontier' challenge you tackled this sprint that you're proud of?
---
# Skeleton Crew Retrospective
URL: https://www.teamretro.com/retrospective-templates/skeleton-crew-retrospective/
Running with a skeleton crew means covering critical work while half the team is on leave, between hires or pulled onto other priorities. The Skeleton Crew Retrospective gives your team a slightly playful way to look back on a period when capacity was tight and only the essentials kept the lights on. It shows what really mattered, what got dropped without anyone noticing and how the team coped under pressure.
The Halloween theme keeps things light around a serious topic: workload and prioritization. The board has four areas. The Bones is for the essentials that held everything together. The Hauntings covers the stress and single points of failure that kept coming back. Dead Weight is for work the team could drop for good, and Raising the Dead is where you decide what to set up or bring back before the next lean stretch.
Run it after a holiday season, a hiring gap or an unexpectedly busy sprint. Finish with a few concrete actions, such as cross-training a second person on a critical system, each with an owner, so the next short-staffed period is less scary.
## Topics
- **The Bones**: What essentials held everything together while we were stretched?
- **The Hauntings**: What stressed us out or kept coming back to spook us?
- **Dead Weight**: What could we drop without anyone noticing or missing it?
- **Raising the Dead**: What should we revive or change before the next lean stretch?
## When to use
- After a holiday season or any period when much of the team was on leave and you ran on minimal staffing.
- During a hiring gap or after departures, when the remaining team had to cover critical work.
- After an unexpectedly busy sprint, when the team had to drop everything but the essentials.
- When you want to find single points of failure and fix them before the next lean period.
- As a seasonal retrospective around Halloween that still deals with a real workload problem.
## Tips and tricks
- Make it safe to talk. Running lean is stressful, so say up front that the goal is to learn, not to blame anyone for what slipped.
- Enjoy the Halloween theme, but make sure the actions that come out of it are concrete and owned.
- Give quieter or part-time members room to contribute. They may have covered unusual tasks and seen problems others missed.
- Watch for survivorship bias: celebrate what worked, but dig into the hauntings and single points of failure that could bite next time.
- Timebox each topic so you have real time left for Raising the Dead.
- Vote on improvements so the team commits to a few changes it can deliver, not an overwhelming list.
## Icebreaker questions
- If you were a Halloween character during our busiest week, which one would you have been and why?
- What's the one task you'd happily bury six feet under and never deal with again?
---
# Appreciation Round Retrospective
URL: https://www.teamretro.com/retrospective-templates/appreciation-round-retrospective/
Recognition is easy to skip when deadlines loom. The Appreciation Round retrospective sets aside time for your team to thank each other, celebrate shared wins and name the small (and big) moments that made a difference. Making appreciation a deliberate part of the meeting means it actually happens, and people hear exactly what their work meant to someone else.
The board has four topics. Thank You is for thanking specific people for specific help. Wins to Celebrate covers what the team achieved together. Qualities I Value recognizes the ongoing behaviors and strengths that make people good to work with. Pay It Forward asks how the team will keep appreciation going after the session. Each person adds their appreciations, then the team reads and discusses them together. The structure is simple enough to run as a standalone session or as the last part of a regular sprint retrospective.
Use it to end a project on a high note, to reconnect a team after a tough stretch, or to make thanks a regular part of how your team works. When people know their effort is noticed, they tend to keep showing up with energy.
## Topics
- **Thank You**: Who helped you and what did they do?
- **Wins to Celebrate**: What shared achievements should we recognize together?
- **Qualities I Value**: What behaviors or strengths make this team great?
- **Pay It Forward**: How can we keep appreciation going beyond today?
## When to use
- At the end of a major project or release, to thank everyone and finish on a positive note.
- When morale is low or after a stressful period, to reconnect people.
- As a regular ritual, so recognition becomes part of your team's normal rhythm.
- When a team member is leaving or a milestone is reached, to say what they've brought to the group.
- With a newly formed or recently merged team, to build trust early.
## Tips and tricks
- Ask for specifics. "Thank you for staying late to fix the build" lands better than "thanks for everything."
- Make sure everyone gives and receives appreciation, and steer some toward quieter team members who get overlooked.
- Keep the session free of criticism. Problems can wait for the next retrospective.
- Give people a minute of quiet before sharing so they can think of something meaningful.
- Keep it short. Even 15 minutes of real recognition changes how people feel about the week.
- Go first as the facilitator, with a specific appreciation that sets the tone.
## Icebreaker questions
- Who is someone outside of work you're grateful for right now, and why?
- What's a small thing that made you smile this week?
---
# Lead Generation and Quality Retrospective
URL: https://www.teamretro.com/retrospective-templates/lead-generation-and-quality/
The Lead Generation and Quality Retrospective is a meeting for sales and marketing to look at the leads you've brought in over a period and ask where they came from, whether they were the right people and whether they turned into business. It works best with numbers on the table, such as lead volume by source, how many leads matched your ideal customer profile (ICP) and conversion at each stage of the funnel.
The board has four columns. Lead Sources compares the channels that delivered with the ones that didn't. Lead Quality looks at how well leads fit your ICP and how your scoring and qualification held up. Conversion Rates follows leads from MQL to SQL to opportunity to closed-won, so you can see where they drop off. Areas for Improvement collects the bottlenecks, from slow hand-offs between marketing and sales to gaps in attribution.
Because both teams are in the room, it's a good place to settle disagreements about what counts as a qualified lead. Finish by turning the biggest gaps into actions with owners, and check them at the next review.
## Topics
- **Lead Sources**: Which lead sources performed well this period?
- **Lead Quality**: How well did the leads match our ideal customer profile?
- **Conversion Rates**: How effectively did we convert leads into opportunities and closed business?
- **Areas for Improvement**: What challenges or roadblocks impacted our lead generation and conversion efforts?
## When to use
- At the end of a sales quarter or marketing campaign, to review lead performance while the numbers are fresh.
- When you launch a new product, service or go-to-market plan, to check that the right leads are coming in.
- After a significant change to your marketing or sales process, to see what it did to lead quality and conversion.
- On a regular rhythm, such as quarterly or twice a year, as part of reviewing your revenue operations.
- When new marketing or sales people join, to agree on how leads are defined, scored and handed over.
## Tips and tricks
- Ask people to bring the metrics and reports they need, so the discussion starts from data.
- Invite marketing, sales and customer success. Each sees a different part of a lead's path.
- Capture every agreed fix as an action with an owner, and keep open questions in a parking lot.
- Split into smaller groups if you want to dig into one lead source or one stage of the funnel.
- Call out the wins as well as the problems, so the review doesn't turn into blame between teams.
- Rotate the facilitator so ownership is shared and no single team sets the agenda.
## Icebreaker questions
- If you could generate leads from any fictional universe, which one would you choose and why?
- Share a funny or embarrassing story from a past lead generation or sales experience.
---
# Dream Within a Dream Retrospective (Inception Edition)
URL: https://www.teamretro.com/retrospective-templates/dream-within-a-dream-inception-edition-retrospective/
The Dream Within a Dream Retrospective takes its idea from Christopher Nolan's film *Inception*, where the characters go down through dreams nested inside other dreams. Your team does the same with the last sprint, starting with what anyone could see and going down a layer at a time toward what people usually leave unsaid.
There are three levels and a way back out. Level 1: Reality covers the visible facts and events. Level 2: The Dream looks for patterns and habits that repeat sprint after sprint. Level 3: The Subconscious is for hidden tensions and unspoken truths. The Kick (Back to Reality) turns what came up into a few actions, the way the kick in the film wakes the dreamers.
The layers give the conversation a natural order: quick facts first, harder topics once people have warmed up. Use it when your usual format has gone stale or you suspect the real issues aren't being said out loud, and keep the action list short.
## Topics
- **Level 1: Reality**: What did you notice on the surface this sprint?
- **Level 2: The Dream**: What recurring patterns or habits are shaping our work?
- **Level 3: The Subconscious**: What hidden tensions or unspoken truths are below the surface?
- **The Kick (Back to Reality)**: What actions will bring us back, stronger than before?
## When to use
- When your team has retrospective fatigue and needs a different format to get people talking.
- When you want to get beneath surface-level observations to root causes and unspoken tensions.
- When people seem to be holding back, and a gradual move from easy topics to hard ones would help them speak up.
- When you want a themed session that still ends with concrete actions.
## Tips and tricks
- Set the scene with a quick reference to Inception so people understand the layers before they start.
- Don't rush the deeper layers. Give people quiet thinking time before they share at Level 3.
- Watch for one or two voices dominating, and invite quieter members in directly.
- Keep Level 1 short so you have time and energy for the levels below it.
- Limit The Kick to two or three actions so the commitments are realistic and owned.
- Tell the team that Level 3 is a judgment-free zone before you open it.
## Icebreaker questions
- If you could design your own dream world, what's the first thing you'd add to it?
- What's a recurring dream you've had, and what do you think it was trying to tell you?
---
# New Year Kickoff Retrospective
URL: https://www.teamretro.com/retrospective-templates/new-year-kickoff-retrospective/
The New Year Kickoff Retrospective is a session for the first weeks of January. Your team looks back over the previous year's achievements, challenges and lessons, including the busy holiday stretch, then agrees on goals for the year ahead. It draws a clean line between last year's work and this year's plans.
The board has four columns. Highlights and Achievements celebrates the year's biggest wins. Challenges and Lessons Learned covers what was hard and what it taught you. Goals and Priorities is where each person names what they want to achieve this year, and Continuous Improvement asks how the team can keep getting better at the way it works. Starting with the wins puts people in the right frame of mind to talk honestly about the hard parts.
You can adapt the prompts to your team's situation, whether that's a product team planning its roadmap or an operations team coming off its busiest season. Either way, people leave with shared goals, a few changes to how you work and actions with owners.
## Topics
- **Highlights and Achievements**: What were your biggest accomplishments or successes last year?
- **Challenges and Lessons Learned**: What were the biggest challenges you faced, and what did you learn?
- **Goals and Priorities**: What are your goals and priorities for the upcoming year?
- **Continuous Improvement**: How can we continue to improve and grow as a team?
## When to use
- At the start of a new year or quarter, to review the previous period and set goals for the next one.
- After a major project, initiative or busy season, to look at what went well, what was hard and what you learned.
- As a regular check on how the team works, so problems get talked about before they grow.
- When new team members have joined, to share the team's history and agree on goals and priorities together.
- During a period of change, to help the team adjust to new circumstances or a new direction.
## Tips and tricks
- Make it safe to be honest, so every perspective gets heard.
- Use a shared board, physical or digital, to capture and organize ideas as they come up.
- Have a dedicated facilitator keep the discussion on track and make sure everyone gets a turn.
- Break into smaller groups for some columns to get deeper discussion and more perspectives.
- Give every action item a clear owner and follow up on it in the weeks after the session.
- Celebrate the wins, and treat the failures as lessons the team can use this year.
## Icebreaker questions
- What was the most memorable or impactful moment for you during the past year, either professionally or personally?
- If you could sum up the past year in one word or phrase, what would it be and why?
---
# Three Little Pigs Retrospective
URL: https://www.teamretro.com/retrospective-templates/three-little-pigs-retrospective/
The Three Little Pigs retrospective uses the children's story to test how sturdy your team's practices are. Your team sorts what it does into three houses: straw for weak points, sticks for things that need reinforcing, and bricks for strong foundations. A fourth column, the Big Bad Wolf, covers the outside threats that could blow any of them down.
The houses make it easy to talk about durability. Straw is a quick fix or temporary workaround, like a deployment checklist that lives in a chat message. Sticks are processes that mostly work but need more structure. Bricks are the reliable practices you want to keep and copy elsewhere.
The light theme makes it easier for people to admit that something they built is made of straw, so the conversation stays relaxed even when the problems are serious.
## Topics
- **House of Straw**: Things that could easily fall apart
- **House of Sticks**: Things that are working but could be improved
- **House of Bricks**: Things that are strong and stable
- **The Big Bad Wolf**: What threats or challenges are we facing?
## When to use
- When you want to check how stable and sustainable your team's practices are.
- After a failure or setback has exposed weak points in how you work.
- During growth or change, when you need to know your foundations will hold.
- When process improvement talk has gone dry and you want a lighter way in.
## Tips and tricks
- Explain the metaphor up front and give an example for each house.
- Push for long-term fixes, not only the next quick patch.
- Use the wolf column to name outside threats, and keep it from turning into a complaint session.
- Pictures from the story help keep the theme going without much effort.
- Keep the tone light, but make sure the serious items still end up with actions.
- Save time at the end to plan how to turn straw and stick items into brick.
## Icebreaker questions
- If you could build a house from any material in the world, what would you choose and why?
- What's your favorite childhood story and what lesson did it teach you?
---
# Oh Canada Retrospective
URL: https://www.teamretro.com/retrospective-templates/oh-canada-retrospective/
The Oh Canada Retrospective gives your sprint review a friendly Canadian theme. Four prompts borrow from familiar Canadian icons, from the True North to maple syrup and that all-purpose "eh?", and each one maps to a standard retrospective question. The theme gives people something to smile about, and the questions still get to what happened in the sprint.
The board has four columns. True North covers what was strong and reliable this sprint. Eh? What Slowed Us Down is for what left you puzzled, frustrated or stuck. New Frontiers holds the fresh ideas and experiments to try next, and Maple Syrup Moments is where you thank the people and moments that made the sprint better. Because thanks get their own column, recognition doesn't get squeezed into the last two minutes.
Use it when your team needs a change from its usual format, to mark Canada Day, or for a distributed team that would enjoy a bit of personality in its retros. The outcome is the same as any good retrospective: agreed actions with owners.
## Topics
- **True North**: What went strong and reliable for us this sprint?
- **Eh? What Slowed Us Down**: What left us puzzled, frustrated or stuck this sprint?
- **New Frontiers**: What fresh ideas or experiments should we try next?
- **Maple Syrup Moments**: Who or what do we want to give thanks for, eh?
## When to use
- When you want a themed twist on your regular sprint retrospective to keep it fresh.
- Around Canada Day, or whenever you want to celebrate with a Canadian team.
- For distributed or Canadian teams that like a relaxed, inclusive tone.
- When team energy is low and a playful theme can get people talking again.
- As a celebration-focused retro after a big milestone or successful release.
## Tips and tricks
- Lean into the theme early. A friendly 'eh?' or a maple leaf on the board helps everyone relax.
- Timebox each column so the theme doesn't stretch the discussion.
- Allow anonymous contributions in Eh? What Slowed Us Down so people feel safe raising blockers.
- Turn the thanks in Maple Syrup Moments into ongoing recognition, not a one-off.
- Group similar ideas before voting so the actions with the most impact rise to the top.
- Close the loop by turning New Frontiers ideas into concrete actions with owners and due dates.
## Icebreaker questions
- If you could only eat one Canadian food for the rest of your life, would it be poutine, maple syrup, or a butter tart?
- What's the most 'Canadian' thing you've done this week, eh?
---
# No-Shave Movember Retrospective
URL: https://www.teamretro.com/retrospective-templates/no-shave-movember-retrospective/
Movember asks people to grow a mustache through November to raise money and awareness for men's health, including prostate cancer, testicular cancer, mental health and suicide prevention. No-Shave November is a similar campaign: participants skip shaving for the month and donate what they'd normally spend on grooming. This retrospective brings both into a team session, so you can reflect on the month and have a real conversation about health, fundraising and how your team supports each other.
The board uses a growth metaphor with three columns. What grew well? celebrates what flourished during the campaign, from the laughs to the money raised. What got patchy? covers where things felt uneven or fell short. Impact & conversations asks what awareness or change the campaign sparked. Run it as a standalone team session or as the wrap-up to a charity drive, while the month is still fresh.
In TeamRetro, remote and in-office colleagues contribute on equal terms, group similar ideas, vote on what matters most and turn good intentions into action items. You finish with a plan for next year's campaign and for keeping men's health on the agenda after November. Learn more about the cause on the [Movember Foundation site](https://movember.com).
## Topics
- **What grew well?**: What flourished during the Movember campaign?
- **What got patchy?**: Where did things feel uneven or fall short?
- **Impact & conversations**: What awareness or change did the campaign spark?
## When to use
- At the end of November, to wrap up your Movember or No-Shave campaign while it's still fresh.
- As a themed team session that mixes reflection with a real conversation about men's health.
- When closing out any charity drive or awareness initiative and you want to capture what you learned.
- To plan next year's fundraising and awareness efforts based on what people actually experienced.
- When you want a lighthearted retrospective that still makes room to talk about well-being.
## Tips and tricks
- Keep the tone light and inclusive. Not everyone can or wants to grow a mustache, so welcome other ways to take part.
- Share a few facts about Movember and men's health at the start so the session stays connected to its purpose.
- Use anonymous contributions in TeamRetro so people can share personal reflections on their health safely.
- Celebrate the wins, and be honest about the patchy spots so next year's campaign improves.
- Turn the top-voted ideas into action items with owners so good intentions don't fade once the mustaches come off.
- Be sensitive to the topic. Men's health includes serious subjects like mental health, so give people room and point them to support resources.
## Icebreaker questions
- If you had to grow one ridiculous facial-hair style for a month, what would it be and why?
- What's one small thing you do to look after your own health and well-being?
---
# AI-Assisted Work Retrospective
URL: https://www.teamretro.com/retrospective-templates/ai-assisted-work-retrospective/
Once AI agents and assistants are part of everyday work, it gets hard to tell real speed-ups from hidden costs. The AI-Assisted Work Retrospective gives your team an evidence-first way to review a cycle of AI-assisted delivery. You name the wins worth protecting, trace each piece of friction to a root cause, and then decide which friction you put there on purpose. That last step matters because not all friction is waste. Review gates, approval steps and verification loops are controls the team chose, and triage separates them from the waste before anyone rushes to "fix" them.
The board has five columns. Went well takes evidence-cited wins. Friction, with the cause names each drag and labels its root cause. Guesses we let stand collects the assumptions the agent (or the team) accepted without checking. Keep or kill marks each piece of friction as a control to protect or waste to remove, and Do this first ends with up to three fixes. Each fix lands at a named altitude (docs, environment, process, material or upstream), so it's aimed at the right level instead of becoming a generic to-do.
Asking for evidence behind wins, causes behind friction and honesty about unchecked assumptions keeps the retro clear of both hype and cynicism, and it gives the team a fixed vocabulary for AI-assisted work. In TeamRetro, everyone adds cards in parallel, groups shared themes and votes, and you leave with owned actions and a clear view of what to protect, what to remove and what to leave alone.
## Topics
- **Went well**: What did AI-assisted work make faster or better this cycle?
- **Friction, with the cause**: Where did it drag, and which root cause was it?
- **Guesses we let stand**: What did the agent (or we) assume without enough information?
- **Keep or kill**: Which of these frictions did we choose on purpose?
- **Do this first**: Of everything here, which one fix pays off most, and at what altitude?
## When to use
- At the end of a sprint or delivery cycle where AI agents or coding assistants did a real share of the work.
- When your team is scaling up AI-assisted workflows and wants to separate real gains from hidden costs.
- After a stretch of fast AI adoption, when friction and workarounds have piled up without review.
- When you suspect someone is about to remove friction that's actually a control worth keeping.
- When you want a shared team vocabulary for talking about AI-assisted work without hype or cynicism.
## Tips and tricks
- Agree on your root-cause vocabulary (docs, environment, process, material, upstream) before you start. Consistent labels make triage and prioritization much sharper.
- Insist on evidence for wins. "It felt faster" isn't a win; "it saved half a day of boilerplate" is.
- In Keep or kill, treat removing a control as a decision. Never delete a review gate just because it's slow. Check first that it isn't catching real problems.
- Cap the action list at three, each with a named owner and an altitude. A longer list usually means nothing gets done.
- Give quieter and more skeptical people room to speak. Enthusiasm for AI can drown out fair concerns about unchecked assumptions.
- Revisit Guesses we let stand next cycle to see whether any of them turned into real cost.
## Icebreaker questions
- If your AI assistant had a personality this sprint, would it be an eager intern, a know-it-all, or a quiet genius, and why?
- What's one task you'd never trust an AI with, and one you'd happily hand over tomorrow?
---
# Hiring Process Retrospective
URL: https://www.teamretro.com/retrospective-templates/hiring-process-retrospective/
The Hiring Process Retrospective is a structured meeting for reviewing how your organization recruits and onboards new people. HR, hiring managers and interviewers look back at a recent hiring round together, name what worked and what didn't, and agree on changes for the next one.
The board follows the whole process from job posting to a new hire's first weeks. Successful Hiring Practices is for what went well. Hiring Process Challenges covers pain points, like a slow time-to-hire or interviews that varied from team to team. Areas for Improvement collects ideas, and Action Plan turns the best of them into tasks with owners and dates.
Because each person sees a different part of the process, putting their views side by side shows problems no single person would spot. Use it to cut time-to-hire, improve the candidate experience or bring hiring closer to what the business actually needs.
## Topics
- **Successful Hiring Practices**: What aspects of our hiring process were effective and successful?
- **Hiring Process Challenges**: What challenges or pain points did we encounter in our hiring efforts?
- **Areas for Improvement**: What specific areas of our hiring process need improvement or change?
- **Action Plan**: What specific actions can we take to implement the identified improvements?
## When to use
- After a major hiring round, to see how well your process worked.
- On a regular schedule, such as quarterly or annually, to keep improving how you hire.
- When you're struggling to attract or keep strong candidates and want to find out why.
- After introducing new hiring tools or processes, to check their effect and adjust.
## Tips and tricks
- Invite people from every role involved in hiring, so you see the whole process.
- Keep the discussion about the process, not about individual interviewers or candidates.
- Bring data such as time-to-hire, cost-per-hire and candidate feedback to back up what people say.
- Rank the action items by likely impact and how easy they are to put in place.
- Give each action an owner and a deadline.
- Schedule a follow-up to check progress on the actions and adjust where needed.
## Icebreaker questions
- If you could hire anyone, living or historical, for a role in our organization, who would it be and why?
- Share a memorable experience, positive or negative, from your own hiring or job search process.
---
# October Harvest Retrospective
URL: https://www.teamretro.com/retrospective-templates/october-harvest-retrospective/
The October Harvest retrospective brings an autumn theme to your team's review. Farmers take stock at harvest time, and this format asks your team to do the same: celebrate what grew well, look honestly at what spoiled and decide what to plant for the months ahead.
The board has four columns. Bountiful Crops holds the wins worth celebrating. Rotten Produce covers what spoiled, caused problems or held you back. Seeds to Sow is for new ideas and experiments, and Ready to Preserve is for the practices worth carrying into next season. Rotten Produce is about what spoiled, not who, so the conversation stays on situations and processes. In TeamRetro you add, group and vote on ideas, then turn the top ones into action items, so the harvest ends with clear next steps.
It's a good fit for end-of-quarter check-ins, autumn team sessions or any time your usual format feels stale. Ready to Preserve gives your team a moment to decide which good habits to protect, which is easy to skip when a retro focuses only on problems and fixes.
## Topics
- **Bountiful Crops**: What flourished and is worth celebrating this season?
- **Rotten Produce**: What spoiled, caused problems, or held us back?
- **Seeds to Sow**: What new ideas should we plant for future growth?
- **Ready to Preserve**: What practices should we carry forward into next season?
## When to use
- End-of-quarter or end-of-cycle reviews, when you want to look back over a longer stretch of work.
- Autumn team sessions where a seasonal theme fits the time of year.
- When standard retrospectives feel stale and the team needs a change of pace.
- Whenever you want to balance celebrating wins with honest reflection and concrete plans.
## Tips and tricks
- Explain the harvest metaphor at the start so everyone knows how each column maps to their work.
- Timebox each column, and use TeamRetro's grouping to cluster similar ideas before discussion.
- Let quieter members add ideas anonymously so their views make it into the harvest.
- Keep Rotten Produce blameless by focusing on processes and situations instead of people.
- Turn Seeds to Sow into clear action items with owners so ideas don't wither after the meeting.
- Revisit Ready to Preserve at the start of your next retro to check the good habits actually stuck.
## Icebreaker questions
- What is your favorite thing about the autumn season?
- If your last sprint were a fruit or vegetable, what would it be and why?
---
# Mission Impossible: Agile Protocol Retrospective
URL: https://www.teamretro.com/retrospective-templates/mission-impossible-agile-protocol-retrospective/
The Mission Impossible: Agile Protocol retrospective treats your last sprint as a covert operation and your team as the agents who pulled it off. People report the objectives they completed, the gadgets that worked (and the ones that blew up), the moments that nearly blew their cover and the plan for the next assignment.
The board has four columns: Mission Accomplished, Gadgets That Worked, Self-Destruct Sequences and Next Mission Briefing. The spy story gives quieter agents an easy way in, and it lets the team talk about failures as intel to learn from instead of something to assign blame for. Gadgets That Worked is the column most formats lack: it asks which tools and tactics gave you an edge, so you keep using them on purpose. It's a good pick for teams that have run Start, Stop, Continue too many times and want a new angle on the same questions.
Whether your squad shipped features, defused a production incident or worked through a tricky backlog, the session ends with a plan. In TeamRetro you brainstorm, group, vote and assign action items together, so every mission closes with clear owners for the next operation.
## Topics
- **Mission Accomplished**: What objectives did we successfully complete?
- **Gadgets That Worked**: Which tools, processes or tactics gave us an edge?
- **Self-Destruct Sequences**: What nearly blew our cover or derailed the mission?
- **Next Mission Briefing**: What actions will we take on the next operation?
## When to use
- When your team wants a themed change of pace from its usual sprint retrospective.
- After a high-stakes sprint, launch or milestone that deserves a proper debrief.
- When morale is low and a playful format can get the team talking again.
- When you want failures to feel safe to discuss, by treating them as intel instead of blame.
- For distributed or remote agile teams that need something to pull everyone into the conversation.
## Tips and tricks
- Open with a short mission briefing in the style of a spy film to set a playful tone.
- Treat failures as intel so agents feel safe sharing setbacks.
- Timebox each column to keep the mission moving and stop one discussion from taking over.
- Use dot voting to decide which threats and actions matter most for the next mission.
- Close with clear action items, each with an owner, so the retrospective changes how the next sprint runs.
- Rotate the facilitator each sprint to keep the format fresh and share ownership of the mission.
## Icebreaker questions
- If you were a secret agent, what would your spy gadget of choice be and why?
- What's the most 'mission impossible' task you've ever pulled off at work?
---
# Aussie Adventure Retrospective
URL: https://www.teamretro.com/retrospective-templates/aussie-adventure-retrospective/
The Aussie Adventure retrospective turns your sprint or project into a road trip through the Australian outback. Instead of the usual columns, your team talks about the sunny stretches, the places it got bogged, the critters that jumped out of nowhere and the road ahead. The lighter framing lowers the stakes, which helps people speak honestly about what went wrong.
The board has four topics. Sunny Skies covers what went brilliantly. Bogged in the Billabong is for the blockers and friction that slowed you down. Critters & Surprises captures the unexpected events, good and bad, that nobody saw coming. The Road Ahead turns it all into next steps. After everyone adds ideas, you group similar ones, vote on priorities and agree on actions with owners.
Themed formats like this one help teams that run frequent retros and want to avoid format fatigue. You don't need to be in Australia to use it. The metaphors work for any team that wants a lighter session and still needs a practical list of actions at the end.
## Topics
- **Sunny Skies**: What went brilliantly and lifted the team?
- **Bogged in the Billabong**: Where did we get stuck or slowed down?
- **Critters & Surprises**: What unexpected things popped up along the way?
- **The Road Ahead**: What should we do next to keep moving forward?
## When to use
- When your team has retro fatigue and needs a different format to get people talking.
- At the end of a sprint or project milestone, to celebrate wins and surface blockers.
- For newer or distributed teams that want to build rapport and still leave with practical actions.
- When you want a lighter theme that lowers the stakes for quieter team members.
## Tips and tricks
- Use the outback metaphors throughout to keep the conversation moving.
- Timebox each topic so you leave plenty of room for The Road Ahead, where the action items come from.
- Group similar ideas before voting so the themes that matter most rise to the top.
- Invite quieter members to share a Sunny Skies moment first, which makes it easier for them to speak up later.
- Keep Bogged in the Billabong blame-free by focusing on systems and process, not individuals.
- Close by giving every next step an owner and a due date.
## Icebreaker questions
- If you could explore any Australian destination, would you pick the Outback, the Great Barrier Reef, or a city beach, and why?
- What's your spirit Aussie animal this sprint: a busy bee, a chilled-out koala, or a hopping-everywhere kangaroo?
---
# Mario Bros Level Up Retrospective
URL: https://www.teamretro.com/retrospective-templates/mario-bros-level-up-retrospective/
The Mario Bros Level Up Retrospective borrows the world of the Super Mario games to frame a team retro. A sprint becomes a level: you collect coins, run into Goombas, grab power-ups and head for the next castle. Most people know the imagery, and it makes it a little easier to talk about obstacles without anyone feeling blamed.
The board has four columns. Coins Collected is for the wins, big and small. Goombas in the Way covers the blockers and frustrations, framed as enemies to beat rather than faults to assign. Power-Ups names the tools, practices and people that gave the team a boost, so you can do more of what works. Next Level Goals sets concrete targets for the next sprint that build on the rest of the board.
It suits teams whose retros have started to feel repetitive, end-of-quarter reviews, and sessions where you want quieter people to join in. Keep the metaphor consistent and make sure the Goombas turn into actions, so the game leads to real change.
## Topics
- **Coins Collected**: What wins and achievements did we collect this round?
- **Goombas in the Way**: What blockers, obstacles or enemies slowed us down?
- **Power-Ups**: What gave us a boost or helped us perform better?
- **Next Level Goals**: What do we want to achieve in the level ahead?
## When to use
- When your retrospectives feel repetitive and you want a themed format to get people involved again.
- After a sprint or project milestone with clear wins to celebrate and obstacles to learn from.
- When you want quieter team members to share more openly.
- For team-building sessions or end-of-quarter reviews where a lighter, game-themed tone fits.
## Tips and tricks
- Introduce the theme at the start. A quick nod to the Mario games gets everyone into a playful mindset.
- Keep the metaphor consistent: coins are wins, Goombas are blockers, power-ups are boosts. That makes it easy to know where each idea goes.
- Timebox each column so the game keeps moving and you don't get stuck on one level.
- Make sure the Goombas turn into concrete actions, so the theme doesn't replace real follow-through.
- Ask everyone to add at least one coin, so recognition comes from the whole team instead of a few voices.
- Watch for the loudest voices taking over. Anonymous ideas and grouping in TeamRetro help balance participation.
## Icebreaker questions
- If you could have one Mario power-up at work this week, would it be the super mushroom, fire flower, or invincibility star, and why?
- Which video game character best represents how your sprint went, and what would they say about it?
---
# Pirates on the High Seas Retrospective
URL: https://www.teamretro.com/retrospective-templates/pirates-on-the-high-seas-retrospective/
The Pirates on the High Seas retrospective casts your sprint or project as a voyage. Your team looks back at the treasure it found and the storms it got through, then looks ahead to the islands worth exploring and the rocks that could sink the ship. The theme is playful, and that's the point: people find it easier to name a "reef" than to say "I'm worried this will fail."
The board has four areas. Treasure is for wins and discoveries. Storms covers the setbacks and pressure the team battled through. Islands of Opportunity is for ideas and experiments worth trying, and Rocks & Reefs is for hidden risks like technical debt, single points of failure or burnout. In TeamRetro, the crew adds ideas privately, groups and votes on them, and turns the top items into action items with an owner, so you leave with a new heading as well as a good story.
Themed formats like this one are useful when the team has run Start/Stop/Continue so often that the answers come out on autopilot. Changing the frame gets experienced teams thinking again, gives newcomers an easy way in, and the Rocks & Reefs column brings up risks a plainer format can miss.
## Topics
- **Treasure**: What wins or discoveries did we find?
- **Storms**: What rough weather or challenges did we battle?
- **Islands of Opportunity**: What promising new lands or ideas should we explore?
- **Rocks & Reefs**: What hidden dangers could sink us if ignored?
## When to use
- When your team has run the same Start/Stop/Continue format for a while and the answers have gone flat
- At the end of a sprint or milestone, when you want to celebrate wins and also talk about the risks ahead
- With newer or distributed teams, where a playful structure makes honest sharing easier
- When you want to bring up hidden risks and technical debt without making the session feel tense
## Tips and tricks
- Use nautical language to keep the session playful, but don't let the metaphor hide the real issues
- Timebox each area so the crew doesn't spend the whole session on Treasure and skip the harder Rocks & Reefs conversation
- Use anonymous brainstorming in TeamRetro for Storms and Rocks & Reefs so quieter people feel safe naming sensitive risks
- Group and vote on ideas before discussing them, so your limited time goes to the items that matter most
- Turn the top Islands of Opportunity and Rocks & Reefs into action items with an owner. A voyage with no new heading was wasted
- Rotate the facilitator each session so a different person takes the helm
## Icebreaker questions
- If you were a pirate, what would your pirate name and signature catchphrase be?
- What's the one item you'd absolutely want stashed in your treasure chest on a long voyage?
---
# Netball Retrospective
URL: https://www.teamretro.com/retrospective-templates/netball-retrospective/
The Netball retrospective uses the language of netball to help your team look back on its work. Netball depends on footwork, positioning and passing, so its terms map neatly onto how a team coordinates. The four columns cover what you achieved, what got in your way, where you overreached and which positions to change.
Point celebrates what the team scored. Obstruction (in netball, defending too close to the player with the ball) covers what stood in your way. Stepping, the footwork violation, is about the times you took on too much or lost your balance. Switch positions asks what you could change to play better next time. Each column ties individual effort back to the team's result.
It suits teams that respond well to sports analogies, and it's a natural fit for anyone who plays or follows netball. If some people don't know the game, explain the four terms at the start. They're simple, and each column's prompt makes sense on its own.
## Topics
- **Point**: What did we achieve?
- **Obstruction**: What got in our way?
- **Stepping**: What made us overreach or lose balance?
- **Switch positions**: What can we change to improve our performance?
## When to use
- After a major project or milestone, to review how the team performed and worked together
- When coordination or communication between team members needs work
- For teams that respond well to sports analogies and a bit of competition
- When roles are being reassigned or the team is being restructured
## Tips and tricks
- Ask people to think about their own performance and the team's
- Explain the netball terms at the start for anyone who doesn't know the sport
- Keep feedback about what happened, not about the person
- Keep the energy up with a game-day feel
- Set a timebox for each column to keep the session moving
- Write action items clearly and give each one an owner
## Icebreaker questions
- If our team was a sports team, what would be our signature winning move?
- What position would you play in our team's game, and why?
---
# Sprint Retrospective
URL: https://www.teamretro.com/retrospective-templates/sprint-retrospective/
The sprint retrospective is the scrum event where your team stops at the end of a sprint, looks at how the work went and agrees what to change. This sprint retrospective template gives you four prompts: what went well, what could be improved, what actions you'll take, and what still puzzles you.
Run it every sprint and the small fixes add up. Looking at wins, problems and open questions side by side lets your team adjust how it plans and works, and the actions you agree on carry into the next sprint with a named owner. The puzzles column keeps unanswered questions on the board so they get picked up instead of forgotten.
## Topics
- **What went well?**: Discuss the positive aspects and successes from the last sprint.
- **What could be improved?**: What slowed us down, and where did we struggle?
- **What actions can we take?**: Propose specific steps to address the areas for improvement.
- **What still puzzles us?**: Surface any open questions, concerns or areas needing further discussion.
## When to use
- At the end of each sprint or iteration, to review how the work went and what to change.
- When your team keeps hitting the same problems and needs to change its approach.
- After a major milestone or release, to capture lessons before the next phase.
- When a new team forms, or when people join or leave and the way you work shifts.
## Tips and tricks
- Set a blame-free tone so people raise problems honestly.
- Hear from everyone, including the quieter people. Silent brainstorming before discussion helps.
- Turn problems into actions. A list of complaints with no next step changes nothing.
- Give each action an owner and a due date, and check on them at the next retro.
- Call out wins and thank the people behind them.
- Timebox each section so the meeting stays focused.
## Icebreaker questions
- If our team was a vehicle, what kind would it be and why?
- What's the best lesson you've learned from a past project?
---
# Spartan Triumph Retrospective
URL: https://www.teamretro.com/retrospective-templates/spartan-triumph-retrospective/
The Spartan Triumph Retrospective borrows the image of an ancient Spartan army returning from a campaign. Your team looks back on the work it just finished as if it were that campaign: the battles it won, the scars it took and the plan for what comes next.
The board has four columns. Battles Won is for the wins worth celebrating. Battle Scars holds the setbacks and what they taught you. Weapons & Allies is where people name the tools, practices and teammates that helped. Next Campaign turns all of that into a short list of actions with owners.
The theme gives people permission to talk about hard work with a bit of swagger, which tends to get more out of a tired team than a plain "what went well" list. Run it after a big release or a demanding quarter, when the team has earned a proper look back. In TeamRetro you brainstorm privately, group and vote on ideas, then carry the Next Campaign actions into your next retro.
## Topics
- **Battles Won**: Which victories should we celebrate from this campaign?
- **Battle Scars**: What wounds or setbacks did we take, and what can we learn?
- **Weapons & Allies**: What tools, people or practices helped us prevail?
- **Next Campaign**: What strategy and actions will guide our next conquest?
## When to use
- After a major project, release or demanding quarter, when the team has earned a proper look back at what it achieved.
- When morale is low and you want a themed alternative to your usual sprint retrospective.
- When a team that has just been through something hard together needs to recognize that as a shared effort.
- When quieter members tend to hold back and a playful theme might get them talking.
## Tips and tricks
- Set the scene with the Spartan theme at the start, but keep it light so nobody feels they have to play along.
- Keep Battle Scars about learning. If the discussion turns to blame, bring it back to what the team would do differently.
- Use dot voting to pick the battle scars and next-campaign actions that matter most, so you don't try to fix everything at once.
- Give everyone a few minutes of silent brainstorming before discussion, so quieter people get their ideas on the board.
- Close by giving each Next Campaign action an owner and a due date.
- Rotate themes over time so recurring retros don't go stale.
## Icebreaker questions
- If you were a Spartan warrior, what would be your weapon of choice and why?
- What's one personal win from this sprint, big or small, that deserves a battle cry?
---
# Beethoven's Symphony of Agile Retrospective
URL: https://www.teamretro.com/retrospective-templates/beethovens-symphony-of-agile-retrospective/
A classical symphony is usually written in four movements, each with its own mood. The Beethoven's Symphony of Agile retrospective borrows that structure: your team reviews its sprint or project as a four-movement piece, from the strong opening notes to the discordant moments, the themes worth repeating and the crescendo you want to build toward.
Each movement maps to a familiar retrospective question. Opening Movement asks what set the tone. Discordant Notes covers what felt out of tune. Recurring Themes picks out the habits that deserve an encore, and The Crescendo turns all of it into actions for a stronger finish. The musical framing gives a routine meeting a different shape, which helps people engage with both the wins and the pain points.
Nobody needs to know classical music to take part. It suits teams that want to refresh their retrospective with something more imaginative, and by the end of the session you'll have a short score of action items, each with an owner.
## Topics
- **Opening Movement**: What powerful notes set the tone this sprint?
- **Discordant Notes**: Where did things feel out of tune or off-key?
- **Recurring Themes**: Which motifs are worth playing again and again?
- **The Crescendo**: How do we build toward a stronger finale next time?
## When to use
- When your regular retrospective feels stale and you want a creative, themed session.
- At the end of a significant sprint, milestone or project with both wins and tensions to explore.
- When you want a memorable metaphor that helps less vocal team members join the conversation.
- For teams that enjoy a playful frame and want to balance celebration with honest problem-solving.
- As a quarterly or special-occasion retrospective that still ends with clear actions.
## Tips and tricks
- Play a Beethoven symphony quietly in the background while the team brainstorms to set the mood.
- Use the musical metaphor to introduce each movement, but keep the prompts concrete so people know what to write.
- Timebox each movement so the session keeps a steady tempo and you reach the crescendo with time to spare.
- Use anonymous brainstorming for Discordant Notes so people can be honest without fear of blame.
- Group and vote on ideas before the crescendo so the actions focus on the highest-impact themes.
- Close by giving every action item an owner and a due date.
## Icebreaker questions
- If this sprint were a piece of music, what genre would it be and why?
- What's a song that perfectly captures your mood right now?
---
# Country Music Roundup Retrospective
URL: https://www.teamretro.com/retrospective-templates/country-music-roundup-retrospective/
The Country Music Roundup retrospective borrows from the way country songs tell stories: the big hit, the heartbreak ballad, the tribute to someone who earned it, the long road ahead. Your team looks back on a sprint or project in the same four parts, and the light theme makes it easier to be honest about the rough patches.
The board has four tracks. Chart-Topping Hits is for your biggest wins. Sad Country Ballads covers what caused heartache or slowed you down, from flaky tests to requirements that changed mid-sprint. Unsung Heroes is for thanking the people and behind-the-scenes work that usually go unnoticed. The Open Road Ahead turns the discussion into changes and experiments to try next.
That's the same ground as a classic retrospective: wins, problems, recognition and next steps. The difference is the framing. It suits a team tired of the usual "what went well, what didn't" routine, or a milestone or end-of-quarter session where a lighter tone fits.
## Topics
- **Chart-Topping Hits**: What were our biggest wins this time around?
- **Sad Country Ballads**: What caused us heartache or slowed us down?
- **Unsung Heroes**: Who or what deserves a shout-out and thanks?
- **The Open Road Ahead**: What should we change or try on the road ahead?
## When to use
- Your team is tired of the standard retrospective format and wants a new theme.
- You want to lighten the mood after a tough sprint and still get honest feedback.
- You're building rapport in a team and want a relaxed setting for reflection.
- It's a milestone, the end of a quarter or another moment that calls for something more playful.
## Tips and tricks
- Play some country music as people join to set the mood.
- Keep Sad Country Ballads blame-free. Talk about problems and processes, not people.
- Timebox each track so the discussion stays balanced and you reach The Open Road Ahead.
- Ask everyone, including quieter team members, to add at least one Unsung Heroes shout-out.
- Group similar ideas before voting so the discussion goes to the biggest themes.
- End every session with clear action items, each with an owner.
## Icebreaker questions
- If your week had a country song title, what would it be?
- Cowboy boots, big hat, or pickup truck: which one best describes your work style and why?
---
# Dungeons & Dragons Quest Retrospective
URL: https://www.teamretro.com/retrospective-templates/dungeons-and-dragons-quest-retrospective/
The Dungeons & Dragons Quest retrospective treats your last sprint or project as a tabletop adventure. Your team is the party, and the work you just finished is the campaign, complete with monsters fought, loot collected and a few traps nobody saw coming.
The board has four columns. Dragons We Slayed is for the big challenges you overcame. Treasure We Found collects wins and gains, from shipped features to new skills. Traps We Triggered covers mistakes, risks and pitfalls. Next Quest is where you set goals and turn the best ideas into actions with owners.
Telling the sprint as a story makes it easier to talk about, and people who rarely speak up in a standard retro often join in once there's a dragon involved. The structure keeps it grounded, so by the end the party knows what it's doing next. You don't need to play D&D to take part, since each column takes a sentence to explain.
## Topics
- **Dragons We Slayed**: What big challenges or obstacles did we overcome?
- **Treasure We Found**: What wins, gains or rewards did we collect along the way?
- **Traps We Triggered**: What mistakes, risks or pitfalls tripped us up?
- **Next Quest**: What adventures and goals should the party tackle next?
## When to use
- After a long or intense project, when the team needs a lighter way to look back.
- When you want a less formal review that gets quieter team members telling their side of the story.
- When you've had big wins and hard fights and want a memorable way to capture the lessons.
- When a new team is getting to know each other and could use a retro that doubles as an icebreaker.
- When your regular sprint retrospectives have gone stale and people have stopped contributing.
## Tips and tricks
- Set the scene by narrating the team's recent work as a quest. A little drama helps people get into character.
- Not everyone plays D&D, so explain each column in a sentence before people start writing.
- Timebox each phase so the storytelling stays lively and you keep time for actions.
- Use anonymous brainstorming first so every adventurer contributes, not only the loudest party member.
- Close by turning the best Next Quest ideas into actions with owners and due dates.
- Keep Traps We Triggered blame-free so people can share mistakes as lessons for the whole party.
## Icebreaker questions
- If you were a Dungeons & Dragons character class, which would you be and why?
- What magical item would you want in your inventory to help with your work?
---
# AI Evolution Retrospective
URL: https://www.teamretro.com/retrospective-templates/ai-evolution-retrospective/
Code assistants, content generators and automated analysis have found their way into most teams' daily work, often one person at a time. Teams rarely stop to ask what's actually working, what's risky and where to go next. The AI Evolution Retrospective gives your team that time, and it turns scattered observations into one honest conversation.
The board has four columns: AI Wins, Friction & Frustrations, Risks & Concerns and Next Experiments. Working through them gives you a balanced view of where the team really is with AI, somewhere between the hype and the fear. The conversation brings out practical lessons, gets everyone agreed on responsible use, and shows which investments in tooling, training or guardrails would make the biggest difference.
It works for any team bringing AI into its work, whether that's an engineering squad adopting coding copilots, a marketing team trying generative content or a leadership group setting AI policy. Run it quarterly or at key milestones, and you'll see how the team's use of AI changes over time and whether it's staying safe and worth the effort.
## Topics
- **AI Wins**: Where has AI helped us work smarter or faster?
- **Friction & Frustrations**: Where has AI slowed us down or let us down?
- **Risks & Concerns**: What worries us about how we're using AI?
- **Next Experiments**: What should we try, learn, or build next?
## When to use
- After several weeks or months with new AI tools, to see what's working and what isn't.
- When your team wants to agree on responsible AI use before scaling it further.
- Every quarter, to track how the team's use of AI is changing.
- When AI adoption feels chaotic and you need to settle on fewer tools and shared standards.
- Before setting AI strategy, policy or training plans for the next period.
## Tips and tricks
- Set a ground rule at the start: raising concerns about AI is welcome. People should be able to flag a risk without looking resistant to change.
- Ask for concrete examples and named tools, not general opinions. That makes wins repeatable and frustrations fixable.
- Make sure optimists and skeptics both get heard. AI conversations tip easily into hype or fear.
- Use anonymous brainstorming for Risks & Concerns so people are honest about data privacy and over-reliance.
- Close by committing to two or three experiments, so the team doesn't overload itself between sessions.
- Track numbers where you can, such as time saved or error rates, so the next retro starts from evidence.
## Icebreaker questions
- If you could hand off one part of your job to an AI today, what would it be and why?
- What's the most surprising thing, good or bad, that an AI tool has done for you recently?
---
# Black Friday Frenzy Retrospective
URL: https://www.teamretro.com/retrospective-templates/black-friday-frenzy-retrospective/
Black Friday is the high-pressure peak of the retail calendar: traffic spikes, flash deals, fulfillment crunches and everyone on deck. Once the dust settles, the Black Friday Frenzy Retrospective gives your team a structured way to go over what actually happened. You capture the wins worth repeating, the bottlenecks that nearly broke things and the lessons that make next season calmer.
The board has four topics. Deals That Delivered covers what worked and should be repeated. Bottlenecks & Breakdowns is for what caused stress, delays or near-misses. Prep & Planning looks back at how well you were set up before the big day, and Lock It In For Next Time collects the improvements you'll commit to. E-commerce, marketing, operations, support and engineering teams all see the event differently, and this format gets every view onto one board while the details are fresh.
The real payoff is turning a once-a-year adrenaline rush into documented knowledge you can reuse. Celebrate the effort, name the friction honestly and agree on next steps with owners. Your team then goes into the next big retail moment (Cyber Monday, the holiday rush or next year's Black Friday) with a plan instead of a scramble.
## Topics
- **Deals That Delivered**: What worked well and is worth repeating next time?
- **Bottlenecks & Breakdowns**: What caused stress, delays or frustration during the event?
- **Prep & Planning**: How well were we set up before the big day?
- **Lock It In For Next Time**: What improvements should we commit to for the next event?
## When to use
- Right after Black Friday, Cyber Monday or another major sales event, while details are fresh.
- When preparing for the next peak retail season and you want to carry the lessons forward.
- For e-commerce, retail, marketing, operations or support teams that went through a high-volume period together.
- To recognize the team's effort after an intense all-hands push and rebuild energy.
- When you want to turn a once-a-year experience into a documented, repeatable playbook.
## Tips and tricks
- Run the session within a week of the event, while memories are still fresh and accurate.
- Set a blameless tone up front. The goal is to improve systems, not to find someone to blame.
- Invite people from marketing, ops, support and engineering so you get the full picture.
- Spend real time celebrating wins as well as fixing problems. People are tired after the rush.
- Prioritize improvements by impact and effort, then give each one an owner and a deadline.
- Write the findings into a runbook you can reuse and refine before the next peak season.
## Icebreaker questions
- What was your personal 'oh no' moment during the Black Friday weekend?
- If you could give your past self one piece of advice before the event kicked off, what would it be?
---
# Lost Deals Retrospective
URL: https://www.teamretro.com/retrospective-templates/lost-deals-retrospective/
A Lost Deals Retrospective is a focused meeting where your sales team reviews recent opportunities that didn't close. It looks past the reason logged in the CRM ("price" or "timing") and asks what actually happened: where the deal went off track, what the team still did well and what to change before the next one.
The board has four columns. What went wrong? collects the factors behind the loss, from pricing and a missing feature to weak qualification or slow responses. What went well? keeps the good work visible, such as a sharp discovery call or a strong demo, so the team doesn't throw out what works. What can we learn? looks for the patterns across deals. What should we do differently? turns those patterns into changes to your process, messaging or playbooks.
Keep it blame-free. The point is to find gaps in the process, not to second-guess the rep who owned the deal. Review one big loss while the details are fresh, or a batch of losses each quarter to spot trends.
## Topics
- **What went wrong?**: What factors contributed to losing the deal?
- **What went well?**: What did we do right during the sales process?
- **What can we learn?**: What key lessons or insights did we gain?
- **What should we do differently?**: How can we apply these lessons to improve?
## When to use
- After losing a major opportunity, while the details are still fresh.
- On a regular rhythm, such as quarterly, to review a batch of lost deals and look for patterns.
- When the team is missing targets or seeing a high share of deals fall through late in the cycle.
- When you're reworking your sales process, playbooks or enablement and want evidence for what to change.
## Tips and tricks
- Keep it blame-free. Focus on learning, not on who lost the deal.
- Invite everyone who touched the deal, such as sales development, pre-sales and account management, for a fuller picture.
- Bring what you know from the buyer's side, such as their stated reason for choosing someone else or notes from a win/loss interview.
- Document the main findings and commit to specific actions.
- Follow up to check the actions were carried out and made a difference.
- Consider an outside facilitator if the loss is sensitive or the team is too close to it.
## Icebreaker questions
- If you could be a door-to-door salesperson, what would be the worst or weirdest product to sell?
- What's the most memorable or cringeworthy sales call or pitch you've experienced?
---
# End of Year Retrospective
URL: https://www.teamretro.com/retrospective-templates/end-of-year-retrospective/
An end of year retrospective is a chance for your team to look back on the past 12 months together. You celebrate what went well, dig into the setbacks and work out what to change before next year's planning starts.
The template has four topics: highlights and achievements, challenges and obstacles, lessons learned, and areas for improvement. Working through them in that order moves the conversation from the year's wins to what you'll do differently, and the lessons column keeps setbacks from turning into a blame session.
A year is long enough that people remember it differently. Reflecting as a group gives everyone the same picture of what happened, and that shared picture is a better starting point for next year's goals than any one person's memory.
## Topics
- **Highlights and achievements**: What were the team's most significant accomplishments this year?
- **Challenges and obstacles**: What were the most significant challenges or setbacks the team faced?
- **Lessons learned**: What lessons did the team learn from the challenges it faced?
- **Areas for improvement**: What aspects of our work or processes could be improved in the coming year?
## When to use
- At the end of a calendar or fiscal year, to review the past 12 months.
- During annual planning or goal-setting, so next year's plan builds on this year's lessons.
- After finishing a major project or initiative, to capture lessons learned.
- When new team members join, to give them context on the year that's just happened.
- Whenever you want to step back from sprint-level detail and look at the bigger picture.
## Tips and tricks
- Set a no-blame tone at the start so people can be honest about the hard parts of the year.
- Bring a timeline of the year's big moments to jog people's memories.
- Ask someone to take notes on decisions and action items.
- Celebrate the wins, and treat failures as lessons to learn from.
- If discussion drifts toward who caused a problem, bring it back to what the team can change.
- Turn each area for improvement into a plan with an owner, and check on it in your first retrospective of the new year.
## Icebreaker questions
- What was the most memorable moment or highlight of the past year for you?
- If you could describe the past year in three words, what would they be?
---
# Pathfinder Retrospective
URL: https://www.teamretro.com/retrospective-templates/pathfinder-retrospective/
The Pathfinder retrospective moves your team from talk to a test in one session. Many retros end with a vague action like "improve communication." This one ends with a small experiment that has a goal, a time limit and a way to tell whether it worked.
The board has three columns that run in order. Let's discuss is where people raise the topics, observations and frustrations worth talking about. Let's change narrows those down to the areas the team could realistically change. Let's try turns each of those into a specific experiment, like piloting a 30-minute planning meeting for two sprints.
It suits teams that feel stuck in their current way of working or keep hitting the same problems. Because each experiment is small and timeboxed, trying something new carries little risk, and the next retro has a clear result to review.
## Topics
- **Let's discuss**: What should we talk about?
- **Let's change**: What areas of change could we pursue?
- **Let's try**: What should we try or experiment with?
## When to use
- When the team feels stuck in its current practices and wants to try something different
- During an organizational change, when old ways of working no longer fit
- When you want the team to test ideas in practice instead of debating them
- When the same issues keep coming back and past actions haven't fixed them
## Tips and tricks
- Keep experiments small and timeboxed, so a failed one costs little and still teaches you something
- Give each experiment a success measure and a review date before the session ends
- Record the experiments that failed as well as the ones that worked, so the next team doesn't repeat them
- Hear from everyone in Let's discuss before narrowing down; the best experiment often comes from a quieter voice
- Open the next retrospective by reviewing each experiment and deciding whether to keep, adjust or drop it
## Icebreaker questions
- What's the most interesting experiment or new approach you've tried recently, either at work or in your personal life?
- If you could instantly change one thing about how we work together, what would it be?
---
# AI Agents Assemble Retrospective
URL: https://www.teamretro.com/retrospective-templates/ai-agents-assemble-retrospective/
AI agents now draft code, triage tickets and summarize long threads for a lot of teams, and the way work gets planned and shipped is changing quickly. The AI Agents Assemble Retrospective gives your team time to look at how people and agents are working together: what is actually speeding up delivery, where handoffs break down, and how much the team trusts its automated teammates. It's a playful format with a practical point, written for product, engineering and operations teams who use agents, copilots or automation every day.
The board has four columns. Algorithmic Wins is for the times an agent saved the day. Glitches and Error 500s covers friction, risk and rework. New Powers Unlocked is for the skills and habits the team is building, and Next Projects is where you decide what the agents take on next. Everyone adds ideas, groups related themes, votes and turns the top items into actions in TeamRetro, so the wins and the concerns about quality, oversight and over-reliance get equal time.
Run it regularly and your team builds a deliberate playbook for working with agents, instead of each person picking up tools on their own. That means less rework, and a person stays in the loop on anything that matters.
## Topics
- **Algorithmic Wins**: Where did AI agents save the day for us?
- **Glitches and Error 500s**: Where did AI agents cause friction, risk, or rework?
- **New Powers Unlocked**: What skills, habits, or workflows are we developing?
- **Next Projects**: What should our AI agents take on next?
## When to use
- Your team has recently brought AI agents, copilots or automation into its workflows and wants to see the impact.
- You want an honest conversation about where AI is helping and where it's creating risk or rework.
- People on the team use AI tools in very different ways, and you want shared practices and guardrails.
- You're running a regular check-in to keep AI adoption deliberate, with a person in the loop.
- Leadership wants to see the productivity gains and the concerns that come with AI tools.
## Tips and tricks
- Set the tone early: the session is about how people and AI work together, not about judging anyone's tool use.
- Ask for specific examples with a measurable effect, not general praise or criticism of AI.
- Give wins and risks the same airtime so the team neither hypes the technology nor dismisses it.
- Record security, privacy and compliance concerns as action items so they don't stall the conversation.
- Rotate facilitation and invite quieter people to share. AI experience varies a lot across most teams.
- Turn the top-voted Next Projects items into owned actions with due dates.
## Icebreaker questions
- If you could assign one boring task to an AI agent forever, what would it be?
- Which fictional robot or AI would you most want on your team, and why?
---
# Engineering Team Retrospective
URL: https://www.teamretro.com/retrospective-templates/engineering-team-retrospective/
The Engineering Team Retrospective is built for developers, QA, DevOps and engineering leads. It covers the technical side of the work, like code quality, tests, pipelines and technical debt, alongside the human side: how the team communicated, shared knowledge and handled on-call.
The board has four columns, each a question. What worked well? records the practices and wins to keep. What slowed us down? collects the blockers, friction and debt. How did we collaborate? looks at communication and support across the team. What should we try next? turns the discussion into a few experiments with owners.
In TeamRetro everyone adds ideas at the same time, then the team groups them, votes on what matters most and turns the top items into tracked actions. Run it at the end of each sprint, after a major release or as a regular check-in, and keep it blameless so people mention the flaky test they ignored as readily as the refactor they're proud of.
## Topics
- **What worked well?**: Which engineering practices or wins should we keep?
- **What slowed us down?**: What blockers, friction, or technical debt held us back?
- **How did we collaborate?**: How well did we communicate and support each other?
- **What should we try next?**: What experiments or improvements should we commit to?
## When to use
- At the end of each sprint or iteration, to review engineering practices and delivery.
- After a major release, incident or production issue, to capture lessons without blame.
- As a regular check to catch technical debt, bottlenecks and collaboration friction before they grow.
- When onboarding new engineers or changing team structure, to agree on ways of working.
## Tips and tricks
- Keep it blameless. Talk about systems, processes and circumstances, not individuals.
- Collect ideas anonymously and in parallel before discussion, so quieter engineers contribute as much as senior ones.
- Use dot voting to pick the topics with the most impact, and leave the rest for another session.
- Agree on a few concrete actions with owners, and review them at the start of the next retrospective.
- Timebox each column so one technical debate doesn't take over the session.
- Rotate the facilitator so the team shares ownership and the format stays fresh.
## Icebreaker questions
- If your codebase were a city, what kind of place would it be right now?
- What's one piece of tech or tooling you couldn't live without this sprint?
---
# Seasons of the Year Retrospective
URL: https://www.teamretro.com/retrospective-templates/seasons-of-the-year-retrospective/
The Seasons of the Year Retrospective uses the four seasons as a way to talk about where your team is right now. Some work is starting to sprout, some is at its peak, some is changing and some has slowed to a stop. Naming a season is often easier than saying "this isn't going well," so harder topics come up sooner.
The board has four areas. Spring is for new beginnings: fresh ideas, new skills and new working relationships. Summer is for what's working at its best. Autumn covers what's changing and how the team is adapting, and Winter is for what has slowed down, frozen or needs a rest.
Every team goes through all four, so the format makes the point that a slow patch is part of the cycle. Run it during a period of change, or every quarter to see how the mix of seasons shifts over time.
## Topics
- **Spring**: Growing or blossoming
- **Summer**: Sizzling or shining
- **Autumn**: Evolving or changing
- **Winter**: Slowing or chilling
## When to use
- When the team wants to look back over several phases of a project or of its own development
- During significant organizational change, to help people talk through how they're adapting
- When you want a metaphor to start a fresh conversation about how the team works
- When the team needs to hear that slow patches and growth spurts are both part of a normal cycle
## Tips and tricks
- Ask people to pick the season that fits each experience, and accept that some will fit more than one
- Remind the team that every season has a purpose. Winter isn't automatically bad news
- Use the change from one season to the next to talk about how the team can prepare for what's coming
- Run it every quarter to see how the mix of seasons changes over time
- Make it safe to raise Winter topics by treating them as the start of renewal, not as complaints
## Icebreaker questions
- If your current work mood was a season, which would it be and why?
- What's your favorite season at work, and what makes it special?
---
# Project Kickoff Planning
URL: https://www.teamretro.com/retrospective-templates/project-kickoff-planning/
A Project Kickoff Planning session is the meeting where your team agrees on what a new project is for and how it will get done, before anyone starts building. Everyone adds their view of the goals, the risks and the dependencies, so disagreements come out now instead of three weeks in.
The board has five areas. Project Goals is for specific, measurable objectives. Key Processes covers the workflows the project needs, both existing ones to fix and new ones to set up. Potential Risks is where the team names what could block or derail the work. Team & Dependencies maps the stakeholders, teams and vendors you rely on, and Timeline & Milestones breaks the work into phases and flags the dates that can't move.
Because people add ideas privately before discussing them, you hear from the quiet engineer who has seen this kind of migration fail as well as from the project lead. You'll finish with goals everyone has agreed to, a list of risks with owners and a first set of milestones.
## Topics
- **Project Goals**: What are the key goals and objectives for this project?
- **Key Processes**: What are the critical processes and workflows needed for success?
- **Potential Risks**: What are the major risks or roadblocks we should plan for?
- **Team & Dependencies**: Who are the key stakeholders, and what dependencies exist?
- **Timeline & Milestones**: What are the key milestones and deadlines we need to hit?
## When to use
- When kicking off a new project or major initiative, so the team agrees on objectives, approach and likely challenges
- After a project is approved but before work begins
- When a project's scope, timeline or resources change significantly and the plan needs another look
- At checkpoints in a long-running project, to review progress, spot new risks and adjust course
## Tips and tricks
- Make it clear that every concern is welcome, including doubts about the plan itself
- Ask one person to take notes on key decisions and action items
- Group related ideas on the board so dependencies and overlaps are easy to see
- Keep the tone solution-focused, but deal with likely roadblocks head-on
- Leave time for questions at the end so everyone actually agrees with the plan
- Give every open risk or unanswered question an owner and a next step
## Icebreaker questions
- If this project were a movie, what would the title and tagline be?
- Share one small win you're proud of from a past project.
---
# Project Post Mortem Template
URL: https://www.teamretro.com/retrospective-templates/project-post-mortem-template/
A post-mortem is the conversation your team has after something ends. Sometimes that something is an incident: a system broke, a release went sideways, a customer felt the pain. Just as often it's an ordinary project that has wrapped, and you want a clear agenda for the review instead of inventing one from scratch. This template handles both. You set the frame with the project's goals and scope, walk through what went well and what didn't, dig into root causes where it matters, and turn the honest parts into lessons learned your organization can reuse.
Here's how it works in TeamRetro. Everyone adds their own observations privately first, so the loudest voice in the room doesn't set the story before quieter people have written anything down. Ideas are then grouped, discussed and voted on, which lets you focus on the handful of themes that matter instead of working through forty comments in no particular order. That's the difference between this and a document you fill in alone: it's a live debrief your whole team runs together, and it ends with owners and due dates on real actions, not a report nobody opens again.
Use it as your default project review at the close of a delivery, a campaign, a migration or a quarter, and as your incident review when something has gone wrong and you need a blameless account of the timeline and its causes. The final topic makes space for kudos, because recognizing the people who carried the work is part of closing it out properly. Either way, the team should leave knowing what to repeat, what to stop and who's doing what next. Export the report when you're done, so the lessons stay findable for the next team that walks into the same situation.
## Topics
- **Project overview, goals and scope**: What did the project set out to do, and by when?
- **What went well**: Which wins and processes are worth repeating?
- **What didn't go well**: Where did we stall, break or miss targets?
- **Root cause analysis**: Why did it go wrong, not just that it did?
- **Lessons learned**: What lessons do we carry forward?
- **Action items, owners and deadlines**: Who is doing what, and by when?
- **Team appreciation and kudos**: Who deserves recognition before we close out?
## When to use
- A project, delivery, migration or campaign has just wrapped and you want a structured review, not an informal chat that fades away
- An incident, outage or failed release needs a blameless post-mortem covering the timeline, root causes and preventive actions
- A long-running program has finished a phase and you want lessons learned captured while the details are still fresh
- A cross-functional group is disbanding, and this is your last chance to debrief and recognize contributors before people move to new work
- Something went unexpectedly well and you want to understand why, so you can repeat it instead of putting it down to luck
## Tips and tricks
- Run it within a week or two of the project closing or the incident being resolved. Memories fade fast, and the useful detail goes with them
- State the blameless rule at the start. You're looking at decisions, systems and pressures, not searching for someone to hold responsible
- Spend a few minutes agreeing on the project overview before opinions start. A shared frame stops the session turning into a debate about what the goal even was
- Skip or shorten root cause analysis for a clean project review, and spend more time on it for incidents where prevention is the point
- Prioritize with voting, then don't let the meeting end without owners and due dates on the top actions, or your lessons learned stay theoretical
- Bring the previous post-mortem's actions into the room and review them first. Nothing improves follow-through like knowing it will be checked
## Icebreaker questions
- In one word, how did this project or incident feel while you were in the middle of it?
- If you could send one sentence of advice back to yourself on day one, what would it say?
---
# All Aboard the Agile Express Retrospective
URL: https://www.teamretro.com/retrospective-templates/all-aboard-the-agile-express-retrospective/
All Aboard the Agile Express treats your sprint or project as a train ride. The metaphor gives the team a shared picture for the retro: an engine pulling you forward, brakes slowing you down, obstacles on the line ahead and a station you're heading for. With that picture in place, it's easier to say what's building momentum and what's dragging on it.
The board has four columns. The Engine is for the practices and people that powered the team. The Brakes covers the friction and blockers that cost you speed. Obstacles on the Track looks ahead to risks and dependencies before they hit, and Next Station is where you agree on the actions to reach before the next retro. Because one column looks forward, the session covers what's coming as well as what already happened, which makes it a good fit for sprint ends, project milestones and quarterly check-ins.
A themed retro like this is a good way to re-engage a team that's tired of the standard "what went well, what didn't" board. It gives a Scrum Master or agile coach a fresh way into the conversation, and the last column keeps everyone heading the same way.
## Topics
- **The Engine**: What powered us forward this sprint?
- **The Brakes**: What slowed us down or held us back?
- **Obstacles on the Track**: What risks or obstacles lie ahead of us?
- **Next Station**: Where do we want to be by our next stop?
## When to use
- When your team is tired of the standard retro format and needs a new way in.
- At the end of a sprint or iteration, to see what's driving momentum and what's slowing you down.
- At project milestones or quarterly check-ins, to agree on direction and upcoming risks.
- When you want to celebrate wins and plan for risks in the same session.
## Tips and tricks
- Explain the train metaphor briefly before brainstorming so everyone knows what each part of the train stands for.
- Give everyone quiet time to add ideas anonymously before discussion, so the first voice doesn't set the direction.
- Keep The Brakes about systems and processes, not individuals.
- Timebox each column to keep the train on schedule and reach Next Station with time for actions.
- Group and vote on similar ideas so discussion goes to the themes that matter most.
- Close by giving every action item an owner and a due date.
## Icebreaker questions
- If our team were a train, would we be a high-speed bullet train, a scenic steam engine, or a stuck-at-the-station local?
- What's the best or most memorable train trip you've ever taken?
---
# Agile Thanksgiving Retrospective
URL: https://www.teamretro.com/retrospective-templates/agile-thanksgiving-retrospective/
Thanksgiving is a natural time to stop and thank the people you work with. The Agile Thanksgiving Retrospective builds that into a retro: your team looks back on the work you've shared, thanks the people behind it, and still comes away with a few things to change. It makes a change from the standard sprint retro without losing the follow-through.
The board has four holiday-themed columns. Grateful For is where people thank specific teammates and moments. What Nourished Us covers the habits, tools and wins that kept the team going. Leftovers to Reheat collects unfinished work and ideas that didn't get attention, and Room for Seconds asks what people want more of next time. The first two show you what to protect, and the last two give you something to act on.
Thanks said out loud, with names and specifics, does more for morale and trust than a generic thank-you at the end of a meeting. Run it in the lead-up to Thanksgiving, at the end of a long sprint or as a year-end wrap-up, and close by turning the leftovers and seconds into actions with owners.
## Topics
- **Grateful For**: Who or what are you most thankful for this sprint?
- **What Nourished Us**: What practices or wins fed the team and kept us strong?
- **Leftovers to Reheat**: What unfinished items should we carry into next time?
- **Room for Seconds**: What would you like more of going forward?
## When to use
- Around Thanksgiving, or in a November sprint, when you want the retro to match the season.
- At the end of a year or quarter, to look back on what the team achieved and thank the people who made it happen.
- When morale is low and the team would benefit from hearing specific thanks from each other.
- After an intense sprint or major release, when the team deserves a pause to acknowledge the effort.
## Tips and tricks
- Set a warm tone at the start: no thanks is too small to share.
- Go around the team so quieter members get a chance to thank someone too.
- Don't let the theme stop you from capturing real improvements. Leftovers to Reheat and Room for Seconds are where they come from.
- Ask for specific, sincere thanks over blanket ones, and don't make recognition feel compulsory.
- Turn Leftovers to Reheat and Room for Seconds items into action items with owners so they don't get forgotten.
- A seasonal touch like a virtual gratitude wall is fine, but keep the session timeboxed.
## Icebreaker questions
- If your sprint were a Thanksgiving dish, what would it be and why?
- What's one thing (work or non-work) you're especially thankful for this year?
---
# Escalation Process Retrospective
URL: https://www.teamretro.com/retrospective-templates/escalation-process-retrospective/
The Escalation Process Retrospective is a focused review of how issues and incidents were escalated and handled in your team or organization. You look at real recent escalations, such as an outage, a customer-reported bug or a compliance question, and trace how each one moved: who raised it, how long it took to reach the right people and what happened next.
The board has four columns. Recent Escalations lists what the team handled. Escalation Effectiveness asks how well the process worked, looking at timeliness, communication, decision-making and resourcing. Process Improvements collects specific changes to escalation paths, triage and documentation. Collaboration and Communication looks at how teams and stakeholders worked together while the escalation was live.
Run it after a significant incident, on a regular schedule, or after a restructure changes who owns what. Use anonymized examples where you can, so the discussion stays on the process and nobody feels singled out.
## Topics
- **Recent Escalations**: What recent escalations or incidents did we handle?
- **Escalation Effectiveness**: How effective were our escalation processes?
- **Process Improvements**: What improvements can we make to our escalation processes?
- **Collaboration and Communication**: How can we improve collaboration and communication during escalations?
## When to use
- After a significant incident or escalation, to review how it was handled.
- As part of a regular process review, to keep escalation procedures current.
- When new systems, processes or teams change who should be involved in an escalation.
- After a restructure, to match escalation paths to new roles.
- When onboarding new team members or stakeholders who need to understand how escalation works.
## Tips and tricks
- Make it safe to share by keeping blame out of the discussion.
- Invite people from different teams and levels, so you hear every side of an escalation and get buy-in for changes.
- Record outcomes and actions, with an owner and a date for each improvement.
- Use anonymized examples or case studies so no individual or team is singled out.
- Point out escalations that went well, and what made them work, so the team keeps doing it.
- Update your written escalation process after each session based on what you learned.
## Icebreaker questions
- If you could design a superhero to handle escalations, what powers would they have?
- Share a funny or memorable experience from a past escalation (without naming names).
---
# Christmas Carol Retrospective
URL: https://www.teamretro.com/retrospective-templates/christmas-carol-retrospective/
The Christmas Carol Retrospective is based on Charles Dickens' *A Christmas Carol*, in which three ghosts show Ebenezer Scrooge his past, his present and the future waiting for him if nothing changes. Your team takes the same tour of its own work, which makes it a natural fit for an end-of-year review.
The board has three columns. Ghost of Christmas Past is for lessons from earlier work and patterns that have built up over time, such as estimates that keep slipping. Ghost of Christmas Present covers what's working and what's causing friction right now. Ghost of Christmas Future looks at the opportunities and risks ahead, and it's where you start turning the discussion into plans.
The story's point is that the future isn't fixed: Scrooge changes once he's seen where he's heading. That's what the third column is for. Ask what will happen if the team carries on as it is, then decide what to change.
## Topics
- **Ghost of Christmas Past**: What can we learn from our previous work and experiences?
- **Ghost of Christmas Present**: What current challenges and successes are we experiencing?
- **Ghost of Christmas Future**: What opportunities and risks do we see ahead?
## When to use
- During end-of-year reviews, when your team is already looking back on the year and setting goals for the next.
- When you want to connect recurring patterns with current challenges and what's coming.
- After a significant organizational change, to talk about what's been lost, what's changing now and what's possible next.
- When morale needs a lift and a story-based format would help.
- For distributed teams, who can share a story most people already know.
## Tips and tricks
- Ask people to write their notes as short stories instead of isolated points.
- Balance reflection with practical action items, especially in the Ghost of Christmas Future column.
- Add a light holiday touch to the board if you like, but don't let it distract people.
- Give Ghost of Christmas Present enough time. Current issues usually produce the most discussion and the most immediate actions.
- If people struggle with Ghost of Christmas Future, prompt them with an ideal outcome or a likely risk.
- For multicultural teams, summarize the story in a minute or two before you start so everyone gets the metaphor.
## Icebreaker questions
- If you could time travel like Scrooge, which period in your team's history would you most want to revisit and why?
- What's one 'gift' (skill, insight, or support) you've received from a team member this year that you're particularly grateful for?
---
# KPop Demon Hunters Retrospective
URL: https://www.teamretro.com/retrospective-templates/kpop-demon-hunters-retrospective/
KPop Demon Hunters is the animated film about K-pop idols who secretly hunt demons. This retrospective borrows that setup: your team is the group, the sprint is the show, and the blockers are the demons that tried to stop it. It's a change of pace from the usual columns, and the prompts still lead to an honest conversation about the work.
The board has four columns. Chart-Topping Hits is for the wins worth celebrating. Demons We Faced names the blockers and frustrations that slowed you down. Finding Our Harmony looks at how well the team collaborated and stayed in sync, which is where relationship and process problems tend to show up. Our Next Hit turns all of it into one or two actions the team will actually do next sprint.
Use it when your retros have gone stale, or after a tough sprint when a lighter tone helps people talk about what went wrong. Nobody needs to have seen the film: each column has a plain prompt, and a one-line intro is enough to set the scene.
## Topics
- **Chart-Topping Hits**: What performances and wins should we celebrate?
- **Demons We Faced**: What blockers and challenges threatened our show?
- **Finding Our Harmony**: How well did we collaborate and stay in sync?
- **Our Next Hit**: What will we do to make the next sprint even better?
## When to use
- When your team's retrospectives have gone stale and you want a themed session to change the routine.
- After an intense or difficult sprint, when a lighter tone helps the team open up about blockers.
- For teams that enjoy pop culture and respond well to story-driven formats.
- As an occasional change of pace between your regular retro formats.
## Tips and tricks
- Introduce the theme at the start and lean into it, so everyone feels free to be playful.
- Keep Demons We Faced blameless. Talk about the obstacle, not the person, so people feel safe naming it.
- Timebox each column so the fun doesn't eat into action planning at the end.
- Ask quieter team members directly for their hit or their demon so every voice is heard.
- Limit actions to one or two high-impact changes so they actually get done by the next sprint.
- Start by reviewing the last session's actions to close the loop and keep the team accountable.
## Icebreaker questions
- If your team were a KPop group, what would your band name be and who plays which role?
- What's the one 'demon' (bad habit or blocker) you'd most love to slay this sprint?
---
# Vendor Management Review
URL: https://www.teamretro.com/retrospective-templates/vendor-management-review/
The Vendor Management Review is a retrospective for the external partners your team depends on, from hosting providers to agencies and contractors. It gives you a regular, structured look at each relationship before small frustrations turn into a contract dispute.
The board has five columns. What's Working Well? covers the vendors and practices worth keeping. Pain Points & Challenges is for the recurring problems, like late deliveries, billing disputes or a vendor that misreads your requirements. Process & Workflow looks at how you work with vendors day to day, Strategic Alignment asks whether your partners fit where the organization is heading, and Cost Optimization looks for savings and better value.
It's most useful for teams that rely on several vendors or have a complicated buying process. Bring data where you have it, such as delivery times or invoice disputes, so the conversation rests on more than impressions.
## Topics
- **What's Working Well?**: Which vendor relationships are thriving, and what makes them successful?
- **Pain Points & Challenges**: What vendor-related issues are causing frustration or delays?
- **Process & Workflow**: How can we improve processes and workflows with our vendors?
- **Strategic Alignment**: How can we better align vendor partnerships with our long-term goals?
- **Cost Optimization**: How can we optimize costs and maximize value from our vendor relationships?
## When to use
- When you have enough vendor relationships that they need a regular review.
- When recurring problems with a particular vendor need to be dealt with.
- As part of a periodic vendor review, or before a contract renewal.
- When a strategic change may affect your current vendors or call for new ones.
## Tips and tricks
- Ask for honest feedback, and keep it about the relationship and the process, not personal blame.
- Invite people from key vendors to give their side, either in this session or a follow-up.
- Back up observations with data, such as delivery times or invoice disputes, wherever you can.
- Give every improvement an owner and a due date.
- Involve procurement, legal or finance when the discussion touches contracts or costs.
- Look for fixes that help both sides, since a vendor relationship only improves if the vendor buys in.
## Icebreaker questions
- If you could outsource any aspect of your personal life to a vendor, what would it be and why?
- Share a funny or memorable experience you've had while working with a vendor (without naming names).
---
# Hawaiian Island Retreat Retrospective
URL: https://www.teamretro.com/retrospective-templates/island-retreat-retrospective/
The Hawaiian Island Retreat Retrospective frames your sprint review as a trip to the islands. Momentum becomes a wave you caught, good moments are sunshine, problems are rough tides and next steps are where you set sail. The theme gives people a lighter way into a conversation that still gets to the problems and the fixes.
The board has four columns. Catch the Wave is for the wins and breakthroughs that moved the team forward. Sunshine Moments is for thanks, in the spirit of mahalo, the Hawaiian word for thank you: shout-outs to the people and moments that made the sprint better. Rough Tides surfaces the friction and blockers that made the work harder than it needed to be. Set Sail is where the team agrees on the actions to carry into the next sprint.
It suits a team that needs a lift after a hard sprint, or a remote team that benefits from a shared picture to talk around. Two of the four columns focus on what's going well, so it's a good choice when you want gratitude to get as much airtime as problems.
## Topics
- **Catch the Wave**: What momentum carried us forward this sprint?
- **Sunshine Moments**: What successes and bright spots deserve a Mahalo?
- **Rough Tides**: What challenges or obstacles created rough waters?
- **Set Sail**: What actions should we paddle toward next sprint?
## When to use
- When your retros have started to feel repetitive and the team needs a fresh format.
- When new team members are joining their first retrospective and you want a welcoming, low-pressure start.
- With a remote or distributed team that benefits from a shared theme to connect around.
- After a hard sprint, when the team needs to balance the problems with some thanks and celebration.
- When quieter team members hold back. A light theme can make sharing feel lower-stakes.
## Tips and tricks
- Explain the theme briefly at the start, including mahalo (thank you), so people engage with it instead of treating it as a gimmick.
- Give all four columns fair time. Teams tend to pile into Rough Tides, so remind people that Catch the Wave and Sunshine Moments matter too.
- Use Set Sail for accountability. Every action needs an owner and a target date before the session ends, because vague actions rarely get done.
- Don't let the island mood stop the team from tackling real problems. Make room for honest, constructive feedback in Rough Tides.
- For remote teams, add a short themed warm-up, such as sharing a favorite beach memory, before you start on the columns.
- Timebox each column. A typical session runs 60–90 minutes: about 10–15 minutes per column, with the last 15 minutes saved for agreeing actions in Set Sail.
## Icebreaker questions
- If you could work remotely from any Hawaiian island for a month, which would you choose and why?
- If your current sprint were a Hawaiian dish, what would it be: a fresh poke bowl, a slow-cooked kalua pig, or something else entirely?
---
# Spice Up Your Retro
URL: https://www.teamretro.com/retrospective-templates/spice-up-your-retro-retrospective/
Spice Up Your Retro sorts your team's feedback the way you'd rate a dish: by how much heat it carries. Mild items are the small wins nobody mentions. Hot items are the issues that burned the team and need attention now. Between them sit the things that worked, and at the end comes the secret sauce: the ideas you want to try next.
The board has four columns. Mild is for small wins and steady progress. Medium covers the practices and decisions that made a real difference. Hot holds the blockers and friction points. Secret Sauce collects bold ideas and experiments for the next sprint. Because the scale runs from good to bad to new, the team covers what went well, what hurt and what to try in one pass.
The food theme makes it easier to talk about friction without the conversation getting heavy, and the Mild column makes sure small wins get noticed alongside the big ones. Run it at the end of a sprint or as a quarterly check-in when your usual format has gone stale.
## Topics
- **Mild**: What small wins and steady progress should we call out?
- **Medium**: What added flavor and genuinely worked well?
- **Hot**: What burning issues need urgent attention?
- **Secret Sauce**: What bold ideas or experiments should we try next?
## When to use
- When your retrospectives have become routine and the team needs a different format to get talking again.
- At the end of a sprint, when you want to give wins and pain points equal time.
- For a team-building session where you want a lighthearted theme that still ends in actions.
- When quieter team members need a low-pressure structure that makes it easier to contribute.
## Tips and tricks
- Lean into the spice theme at the start with a quick food question, so people relax before the real discussion.
- Remind the team to add items to every column, not just Hot.
- Group similar ideas before voting so the discussion goes to the themes with the most votes.
- Timebox each column so the team doesn't spend the whole session on the Hot issues.
- Turn the top Hot items and Secret Sauce ideas into actions with an owner before you close.
- Rotate the facilitator role so different people get to set the tone.
## Icebreaker questions
- If your week at work was a dish, how spicy would it be and why?
- What's your go-to comfort food after a tough day, and what made this week tough or easy?
---
# Kanban Flow Retrospective
URL: https://www.teamretro.com/retrospective-templates/kanban-flow-retrospective/
Kanban teams don't work in sprints, so a sprint-shaped retrospective often misses the point. The Kanban Flow Retrospective looks at how work moves through your board: where cards stall, where they move quickly and what causes the pile-ups. It's a practical way to find the friction that slows delivery and makes it hard to predict.
The team works through four topics: what flowed well, where the bottlenecks were, whether your work-in-progress (WIP) limits and policies are working, and what you'll change. Discussing them together in TeamRetro builds a shared picture of how work gets from "to do" to "done". It suits teams practicing Lean or Kanban, and any agile team trying to improve cycle time and throughput.
Run it regularly and it becomes a habit of small improvements (kaizen). Bringing the board and your flow metrics into the room keeps the conversation on the system instead of on individuals, so the team can agree on process changes and check at the next session whether they worked.
## Topics
- **What flowed well?**: Where did work move smoothly through the board?
- **Where were the bottlenecks?**: Which stages caused work to pile up or stall?
- **WIP limits and policies**: Are our work-in-progress limits and rules working?
- **What will we improve?**: What concrete changes will improve our flow?
## When to use
- When your team practices Kanban or Lean and wants to improve flow without waiting for a sprint to end.
- When cycle times are rising or work feels stuck, and you need to find the bottleneck.
- When WIP limits and column policies are unclear or being ignored.
- When you want retrospective discussion tied to flow metrics like throughput and lead time.
- Every two weeks or once a month, to make improving flow a habit.
## Tips and tricks
- Bring the board and your flow metrics (cycle time, throughput, WIP) so the discussion starts from data.
- Talk about the system, not individuals. Bottlenecks are usually process problems, so keep it blame-free.
- Limit yourselves to one or two improvement actions so the team can deliver them before the next retro.
- Give every action an owner and a way to measure it at the next session.
- Use anonymous idea entry before discussion so quieter team members contribute.
- Start by reviewing the actions from last time to see what's changed.
## Icebreaker questions
- If your workflow were a type of traffic, what would it be right now: open highway, rush hour, or total gridlock?
- What's one thing in your daily routine that always flows smoothly, no bottlenecks attached?
---
# Start Stop Continue Retrospective
URL: https://www.teamretro.com/retrospective-templates/start-stop-continue-retrospective/
Start Stop Continue is a retrospective format built on three questions: what should your team start doing, what should it stop doing, and what should it keep doing? Every answer is a behavior someone can act on, so the meeting ends with a short list of changes instead of a long list of complaints.
Teams use it in agile retrospectives because it needs almost no explanation. Everyone adds ideas to three columns: things to begin (Start), things to drop (Stop) and things that are working and worth keeping (Continue). The structure keeps the conversation on what people actually do, which makes it easy to turn the top items into actions with an owner.
It works best when you want concrete changes out of the meeting, with the wins on the table next to the problems. The Continue column is the one teams rush, and it's the one that stops a good habit from quietly disappearing.
You'll also see this exercise written as "Stop Start Continue." It's the same thing: the three categories are identical and you can run them in whichever order your team prefers. Some facilitators lead with Stop to clear away what isn't working before deciding what to begin. Others lead with Start to keep the tone forward-looking. Either way, you finish with a short list of behaviors to begin, end and keep.
Start Stop Continue is useful well beyond the sprint retrospective. Because it produces specific, behavior-level feedback, teams use the same Start Stop Continue template for peer feedback, manager one-on-ones, project post-mortems and personal goal-setting. In a one-on-one, for example, a report might ask their manager to "start sharing the weekly priorities earlier," "stop scheduling reviews on Friday afternoons" and "continue the open Q&A at standup." The free template above gives everyone a private space to add ideas before the team groups them, votes and agrees on actions together.
## Topics
- **Start**: What should we start doing?
- **Stop**: What should we stop doing?
- **Continue**: What should we continue doing?
## When to use
- When you want a short list of specific actions out of the retro
- During a period of change, to decide which practices to keep and which to drop
- With a new team that needs a simple, familiar way to give feedback
- When discussions keep drifting into the abstract and you need behaviors the team can act on
## Tips and tricks
- Start with the Continue column so the team names what's working before it gets to the problems
- Ask for specific behaviors. "Communicate better" is a wish; "post a summary after every client call" is something you can do
- Give each column real time. If Stop takes the whole meeting, the team leaves with nothing to keep
- Talk about behaviors and practices, not individuals
- Cap the actions at two or three so they actually get done
- Check the last retro's actions at the start of the next one to see what changed
## Icebreaker questions
- What's one positive change you've noticed in our team over the last month?
- If you could instantly implement one improvement to our team's way of working, what would it be?
---
# American Football (NFL) Retrospective
URL: https://www.teamretro.com/retrospective-templates/american-football-nfl-retrospective/
The NFL Retrospective borrows the language of American football for your team's retro. Football teams watch game film after every game to see what worked and plan the next one, and this format asks your team to do the same with its last sprint or project.
The board has four columns. Touchdowns is for the wins and work you delivered. Lines of Scrimmage covers the constraints and rules you play within, both the ones that protect quality and the ones worth challenging. Interceptions and Tackles is for the setbacks and what slowed you down, and The next plays is where you decide what to try next. The constraints column is the unusual one. Most retros don't ask what boundaries the team is working inside, and naming them often explains why the same problems keep coming back.
It goes down well with teams who enjoy sport or want a change from their usual routine. Football terms give the team a lighter way to talk about performance, which makes the harder conversations easier to start.
## Topics
- **Touchdowns**: What key outputs did we deliver?
- **Lines of Scrimmage**: What boundaries are we working within?
- **Interceptions and Tackles**: What didn't go to plan? What slowed us down?
- **The next plays**: What do we want to try next?
## When to use
- When morale needs a lift and you want the retro to feel different.
- After a major milestone or release, to review how the team played the whole season.
- When you're introducing new team members to retrospectives and want an approachable format.
- When the team needs a fresh angle on how it works and collaborates.
## Tips and tricks
- Keep the football metaphors consistent, but don't let them take over the retro.
- Bring in a few team stats, like cycle time or bugs found, to show trends the way a broadcast shows player stats.
- Rotate the coach (facilitator) role so different team members get to lead.
- Use a timer to keep each column focused, like the quarters of a game.
- Keep a playbook of strategies that worked, built up from retro to retro.
- Explain the terms for anyone who doesn't follow football, so nobody is left out.
## Icebreaker questions
- If our team were an NFL team, what would our team name and mascot be, and why?
- What's your favorite comeback story (in sports or technology) and what made it successful?
---
# All I Want for Christmas is Feedback Retrospective
URL: https://www.teamretro.com/retrospective-templates/all-i-want-for-christmas-is-feedback-retrospective/
All I Want for Christmas is Feedback turns your end-of-year retro into a festive exchange. Your team hands out thanks, names the lumps of coal it would rather leave in last year, and shares its wishes for the year ahead. The theme makes it easier to be candid at a busy time of year, when people are already thinking back.
The board has three columns. Gifts to Give is for appreciation and feedback, including constructive feedback offered as a gift. Lumps of Coal covers what didn't go well and should be left behind, kept to processes and situations, not people. Christmas Wishes asks what the team hopes for next year, and those wishes become the seeds of your goals and actions. Treating feedback as something you give makes it feel generous instead of critical, which helps people be honest.
Run it as a year-end celebration, a final sprint retrospective before the holidays, or a team-bonding session with real reflection in it. Whether your team had a smooth year or weathered a few storms, it brings back the moments that mattered, recognizes the people who made a difference and sets up a few clear actions for January.
## Topics
- **Gifts to Give**: What appreciation or feedback would you like to give the team?
- **Lumps of Coal**: What didn't go so well and should be left behind?
- **Christmas Wishes**: What hopes or wishes do you have for the team in the year ahead?
## When to use
- As a year-end or last-sprint-of-the-year retro, to look back on the past twelve months in a festive way.
- When you want to lift morale over the holidays and still capture real improvements.
- For distributed or hybrid teams who can't get together in person but want a shared end-of-year session.
- When feedback has been hard to get out of the team and a playful theme could make it easier.
- As a team-bonding session that pairs holiday spirit with concrete plans for the new year.
## Tips and tricks
- Set a relaxed tone with seasonal music or a festive background before you start.
- Make it clear that Lumps of Coal is about processes and situations, not people.
- Ask for specific feedback in Gifts to Give so the appreciation feels genuine.
- Timebox each column so the session keeps its energy and you have time to turn Christmas Wishes into actions.
- Not everyone celebrates Christmas. Keep the theme light and optional so everyone feels comfortable joining in.
- Group and vote on themes before discussion so the most important wishes rise to the top and get owners.
## Icebreaker questions
- What's the best gift you've ever given or received, and why did it mean so much?
- If you could unwrap one new skill or superpower for the team next year, what would it be?
---
# Must Should Could Won't Retrospective
URL: https://www.teamretro.com/retrospective-templates/mscw-retrospective/
Must Should Could Won't, better known as MoSCoW, sorts work into four groups: what you must do, what you should do, what you could do if there's time, and what you won't do this time. Run as a retrospective, it gets your team to agree on priorities for the next sprint or release out loud, with everyone in the room.
Dai Clegg developed the method at Oracle in the 1990s, and it became a standard part of agile project management and business analysis, especially in DSDM. The categories are Must have (critical), Should have (important), Could have (desirable) and Won't have (not this time).
It fits agile ways of working because it puts the highest-value work first. It also gives the product owner a structured way to see the backlog from the customer's side: if a customer would notice it missing at launch, it's probably a Must.
The Won't column does more work than it looks. Writing down what you've agreed not to do keeps it from creeping back into the sprint, and it tells stakeholders plainly what won't be delivered.
## Topics
- **Must**: What must we deliver, no matter what?
- **Should**: What's important but not critical?
- **Could**: What would be nice if time allows?
- **Won't**: What are we agreeing not to do this time?
## When to use
- When planning a new project or initiative and you need clear priorities
- During backlog refinement, to sort and prioritize feature requests
- When resources are tight and you have to make hard calls about scope
- In stakeholder meetings, to set expectations about what will be delivered and when
## Tips and tricks
- Keep Must items to no more than about 60% of the total effort, the DSDM guideline, so the plan has room for surprises
- Revisit the categories as business needs and constraints change
- Timebox the discussion of each item so one debate doesn't eat the meeting
- Write down why each item landed where it did, so the next debate doesn't start from scratch
- Involve the stakeholders who own the requirements, so the priorities stick
- Check dependencies before you place an item: a Could that a Must depends on is really a Must
## Icebreaker questions
- What's the most difficult priority decision you've had to make in a project?
- If you could only deliver three features in your current project, what would they be and why?
---
# Big Bang Blast Retrospective
URL: https://www.teamretro.com/retrospective-templates/big-bang-blast-retrospective/
Big Bang Blast gives your retrospective a space theme. Borrowing loosely from the origin of the universe, your team traces the spark that got the work started, the forces that pushed it forward, the debris that slowed it down and the new galaxies you want to reach next. The theme keeps energy up, and the session still ends with a list of actions.
The four topics follow a simple story. The Spark covers the early energy and breakthroughs, Expanding Forces is for what kept the team moving, Cosmic Debris names the obstacles and friction, and New Galaxies collects the ideas you want to reach for. A memorable theme helps with retrospective fatigue, and people often find it easier to give candid feedback when a problem is framed as debris to clear.
It works well for agile teams, product squads and project groups after a major launch, milestone or intense delivery period. You recognize what went well and still commit to concrete improvements. In TeamRetro, you capture ideas, vote on priorities and turn the results into action items you can track.
## Topics
- **The Spark**: What ignited momentum and got things moving?
- **Expanding Forces**: What propelled us forward and helped us grow?
- **Cosmic Debris**: What slowed us down or created friction?
- **New Galaxies**: What bold ideas or improvements do we want to reach for?
## When to use
- After a major product launch, milestone or release, when you want to celebrate momentum and review what to improve.
- When standard retrospective formats feel stale and you want a themed session to change things up.
- After an intense or high-pressure delivery period that deserves recognition as well as reflection.
- At the start of a new quarter or initiative, to capture lessons and set ambitions for what's ahead.
## Tips and tricks
- Introduce the space theme up front so everyone understands the metaphor and feels free to play with it.
- Timebox each topic so no single discussion takes over the session.
- Use anonymous idea entry to get candid feedback, especially on Cosmic Debris.
- Vote on New Galaxies ideas so the team focuses on the highest-impact improvements instead of trying to do everything.
- Turn the top-voted items into owned action items with due dates.
- Recognize the wins properly before you move on to the problems.
## Icebreaker questions
- If your sprint were a celestial event, would it be a supernova, a meteor shower, or a quiet orbit, and why?
- If you could name a star after one team achievement this cycle, what would the star be called?
---
# SLA Compliance Retrospective
URL: https://www.teamretro.com/retrospective-templates/sla-compliance-retrospective/
The SLA Compliance Retrospective is a meeting for reviewing how your team performed against its service level agreements (SLAs) and deciding what to change. The numbers come first: response times, resolution times, uptime and whatever else your SLAs measure. Then the team works out what caused the misses and agrees on fixes.
The board has four areas. SLA Metrics Review is where you go through the targets you met and missed. SLA Challenges covers the bottlenecks and root causes behind the misses. Improvement Opportunities is for concrete actions, and Cross-Team Collaboration looks at the handoffs between teams, since delays often build up where one team's work passes to another.
It suits teams with firm SLA commitments, such as IT services, customer support, logistics and healthcare. Run it each time you report on SLA performance, monthly or quarterly, and after any serious breach or customer escalation, so the review leads to follow-up actions and not only a report.
## Topics
- **SLA Metrics Review**: How did we perform against our SLA targets?
- **SLA Challenges**: What factors impacted our ability to meet SLAs?
- **Improvement Opportunities**: How can we improve our SLA performance?
- **Cross-Team Collaboration**: How can we work together better to meet our SLAs?
## When to use
- When your team delivers services against defined SLA targets.
- Each time you report on SLA performance, so the numbers lead to follow-up actions.
- After a significant SLA breach or customer escalation, to review root causes and prevention.
- When SLA misses keep tracing back to handoffs between teams.
- When you want to catch the factors affecting SLA compliance before they cause a breach.
## Tips and tricks
- Have accurate, current SLA performance data ready so the review starts from facts.
- Keep the discussion blameless and focused on process, not individual accountability.
- Invite people from the other teams involved in SLA delivery, especially those at the handoffs.
- Prioritize improvements the team can realistically make within its own control.
- Give each action a clear owner and timeline.
- Run it on a regular schedule, such as monthly or quarterly, so every reporting period is followed by actions.
## Icebreaker questions
- If you could create a new SLA for our team, what would it be and why?
- Share a memorable experience (positive or negative) related to SLA compliance from your career.
---
# Pipeline Management Retrospective
URL: https://www.teamretro.com/retrospective-templates/pipeline-management-retrospective/
A Pipeline Management Retrospective is a pipeline review for the people who move leads and deals through it: sales, implementation and anyone else who hands work along the line. Instead of going deal by deal, your team looks at the process itself and asks where work slows down, where it gets stuck and what would keep it moving.
The board has four topics. Pipeline Bottlenecks covers the stages that caused delays, Pipeline Streamlining collects practical fixes, Pipeline Roadblocks looks at outside pressures like market shifts or internal policy, and Pipeline Collaboration covers handoffs between teams. Bring your pipeline numbers, such as stage conversion rates or time in stage, so the discussion starts from what actually happened.
The approach borrows from agile retrospectives and lean thinking: make the flow visible, then remove the waste that slows it. Run it quarterly, or after you change tools or process, and leave with a few changes that each have an owner.
## Topics
- **Pipeline Bottlenecks**: What pipeline stages or processes caused delays or created bottlenecks?
- **Pipeline Streamlining**: What would make our pipeline faster and simpler?
- **Pipeline Roadblocks**: What inside or outside the company held the pipeline back?
- **Pipeline Collaboration**: How can teams work together better across pipeline stages?
## When to use
- When the same pipeline bottlenecks keep coming back.
- After a major process change or a move to a new CRM or pipeline tool.
- On a regular schedule, such as quarterly or twice a year, to keep improving how the pipeline runs.
- When onboarding new people or restructuring the teams that work the pipeline.
- When conversion rates or forecast accuracy fall short of expectations.
## Tips and tricks
- Make it safe to be candid about stalled deals. The point is fixing the process, not judging who owned them.
- Invite people from every pipeline stage, not only sales.
- Bring data such as time in stage and conversion rates, so the discussion rests on numbers instead of impressions.
- Agree on a small number of fixes and give each an owner and a date.
- Schedule the next pipeline retrospective before you leave, so you can check whether the fixes worked.
- Call out deals that moved well and ask what made them different.
## Icebreaker questions
- If our pipeline was a famous movie, which one would it be and why?
- If you could add one superpower to our pipeline management process, what would it be?
---
# The Hero's Journey Retrospective
URL: https://www.teamretro.com/retrospective-templates/the-heros-journey-retrospective/
The Hero's Journey Retrospective borrows the story structure Joseph Campbell called the monomyth: a hero sets out on a quest, gets help along the way and comes back with something of value. Your team retells its project in those terms.
The board has five columns. Hero names who is on the journey, whether that's the whole team, one role or a group within it. Quest covers the challenges ahead. Guide is for the people who support the hero, Inventory for the tools and resources you have to work with, and Treasure for the rewards waiting at the end.
Telling the work as a story makes it easier to talk about hard stretches without anyone feeling blamed, and the Guide column gives you a natural place to thank the people who helped. It suits long projects and big changes, where the team has been through enough that the story is worth telling.
## Topics
- **Hero**: The person or group going through the journey
- **Quest**: The challenges ahead
- **Guide**: The people supporting the hero
- **Inventory**: The tools and resources available
- **Treasure**: The rewards and achievements that await
## When to use
- At the start of a big project or initiative that will need sustained effort from the team
- After a major milestone, to look back on how you got there and prepare for the next stage
- When morale is low and you want to talk about challenges without the meeting turning into a list of complaints
- During organizational change, when the team needs to make sense of where it's heading
## Tips and tricks
- Invite people to use the story to describe challenges. It's easier to talk about a dragon than to criticize a colleague
- Draw a simple journey map so the team can see where it is in the story
- Make sure everyone adds to each column. The most useful guide is often someone nobody thought to mention
- Keep the tone forward-looking and avoid blame. The hero is meant to come out stronger
- Save the finished board. It's a useful record when you start the next big project
- Give the discussion enough time. Rushing the story leaves you with a list instead of a conversation
## Icebreaker questions
- If you could choose any fictional character as a mentor for our team, who would it be and why?
- What's the most epic 'quest' you've completed in your professional life so far?
---
# Brazilian Rhythm Retrospective
URL: https://www.teamretro.com/retrospective-templates/brazilian-rhythm-retrospective/
The Brazilian Rhythm Retrospective borrows from Brazilian music, from fast samba to the looser feel of bossa nova, and asks how well your team kept time together. A band sounds good when everyone plays in time, and a team works the same way: people build on each other and adjust when the beat slips. The theme adds some warmth to the meeting and makes it easier to talk about pace and morale.
The board has four sections. Samba is what kept the team moving. Off-Beat covers what threw you off, such as interruptions or unclear requirements. New Tune is for experiments worth trying next sprint, and Carnival is for wins and the people behind them. Opening and closing on the positive sections keeps the talk about friction in proportion.
Framing the retro around rhythm gets people discussing cadence and morale, which a plain list of tasks rarely brings up. Run it in TeamRetro to brainstorm privately, group and vote, then turn the top ideas into action items the team can follow up next sprint.
## Topics
- **Samba (Kept Us Moving)**: What kept the team energized and in rhythm?
- **Off-Beat (Threw Us Off)**: What disrupted the team's flow or broke the rhythm?
- **New Tune (Worth Trying)**: What new ideas or experiments should we try next?
- **Carnival (Worth Celebrating)**: What wins and achievements deserve a celebration?
## When to use
- When you want to change the feel of a routine sprint retrospective.
- After a high-pressure release, to look at pace and celebrate what the team got done.
- When your usual formats feel stale and you want a new metaphor.
- For remote or distributed teams that want a bit of personality in their retro.
- When you want honest talk about friction alongside real recognition of what went well.
## Tips and tricks
- Play some Brazilian music as people join to set the theme.
- Keep the focus on pace and flow, not a list of finished tasks, so you learn how the team actually works together.
- Time-box each topic so no single area takes over the session.
- Remind quieter people that every instrument matters to the song, and let everyone add notes privately first.
- Use dot voting to pick the ideas that matter most before turning them into action items.
- Don't skip Carnival. Celebrating wins balances the discussion of what went wrong.
## Icebreaker questions
- If your work week were a music genre, what would it be and why?
- What song best captures the energy of your last sprint?
---
# Code Review Retrospective
URL: https://www.teamretro.com/retrospective-templates/code-review-retrospective/
A code review retrospective is a meeting where your team looks at how it reviews code, not at the code itself. Pull requests that sit for days, comments without context, reviews that only check style: these problems rarely come up in a regular sprint retro, because they're spread across everyone's week instead of tied to one event.
The board has four columns. "What is going well?" collects the review habits worth keeping, like a useful checklist or a respectful tone. "What isn't going well?" covers the pain points, from oversized pull requests to inconsistent standards. "What can we improve?" turns those into specific changes, such as a limit on change size or an agreed turnaround time. "What questions have surfaced?" parks the open questions the team needs to research before it can decide.
Run it after a major release, when review delays start slowing delivery, or when new people join and the team's unwritten review standards need writing down. Keep it blameless: the subject is the process, not anyone's comments on a particular pull request.
## Topics
- **What is going well?**: What's working well in our code reviews?
- **What isn't going well?**: What challenges or pain points did we face during code reviews?
- **What can we improve?**: How can we improve our code review process and practices?
- **What questions have surfaced?**: What new questions or areas for further exploration emerged?
## When to use
- When reviews are slowing delivery or causing friction and you want to find out why.
- When you want developers to share the review practices that work for them.
- After major releases or projects, to look at how reviews held up under pressure.
- When new people join and the team's review standards, expectations and turnaround times need agreeing.
## Tips and tricks
- Keep the discussion blame-free so people give honest feedback about reviews they found hard.
- Recognize good reviewing, such as clear comments or a fast turnaround, as well as the problems.
- Involve everyone who writes or reviews code, including testers.
- Agree on one or two concrete changes instead of a long list of good intentions.
- Follow up on action items and track progress in your next retrospectives.
- Rotate the facilitator so different perspectives lead the discussion.
## Icebreaker questions
- What's the most interesting code you've reviewed recently?
- If you could add one feature to your code editor, what would it be?
---
# Blogger Day Retrospective
URL: https://www.teamretro.com/retrospective-templates/blogger-day-retrospective/
Blogger Day is a retrospective for writers, content creators and the communities around them. Whether you run a personal blog, contribute to a shared publication or manage a content team, it gives everyone time to look back at what they've published, share what they learned and remember why they write.
The board has four topics. What resonated covers the posts and moments that connected with readers. What got in the way is for creative blocks, time pressure and technical problems. Fresh ideas collects new topics and formats to try, and Community support recognizes how people helped each other. Putting these views side by side gives contributors a clearer picture of their shared voice and ends with concrete next steps for the content calendar.
Its value is in turning scattered individual experiences into shared learning. Use it at the end of a campaign or publishing season, or as a regular check-in to keep ideas coming and the community connected.
## Topics
- **What resonated**: Which posts or moments connected best with readers?
- **What got in the way**: What blocked you from writing or publishing well?
- **Fresh ideas**: What new topics or formats should we try next?
- **Community support**: How did we help and lift each other up?
## When to use
- At the end of a publishing campaign or content season, to review what worked and what didn't.
- As a recurring check-in for a blogging community or content team, to keep ideas and morale fresh.
- After a collaborative project or guest series, to capture lessons and thank contributors.
- When planning a new content calendar and you want ideas from the whole community.
## Tips and tricks
- Bring real metrics or reader comments to the session so reflections rest on evidence as well as gut feel.
- Keep What got in the way focused on obstacles and processes, not individual blame.
- Timebox the Fresh ideas brainstorm, then group and vote on the most promising ones.
- Give quieter contributors airtime by collecting written input in TeamRetro before group discussion.
- Close by turning the best ideas into actions with owners and dates on the content calendar.
- Celebrate wins out loud. People keep writing when someone notices their work.
## Icebreaker questions
- If your blog had a theme song, what would it be and why?
- What's the one post you've written that you're secretly most proud of?
---
# Lightning Retrospective
URL: https://www.teamretro.com/retrospective-templates/lightning-quick-retrospective/
The Lightning Retrospective is a short, energetic format for teams that want to reflect without a long meeting. It borrows the imagery of a thunderstorm: lightning for the moments that drove progress, thunder clouds for the friction that slowed you down, and a power surge for the changes that would give the next sprint a lift.
The board has three columns. Lightning Bolts captures the wins, decisions and habits that created momentum, so you can repeat them. Thunder Clouds collects the blockers, miscommunication and drag, with the focus on patterns over one-off bad days. Power Surge is the forward-looking column, where the team picks one or two concrete changes and gives each an owner. Each column is meant to be quick: short notes, a fast vote and a focused discussion on the top items.
It suits teams on short sprints and teams whose retros have started to drag. You can explain it in a minute, and most teams finish in under an hour.
## Topics
- **Lightning Bolts**: What sparked energy and drove progress this sprint?
- **Thunder Clouds**: What created noise, friction, or slowed the team down?
- **Power Surge**: How can we amplify our energy and supercharge the next sprint?
## When to use
- When your retrospectives feel repetitive or low on energy and you want a quicker format.
- When you're running a short sprint and need a retro that gets to actions without taking much time.
- After an intense stretch of work, when the team wants to process the highs and lows without a long meeting.
- When introducing a new team to retrospectives and you want a format that's easy to explain.
- When you want to cover wins, friction and next steps in one focused session.
## Tips and tricks
- Keep it moving. Aim for 30–45 minutes and use a timer for each column. Save deep dives for a separate problem-solving session.
- Have everyone add ideas on their own before discussion starts, so the loudest voices don't set the agenda.
- Don't let Power Surge become a wish list. Narrow it to one or two concrete changes with owners and a timeline, because unowned actions rarely get done.
- Watch for Thunder Clouds turning into a venting session. Acknowledge the frustration, then steer toward root causes and what the team can actually change.
- Ask people to add risks to Thunder Clouds as well as problems that already happened. A risk raised early is much cheaper to deal with.
- Start by reviewing the actions from your last Lightning Retrospective. Acknowledging what got done, and what didn't, shows the team that the retro leads to change.
## Icebreaker questions
- If your energy this sprint were a weather event, what would it be and why?
- If you could harness the power of lightning for one superpower at work, what would it be?
---
# The Telephone Game Retrospective
URL: https://www.teamretro.com/retrospective-templates/the-telephone-game-retrospective/
The Telephone Game Retrospective is based on the children's game where a whispered phrase changes a little with every person until it arrives as something else entirely. Your team uses the same idea to look at how requirements, decisions and updates traveled during a sprint or project, and where they changed along the way.
The board follows the message from start to finish. The Original Message covers what was communicated clearly. Lost in Translation is where information was distorted, dropped or misread as it passed between people and tools. The Source of the Static digs into why, and Clearing the Line turns that into changes the team will make.
Tracing the path of a real message keeps the conversation on handoffs and channels, not on who got it wrong. You come out with a few specific fixes, such as a single place for decisions or a written summary after meetings. It suits distributed and cross-functional teams, where a lot depends on handoffs going right.
## Topics
- **The Original Message**: What was clearly and effectively communicated from the start?
- **Lost in Translation**: Where did the message get distorted, lost, or misunderstood?
- **The Source of the Static**: What caused the breakdowns in how information traveled?
- **Clearing the Line**: How can we make our communication clearer and more reliable?
## When to use
- When recurring misunderstandings or rework suggest information is getting lost somewhere.
- After a project with many handoffs between people, teams or tools, to trace where clarity was lost.
- For distributed or cross-functional teams that rely on async and written communication.
- When onboarding new people exposes gaps in how knowledge is shared and documented.
- When you want a lighter format for a serious topic, so people talk honestly about communication problems.
## Tips and tricks
- Keep the conversation on systems and handoffs, not individuals.
- Trace one real message that got distorted, step by step, to ground the discussion in a concrete story.
- Invite people from different roles and teams so every point along the chain is represented.
- Timebox each topic, especially The Source of the Static, where discussion can run long.
- Pick two or three improvements so the commitments are realistic and easy to track.
- Check the agreed actions at the next retrospective to see whether communication actually improved.
## Icebreaker questions
- What's the funniest miscommunication you've ever been part of, at work or in life?
- If your team's communication were a phone signal, how many bars would it have today?
---
# Sailboat Retrospective
URL: https://www.teamretro.com/retrospective-templates/sailboat-retrospective/
The Sailboat Retrospective asks your team to picture itself as a boat heading for a destination. It's a simple metaphor, and it gets people talking about forces they'd struggle to name in a plain "what went well" list.
The board has five areas. The goal is where you're heading. Wind is whatever pushes the team forward, anchors are what slow it down, and rocks are the risks ahead that could sink you if nobody steers around them. The sun covers the things that keep morale up.
Because one board covers both what's behind you and what's ahead, the sailboat retrospective works well when your team has drifted from its goals or is tired of the usual formats. It lets you talk about risks before they land, as well as the problems you've already hit.
## Topics
- **Goal**: What are we working toward?
- **Wind**: What is pushing us forward?
- **Anchor**: What is holding us back?
- **Rocks**: What risks do we face?
- **Sun**: What is making us feel good?
## When to use
- When your team has retrospective fatigue and needs a visual format to get people talking again
- At project milestones or quarterly reviews, to check progress and plan the next stretch
- When you want to discuss the risks ahead as well as the problems you've already hit
- For teams new to retrospectives, who benefit from a clear metaphor to guide the discussion
## Tips and tricks
- Explain the metaphor before anyone writes a note, so everyone knows what each part of the boat stands for
- Keep the picture visible all session so people place each note against the part of the boat it belongs to
- Give the anchors and rocks as much time as the wind and sun, so the session doesn't turn into a list of complaints
- Go around the room for each area so quieter team members get a turn
- Finish by picking the actions with the most impact that the team can actually carry out
- Split larger teams into breakout rooms so everyone gets a chance to contribute
## Icebreaker questions
- If your current project was a type of boat, what would it be and why?
- What's your favorite memory of being near water (ocean, lake, river)?
---
# Agile Center of Excellence Retrospective
URL: https://www.teamretro.com/retrospective-templates/agile-center-of-excellence-retrospective/
An Agile Center of Excellence (ACoE) brings together coaches, Scrum Masters, agile leaders and practitioners to improve how agile is practiced across an organization. This retrospective gives that group time to look at its own work: the standards it sets, the coaching it runs and the support it gives teams. The point is to find out what is actually moving teams forward and what is getting in their way.
It runs above the level of a single sprint. The board has four columns: Value We're Delivering, Practices to Refine, Organizational Impediments and Improvement Experiments. Participants look at the impact the center is having, where practices have drifted or vary between teams, which blockers no single team can remove, and what to try next. Looking for patterns across teams, not one-off events, lets the ACoE spend its effort on the changes that help many teams at once.
You come out with a short, prioritized improvement backlog the whole community has agreed on. Run it quarterly, after a major program increment or as part of your community-of-practice cadence, and you'll have a regular record of whether the center is making a difference. If you scale with [SAFe](https://scaledagileframework.com/), it fits alongside SAFe's communities of practice and its Lean-Agile Center of Excellence.
## Topics
- **Value We're Delivering**: What impact is the center having on teams?
- **Practices to Refine**: Which agile practices need more consistency or rethinking?
- **Organizational Impediments**: What systemic blockers sit beyond any single team?
- **Improvement Experiments**: What should we try next to grow agile maturity?
## When to use
- Quarterly or after a major program increment, when your agile community wants to look at its impact and reset priorities.
- When agile practices have drifted or vary between teams and you need to agree on standards again.
- When the same impediments show up in several teams and need fixing at the organization level.
- As a regular check-in for a community of practice or center of excellence that needs to show leadership what it delivers.
- During an agile transformation, to track maturity, capture lessons and plan the next round of coaching and training.
## Tips and tricks
- Stay on cross-team patterns and out of the details of any one team's sprint. That's the level this retro is for.
- Invite coaches, Scrum Masters and agile leaders, plus a few practitioners from the teams you support, so you hear how the center's work lands from outside it.
- Back up impediments and value claims with evidence where you can. Adoption or maturity data makes an escalation far more persuasive to leadership.
- Commit to a small number of experiments so the center can deliver them and measure the results next cycle.
- Watch for the echo chamber. Agile enthusiasts can celebrate practices that teams quietly find a burden, so ask for dissenting views.
- Give every action an owner and a success signal, so the next retro reviews progress instead of reopening the same discussions.
## Icebreaker questions
- If our Agile Center of Excellence were a superhero, what would its superpower be?
- What's one agile myth you wish you could permanently retire across the organization?
---
# FIFA World Cup Retrospective
URL: https://www.teamretro.com/retrospective-templates/fifa-world-cup-retrospective/
The FIFA World Cup Retrospective frames your sprint or project as a football match. Your team looks back at the goals it scored and the chances it missed, owns up to the fouls that slowed play, and agrees on a game plan for the next match. Everyone plays for the same side, which makes it a natural fit for a team conversation.
The board has four topics. Goals Scored is for the wins worth celebrating. Missed Shots covers the near misses and chances that slipped away. Fouls & Yellow Cards is for blockers and friction, and Game Plan is where the team turns all of that into actions. Football gives people an easy shorthand for awkward topics: "our estimates went wide" is easier to say than "we got it wrong again."
Run it during a World Cup or any big tournament, or whenever your regular retrospective needs a change. In TeamRetro you collect ideas, group similar ones, vote on what matters most and turn the top plays into actions with an owner, so the team leaves with a plan for the next round.
## Topics
- **Goals Scored**: What wins and achievements should we celebrate?
- **Missed Shots**: What opportunities did we let slip away?
- **Fouls & Yellow Cards**: What slowed us down or caused friction?
- **Game Plan**: What's our strategy for the next match?
## When to use
- During a World Cup or another big football tournament, when the theme is already on people's minds.
- When morale needs a lift and you want to celebrate wins while still working on real problems.
- At the end of a sprint, project or quarter, to review how the team played.
- For teams new to retrospectives, who find a familiar metaphor makes honest sharing easier.
- When you want celebration, reflection and planning in one short session.
## Tips and tricks
- Set the tone with a quick football intro. It gives people a shared language for the rest of the session.
- Timebox each topic like a half of a match so the conversation doesn't drift into extra time.
- Invite quieter team members to take their shot, and let them add ideas anonymously if that helps.
- Keep Fouls & Yellow Cards about situations and processes, not individuals.
- Use dot voting to pick the plays that matter most before you agree on the game plan.
- Close by giving every game plan action an owner so it doesn't get left on the bench.
## Icebreaker questions
- If our team were a national football team, what would our team chant be?
- Which World Cup moment best describes how our last sprint felt?
---
# Fiscal Year-End Review
URL: https://www.teamretro.com/retrospective-templates/fiscal-year-end-review/
The Fiscal Year-End Review is a retrospective for the close of your financial year. Leads from finance, sales, marketing and product look back at revenue, spending and the year's big initiatives against the targets you set, then agree on what to change for the year ahead.
The board has four columns. Revenue Analysis compares results with targets by product line, region or segment. Expense Management looks at where the money went and which spending paid off. Strategic Initiatives asks which projects moved the numbers and which drained resources. Strategic Outlook turns all of that into priorities for next year.
Because everyone adds ideas before the discussion starts, you hear from every function, including the people who don't own the spreadsheet. Bring the reports with you, keep the conversation on decisions instead of blame, and finish with an owner and a date for each change you agree on.
## Topics
- **Revenue Analysis**: How did our revenue performance compare to targets?
- **Expense Management**: How well did we control and optimize expenses?
- **Strategic Initiatives**: What major initiatives drove (or hindered) our performance?
- **Strategic Outlook**: How should we adjust our financial strategy for the upcoming year?
## When to use
- At the end of each fiscal year, to review results and plan the next one.
- When you're preparing annual budgets, forecasts and growth plans.
- After a major business event, such as an acquisition or a funding round, to rethink financial strategy.
- When results have drifted well away from target and you need to agree on a correction.
## Tips and tricks
- Share the key reports and metrics a few days ahead so people arrive having read them.
- Keep the discussion blameless so people can talk openly about the targets you missed.
- Make sure finance, sales, marketing and product are all in the room.
- Save time for next year's strategy as well as last year's numbers.
- Give every major action an owner and a due date.
- Split into smaller groups to dig into specific areas, then bring the findings back to the whole room.
## Icebreaker questions
- If our company was a publicly traded stock, would you buy, sell or hold? Why?
- What's one financial metric or KPI you wish we tracked more closely?
---
# Speed Car Retrospective
URL: https://www.teamretro.com/retrospective-templates/speed-car-retrospective/
The Speed Car retrospective uses racing metaphors to look at how your team is performing and where it can improve. Borrowing from Formula 1, it asks people to think about what pushes the work forward (Engines), what holds it back (Brakes), and who helps the team succeed (Pit Crew).
The racing theme gives the meeting some energy and makes it easier to talk about pace without it feeling like a performance review. Putting engines and brakes side by side shows your team where the time goes, and the pit crew column is a chance to recognize the people outside the team who keep things moving.
It works well for teams in fast-moving environments, because technical and interpersonal causes of a slowdown come up in the same conversation.
## Topics
- **Engines**: What is driving us forward?
- **Brakes**: What is slowing us down?
- **Pit Crew**: Who is supporting us?
## When to use
- When your team feels stuck or slow and needs a lift.
- After a fast-paced project, to see what helped you move quickly and what caused delays.
- When you want to recognize the people and teams that support you, and work out what you need from them.
- When your usual retro format has gone stale and you want a fresh way to talk about pace.
## Tips and tricks
- Use racing language through the session to keep the theme going.
- Ask for technical and human factors in each category.
- Balance problems with wins. Give the engines and the pit crew real time.
- Turn the biggest brakes into actions you can take next sprint.
- Racing visuals or a countdown at the start can set the mood, if your team enjoys that kind of thing.
- Timebox each area so all three get attention.
## Icebreaker questions
- If your team were a race car, what type would it be and why?
- What's your favorite pit stop moment, a time when someone helped you past a problem?
---
# Captain Planet Team-Up Retrospective
URL: https://www.teamretro.com/retrospective-templates/captain-planet-team-up-retrospective/
The Captain Planet Team-Up retrospective takes its theme from the 1990s cartoon in which five young heroes combine the powers of their rings (Earth, Fire, Wind, Water and Heart) to summon Captain Planet. Your team uses the same five elements to look at how it's working, with delivery and morale getting equal space.
Each element has its own focus. Earth is what's stable and working. Fire is the team's energy, including where burnout is creeping in. Wind collects new ideas and changes in the air. Water looks at what's flowing smoothly and where work gets stuck. Heart covers morale, trust and how well people support each other. In TeamRetro, people add notes to each element, group similar themes and vote on what matters most, then turn the top items into actions.
Use it when your team is tired of the standard "what went well, what didn't" routine. Fire and Heart put energy and morale on the board next to process, and those notes often explain the delivery problems that show up under Earth and Water.
## Topics
- **Earth: What's Solid**: What stable foundations are supporting the team?
- **Fire: Energy & Passion**: Where is energy high, and where is burnout creeping in?
- **Wind: Ideas & Change**: What new ideas or changes are blowing through the team?
- **Water: Flow & Blockers**: What's flowing smoothly and what's getting stuck?
- **Heart: Team & Morale**: How connected, supported, and motivated does the team feel?
## When to use
- When your team is in a routine rut and wants a themed format for a change.
- When you want to give morale and energy as much attention as delivery.
- After an intense or high-pressure sprint, to check in on burnout and motivation.
- With a team that responds well to metaphor and storytelling.
- As a quarterly or milestone retrospective, when you want to look at the team from several angles.
## Tips and tricks
- Introduce the five elements briefly so everyone knows what each one covers before adding notes.
- Ask people to add something to every element, including the less obvious ones, so you get a balanced picture.
- Give Heart as much weight as the others. Morale and connection often explain the delivery issues.
- Use dot voting across all five elements so the team focuses on the actions with the most impact.
- Keep the tone light, but make sure every important point ends up as an action item with an owner.
- Timebox each element so you don't spend all your energy on the first one or two.
## Icebreaker questions
- If you could have one of Captain Planet's elemental powers (Earth, Fire, Wind, Water, or Heart), which would you choose and why?
- Which fictional team or duo do you think has the best 'combining powers' chemistry?
---
# KALM Retrospective
URL: https://www.teamretro.com/retrospective-templates/kalm-retrospective/
The KALM retrospective asks your team to sort its work practices into four categories: Keep, Add, Less and More. You hold on to what's working, add something new where there's a gap, and adjust the rest.
Start Stop Continue gives you three choices: begin something, end it or leave it alone. KALM swaps the hard stop for 'less' and adds 'more', so a practice can be turned up or down without being dropped. Your team gets to fine-tune how it works instead of making dramatic changes.
The format suits teams that want gradual, steady improvement. Most of the conversation is about what to keep and adjust, and little is about what to cut entirely, so the tone stays positive and the discussion stays practical.
## Topics
- **Keep**: What should we keep doing?
- **Add**: What should we start doing?
- **Less**: What should we do less of?
- **More**: What should we do more of?
## When to use
- When you want small, steady improvements instead of a big change.
- When the team is performing well and needs fine-tuning, not an overhaul.
- When you want to protect good practices while adjusting the ones that have drifted.
## Tips and tricks
- Start by reviewing the actions from your last retrospective.
- Ask for specific examples. 'Code reviews take three days' is easier to act on than 'reviews are slow'.
- If ideas pile up, use dot voting to pick the ones worth discussing.
- Steer complaints toward a suggested change before they go on the board.
- Give each of the four categories its share of discussion time.
- Finish by turning the top-voted items into actions with owners.
## Icebreaker questions
- What's one small change you made recently that had a positive impact?
- If you could instantly master one new skill that would help the team, what would it be?
---
# Dark Souls Bonfire Retrospective
URL: https://www.teamretro.com/retrospective-templates/dark-souls-bonfire-retrospective/
The Dark Souls Bonfire Retrospective borrows the checkpoints from FromSoftware's Dark Souls games. In the game, a bonfire is where you rest, refill your flask and plan your next attempt at a boss that has already beaten you several times. This retrospective gives your team the same pause at the end of a sprint.
The board has four columns. Bonfires Lit is for wins and milestones. Bosses We Fought covers the big obstacles that tested the team. You Died: Lessons Learned is where you talk about what went wrong and what it taught you. Souls & Upgrades turns all of that into actions for the next sprint.
The theme earns its place in the You Died column. Dark Souls players expect to die over and over, and treating failure as part of the run makes it easier for people to own their mistakes without getting defensive. It suits teams that know the games, but each metaphor takes a sentence to explain to anyone who doesn't.
## Topics
- **Bonfires Lit**: What wins and milestones did we reach this sprint?
- **Bosses We Fought**: What major challenges or obstacles tested the team?
- **You Died: Lessons Learned**: Where did we fail, and what did those deaths teach us?
- **Souls & Upgrades**: What improvements and actions will we carry into the next run?
## When to use
- Your team knows its way around games and you want a themed retrospective with a story to it.
- Morale has dropped after a sprint full of setbacks, and you want to talk about failures without the mood getting heavy.
- Your usual Start Stop Continue retros have gone flat and the team needs a change of format.
- The team hit one or more major obstacles ('bosses') and needs to work out a plan for them.
- You want the team to get comfortable treating failure as something to learn from.
## Tips and tricks
- Set the scene with a bonfire image or quiet Dark Souls music in the background before you start.
- Keep the You Died column blame-free. Remind everyone you're there to learn from what happened, not to find who caused it.
- Timebox each column so the boss discussion doesn't take over. Aim for 8–10 minutes per column.
- Use grouping and voting in TeamRetro to find the boss most worth tackling first.
- Turn every item in Souls & Upgrades into an action with an owner, so the upgrades actually get equipped.
- Ask quieter teammates for their input directly. Even a small bonfire counts.
## Icebreaker questions
- If your past sprint were a Dark Souls boss, what would its name and signature attack be?
- What's the one 'bonfire' moment recently that made you breathe a sigh of relief?
---
# Road Trip Retrospective
URL: https://www.teamretro.com/retrospective-templates/road-trip-retrospective/
The Road Trip Retrospective frames your sprint or project as a drive your team took together. Some stretches were smooth, some had potholes, something kept the tank full, and there's a destination up ahead. Talking about a bumpy road is easier than talking about a failed process, so problems tend to come out sooner.
The board has four areas. Smooth Roads is for what went well and kept the team moving. Potholes & Roadblocks covers what slowed you down or got in the way. Fuel in the Tank is for the people, tools and habits that kept the team going, and Next Destination is where you agree on goals and actions for the next leg.
Use it at the end of a sprint, after a milestone, or when your usual retro needs a change. It works well for distributed teams, because the road gives everyone the same picture of where the team has been and where it's going next.
## Topics
- **Smooth Roads**: What went well and kept us cruising forward?
- **Potholes & Roadblocks**: What slowed us down or got in our way?
- **Fuel in the Tank**: What energized and kept the team going?
- **Next Destination**: Where do we want to head, and how do we get there?
## When to use
- At the end of a sprint or iteration, when you want a change from your standard retrospective format.
- After a major project or milestone, to look back over the whole trip and plan the next leg.
- When team energy is low and a light metaphor could get people talking honestly again.
- For distributed or remote teams who need a shared picture of where they've been and where they're going.
## Tips and tricks
- Introduce the road trip metaphor at the start so everyone knows what each area is for.
- Timebox each topic so the conversation doesn't stall on any single issue.
- Remind the team that every passenger sees a different part of the road, so quieter people know their view counts.
- Group similar ideas before voting so you discuss each big theme once.
- Turn Next Destination items into actions with an owner, so the retrospective leads to change.
- Rotate the facilitator each session so the format stays fresh and more people learn to run it.
## Icebreaker questions
- What's the best road trip snack of all time, and why is it non-negotiable?
- If our team's journey this sprint were a type of road, what would it be: highway, dirt track, or scenic route?
---
# Team Retreat Planning
URL: https://www.teamretro.com/retrospective-templates/team-retreat-planning/
Team Retreat Planning gets your whole team involved in planning its next offsite, so the retreat is built around what people actually need from it. You agree on the goals first, then decide what sessions, social time and setting will deliver them.
The board has four columns. Retreat Goals is where you agree what the time away is for, whether that's strategy, problem-solving, skills or reconnecting. Agenda Planning lists the sessions that serve those goals, from workshops to a retrospective. Team Bonding covers the informal time where people get to know each other, like group meals or a hike. Venue and Logistics handles the practical side: cost, access, meeting space and dietary needs.
Starting from goals stops the agenda filling up with activities nobody can explain. The same board works for a one-day offsite or a multi-day getaway. Use it after a stretch of intense work, when new people have joined, before a big new initiative, or as part of an annual planning rhythm.
## Topics
- **Retreat Goals**: What are the key objectives you hope to achieve during the retreat?
- **Agenda Planning**: What types of activities or sessions would help achieve the retreat goals?
- **Team Bonding**: How can we create opportunities for genuine connection and relationship building?
- **Venue and Logistics**: What factors should we consider when choosing a retreat location and accommodations?
## When to use
- When your team is facing big changes or challenges and needs time to realign.
- After a period of intense work or high stress, to recharge and reconnect.
- When several new people have joined and the team needs to gel.
- Once or twice a year, as a regular habit for team development and planning.
- When launching a new project or initiative, to get everyone pointed the same way from the start.
## Tips and tricks
- Involve the whole team in planning so the retreat reflects what everyone needs from it.
- Leave plenty of free time between sessions for unplanned conversations.
- Ask people to keep laptops and phones away during sessions.
- Give people roles for the day, such as timekeeper or logistics lead, so things run smoothly.
- Build in time at the end to capture takeaways and actions.
- Follow up a week or two later so the decisions from the retreat don't fade.
## Icebreaker questions
- If you could have any superpower, what would it be and why?
- What's the most adventurous thing you've ever done?
---
# New Team Member Onboarding Retrospective
URL: https://www.teamretro.com/retrospective-templates/new-team-member-onboarding-retrospective/
The New Team Member Onboarding Retrospective is a session where your current team works out what a new hire needs to know to settle in. Together you list what to cover across five areas: company culture, role responsibilities, team dynamics, growth and development, and anything else people think matters. The result is an onboarding plan that sets clear expectations and helps the new person contribute from their first days.
Your team draws on its own experience of joining. People remember what confused them, what they had to find out the hard way and what they wish someone had told them, and that adds up to a plan covering both the practical and the cultural side of joining. Run it again when the team changes or after a new hire has settled in, and the plan keeps improving from what the team thinks is important, beyond your standard onboarding checklists and documents.
## Topics
- **Company Culture**: What aspects of our company culture should new hires understand?
- **Role Responsibilities**: What key duties and expectations should be covered for this role?
- **Team Dynamics**: How can we help new hires integrate into the team smoothly?
- **Growth and Development**: What opportunities exist for professional growth and skill development?
- **Open Discussion**: What other areas should we cover during onboarding?
## When to use
- Before a new hire starts, so the team agrees on what to cover and who will cover it.
- As a team-building activity that makes your culture and team norms explicit.
- After significant team changes or restructuring, to realign on roles and responsibilities.
- Once or twice a year, to review and update your onboarding process.
## Tips and tricks
- Ask for open, honest input from new and existing team members alike.
- Have people think back to their own first day on the job.
- Ask: what's something you wish someone had told you about the organization?
- Where you can, involve cross-functional stakeholders for a wider view.
- Share the results with your new team members and ask for their feedback and questions.
- Try running it as an icebreaker with the new team member and the current team together.
## Icebreaker questions
- If you could pick a new hobby or skill to learn, what would it be and why?
- What's the best piece of advice you've ever received, and who gave it to you?
---
# Volleyball Retrospective
URL: https://www.teamretro.com/retrospective-templates/volleyball-retrospective/
The Volleyball Retrospective reviews your team's work the way a coach reviews a match, one type of play at a time. Each column is a move from the game.
Serves are the initiatives the team started. Digs are the challenges you recovered from and turned around, like a production incident that led to better monitoring. Sets are the enablers: the tools, practices and support that set others up to succeed. Spikes are the wins, and Blocks are the problems the team headed off before they landed, such as updating dependencies before a security issue.
The format gives credit to work that usually goes unnoticed. In volleyball the setter rarely scores, but most attacks depend on a good set, and the Sets and Blocks columns do the same for the people who keep your team running. It suits a team that likes sports metaphors or wants a change from its usual retro.
## Topics
- **Serves**: What did we start?
- **Digs**: What challenges did we reframe?
- **Sets**: What set us up for success?
- **Spikes**: What winning moves did we make?
- **Blocks**: What issues did we prevent?
## When to use
- When your team needs a change of pace from its usual retrospective
- After a project phase where different people played distinct roles
- When you want to recognize the support work that made the wins possible
- When your team responds well to sports analogies
## Tips and tricks
- Ask about both individual and team contributions. In volleyball, a point needs both
- Explain each play at the start for anyone who doesn't follow the sport
- Rotate positions: go around the room so each person gets time to speak
- Timebox each column to keep the pace up
- Treat Digs as recoveries, not failures, so the discussion stays on what the team learned
- Give Sets and Blocks as much attention as Spikes. That's where the quieter work gets credit
## Icebreaker questions
- If our team were a volleyball team, what position would you play and why?
- What's your favorite sports moment where teamwork made all the difference?
---
# Simply Agile Retrospective
URL: https://www.teamretro.com/retrospective-templates/simply-agile-retrospective/
Sometimes the best retrospective is the simplest one. The Simply Agile Retrospective skips the metaphors and asks the questions your team would ask anyway: what worked, what didn't and what you'll change, with a short round of thanks at the end. It's quick to explain and easy to facilitate, so the time goes on the discussion.
The board has four areas. "What worked well?" is for the practices and wins worth repeating. "What didn't work?" covers what slowed the team down or caused frustration. "What will we change?" turns the discussion into one or two actions with owners, and "Kudos & shout-outs" is a short space to thank the people who helped.
It suits new Scrum teams building the habit of regular retros, and experienced teams who want a reliable default they can run every sprint in 30 to 45 minutes. In TeamRetro, people add ideas on their own first, then the team groups them, votes and assigns actions.
## Topics
- **What worked well?**: What went smoothly and is worth repeating?
- **What didn't work?**: What slowed us down or caused frustration?
- **What will we change?**: What concrete actions will we try next?
- **Kudos & shout-outs**: Who or what deserves recognition this sprint?
## When to use
- At the end of a sprint or iteration, when you want a quick, focused reflection without much facilitation overhead.
- For new agile or Scrum teams building the habit of regular retrospectives.
- When time is short and you need clear actions in 30 to 45 minutes.
- As a default retrospective you can run every sprint and compare over time.
## Tips and tricks
- Keep it to 30 to 45 minutes so the conversation stays sharp.
- Limit the team to one or two concrete actions per retrospective so they actually get done.
- Start with anonymous brainstorming for honest input, then group and discuss themes together.
- Give each action an owner and a due date so nothing falls through the cracks.
- Rotate the facilitator so more people on the team learn to run a retro.
- Check the previous retrospective's actions at the start of each session.
## Icebreaker questions
- If this sprint were a weather forecast, what would it be?
- What's one word that sums up how you felt about this iteration?
---
# Blast Off Launch Retrospective
URL: https://www.teamretro.com/retrospective-templates/blast-off-launch-retrospective/
Before the countdown to your next launch starts, it's worth looking back at the last one. The Blast Off Launch Retrospective frames a recent launch, release or major milestone as a rocket journey: the fuel that powered you, the drag that slowed the ascent, the course corrections you'd make and where you're aiming next. The space theme gives the conversation some lift without making it any less useful.
The board has four topics. Fuel for Lift-Off covers what gave the launch momentum. Drag & Resistance names the obstacles and friction on the way up. Course Corrections is for concrete changes to processes, tools or behaviors, and Next Destination sets goals for the next mission. Because the metaphor is playful, people at every level of seniority find it easier to speak honestly. It's especially useful for product launches, releases and project go-lives, where morale matters as much as the technical result.
In TeamRetro, the session ends with a shared look at what went well and a clear list of action items. Use it to close out a high-stakes release or mark the end of a project phase, and you'll go into the next launch knowing what to keep and what to change.
## Topics
- **Fuel for Lift-Off**: What powered our launch and gave us momentum?
- **Drag & Resistance**: What slowed us down or created friction on the way up?
- **Course Corrections**: What should we adjust or steer differently next time?
- **Next Destination**: Where are we aiming for our next mission?
## When to use
- After a major product launch or release, to celebrate the wins and capture lessons before the next cycle begins.
- At the close of a project phase or go-live, where morale and momentum matter as much as the technical result.
- When a standard retrospective feels stale and you want a themed format to change things up.
- After a high-pressure delivery, to help the team decompress, reflect and reset for the next mission.
## Tips and tricks
- Open with a quick mission briefing so everyone is in a playful, open frame of mind.
- Keep Drag & Resistance focused on systems and processes, not individuals, so people feel safe.
- Timebox each topic to about 10 minutes so the session doesn't drift.
- Have every crew member add ideas on their own first, which limits groupthink and the pull of louder voices.
- Turn Course Corrections into owned action items so the improvements actually reach the next launch.
- Finish on Next Destination so the session closes looking forward.
## Icebreaker questions
- If our team launch were a space mission, would it have been a smooth orbit or a bumpy re-entry, and why?
- If you could pack one item for the next mission to make it easier, what would it be?
---
# Personal Growth Retrospective
URL: https://www.teamretro.com/retrospective-templates/personal-growth-retrospective/
The Personal Growth retrospective turns the usual retro around. Instead of asking how the team's process went, it asks each person what they want to get better at, and what the team can do to help.
The board has three columns. Improve is for actions you'll take yourself before the next sprint, like asking for feedback after each presentation. Support is where you ask the team for something specific, such as more code reviews or a chance to shadow a client meeting, and say why it matters. Grateful closes the session with thanks for the people and conditions that helped you this period.
Because people say their goals out loud and the team hears exactly what help is wanted, support stops being a vague offer and becomes something someone can act on. It works well before performance reviews, after a big milestone, or any time the team wants to know each other better. Start by sharing a growth area of your own; it makes it easier for others to do the same.
## Topics
- **Improve**: What actions can you personally take to improve the next sprint?
- **Support**: How can the team help you going forward and why is that important?
- **Grateful**: What are you grateful for at work?
## When to use
- When people on the team want clearer direction on their professional development
- Before performance reviews, to help each person set goals they've already talked through
- When the team wants to get better at supporting each other
- After a major project milestone, to reflect on what each person learned
## Tips and tricks
- Go first and share one of your own growth areas; it makes it easier for others to be candid
- Ask for specific commitments. "Get better at presenting" is a wish; "ask for feedback after every demo" is an action
- Keep the focus on what each person can do, not on blaming others or circumstances
- Follow up on support requests in the next team meeting or in one-on-ones
- Run it every quarter so people can see how far they've come
- Let people keep sensitive development topics private, and follow up one-on-one instead
## Icebreaker questions
- What's one skill you learned as a child that still helps you today?
- If you could instantly master any professional skill, what would it be and why?
---
# Mid-Year Goal Check-In
URL: https://www.teamretro.com/retrospective-templates/mid-year-goal-check-in/
A mid-year goal check-in is a structured conversation at the halfway point of the year. Managers and team members look at the goals they set at the start of the year, see what's been achieved and change course where they need to, while there's still time to make a difference.
The template walks through five prompts: progress so far, whether the goals still fit your priorities and values, the hurdles you've hit, the habits that have helped or hurt, and the next specific step. Working through them in order moves the conversation from looking back to deciding what happens next.
Run as a team, the mid-year check-in makes goals and expectations visible to everyone, which makes it easier to hold each other to them. Run one-to-one, it gives a manager and a team member an honest midpoint review well before the end-of-year appraisal.
## Topics
- **Progress Update**: What milestones have you achieved toward your goal/s so far?
- **Alignment with Values**: How well do the goal/s still fit your current priorities and values?
- **Hurdles and Challenges**: What obstacles have you encountered, and how have you addressed them?
- **Habits and Behaviors**: What actions or behaviors have been helping you achieve progress?
- **Next Steps**: What's the next specific action you can take to move closer to your goal/s?
## When to use
- When you need a formal mid-year review of individual and team goals.
- To celebrate wins from the first half of the year and name what's getting in the way.
- To reset goals and priorities when circumstances have changed since you set them.
- When team members and stakeholders need a shared picture of what's expected for the rest of the year.
- Ahead of second-half planning, so the plan starts from what you've learned.
## Tips and tricks
- Make it safe to be honest. Nobody gets blamed for a goal that slipped.
- Invite stakeholders and cross-functional partners when you need a wider view of progress and problems.
- Back up observations with data and metrics, and make room for how people felt about the half-year too.
- Celebrate wins, including the small ones.
- Give every action an owner and a date, and check on them before the year ends.
- Let the team or the individual lead the conversation instead of the manager, and keep feedback constructive.
## Icebreaker questions
- If you had to sum up our year so far in one word, what would it be and why?
- Share a personal or professional achievement from the past six months that you're particularly proud of.
---
# Staff Retention Strategy Workshop
URL: https://www.teamretro.com/retrospective-templates/staff-retention/
A Staff Retention Strategy Workshop brings HR, managers and team members together to work out why people stay and what would make them leave. It's an employee retention workshop run as a retrospective: everyone adds ideas privately, then the group sorts them, votes and turns the strongest into actions.
The board moves from diagnosis to plan. Start with what motivates your employees and what the company already does well, then name the gaps, from onboarding to career paths. Finish with specific retention strategies and the supportive culture you want to build.
Bring data if you have it, such as exit interview themes or engagement survey results, so the discussion starts from evidence. Leave with a small number of initiatives, each with an owner and a date to review whether turnover has moved.
## Topics
- **What motivates our employees?**: What makes people want to stay here?
- **Our Company's Capabilities**: What resources and strengths does our company have?
- **Areas for Improvement**: Where are we falling short for our people?
- **Retention Strategies**: Which changes would most improve retention?
- **Building a Supportive Culture**: What would make our culture more supportive?
## When to use
- When turnover is rising and you want to find the causes before more people leave.
- As a regular review of whether your retention strategies are working.
- Before or during a major organizational change that could affect how people feel about their jobs.
- After exit interviews or an engagement survey point to problems with job satisfaction or culture.
- While retention is healthy, to find out what's keeping it that way.
## Tips and tricks
- Make it safe to speak. People rarely say why they might leave unless they trust the room.
- Include people from different levels and departments, not only HR and leadership.
- Collect ideas anonymously so people can be candid without worrying about repercussions.
- Agree on two or three initiatives and give each one an owner.
- Review the initiatives at your next session and check them against turnover and survey data.
- Tell the whole company what you're changing, so people see their input led somewhere.
## Icebreaker questions
- If you could choose any job in the world, what would it be and why?
- What's the best lesson you've learned from a previous job?
---
# Oktoberfest Brewfest Retrospective
URL: https://www.teamretro.com/retrospective-templates/oktoberfest-brewfest-retrospective/
The Oktoberfest Brewfest retrospective brings the feel of a festival beer hall to your team's review. Borrowing from Munich's Oktoberfest, it uses the imagery of brewing and toasting to help your team look back and plan ahead in a relaxed, celebratory mood. It works well in the autumn, as a change from your usual sprint or project review.
Four beer-themed prompts map onto familiar retrospective questions. What's Brewing Nicely covers what's going well. What Left a Bad Taste is for the problems. Ingredients to Add asks what you should mix in to brew a better batch next time, and Raise a Toast is for celebrations and shout-outs. The prompts are easy to answer, which helps quieter team members join in.
Use it to close a sprint, wrap up a quarter or mark the festive season. Because the session ends on a toast, people leave on a positive note with a clear list of improvements to try. If some of your team don't drink, the metaphor works just as well with coffee or soda, since none of the prompts depend on beer.
## Topics
- **What's Brewing Nicely**: What has been going well and tastes great?
- **What Left a Bad Taste**: What went wrong or felt sour this time around?
- **Ingredients to Add**: What should we mix in to brew a better batch next time?
- **Raise a Toast**: Who or what deserves a celebratory cheers this round?
## When to use
- When you want a seasonal twist on your end-of-sprint or end-of-quarter review in the autumn.
- When team morale needs a lift and you want the session to feel relaxed and low-pressure.
- When new members have joined and you want a relaxed format that gets everyone contributing.
- When celebrating a major milestone or release, to balance recognition with honest improvement.
- When your usual retrospective format feels stale and the team needs a change.
## Tips and tricks
- Lean into the theme: use beer and festival imagery in your intro to set a relaxed, playful mood.
- Timebox each column so the festivities don't crowd out the discussion, and aim for even contributions across all four.
- Keep What Left a Bad Taste blame-free by focusing on processes and situations instead of individuals.
- Close with Raise a Toast so the session ends on a positive note.
- Let quieter members add their thoughts anonymously first, then group and vote so everyone has a say.
- Turn the top improvement ideas into action items with owners so they don't go flat after the meeting.
## Icebreaker questions
- If your last sprint were a beer, what kind would it be and why?
- What's one festive tradition you'd love to bring into your team's culture?
---
# Operational Efficiency Review
URL: https://www.teamretro.com/retrospective-templates/operational-efficiency-review/
The Operational Efficiency Review is a structured retrospective for looking at how your business runs: its operations, processes and costs. The aim is to find where time and money are being lost and agree on what to change. It works best with people from several functions in the room and real numbers on the table.
The session starts by recognizing the operational gains from the last period and the work behind them. The team then looks at the areas that need attention, brainstorms possible solutions and turns the strongest into action plans with owners, timelines and measures. You're looking for workflows to simplify, duplicated effort to cut and savings that don't cost you quality or customer satisfaction.
Running it regularly keeps the team focused on the same performance indicators (KPIs) and shows whether last period's changes actually worked. You can adapt the prompts to your industry, from manufacturing and logistics to support and finance teams.
## Topics
- **Operational Wins**: What operational successes did we achieve this period?
- **Areas for Improvement**: What operational areas need attention or optimization?
- **Potential Solutions**: What ideas do we have to address operational inefficiencies?
- **Action Plans**: What specific steps should we take to improve operational efficiency?
## When to use
- Run it on a regular cadence, such as quarterly, so operational reviews become a habit.
- Use it when you need to cut costs or fix slow processes across the organization.
- Run it during rapid growth, market shifts or organizational changes that affect how you operate.
- Use it when preparing for annual budgeting and strategic planning, to find savings and process improvements.
- Run it after a major system implementation, merger or acquisition, to remove duplicated effort and settle on one way of working.
## Tips and tricks
- Bring the relevant operational metrics and KPIs so the discussion runs on data.
- Keep it blame-free so people can discuss problems without fear of repercussions.
- Involve people from other functions and subject matter experts for a wider view and stronger buy-in.
- Prioritize initiatives by likely impact, feasibility and fit with your strategy.
- Give every action plan an owner, a timeline and a success measure.
- Celebrate quick wins and report progress regularly so the effort keeps going.
## Icebreaker questions
- If you could eliminate one operational inefficiency with a magic wand, what would it be and why?
- Share a personal experience where a process improvement made your life easier or more efficient.
---
# Toy Story Tales Retrospective
URL: https://www.teamretro.com/retrospective-templates/toy-story-tales-retrospective/
The Toy Story Tales Retrospective borrows the world of the films, where a group of toys sticks together through every setback, to frame a familiar set of retro questions. Your team looks back on its last sprint or project through four topics with a Toy Story theme.
A Friend in Me is for the support and teamwork that helped most. Lost in the World covers where people felt stuck, confused or off track. To Infinity and Beyond is for momentum and big wins, and Packing the Toy Box is where you decide what to keep, what to change and what to try next.
The theme makes it easier for people to talk, especially quieter team members and anyone new, and it gives a tired team a lighter session after an intense sprint. The structure underneath is the one a standard retro uses, so you still leave with actions and owners.
## Topics
- **A Friend in Me**: What support or teamwork helped you most?
- **Lost in the World**: Where did you feel stuck, confused or off-track?
- **To Infinity and Beyond**: What gave us momentum or a big win?
- **Packing the Toy Box**: What should we keep, change or try next?
## When to use
- When your team needs a lighter break from its usual retrospective format.
- After a long or intense sprint, when lifting the mood will help people talk honestly.
- For teams that enjoy themed sessions and want a change from their regular agile ceremonies.
- When new team members have joined and you want a friendly, low-pressure way in.
## Tips and tricks
- Set a playful tone with character images, then keep the reflection itself concrete.
- Use the light framing to draw out quieter voices, and make sure everyone gets a turn.
- Timebox each topic so the theme doesn't crowd out discussion and action setting.
- Keep Lost in the World on situations and behaviors, not blame.
- Close by turning your best Packing the Toy Box ideas into actions with owners and due dates.
- Rotate facilitation so different people can put their own spin on the theme.
## Icebreaker questions
- If you were a Toy Story character this sprint, who would you be and why?
- What's one toy from your childhood you'd love to have on the team right now?
---
# Trick or Treat Retrospective
URL: https://www.teamretro.com/retrospective-templates/trick-treat-retrospective/
The Trick or Treat Retrospective gives your sprint review a Halloween theme. Treats are the wins and the things that went well. Tricks are the obstacles that tripped the team up. Haunting Concerns is for the worries people are carrying into the next sprint, and Boo-tiful Ideas is where you come up with fixes.
The Haunting Concerns column is the one that sets it apart. Most retros look back, but this one gives people a place to name a risk before it turns into a problem, such as a key developer going on leave or technical debt that's getting harder to work around. Calling problems tricks also takes some of the sting out of raising them.
It's an obvious fit for the last retro in October, and it works any time your team is tired of the usual format. Explain the theme briefly at the start, since not everyone grew up with Halloween.
## Topics
- **Treats**: What sweet successes did we enjoy?
- **Tricks**: What obstacles tripped us up?
- **Haunting Concerns**: What worries are haunting the team?
- **Boo-tiful Ideas**: What magical improvements can we conjure?
## When to use
- Around Halloween, when the theme feels natural and timely.
- When retrospective fatigue has set in and you want a fresh format to get people talking.
- When you want problems to feel easier to raise, by calling them tricks instead of failures.
- When the team is carrying worries about upcoming work and you want them on the table.
## Tips and tricks
- Set the mood with Halloween visuals or background music.
- Make it clear that tricks are obstacles the team faced together, not a chance to blame individuals.
- Split the time between treats and tricks so you celebrate wins and still deal with the problems.
- Make sure the session ends with concrete next steps and an owner for each.
- Not everyone is familiar with Halloween, so take a moment to explain the theme.
- Start with treats to set a positive tone before moving on to tricks.
## Icebreaker questions
- If you could dress up as any character for Halloween, who would you be and why?
- What's your favorite Halloween candy or treat, and does it say anything about your personality?
---
# Love, Wish & Wonderland Retrospective
URL: https://www.teamretro.com/retrospective-templates/love-wish-and-wonderland-retrospective/
Love, Wish & Wonderland is a retrospective that moves from appreciation to imagination. Your team starts with what it values, moves on to what it would change, then spends some time on ideas that might seem out of reach today. The light framing makes it easier for people to share honest feelings as well as bold ideas.
The board has four columns. Love surfaces the practices, habits and wins the team wants to protect. Wish captures realistic improvements people would like to see, framed as hopes instead of complaints. Wonderland is the no-limits column for "what if" ideas and experiments, with no feasibility check yet. Actions turns the strongest wishes and Wonderland ideas into commitments with owners.
It works well after a milestone, with a tired team that needs some energy back, or at the start of a new initiative where imagination matters. In TeamRetro you can run it remotely or in the room: add ideas, group the themes, vote on what matters most and track the actions through to your next retro.
## Topics
- **Love**: What do you genuinely value and want to keep?
- **Wish**: What changes or improvements would you like to see?
- **Wonderland**: What bold 'what if' ideas could we explore?
- **Actions**: What will we commit to doing next?
## When to use
- When the team wants a change from the standard sprint retrospective.
- After reaching a milestone or finishing a project, to celebrate and think about what's next.
- When morale or energy is low and you want to start from what's going well.
- At the start of a new initiative where open, blue-sky thinking is useful.
- When you want practical improvements and bigger ideas in the same session.
## Tips and tricks
- Say at the start that Wonderland is judgment-free, so people feel safe sharing wild ideas.
- Start with Love to build some positive energy before moving on to wishes and what-ifs.
- Use anonymous input so quieter or more junior team members share openly.
- Timebox each column so Wonderland doesn't crowd out the actions.
- Group and vote on ideas to find the themes that matter most to the whole team.
- Turn the top wishes and Wonderland ideas into actions with owners, so the session changes something.
## Icebreaker questions
- If your team had a magic wand, what one thing would you instantly change about how you work?
- What fictional place or story world best represents your team right now, and why?
---
# SWOT Analysis for teams
URL: https://www.teamretro.com/retrospective-templates/swot-analysis-for-teams/
SWOT analysis is a planning method that looks at four areas: Strengths, Weaknesses, Opportunities and Threats. It's usually credited to Albert Humphrey, who worked on it at the Stanford Research Institute in the 1960s and 1970s, and teams use it to sort the internal and external factors that affect their success.
In a team SWOT analysis, you look at your own capabilities (Strengths and Weaknesses) alongside the outside forces you have to respond to (Opportunities and Threats). That helps you build on what you're good at and deal with problems before they grow.
SWOT is most useful for strategic planning, project reviews and team development. Because it puts the good and the bad on the same board, the action plan that comes out of it tends to be more balanced.
The four quadrants split into two pairs. Strengths and Weaknesses are internal: they describe things inside your team or organization that you control, such as skills, processes, resources, or reputation. Opportunities and Threats are external: they describe forces in the wider market or environment that you don't control but must respond to, such as competitors, regulation, customer trends, or new technology. Keeping internal and external factors separate is what stops a SWOT from collapsing into a single undifferentiated list. A common point of confusion is the line between a Strength and an Opportunity: a Strength is something you already have, while an Opportunity is an external opening you could take advantage of.
The Threats quadrant is the one teams most often skip, and it's often the most useful. A good threat analysis looks across several categories: competitive threats (a rival's new feature or lower price), market threats (shrinking demand or a shifting customer base), regulatory threats (new compliance requirements), and resource threats (key-person dependency, supplier risk, or budget cuts). For example, a SaaS team's SWOT might list "experienced engineering team" as a Strength, "no enterprise sales motion" as a Weakness, "growing demand for our category" as an Opportunity, and "a well-funded competitor moving into our niche" as a Threat. Naming threats early turns them from surprises into planned-for risks.
## Topics
- **Strengths**: What advantages do we have over others?
- **Weaknesses**: What weaknesses do we have relative to others?
- **Opportunities**: What could we do to exploit our advantages?
- **Threats**: What external forces could negatively impact us (competitive, market, regulatory, or resource threats)?
## When to use
- Before starting a new project or initiative, to assess readiness and spot potential challenges
- During strategic planning sessions, to connect team goals to the organization's objectives
- When facing significant changes or challenges, to evaluate the team's position and options
- In quarterly reviews, to track progress and adjust team strategy
## Tips and tricks
- Ask for specific, concrete examples instead of general statements
- Spend equal time on each of the four quadrants
- Use dot voting to prioritize the most important items in each category
- Write action items that use your strengths to address your weaknesses
- Keep previous SWOT analyses and compare them to track progress over time
- Think about both the short and long term when identifying opportunities and threats
## Icebreaker questions
- What's one unexpected strength you discovered about our team in the past month?
- If you could instantly improve one aspect of our team, what would it be and why?
---
# Pizza Party Retrospective
URL: https://www.teamretro.com/retrospective-templates/pizza-party-retrospective/
The Pizza Party Retrospective frames your sprint as a pizza your team made together. Some of it came out well, some of it got burnt, and there are a few toppings you'd add or drop next time. It's a light theme, and it makes feedback easier to give: saying the crust got burnt is less loaded than saying a process failed.
The board has four areas. Cheesy Goodness is for the wins and moments that made the team happy. Burnt Crust covers what went wrong or left a bad taste, without pointing at who left it in the oven. New Toppings is for ideas and experiments to try next sprint, and Leave Off the Menu is for habits, meetings and processes the team should stop.
Use it when your regular retro has gone stale, after a release you want to celebrate, or when a new team is getting into the habit of reflecting. Close with two or three actions and an owner for each, so the session ends with more than a good mood.
## Topics
- **Cheesy Goodness**: What went really well and made everyone happy?
- **Burnt Crust**: What got overcooked, went wrong, or left a bad taste?
- **New Toppings**: What new ideas or experiments should we try next?
- **Leave Off the Menu**: What should we stop doing or remove entirely?
## When to use
- When your regular retrospectives feel stale and the team needs a fresh format
- After a major release or milestone you want to celebrate in a relaxed setting
- When you want quieter team members to give honest feedback without feeling put on the spot
- As a light way to get a new team into the habit of regular reflection
## Tips and tricks
- Lean into the theme. Order actual pizza or host a virtual lunch to set a relaxed, social tone
- Explain what each area stands for before people start adding ideas, so the metaphor stays clear
- Timebox each area so the jokes don't crowd out the actions
- Use anonymous contributions in TeamRetro so quieter team members speak up
- Pick a few actions at the end instead of trying to fix everything at once
- Don't let the theme take over. Always close with clear owners and next steps
## Icebreaker questions
- If you were a pizza topping, which one would you be and why?
- What's your go-to comfort food after a tough day at work?
---
# Star Wars: The Agile Force Awakens Retrospective
URL: https://www.teamretro.com/retrospective-templates/star-wars-the-agile-force-awakens-retrospective/
This Star Wars retrospective gives your sprint review a space-opera frame. Your team sorts what happened into four camps: what gave it strength, what pulled it off course, the path to grow stronger and the small annoyances that keep firing and missing.
The board has four columns. The Force is for wins and good habits. The Dark Side holds the obstacles and missteps that held you back. The Jedi Path is where you list new practices to start. The Stormtroopers column is for recurring irritations, like an out-of-date board or notifications going to the wrong channel, that never feel serious enough for a normal retro but drain energy every week.
The structure is close to Start Stop Continue, with the extra Stormtroopers column for the small stuff. Everyone adds notes privately, then you group them, vote and turn the top items into actions. Nobody needs to have seen the films; the column prompts explain themselves. Use it when your team is tired of the usual format, or around a release when people could use a lighter session.
## Topics
- **The Force**: What went well and gave us strength this sprint?
- **The Dark Side**: What pulled us off course or held us back?
- **The Jedi Path**: What should we start doing to grow stronger?
- **The Stormtroopers**: What recurring annoyances keep missing the mark?
## When to use
- When your team is tired of the usual retro and needs a different format to get talking.
- At the end of a sprint or milestone, when you want a candid conversation about what worked and what didn't.
- With a newer team, where a themed frame makes it easier to raise tough topics.
- Around a release or a team event, when you want a lighter session that still ends in actions.
## Tips and tricks
- Play some film music or invite themed backgrounds as people join, but don't let the theme take over the session.
- Keep the Dark Side blame-free. Talk about how the work is set up, not about individuals.
- Timebox each column so you leave time for grouping, voting and agreeing on actions.
- Use dot voting to pick the Jedi Path ideas and Stormtrooper fixes worth acting on.
- Turn the top votes into actions with an owner and a due date.
- Use anonymous mode, or ask quieter people to go first, so the loudest voices don't take over.
## Icebreaker questions
- If you could have one Star Wars character on your team this sprint, who would it be and why?
- Are you more of a Jedi, a Sith, or a droid when it comes to your work style?
---
# Take the Controller Retrospective
URL: https://www.teamretro.com/retrospective-templates/take-the-controller-retrospective/
Take the Controller treats your last sprint like a video game. Your team posts its high scores, reports the glitches that tripped everyone up, names the power-ups that helped, and plans how to get through the next level.
The board has four columns. High Scores is for wins and achievements. Glitches & Bugs holds the process problems and friction points, like standups that overrun or a staging environment that keeps going down. Power-Ups is for the tools, habits and people that helped the team perform better. Next Level is where you pick a few concrete actions for the next sprint.
The gaming language makes it easy to talk about problems as things to fix rather than faults, which helps when the team has had a rough sprint. Any team that works in cycles can use it, from software to campaigns to operations. Run it when your usual format has gone stale, or after a release when there are both wins and bugs to talk about. Nobody needs to be a gamer to follow along.
## Topics
- **High Scores**: What wins or achievements did we earn this sprint?
- **Glitches & Bugs**: What broke, slowed us down, or didn't behave as expected?
- **Power-Ups**: What tools, habits or people helped us perform better?
- **Next Level**: What should we do to level up in the next sprint?
## When to use
- When your team is tired of its usual retrospective format and needs a change of pace.
- After a sprint, milestone or release, when there are wins to celebrate and improvements to plan.
- When quieter team members need a low-pressure theme to make contributing easier.
- With teams that enjoy games and would welcome the theme.
## Tips and tricks
- Use the gaming language from the start. It helps people relax and share more openly.
- Timebox each column so no single level takes over the session.
- Group similar glitches before voting so the team focuses on patterns, not one-off complaints.
- Make sure every player gets a turn at the controller, and invite quieter members to add their high scores.
- Turn Next Level ideas into actions with owners and due dates, so the improvements ship before the next retro.
- Don't let the theme hide real problems. Give Glitches & Bugs as much attention as High Scores.
## Icebreaker questions
- If your work this sprint were a video game, what genre would it be and why?
- What's the one in-game power-up you wish you could use in real life at work?
---
# Reddit Rewind Retrospective
URL: https://www.teamretro.com/retrospective-templates/reddit-rewind-retrospective/
The Reddit Rewind retrospective borrows Reddit's vocabulary of upvotes, downvotes, trending threads and hot takes to look back on a project, sprint or year. Most of your team will know what those words mean already, so the format needs almost no explanation, and the casual framing makes it easier to say what actually flopped.
The board has four areas. Most Upvoted is for the wins and highlights that earned their karma. Most Downvoted covers the frustrations and friction that dragged the team down. Trending Threads collects the open questions the team keeps coming back to, and Hot Takes is for the bold or unpopular opinions people don't usually voice in a retro.
Voting works the way it does on Reddit: the items with the most votes rise to the top and get discussed first. Run it for an end-of-year review, a check-in with a community or content team, or whenever your usual format has gone stale. Finish by turning the top-voted downvotes and threads into a few actions with an owner.
## Topics
- **Most Upvoted**: What earned the most karma this time around?
- **Most Downvoted**: What got buried and left us frustrated?
- **Trending Threads**: Which ongoing topics still need more discussion?
- **Hot Takes**: Got a bold or unpopular opinion to share?
## When to use
- At the end of the year, when your team wants a lighter way to look back on the highs and lows.
- When your usual retrospective format has gone stale and participation is dropping.
- For community, content or social media teams who already think in upvotes and threads.
- When you want the candid feedback that a standard format tends to miss.
## Tips and tricks
- Lean into the Reddit theme from the start. It tells people that playful, honest contributions are welcome.
- Use voting the way Reddit uses upvotes, so the items the team cares about most rise to the top.
- Before Hot Takes, say out loud that bold opinions are safe to share and won't be held against anyone.
- Timebox each category so there's enough time left to turn the top items into actions.
- Allow anonymous entries so quieter team members contribute too.
- Group similar items before you discuss them, and commit to a small number of concrete actions.
## Icebreaker questions
- If your week was a Reddit post, what would the title be and how many upvotes would it get?
- What's one subreddit (real or made up) that perfectly describes our team right now?
---
# Hot Air Balloon Retrospective
URL: https://www.teamretro.com/retrospective-templates/hot-air-balloon-retrospective/
The Hot Air Balloon retrospective pictures your team as a balloon in flight. Hot Air is whatever keeps you rising, Anchors are the things holding you down, and Shout outs and Kudos is where you thank the people who made a difference.
The metaphor needs almost no explanation, so the team gets straight to examples: a testing change that cut production bugs, a legacy system nobody understands, a teammate who stayed late to debug an incident. Because recognition has its own column, good work gets named instead of being skipped on the way to the problems.
It suits teams that want to keep the tone positive while still dealing with what's slowing them down. Start with Hot Air, spend most of the time on the Anchors you can actually change, and finish with kudos.
## Topics
- **Hot Air**: What is making us fly?
- **Anchors**: What is keeping us down?
- **Shout outs and Kudos**: Who do we want to acknowledge?
## When to use
- When you want an upbeat retro that still deals with real problems
- After a significant project milestone, to look back at how the team worked
- When you need to name both what's helping the team and what's in the way
- When the team has worked hard and deserves recognition built into the retro
## Tips and tricks
- Start with Hot Air to build momentum before you get to the challenges
- Ask for specific examples. "Stand-ups are better" is less useful than "stand-ups now finish in 10 minutes"
- Make sure Shout outs and Kudos covers different people and different kinds of contribution, not only the most visible work
- Park Anchors that need people outside the team, and assign someone to raise them
- Use dot voting to choose which Anchors to tackle first if you have a lot of them
## Icebreaker questions
- If you could take a hot air balloon ride anywhere in the world, where would you go and why?
- What gives you the most lift or energy during your workday?
---
# New Year's Resolutions Retrospective
URL: https://www.teamretro.com/retrospective-templates/new-years-resolutions-retrospective/
A new year is a natural point for a team to look back and plan ahead. The New Year's Resolutions Retrospective gives your team a structured way to celebrate last year's wins, name what held you back and agree on the goals and habits you want to carry into the months ahead. It combines a standard retrospective with the clean slate a new year brings.
The session runs through four connected conversations: looking back on the year, letting go of habits that no longer help, defining the resolutions you'll commit to and naming the support you'll need to keep them. Leaving Behind matters as much as the resolutions themselves, because dropping an old habit is often what frees up time for a new one. Moving from reflection to commitment gives the team a shared direction and turns vague hopes into a few specific commitments with owners.
Run it in early January, at the start of a fiscal year or at any natural milestone. A resolution without support tends to fade by spring, so the last column asks what help the team needs to keep each one.
## Topics
- **Looking Back**: What are we proud of from the past year?
- **Leaving Behind**: What habits or practices should we stop in the new year?
- **Resolutions**: What goals or commitments do we want to make this year?
- **Support Needed**: What help do we need to make these resolutions stick?
## When to use
- At the start of a new calendar or fiscal year, when people are already reflecting and planning.
- When you want a year in review and goal setting in a single session.
- To bring a team back together after a holiday break or a major milestone.
- When motivation is dipping and the team needs a shared direction again.
## Tips and tricks
- Keep resolutions specific and few. Three to five shared goals are far more achievable than a long wish list.
- Spend real time on the wins before moving to what should change, so the session starts on a positive note.
- Give each resolution an owner and a check-in schedule so it doesn't fade once the meeting ends.
- Make it safe to discuss what to leave behind. Talk about patterns and processes, not individuals.
- Bring the resolutions back in later retros to track progress through the year.
- Use anonymous brainstorming so quieter team members can add their ideas.
## Icebreaker questions
- If you could give the past year a movie title, what would it be?
- What's one personal habit you're hoping to start in the new year?
---
# Lunar New Year Reflections Retrospective
URL: https://www.teamretro.com/retrospective-templates/lunar-new-year-reflections-retrospective/
Lunar New Year is a time for fresh starts in many communities across East and Southeast Asia and around the world. The Lunar New Year Reflections retrospective borrows a few of its traditions to help your team close out one cycle and start the next with clear goals.
The board has four columns, each tied to a custom of the season. Sweep It Away comes from cleaning the house before the new year to clear out bad luck: the team names the habits and frustrations it wants to leave behind. Lucky Wins celebrates the successes and lucky breaks of the past year. Gratitude & Red Envelopes draws on the custom of giving red envelopes for good fortune, and it's the place to thank colleagues. Wishes for the New Year captures hopes and goals for the year ahead, which you then turn into actions.
You don't need to celebrate Lunar New Year to run it. Some teams use it as a year-in-review in January or February, and others use it any time they want a reset that mixes recognition with planning. Say in your intro that the theme is a way in and the conversation is about your team's work.
## Topics
- **Sweep It Away**: What old habits or frustrations should we leave behind?
- **Lucky Wins**: What went well and brought us fortune this past year?
- **Gratitude & Red Envelopes**: Who or what are we grateful for this year?
- **Wishes for the New Year**: What do we hope to achieve in the year ahead?
## When to use
- Around Lunar New Year, to mark a seasonal reset with your team.
- As a year-in-review retrospective when you want a celebratory, reflective tone instead of a standard sprint review.
- When morale needs a lift through thanks, recognition and a sense of a fresh start.
- To kick off annual planning by deciding what to leave behind and what to aim for.
## Tips and tricks
- Set the scene with a short note on the Lunar New Year customs behind each column, so everyone understands the theme.
- Be inclusive. Acknowledge that not everyone celebrates Lunar New Year, and frame the session as a chance for any team to reflect and reset.
- Give everyone a moment of quiet thinking time before sharing in Gratitude & Red Envelopes, so the thanks are specific.
- Keep Sweep It Away blameless by focusing on processes and habits, not people.
- Turn Wishes for the New Year into actions: group similar hopes, vote and give each priority an owner and a timeline.
- Timebox each column so you still have energy for the forward-looking discussion at the end.
## Icebreaker questions
- Which animal of the Lunar New Year zodiac best matches your work style, and why?
- What is one tradition or food you associate with celebrating a fresh start?
---
# Chinese New Year Retrospective
URL: https://www.teamretro.com/retrospective-templates/chinese-new-year-retrospective/
The Chinese New Year Retrospective borrows the themes of the Lunar New Year: celebrating the year that's ending, cleaning out the old before the new year arrives, and making wishes for the year ahead. Your team follows the same order, which suits any point where you want a clear break between how you've been working and what comes next.
The board has four columns. Year of Achievement is for wins, big and small. Fortune and Wisdom collects the lessons the team learned from successes and setbacks alike. Spring Cleaning, named after the custom of cleaning the house before the new year, is for the habits and processes you want to leave behind. New Year Wishes is where those become specific improvements for the next cycle.
Run it around the Lunar New Year, at the start of a quarter or after a long project. A minute on the traditions at the start gives everyone the context, and the celebratory mood makes it easier to be honest about what to drop.
## Topics
- **Year of Achievement**: What accomplishments made you proud this past cycle?
- **Fortune and Wisdom**: What lessons did we learn?
- **Spring Cleaning**: What should we leave behind as we move forward?
- **New Year Wishes**: What positive changes should we implement?
## When to use
- When you want to give your team's reflection a different theme
- Around Chinese New Year, as part of the celebrations
- When your team needs a clear break between past practices and the improvements ahead
- At the start of a new quarter or project, as a fresh-start retro
## Tips and tricks
- Share a little about Chinese New Year traditions before you start, so everyone has the context
- Use the Chinese zodiac animals as light metaphors for different kinds of challenges or successes
- Ask people to think about the whole cycle you're reviewing, not only the last few weeks
- Use a Chinese proverb as a discussion prompt if one fits the conversation
- Keep the mood celebratory, but make sure New Year Wishes ends with specific actions
## Icebreaker questions
- If you were a Chinese zodiac animal, which would you be and why?
- What's your favorite way to celebrate new beginnings?
---
# Marketing Campaign Retrospective
URL: https://www.teamretro.com/retrospective-templates/marketing-campaign-retrospective/
A marketing campaign retrospective is a meeting your team holds once a campaign has finished, to compare what happened with what you planned and decide what to do differently next time. It takes the retrospective format agile software teams use after each sprint and applies it to campaign results, with the data on the table.
The board has five columns. Campaign Performance looks at results against goals and KPIs, like open rates, click-through and leads. Customer Feedback brings in what customers said, in their own words where you can. Return on Investment sets cost against revenue and longer-term value. Brand Impact covers how the campaign changed the way people see you, good and bad. Lessons Learned pulls it together into changes for the next campaign.
Share the reports before the session, so the time goes on interpreting the numbers instead of reading them. Invite people beyond marketing, such as sales and customer service, who saw the campaign from the customer's side. If you planned the campaign with a [Marketing Campaign Futurespective](/retrospective-templates/marketing-campaign-futurespective/), bring that board along and check your goals against the results.
## Topics
- **Campaign Performance**: How did the campaign perform against its goals and KPIs?
- **Customer Feedback**: What did customers appreciate or find challenging about the campaign?
- **Return on Investment**: How did the campaign's costs compare with the revenue and business impact it generated?
- **Brand Impact**: How did the campaign affect our brand perception and reputation?
- **Lessons Learned**: What insights and actionable learnings can we take from this campaign?
## When to use
- After a major marketing campaign or initiative ends, to review how well it worked.
- As part of a regular marketing review, to refine strategy and tactics based on real performance data.
- After a product, service or brand launch, to review the go-to-market campaigns before the next launch.
- After a big shift in the market, customer behavior or competition, to check your campaigns still fit.
- When a campaign underperformed, to find the root causes before you repeat them.
## Tips and tricks
- Make it safe to be candid. People should be able to say a campaign missed without anyone getting defensive.
- Pair the numbers with qualitative input: customer conversations, social sentiment and what the team noticed.
- Invite sales, product and customer service to get a fuller view of the campaign's impact.
- Focus on what to repeat or change, not on who to blame.
- Write down the main lessons and decisions somewhere the next campaign team will find them.
- Recognize good work as well as problems, so the review doesn't feel like a post-mortem.
## Icebreaker questions
- If our marketing campaign was a movie, what genre would it be and why?
- Share a creative or unconventional marketing campaign that caught your attention recently, and what made it memorable.
---
# 4-Week Sprint Retrospective
URL: https://www.teamretro.com/retrospective-templates/4-week-sprint-retrospective/
A four-week sprint is long enough for a lot to happen: several deliverables, a priority change or two, maybe a new person on the team. By the time the retro comes around, week one feels like a long time ago. The 4-Week Sprint Retrospective is built for that gap. It asks your team to look back across the whole month, starting from week one, and pull out what worked and what got in the way.
The board has four columns: What went well, What slowed us down, What we learned and What to improve next sprint. Start with the wins, move on to the friction, name the lessons, and finish with a short list of actions for the next cycle. A month of notes shows patterns a two-week retro can miss, like a blocker that turned up in week one and again in week four, or a process that drifted a little each week. In TeamRetro everyone adds ideas privately first, so remote and in-person people contribute on equal terms, and the actions you agree on carry into the next retro.
It suits teams on monthly or four-week cycles who want a retrospective that matches the rhythm of their work. Run it every cycle and you'll see whether last month's actions changed anything, and whether delivery is getting more predictable.
## Topics
- **What went well**: What achievements and wins should we celebrate this sprint?
- **What slowed us down**: Which blockers, friction points or challenges held us back?
- **What we learned**: What insights or lessons can we take from this sprint?
- **What to improve next sprint**: What concrete actions will we take into the next cycle?
## When to use
- Your team works in monthly or four-week cycles and needs a retro that matches that cadence.
- You want to spot longer-term trends and recurring blockers that a two-week retro tends to miss.
- You're wrapping up a big chunk of work and want to mark the wins before planning what to change.
- You're setting up a new team on four-week sprints and want a reflection routine from the first cycle.
## Tips and tricks
- A month is a long time, so ask people to skim their boards, commits or notes before the session. Otherwise week one gets forgotten.
- Timebox each column. Longer sprints produce more notes, and without a limit the discussion sprawls.
- Limit actions to two or three that the team can actually deliver in the next cycle.
- Give every action an owner and check them at the start of the next retrospective.
- Rotate the facilitator each cycle so one person's view doesn't shape every retro.
- Keep input anonymous so people are honest about blockers, especially ones involving team dynamics or other teams.
## Icebreaker questions
- If you had to sum up the last four weeks in a single GIF or emoji, what would it be?
- What's one thing outside of work that kept you energized this past month?
---
# Bug Busters Retrospective
URL: https://www.teamretro.com/retrospective-templates/bug-busters-retrospective/
The Bug Busters Retrospective is for the sprint where bugs took over: the regression that came back, or the defect a customer found before you did. Instead of treating each bug as a one-off, your team looks at the pattern behind them, from testing gaps to unclear requirements, and agrees on the safeguards that would have caught them.
The board has four columns. Bugs We Squashed starts with what went right, so the team names the practices worth keeping. Bugs That Slipped Through looks at what reached production or was caught too late. What Slows Us Down covers the friction in finding and fixing bugs, such as flaky tests or thin logs. Prevention Plan turns all of it into action items with owners that you can track next sprint.
It suits developers, QA and product people who want fewer defects and a shared sense of who owns quality. Keep it blameless: the question is how the system let a bug through, not who wrote it.
## Topics
- **Bugs We Squashed**: Which defects did we successfully catch and resolve?
- **Bugs That Slipped Through**: Which defects reached production or were caught too late?
- **What Slows Us Down**: What makes finding or fixing bugs harder than it should be?
- **Prevention Plan**: What can we do to stop these bugs happening again?
## When to use
- After a release or sprint with more defects or escaped bugs than usual.
- When regression bugs keep coming back and the team wants to understand why.
- As part of a wider push to improve testing and prevention.
- After a production incident, for a blameless review of how the bug slipped through.
## Tips and tricks
- Keep the tone blameless. Talk about systems, processes and gaps, not the people who introduced bugs.
- Bring data such as defect counts, escape rates or time to resolution so the discussion rests on facts.
- Use voting to focus your action items on the bugs and gaps with the biggest impact.
- Make each action item specific and give it an owner so prevention measures actually happen.
- Invite QA, developers and product together so quality is everyone's job.
- Check the prevention actions from earlier sessions to see whether recurring bugs went down.
## Icebreaker questions
- What's the weirdest or funniest bug you've ever encountered?
- If you could permanently delete one type of bug from existence, what would it be?
---
# Goldilocks Retrospective
URL: https://www.teamretro.com/retrospective-templates/goldilocks-retrospective/
The Goldilocks retrospective borrows the fairy tale to help your team review how it works. Each process or habit goes in one of three columns: Too Hot for things that take too much time and energy and should stop or shrink, Too Cold for things that need more attention and should start, and Just Right for things that are working and should continue.
The story is familiar enough that nobody needs it explained, and the labels make it easy to say "this meeting is too hot" without it sounding like a complaint about whoever runs it. The best conversation is usually about what "just right" means for your team, and whether that matches what the rest of the organization expects from you.
Use it when you want a lighter alternative to Start Stop Continue that still ends with clear actions: what to cut back, what to add and what to protect.
## Topics
- **Too Cold**: What should we start doing or do more of?
- **Just Right**: What should we keep doing?
- **Too Hot**: What should we stop doing or do less of?
## When to use
- When you want a regular retrospective that ends with clear things to stop, start and keep.
- After a major project or milestone, to look at what worked and what to change.
- When you notice recurring issues or bottlenecks in your team's workflow.
- When you want honest feedback about processes without it feeling personal.
## Tips and tricks
- Lean into the theme with a picture of three bowls of porridge or a quick retelling of the story.
- Make sure everyone contributes, including quieter team members.
- Keep the focus on processes and practices, not individuals.
- Rotate the facilitator so different voices are heard and people get to run the retrospective their own way.
- Finish with an action plan for the items in Too Hot and Too Cold.
- Use a Return on Time Invested (ROTI) vote at the end to check whether the meeting was worth the team's time.
## Icebreaker questions
- If you were a character in the Goldilocks story, which one would you be and why?
- What's your favorite fairy tale or childhood story, and why has it stuck with you?
---
# Artificial Intelligence Arena Retrospective
URL: https://www.teamretro.com/retrospective-templates/artificial-intelligence-arena-retrospective/
The Artificial Intelligence Arena retrospective gives your team a set time to look at how AI tools are changing the way you work. Most teams pick up copilots, chat assistants and automation one person at a time, and nobody stops to ask what's actually helping, what's going wrong or where the new risks are. This format turns that vague conversation into specific examples from your own work.
The board has four topics. AI Wins covers the tasks AI has made faster or better. Friction & Limits is for wrong answers, inconsistent results and time lost to cleanup. Risks & Watchpoints covers data privacy, security, bias and over-reliance. Experiments & Next Steps is where you decide what to try next. Everyone adds notes, then the team groups them, votes and agrees on a few next steps with owners.
Run it when you're piloting a new AI coding assistant, adding generated content to your workflow, or trying to agree on how the team should use these tools at all. You'll come away knowing what to expand, what to stop and which safeguards keep people in charge of the final call.
## Topics
- **AI Wins**: Where has AI added real value for us?
- **Friction & Limits**: Where has AI slowed us down or fallen short?
- **Risks & Watchpoints**: What risks or concerns should we keep an eye on?
- **Experiments & Next Steps**: What should we try or improve with AI next?
## When to use
- After your team has adopted new AI tools and you want to know what's working and what isn't.
- When you need to agree on how the team uses AI, or raise risks before they grow.
- Every few months, to track how AI is changing your team's workflow.
- When deciding which AI experiments or tools to prioritize for the next quarter.
## Tips and tricks
- Agree up front that wins and problems both get airtime, so the session doesn't turn into a debate about AI in general.
- Ask for specific examples instead of broad opinions about AI, so the team has something concrete to act on.
- Give quieter team members and AI skeptics equal airtime. Mixed views keep the team clear of both hype and unfounded fear.
- Timebox each topic so the discussion doesn't get stuck on one AI controversy.
- Close with next steps that each have an owner and a way to measure them.
- At the next session, revisit the experiments and risks you logged to see what changed.
## Icebreaker questions
- If you could hand off one tedious part of your job to an AI tomorrow, what would it be?
- What's the most surprising thing an AI tool has helped you with recently?
---
# Pre-Launch Futurespective
URL: https://www.teamretro.com/retrospective-templates/prelaunch-planning-retrospective/
A Pre-Launch Futurespective is a planning session you run before a product or feature launch, not after it. Your team pictures launch day and the weeks that follow, then works backward to what has to be true for it to go well. It's easier to find a missing rollback plan or an untrained support team now than at 2am on launch night.
The board has four areas. Critical Preparations is for the tasks, checks and sign-offs the launch can't go ahead without. Boosters covers what would help the launch land: a beta customer's testimonial, timing with an industry event, an early briefing for sales. Monitoring & Signals asks how you'll know whether the launch is working, from error rates to support ticket volume. Risks & Unknowns is for untested assumptions, outside dependencies and the scenarios nobody has planned for.
Run it one to two sprints before launch, so there's still time to act on what you find. It works best with everyone who touches the launch in the room, from engineering and product to marketing, sales and support, because the gaps usually sit between those groups. You'll leave with a prioritized list of actions, each with an owner, instead of a general feeling that things are probably fine.
## Topics
- **Critical Preparations**: What must be done before we can launch?
- **Boosters**: What will accelerate our launch success?
- **Monitoring & Signals**: How will we know if the launch is succeeding or struggling?
- **Risks & Unknowns**: What could go wrong or catch us off guard?
## When to use
- When your team is 1–4 weeks from a significant product or feature launch and wants to check nothing critical has been missed
- When a launch involves engineering, marketing, sales and support, and you need everyone to agree on what "ready" means
- When a past launch went badly and the team wants to prepare more deliberately this time
- When you're launching into a new market or to a much larger audience, and getting it wrong would cost more than usual
- When you want a repeatable readiness check to run before every major release
## Tips and tricks
- Run it 1–2 sprints before your target launch date: early enough to act on what you find, close enough that the details are real
- Invite engineering, product, design, marketing and support. Blind spots tend to sit at the boundaries between functions
- Use dot voting on Critical Preparations and Risks & Unknowns so the team deals with the highest-impact items first
- Don't let it turn into a status meeting. If someone raises an item that's already done, note it and move on; you're looking for gaps
- Give every action an owner and a due date before you close. Without follow-through, a futurespective is wishful thinking
- After launch, return to the Monitoring & Signals items for a quick post-launch review, and add what you learn to your launch playbook
## Icebreaker questions
- If your launch were a rocket, what stage of the countdown would it be at right now, and is everything go for launch?
- What's the most memorable product launch you've ever seen, good or bad, and what made it stick?
---
# Sweet Success Shop Retrospective
URL: https://www.teamretro.com/retrospective-templates/sweet-success-shop-retrospective/
The Sweet Success Shop retrospective turns your last sprint or project into a candy store. Each column is a shelf: the sweet successes worth savoring, the sour moments that left a bad taste, the half-baked work still in the oven and the secret recipes worth passing on.
Sweet Successes is for wins of any size. Sour Moments holds what went wrong or caused friction, like a staging environment that was down for two days. Still in the Oven covers unfinished work and ideas that need more time, so they don't drop off the radar. Secret Recipes is where people share the shortcuts and habits that made their work easier, such as writing the test first or a quick design huddle before building.
Two of the shelves are unusual. Still in the Oven gives half-done work a place to be tracked instead of forgotten, and Secret Recipes spreads good practice across the team. Run it at the end of a sprint, after a major release, or as a quarterly check-in when your usual format has started to feel repetitive.
## Topics
- **Sweet Successes**: What went really well that we should celebrate?
- **Sour Moments**: What left a bad taste and needs improving?
- **Still in the Oven**: What ideas or work are half-baked and need more time?
- **Secret Recipes**: What tips or practices should we share with the team?
## When to use
- At the end of a sprint, when you want a themed change from your standard format.
- After a major release or milestone, to celebrate wins and capture what you learned.
- When morale is low and you want to start with appreciation.
- As a quarterly or end-of-project review.
- With newer or remote teams, who often open up more in a relaxed, themed session.
## Tips and tricks
- Use the candy-store theme to keep the mood light when the discussion gets to tough topics.
- Timebox each shelf so Sweet Successes doesn't take the whole session.
- Keep Sour Moments blameless by asking what the team can learn from each one.
- Turn on anonymous entry for sensitive topics so people can be honest.
- Turn the top discussions into actions with owners before you close.
- Rotate the facilitator so different people shape the session.
## Icebreaker questions
- If you were a candy or dessert, which one would you be and why?
- What's the sweetest moment you had at work this sprint?
---
# Cricket Retrospective
URL: https://www.teamretro.com/retrospective-templates/cricket-retrospective/
The Cricket Retrospective reviews your sprint the way a commentator reviews an innings. Cricket keeps careful score of steady progress, big hits and the moments a batter is out, and that gives your team a ready-made vocabulary for what went right and what didn't.
The board has four columns. Runs is for steady progress: the everyday work that moved the team forward. Boundaries are the big hits, such as a launch ahead of schedule or a migration with zero downtime. Wickets are the setbacks that cost you, from unstable third-party APIs to unclear requirements. Ducks, named after a batter out for zero, are the outright failures and what the team learned from them.
It lands best with teams that follow cricket, as in India, Australia or the UK, but the terms take a minute to explain to anyone. Keeping Wickets and Ducks separate is useful: one is about obstacles to remove, the other about mistakes to learn from.
## Topics
- **Runs**: What progress did we make?
- **Boundaries**: What great outcomes did we deliver?
- **Wickets**: What setbacks did we encounter?
- **Ducks**: What failures did we learn from?
## When to use
- When your team follows cricket, or enjoys sports metaphors, and wants a change from the usual format
- After a significant project milestone or sprint, when you want to look at both successes and failures
- When morale needs a lift and a more playful setting would help people give feedback
- When you want serious reflection with a lighter touch
## Tips and tricks
- Start with a quick explanation of the cricket terms for anyone who doesn't follow the sport
- Borrow cricket scoring to size each item, the way a boundary counts for more than a single run
- Make sure everyone gets a turn to bat, so the same few people don't do all the talking
- Keep Wickets and Ducks constructive by asking what the team learned, not who was out
- Timebox the discussion in "overs" to keep things moving
- Add cricket imagery or sound effects if your team enjoys the theme
## Icebreaker questions
- If your last sprint was a cricket match, what would be your playing position and why?
- What's your favorite sporting moment, and does it remind you of anything our team has done?
---
# Valentine's Day Retrospective
URL: https://www.teamretro.com/retrospective-templates/valentines-day-retrospective/
The Valentine's Day retrospective puts a February theme on a familiar set of retro questions. What we love is for appreciation: the people, practices and wins your team is grateful for. Crushing on collects new ideas people are excited to try. Heartbreaks covers what caused frustration or let the team down, and Relationship goals turns the conversation into a few commitments.
Opening with appreciation changes the tone of the whole meeting. Once people have thanked each other, it's easier to be candid about the heartbreaks, and the theme gives everyone a lighter way to raise tension that might otherwise go unsaid.
Run it on or around February 14, or any time morale needs a lift. The theme keeps it light, and you still leave with specific actions and an owner for each.
## Topics
- **What we love**: What do you adore about how the team worked?
- **Crushing on**: What new ideas or practices are you excited to try?
- **Heartbreaks**: What caused frustration or let the team down?
- **Relationship goals**: What commitments will help us grow stronger together?
## When to use
- Around February 14, when you want a seasonal touch on your regular retrospective.
- When morale needs a lift and you want to make room for appreciation.
- When tension has been building and a lighter frame can help people raise it.
- As a change of pace from your standard format.
## Tips and tricks
- Set a warm mood with a themed background, heart images or a short playlist.
- Start with What we love so people feel safe before moving on to Heartbreaks.
- Remind the team that heartbreaks are about issues, not individuals.
- Use anonymous brainstorming so quieter people can share honestly.
- Group and vote so the discussion focuses on the items that matter most.
- Close by turning Relationship goals into a few owned, timeboxed actions.
## Icebreaker questions
- If your team had a relationship status this sprint, what would it be and why?
- What's one small thing a teammate did recently that made your heart melt?
---
# Go-To-Market Strategy Planning
URL: https://www.teamretro.com/retrospective-templates/go-to-market-strategy-planning/
A Go-To-Market Strategy Planning session brings product, marketing, sales and support together to agree on how a product will reach customers. The board covers six areas: Target Market, Positioning & Messaging, Pricing Strategy, Promotion & Marketing, Sales & Distribution, and Launch Roadmap.
Each group usually holds part of the picture. Sales knows which customers are ready to buy, marketing knows which messages land, and product knows what will actually ship by launch day. Putting all of it on one board, with everyone adding ideas before the discussion, shows where those views clash while there's still time to fix them.
You finish with decisions instead of a slide deck: who you're selling to, what you'll say, what you'll charge, where you'll sell and the dates that matter. Run it before a new product launch or a significant update, and come back to the same board once early market feedback arrives.
## Topics
- **Target Market**: Who are the ideal customers for this product?
- **Positioning & Messaging**: How should we position and differentiate our product?
- **Pricing Strategy**: How should we price our product for optimal adoption and revenue?
- **Promotion & Marketing**: How can we effectively promote and market our product?
- **Sales & Distribution**: How will we sell and distribute our product?
- **Launch Roadmap**: What are the key milestones and timelines for our product launch?
## When to use
- When you're preparing a new product launch or a significant update to an existing product.
- When product, marketing and sales need to agree on one plan before work starts.
- When you're reviewing market opportunities, competitors and customer needs to sharpen positioning and messaging.
- When you need a marketing and sales plan the whole launch team has seen and agreed to.
- When you're setting timelines, milestones and resourcing for a launch.
## Tips and tricks
- Invite product management, marketing, sales and customer support so every part of the launch is represented.
- Bring market research and competitor analysis into the session so decisions rest on evidence.
- Agree on objectives and success metrics before launch, so you can tell afterward whether it worked.
- Expect to change the plan once market feedback comes in, and schedule a follow-up session for it.
- Write down the agreed messaging so every team uses the same words.
- Track performance data after launch and bring it back to the team to adjust the strategy.
## Icebreaker questions
- If our product was a celebrity, who would it be and why?
- Share a memorable product launch experience, either as a customer or a team member, and what made it successful or challenging.
---
# Logistics and Supply Chain Retrospective
URL: https://www.teamretro.com/retrospective-templates/logistics-and-supply-chain/
The Logistics and Supply Chain Retrospective is a meeting for operations teams to review a recent period or project and agree on what to change. It follows the familiar retro pattern of what went well, what went wrong and what to improve, but the prompts are written for procurement, inventory, transportation, warehousing and distribution.
The board has four columns. Successful Deliveries is for on-time arrivals, efficient routes and partners who came through. Inventory Challenges covers stockouts, overstock, forecasting misses and visibility gaps between sites. Process Improvements is where people suggest system upgrades, new tools or changes to how work flows through the warehouse. Collaboration and Communication looks at hand-offs between procurement, logistics, operations and customer service, and with your suppliers.
Bring the numbers you track, such as on-time delivery rate, stockouts and cost per shipment, and pair them with what people saw on the floor. Run it after a peak season, a disruption or a system rollout, or on a quarterly rhythm, and finish with a short list of fixes that each have an owner.
## Topics
- **Successful Deliveries**: What went well with our logistics and delivery operations?
- **Inventory Challenges**: What inventory management issues did we face?
- **Process Improvements**: What processes or systems need improvement in our supply chain?
- **Collaboration and Communication**: How can we improve collaboration and communication within our supply chain team?
## When to use
- At the end of a project, product launch or major supply chain initiative, to review the outcome and find what to improve.
- On a regular rhythm, such as quarterly or twice a year, to keep improving supply chain operations.
- After a significant disruption, to find the root causes and plan how to reduce the risk next time.
- When new team members or partners join, to agree on expectations and share what works.
## Tips and tricks
- Invite everyone involved in the supply chain, including procurement, logistics, operations and customer service.
- Make it safe to raise problems. People need to be able to talk about mistakes without fear of blame.
- Use data and metrics to back up observations, and add what customers and frontline staff are telling you.
- Prioritize the actions and give each agreed change an owner.
- Review the actions from previous retrospectives so progress stays visible.
- Consider inviting suppliers or logistics providers to hear their side of the problems you share.
## Icebreaker questions
- If you could be any mode of transportation, what would you be and why?
- Share a memorable or funny experience you've had related to logistics or supply chain operations.
---
# Marketing Campaign Futurespective
URL: https://www.teamretro.com/retrospective-templates/marketing-campaign-futurespective/
A retrospective looks back once the work is done. A futurespective looks ahead, before it starts. The Marketing Campaign Futurespective gets everyone involved in a campaign into one session to agree on what it's for, who it's aimed at and how you'll know it worked, so you don't discover the disagreements halfway through the launch.
The board has six columns that run in planning order. Campaign Goals sets measurable objectives tied to business targets. Target Audience defines the segments and personas you're trying to reach. Brand Messaging captures the value propositions you want each audience to hear. Marketing Channels picks where you'll show up, based on where those audiences actually spend time. Campaign Strategies is for specific tactics and creative ideas. Metrics and Measurement links each goal to the numbers you'll track.
Invite the people who will build and run the campaign, plus sales or product if they'll be affected. Bring results from past campaigns to the discussion, so the plan starts from what has worked for you before.
## Topics
- **Campaign Goals**: What are the primary objectives for this marketing campaign?
- **Target Audience**: Who are the key customer segments we want to target?
- **Brand Messaging**: What are the key brand messages and value propositions we want to communicate?
- **Marketing Channels**: Which marketing channels should we prioritize for this campaign?
- **Campaign Strategies**: What specific tactics and creative approaches should we consider?
- **Metrics and Measurement**: How will we measure the success of this marketing campaign?
## When to use
- When planning a new marketing campaign, to agree on goals and approach before work starts.
- Before a product or service launch, to build the go-to-market plan with everyone involved.
- When refreshing an existing marketing strategy that isn't reaching the right audience.
- When you're considering new channels, tactics or creative approaches and want to test them against your goals first.
- When several teams need to deliver consistent messaging across one campaign.
## Tips and tricks
- Collect ideas before anyone critiques them, so creative options get a fair hearing.
- Tie every campaign goal to a business objective or KPI.
- Bring data from past campaigns so you repeat what worked and avoid old mistakes.
- Map the customer's path across channels so each touchpoint supports the next.
- Be realistic about budget and timeline, and prioritize the tactics with the most impact.
- Agree who owns each part of execution and measurement before the session ends.
## Icebreaker questions
- If our brand was a famous celebrity, who would it be and why?
- Share a memorable marketing campaign that resonated with you personally, and explain what made it impactful.
---
# Arctic Expedition Retrospective
URL: https://www.teamretro.com/retrospective-templates/arctic-expedition-retrospective/
The Arctic Expedition retrospective pictures your sprint or project as a polar trek. Your team looks at what kept it moving, what slowed it down, which dangers are hiding ahead and which goal should guide the next leg. Stepping into the expedition gives people some distance from the day-to-day, which makes it easier to see the whole route.
The board has four topics. Supplies are the resources, strengths and habits that kept you going. Blizzards are the obstacles that blocked your path. Icebergs are the risks below the surface that haven't caused trouble yet but could, like knowledge held by one person or growing tech debt. North Star is the shared goal that keeps the team oriented. Icebergs is what sets this format apart, because it gets risks onto the board before they turn into crises.
Use it to wrap up a sprint or project, or for a seasonal session when your team wants a change from standard formats. The theme keeps the mood light, and quieter team members often find it easier to raise a concern as an iceberg than as a complaint.
## Topics
- **Supplies**: What kept us going and fueled our progress?
- **Blizzards**: What storms slowed us down or blocked our path?
- **Icebergs**: What hidden risks could threaten us ahead?
- **North Star**: What goal should keep us oriented going forward?
## When to use
- When you want to refresh a standard sprint retrospective with a themed format.
- When wrapping up a project or milestone and you want to capture both achievements and the risks ahead.
- When the team needs to surface hidden risks and technical debt before they cause problems.
- When you need to agree on a shared goal after a period of intense work.
- For a seasonal or end-of-year session where a lighter theme helps people join in.
## Tips and tricks
- Describe the expedition at the start so everyone knows what each topic stands for.
- Timebox each topic so the discussion doesn't stall in one place.
- Ask quieter members for Icebergs in particular, since spotting hidden risks is everyone's job.
- Group similar ideas before voting so you can prioritize the biggest blizzards and icebergs.
- Turn the North Star into concrete action items with clear owners.
- Keep the tone light but focused, and treat blizzards as problems to solve, not people to blame.
## Icebreaker questions
- If you were heading on a real Arctic expedition, what one item would you absolutely have to pack?
- Would you rather face a blizzard, a polar bear, or a week of total darkness, and why?
---
# Harry Potter Themed Retrospective
URL: https://www.teamretro.com/retrospective-templates/harry-potter-retrospective/
The Harry Potter Retrospective brings the wizarding world from J.K. Rowling's books into your team's review of a sprint or project. Each topic is named after a spell or potion from the series, which gives people a shared, slightly playful language for talking about what worked and what didn't. Whether your team is full of Gryffindors charging ahead or Ravenclaws analyzing every detail, there's room for both on the board.
The board has four topics. Lumos is for what went well and lit the way. Nox is for the dark forces that blocked you. Polyjuice Potion asks what you'd transform or improve, and Expecto Patronum is for new ideas and actions to protect the team next time. Under the theme these are the familiar retrospective questions, so you still finish with clear actions.
Calling a blocker a "dark force" makes it a little easier to raise, and the story gives quieter team members a way in. Use it when your team has retrospective fatigue, when you're welcoming new members, or when the team simply shares a love of the books.
## Topics
- **Lumos**: What spells worked? What lit up our path?
- **Nox**: What dark forces blocked or hindered us?
- **Polyjuice Potion**: What could we transform or improve next time?
- **Expecto Patronum**: What new spells should we try to protect and guide us?
## When to use
- When your team has retrospective fatigue and needs a themed format to restart the conversation.
- When onboarding new team members and you want a low-pressure retrospective that gets everyone contributing.
- When celebrating a major milestone or release and you want to look back in a memorable way.
- When your team shares a love of Harry Potter and you want to use that common ground.
- When metaphor and storytelling would make it easier for people to raise difficult topics.
## Tips and tricks
- Set the scene in the meeting invite with a Harry Potter-themed image so people arrive in the spirit.
- Invite people to use the theme when writing ideas, and make it clear plain language is just as welcome. The goal is reflection, not a creative writing contest.
- Don't let the theme take over. The magic is there to help honest conversation, so keep pulling the discussion back to actions.
- Use Expecto Patronum to close on a forward-looking note, and make sure every action has an owner and a due date before you finish.
- Not everyone has read the books. Explain each topic's metaphor at the start so nobody feels left out.
- If the team gets stuck, ask questions like "What would Dumbledore advise here?" or "What would your Hogwarts House do differently?"
## Icebreaker questions
- Which Hogwarts House (Gryffindor, Hufflepuff, Ravenclaw, or Slytherin) do you think your team belongs to, and why?
- If you could use one spell from the Harry Potter universe to improve how your team works, what would it be and what would it do?
---
# Broken Car Breakdown Retrospective
URL: https://www.teamretro.com/retrospective-templates/broken-car-breakdown-retrospective/
The Broken Car Breakdown retrospective treats your team like a car pulled over on the side of the road. Everyone knows what a breakdown feels like, so the metaphor gives the whole team, technical or not, a shared way to talk about what's slowing you down and what you need to get going again.
The board has four parts. The Engine is what drives you forward. Flat Tires are the blockers holding you back right now. Warning Lights are the risks that aren't critical yet but could cause a breakdown if you ignore them. Fuel is what the team needs to recover. People add notes to each part, then the team groups them, votes and turns the top items into actions.
Use it when work has stalled, when the same problems keep coming back, or when your usual retrospectives have gone stale. Give Warning Lights proper time: it catches the tech debt and single points of failure that a "what went wrong" list tends to miss until they turn into flat tires.
## Topics
- **The Engine**: What is driving us forward and keeping us moving?
- **Flat Tires**: What is slowing us down or stopping us completely?
- **Warning Lights**: What risks or early warning signs should we watch?
- **Fuel**: What do we need to keep going and recover?
## When to use
- When your team feels stuck and you want a clear way to find the blockers.
- When standard retrospectives have gone stale and you want a metaphor that gets people talking.
- When the same problems keep coming back and you want to find their causes and early warning signs.
- After a hard sprint or project phase where momentum dropped and the team needs to reset.
- When new members join and need an easy way to talk about team friction.
## Tips and tricks
- Explain what each part of the car stands for before anyone adds notes.
- Keep Flat Tires and Warning Lights blameless. Talk about processes and situations, not individuals.
- Time-box each section so the problems don't take the whole meeting and you still have time for Fuel.
- Group similar notes before voting so the biggest issues stand out and you don't discuss the same thing twice.
- Give every Fuel item an owner and a next step, or good intentions never leave the garage.
- Allow anonymous input so quieter team members can raise what they'd keep to themselves in an open discussion.
## Icebreaker questions
- If your team were a vehicle right now, what would it be: a sports car, a minivan, or a car up on bricks?
- What's the longest road trip you've ever taken, and what kept you going?
---
# The Family Circle Retrospective
URL: https://www.teamretro.com/retrospective-templates/the-family-circle-retrospective/
The Family Circle Retrospective gives each part of your team's work a family role. New ideas are the Baby, the things performing best are the Golden Child, and the reliable processes nobody worries about are the Adult. The Grandparent holds the lessons you've learned the hard way, and the Long Lost Relative is whatever is coming over the horizon.
The roles cover familiar retro ground (what's new, what's going well, what's stable, what you've learned, what's next), but the family framing makes it easier to talk about how those pieces relate. A Baby practice might become next quarter's Golden Child. An Adult process might be aging into something the team should retire.
Use it when you want to look at how the team has changed over a longer stretch, not only the last sprint. It also gives people a lighter way into conversations about team dynamics, because they're talking about a role on the board before they're talking about each other.
## Topics
- **Baby**: What is something new?
- **Golden Child**: What is performing well?
- **Adult**: What is stable and reliable?
- **Grandparent**: What have we learned from?
- **Long Lost Relative**: What is on the horizon?
## When to use
- When you want to look at how the team's practices have grown and changed over several months
- During a period of change, to sort out what's new, what's settled and what's coming
- At the end of a quarter or project, to collect lessons before you plan the next one
- When you want a more personal conversation about team dynamics without putting anyone on the spot
## Tips and tricks
- Explain up front that no role ranks above another. The Adult column matters as much as the Golden Child
- Use the metaphor to get people talking, and drop it if it isn't landing with your team
- Look for links between columns, such as a Baby practice that could become the next Golden Child
- Keep the discussion on the work. The roles describe practices and projects, not people on the team
- If you have time, do a second pass through the columns to pick up ideas people missed the first time
## Icebreaker questions
- If your current project was a family member, who would it be and why?
- What's your favorite family tradition, and how might it apply to our team?
---
# Strategic Roadmap Planning
URL: https://www.teamretro.com/retrospective-templates/strategic-roadmap-planning/
Strategic Roadmap Planning is a session where your team turns the reasons behind an initiative into a plan. You start with the core objectives, break them into goals for the next few years and the next few months, then mark the milestones that will tell you you're on track.
The board has four columns, moving from the big picture down to checkpoints. Key Objectives captures the why: the outcomes the initiative exists to deliver. Long-Term Goals covers the next 1–3 years. Short-Term Goals holds the deliverables for the next 3–6 months. Milestones marks the checkpoints along the way, such as a pilot launch or a migration that's half done.
Bringing every function into the room surfaces roadblocks and dependencies early, while there's still time to plan around them, and it means the people doing the work have agreed to the timeline. Use it to kick off a major initiative, at the start of an annual or quarterly planning cycle, or when a change in the business means your current priorities need another look.
## Topics
- **Key Objectives**: What are the core objectives driving this initiative?
- **Long-Term Goals**: What major goals need to be accomplished over the next 1–3 years?
- **Short-Term Goals**: What are the key deliverables to accomplish in the next 3–6 months?
- **Milestones**: What are the major checkpoints or accomplishments along the way?
## When to use
- When kicking off a new planning cycle or a major initiative that needs several functions to agree.
- At the start of a large, complex project, to map out a shared roadmap and how you'll measure success.
- When a change in the business means your priorities need another look.
- As part of annual or quarterly planning, to agree on the roadmap ahead.
## Tips and tricks
- Invite someone from every function the roadmap depends on, and get their agreement early.
- Lay the roadmap out visually so dependencies and milestones are easy to see.
- Keep timelines realistic. A roadmap that slips in the first month loses the team's trust.
- Book regular checkpoints to review progress, adjust and celebrate milestones.
- Check that every goal is specific, measurable and traces back to a key objective.
- List the main risks and dependencies up front, with a plan for each.
## Icebreaker questions
- If you could pick one superpower to help achieve our roadmap goals, what would it be?
- What's a past project you're proud of that needed careful planning?
---
# Basketball Retrospective
URL: https://www.teamretro.com/retrospective-templates/basketball-retrospective/
The Basketball Retrospective uses the language of the court to help your team look back on a sprint or project. The terms are familiar to fans and easy to pick up for everyone else, so the session feels relaxed without losing focus.
The board has four topics. Slam Dunks are the clear wins. Hang Time is for anything still up in the air: pending decisions, unanswered questions and work in transition. Out of Bounds covers what didn't go well, and Tactics is the next play you want to try. Most formats don't have a Hang Time column, and it's a useful way to get open questions in front of the people who can answer them.
The theme gives people a lighter way to talk about problems, which helps feedback feel less personal. Like players on a court, everyone thinks about their own part and the team's at the same time, and you finish with a short list of plays to run next sprint.
## Topics
- **Slam Dunks**: What were our point-scoring wins?
- **Hang Time**: What is still up in the air?
- **Out of Bounds**: What did not go so well?
- **Tactics**: What play do we want to try next?
## When to use
- When your team feels stuck or flat and needs a livelier session
- For teams that respond well to sports analogies and a bit of friendly competition
- During high-intensity project phases, when you need to separate clear wins from real problems
- When decisions are piling up and you want one place to list everything still up in the air
## Tips and tricks
- Keep a good pace, like a basketball game, so the energy stays up through the session
- Encourage everyone to take a shot and add ideas, even ones that feel risky
- Use the basketball theme to make feedback more playful and less personal
- Call a timeout when a discussion gets heated or drifts off track
- Give each Hang Time item an owner and a date by which it should be resolved
## Icebreaker questions
- If your development style was a basketball move, what would it be and why?
- Which famous basketball player would you most want on our team, and why?
---
# Superhero Retrospective
URL: https://www.teamretro.com/retrospective-templates/superhero-retrospective/
The Superhero retrospective borrows from comic books to get your team talking about how it works. Instead of "what went well", people name the team's superpowers, its weaknesses, the nemesis that makes the job harder and the sidekicks and gadgets that help.
The metaphor puts a little distance between people and the problem. It's easier to call a slow approval process the team's kryptonite than to complain about it directly, and that tends to bring out more honest feedback. Starting with the team's values gives everyone a shared reference point for the rest of the discussion.
It suits teams who enjoy some play in their retrospectives and still want to leave with real actions about their work and how they collaborate.
## Topics
- **Our Values**: What do we stand for?
- **Superpowers**: What are our strengths?
- **Weaknesses**: Where might we be vulnerable?
- **Evil Nemesis**: What makes our role harder?
- **Sidekicks and gadgets**: Who or what supports us?
## When to use
- When team morale is low and you want a retrospective people look forward to
- After a hard project, to recognize the team's strengths and name where it can grow
- When new people join and you want them to see how the team works, in a lighter format
- When the team feels stuck and needs a fresh angle on old problems
## Tips and tricks
- Lean into the theme and let people play with the metaphors
- Keep an eye on the balance between play and productive discussion
- Use real superhero examples to illustrate a point or get ideas flowing
- Make it safe to talk about weaknesses. Every hero has one
- Capture action items from each topic so they get followed up
- Superhero props or virtual backgrounds help set the mood
## Icebreaker questions
- If you could have any superpower to help you in your role, what would it be and why?
- Which superhero team (Avengers, Justice League, etc.) does our team most resemble and why?
---
# The Master Baker
URL: https://www.teamretro.com/retrospective-templates/the-master-baker/
The Master Baker retrospective looks at how your team spent its time. Like a baker checking a tray, you sort the sprint's activities into three columns: Under-baked for work that didn't get enough time, Perfectly Baked for work that got about the right amount, and Overbaked for work that took more time than it was worth.
It's a simple lens, and it surfaces things a standard retro can miss. Nobody files a complaint about a meeting running long or a review being rushed, but once those activities are on the board, the pattern is hard to ignore: code reviews squeezed, refinement sessions going in circles, documentation pushed to the bottom of the list.
Use it when the team feels busy but not productive, or when you suspect some work is getting too much attention and other work too little. The conversation ends with specific changes to how you'll split your time next sprint.
## Topics
- **Under-baked**: What did we not spend enough time on?
- **Perfectly Baked**: What did we spend just enough time on?
- **Overbaked**: What did we spend too much time on?
## When to use
- When the team wants to look at how it splits its time across different activities
- After a project phase, to check whether time went where it was needed
- When you suspect some work is getting too much attention and other work too little
- During a heavy workload, when the team has to decide what to cut back
## Tips and tricks
- Ask for specific examples. "Meetings ran long" is hard to act on, while "the release meeting ran 40 minutes over" points to a fix
- Timebox each column. Running over in a retro about time is hard to defend
- Keep a parking lot for improvement ideas that come up mid-discussion
- Look for patterns that repeat every sprint and set aside the one-off incidents
- End with one or two specific changes to how the team will split its time next sprint
- Use rough relative sizes, such as small, medium and large, to compare how much time each activity took
## Icebreaker questions
- If your last sprint was a baked good, what would it be and why?
- What's your favorite recipe for success when working on challenging projects?
---
# Sprint Review Feedback
URL: https://www.teamretro.com/retrospective-templates/sprint-review-feedback/
A sprint review is where your team shows stakeholders what it built and hears their reaction. Sprint Review Feedback is a short retrospective on that meeting: what went well, what could be improved, how to improve it, and anything else people want to raise.
Run it straight after the review, while the demo and the questions are still fresh. The findings tend to be practical: the demo environment broke, there wasn't enough time for stakeholder questions, or the work was shown without the business context people needed.
Doing this every few sprints keeps the sprint review worth attending. Stakeholders get a clearer view of progress, and your team gets better feedback on the product increment.
## Topics
- **What went well?**: Identify the positive aspects of the sprint review.
- **What could be improved?**: Where did the sprint review fall short?
- **How can we improve?**: What will we change for the next sprint review?
- **Additional Feedback**: Share any other thoughts or suggestions related to sprint reviews.
## When to use
- After each sprint review, to capture feedback and pick one or two improvements.
- When your team thinks the sprint review could be more useful.
- Every few sprints, as a regular check on how your scrum events are working.
- When new team members or stakeholders join the sprint review.
## Tips and tricks
- Ask everyone for honest feedback, including the stakeholders who attended.
- Have a facilitator or note-taker so every piece of feedback gets recorded.
- Pick the improvements that matter most and act on them before the next review.
- Share the feedback and actions with the wider team and stakeholders.
- Note what worked so you keep doing it.
- Check last time's actions before adding new ones.
## Icebreaker questions
- If the sprint review was a movie, what genre would it be and why?
- If you could add one unique element to the sprint review, what would it be?
---
# Pros and Cons Retrospective
URL: https://www.teamretro.com/retrospective-templates/pros-and-cons-retrospective/
Sometimes the fastest way to a decision is to lay everything out side by side. The Pros and Cons retrospective has your team review a sprint, project, decision or process by listing what's working and what isn't, then deciding together what to keep and what to change.
Most people already know the method from their own decisions, so nobody needs it explained. In a team setting, everyone adds the upsides and downsides they've seen, the group votes on what matters most, and you finish with a shared view of where things stand. It's especially useful when the team feels divided or unsure, because both columns get the same attention and neither side can dominate.
The board has two columns, Pros and Cons, so it's quick to set up and easy for anyone to follow, whatever their agile experience. Use it to judge a tool, a way of working or a significant decision, and close by turning the top-voted items into next steps with an owner.
## Topics
- **Pros**: What's working in our favor?
- **Cons**: What's working against us?
## When to use
- When your team needs to evaluate a tool, process or way of working and decide whether to keep it
- When you face a significant decision and want to hear both sides before committing
- After a sprint or project, to quickly capture what helped and what got in the way
- When the team feels divided and you want a neutral structure that gives both sides a fair hearing
- As a fast, low-prep retrospective for teams new to agile or short on time
## Tips and tricks
- Say exactly what you're evaluating up front (a sprint, a tool or a decision) so everyone weighs the same thing
- Ask for ideas in both columns; a list of only cons is a venting session, not a review
- Use dot voting to pick the pros and cons that matter most instead of trying to act on everything
- Keep the cons constructive by focusing on situations and processes, not individuals
- Close with clear next steps that have an owner and a timeframe, so something actually changes
- Timebox each phase so the discussion keeps moving and doesn't go in circles
## Icebreaker questions
- If your week had a pro and a con, what would each be in three words?
- What's one purchase that turned out to have way more pros than cons?
---
# Crisis Management Futurespective
URL: https://www.teamretro.com/retrospective-templates/crisis-management-futurespective/
A Crisis Management Futurespective is a planning session where your team imagines the crises it could face and works out what to do about them while there's still time. A data breach, a supplier going under, a sudden change in regulations: it's far easier to decide who does what in a calm meeting than in the middle of an incident.
The board has four columns, worked in order. Potential Crisis Scenarios gathers the risks, and nothing is dismissed as too unlikely at this stage. Impact Assessment looks at what each one would cost in money, operations, reputation and legal exposure, so you can rank them. Mitigation Strategies covers what would make the most serious crises less likely or less damaging. Response Protocols sets out roles, decision-making authority and who needs to hear what if a crisis does hit.
Run it as part of business continuity planning, before a major launch, during a restructure or after a near-miss. Repeat it as circumstances change, and test the response protocols with a tabletop exercise so they work when you need them.
## Topics
- **Potential Crisis Scenarios**: What potential crises or challenges could our team/organization face?
- **Impact Assessment**: What would be the potential impact of each crisis scenario?
- **Mitigation Strategies**: What proactive measures can we take to mitigate or prevent each crisis scenario?
- **Response Protocols**: How should we respond and communicate during each crisis scenario?
## When to use
- When your team or organization works in a high-risk environment where crises are more likely.
- After a significant crisis or near-miss, to find where you were underprepared.
- As part of regular risk management and business continuity planning.
- Before launching new products, services or operations that bring new risks.
- During organizational change or restructuring, when uncertainty is high.
## Tips and tricks
- Make it safe to raise uncomfortable risks without fear of repercussions.
- Involve people from different departments, levels and areas of expertise so you see the full range of risks.
- Review and update your crisis plans as circumstances change so they stay current.
- Test your response protocols with simulations or tabletop exercises, and fix what they reveal.
- Keep preparedness visible with regular reminders and training, so the plan doesn't sit unread in a shared drive.
- Agree on clear lines of communication and decision-making authority so the response is fast and coordinated.
## Icebreaker questions
- If you could have any superpower to help manage a crisis, what would it be and why?
- Share a personal experience where you had to handle a challenging or unexpected situation. What did you learn from that experience?
---
# Quarterly Sales Retrospective
URL: https://www.teamretro.com/retrospective-templates/quarterly-sales-retrospective/
A quarterly sales retrospective is a meeting where your sales team looks back at the last three months: the deals you won, the ones you lost, and what made the difference. Where a pipeline review asks what's going to close, this one asks how the team sells and what it should change before the next quarter's targets kick in.
The board has four areas. Wins and Achievements is for the closed deals, shorter cycles and individual results worth celebrating, along with what made them work. Challenges Faced covers the setbacks, from pricing pressure and delayed launches to a slow internal approval process. Lessons Learned asks what the team now knows that it didn't at the start of the quarter, and Actions for Next Quarter turns that into a few specific priorities with an owner.
Bring the numbers, such as win rate, cycle length and lead quality, so the conversation rests on facts as well as anecdotes. Because reps add ideas privately before discussing them, you hear from newer reps as well as top performers, and a lost deal can be discussed as a process problem instead of someone's fault.
## Topics
- **Wins and Achievements**: What were our biggest sales wins this quarter?
- **Challenges Faced**: What were the biggest obstacles or setbacks we encountered?
- **Lessons Learned**: What did we learn this quarter?
- **Actions for Next Quarter**: What should be our key priorities for improving next quarter?
## When to use
- At the end of each quarter, once results and pipeline data are final
- When win rates, cycle length or lead quality have shifted and the team wants to understand why
- When the team keeps losing deals for the same reason and needs to agree on a fix
- Before quarterly planning, so new targets build on what actually worked
- When you want to recognize the quarter's wins and make sure the practices behind them spread across the team
## Tips and tricks
- Keep it blame-free, especially when discussing lost deals, so reps talk honestly about what happened
- Bring the quarter's metrics so the conversation rests on data as well as memory
- Ask a neutral facilitator, such as someone from sales ops or another team, to run the session
- Include reps from different teams and levels, so you hear from SDRs as well as senior account executives
- Pick a few high-impact actions instead of trying to change everything at once
- Review last quarter's actions at the start of the next retro so the team sees what changed
## Icebreaker questions
- If our sales team were a professional sports team, which one would we be and why?
- Share a funny or memorable experience you had with a customer this quarter.
---
# Rate of Improvement Retrospective
URL: https://www.teamretro.com/retrospective-templates/rate-of-improvement-retrospective/
The Rate of Improvement (ROI) retrospective asks where your team's effort has produced the most progress, and where it hasn't. The name plays on return on investment: instead of money, you're weighing how much improvement the team got back for the time and energy it put in.
The board has three columns. Highest ROI is for the areas where effort paid off quickly, like an automated test suite that cut bug-fix time or a planning format that made delivery more predictable. Lowest ROI covers the effort that didn't move things forward, such as long architecture debates with no decision or constant context switching. Potential ROI looks ahead to where a change would pay off next.
Because the format asks people to compare returns, it works best with evidence: cycle time, throughput, escaped defects or anything else your team already tracks. Use it when progress feels slow, after a big project, or as a periodic check alongside your usual retrospectives, and finish by turning the most promising Potential ROI ideas into actions with an owner.
## Topics
- **Highest ROI**: In which areas did we have the highest ROI?
- **Lowest ROI**: In which areas did we have the lowest ROI?
- **Potential ROI**: Where can we improve our ROI?
## When to use
- When the team feels its progress has stalled or slowed in some areas
- After a major project or initiative, to see which efforts paid off
- Every few months, alongside your usual retros, to check where improvement effort is going
- When a change in strategy or priorities means the team should rethink where it spends its improvement time
## Tips and tricks
- Bring metrics like cycle time, throughput and escaped defects so claims of high or low ROI rest on evidence
- Don't confuse high effort with low ROI; some hard problems need more investment before they pay off
- Make it safe to admit that an effort didn't work, or the Lowest ROI column will stay empty
- Turn the best Potential ROI ideas into action items with an owner
- Use it alongside formats that look at process, teamwork or technical practice, not as a replacement
## Icebreaker questions
- If our team were a vehicle, what would it be and why?
- What's one new skill you've picked up recently that made your work faster?
---
# Sherlock Retrospective
URL: https://www.teamretro.com/retrospective-templates/sherlock-retrospective/
The Sherlock Retrospective asks your team to investigate its last sprint the way Sherlock Holmes works a case: start from the evidence, follow the clues and only then draw conclusions. The detective framing keeps the discussion on facts and patterns, which makes it easier to talk about problems without anyone feeling accused.
The board has four areas. Case closed is for the problems the team solved and the goals it reached. Clues covers the tools, practices and habits that helped along the way. Elementary is for what the team learned, and Puzzles is for the questions nobody has answered yet.
It works well when the team is chasing a recurring issue or wants to understand what led to a success or a failure. Puzzles often becomes the next investigation, so finish by agreeing who will look into the most important open questions before the next retro.
## Topics
- **Case closed**: What did we solve?
- **Clues**: What helped us on the way?
- **Elementary**: What have we learned?
- **Puzzles**: What remains a mystery?
## When to use
- When the team needs to investigate a complex problem or a recurring issue
- After a challenging project, to understand what led to success or failure
- When you want more analytical thinking in your retrospectives
- When the team wants a new approach to problem-solving
## Tips and tricks
- Ask people to bring evidence and observations to back up their points, the way a detective would
- Use the detective theme to keep the discussion on facts and patterns and away from blame
- Give the investigation enough time. Don't rush to conclusions before you've looked at all the clues
- Keep a 'case file' of actions and insights to track progress over time
- Ask probing questions to dig into issues and find root causes
- Make it safe for team members to share observations and half-formed theories
## Icebreaker questions
- If you were a detective, what would be your signature method for solving cases?
- What's the biggest mystery you've solved in your professional life?
---
# The Time Traveler Retrospective
URL: https://www.teamretro.com/retrospective-templates/the-time-traveler-retrospective/
The Time Traveler Retrospective moves your team through three points in time. The Past covers the key moments of the last sprint, The Present is what people are focused on right now, and The Future is what they want to see next.
Putting all three on one board helps you connect them. A problem in the Past column often shows up again as a worry in the Present, and that link makes it clearer which item in the Future column deserves an action.
The fourth column, Time Loop, asks what you'd happily do over and over. It's where the team names the habits worth keeping, such as Friday code reviews or breaking big tasks into smaller ones, so they don't get lost while you focus on what to fix.
## Topics
- **The Past**: What were your key moments in the last sprint?
- **The Present**: What are you focused on right now?
- **The Future**: What would you want to see in the future?
- **Time Loop**: What is something you would do over and over?
## When to use
- When you want to connect what happened last sprint with where the team is heading
- During a period of significant change, to keep track of how far you've come
- When you want to spot patterns in how the team works over time
- At a quarter end or project wrap-up, when there's time to look back and plan ahead
## Tips and tricks
- Ask for specific examples, not general statements
- Timebox each column so the past doesn't take over the meeting
- Spend more of the discussion on what to change than on what already happened
- Point out links between columns, such as a past problem that shows up again in the present
- Use Time Loop to name the habits worth protecting
- Draw a simple timeline on the board to keep track of discussion points
## Icebreaker questions
- If you could time travel to any moment in your career, where would you go and why?
- What's one work habit you wish you could have started earlier in your career?
---
# The Archer Retrospective
URL: https://www.teamretro.com/retrospective-templates/the-archer-retrospective/
The Archer Retrospective borrows from archery to compare what your team aimed for with what actually happened. You start by naming the target, then sort the sprint into bulls-eyes, where you hit the mark, and missed shots, where you didn't.
The board has five columns. The Target sets the goal you're measuring against, so make it specific: a number, a date, a feature. Bulls Eye and Missed Shots cover the results. Focus asks what would steady your aim next time, and The Wind covers outside forces, such as shifting priorities or a third-party dependency, that could push you off course.
Starting from the target keeps the conversation honest. It's hard to argue about whether something went well when the goal is written at the top of the board, and The Wind gives you a place to raise risks before they land.
## Topics
- **The Target**: What were we aiming for?
- **Bulls Eye**: Where did we hit the mark?
- **Missed Shots**: Where were we off the mark?
- **Focus**: What will help us focus for our next shot?
- **The Wind**: What can cause us to go off target?
## When to use
- When you want to compare what the team planned with what it delivered
- After a major milestone or release
- When the team keeps missing targets or deadlines and you want to find out why
- When outside factors, such as shifting priorities or dependencies, are affecting delivery
## Tips and tricks
- Write the target at the top of the board before anyone adds notes, so everyone measures against the same goal
- Keep the discussion balanced. If Missed Shots takes the whole meeting, the team leaves without knowing what to keep doing
- Use The Wind to spot risks early and agree on how you'll handle each one
- Save most of the time for Focus, where the next actions come from
- Record what worked in Bulls Eye so you can repeat it next sprint
- Go around the room for each column so everyone gets a turn
## Icebreaker questions
- If your last sprint was an arrow, what kind of shot would it have been?
- What's something you do outside work that takes real precision?
---
# Book Club Retrospective
URL: https://www.teamretro.com/retrospective-templates/book-club-retrospective/
The Book Club retrospective asks your team to treat the last sprint as a book. What genre was it? Where did the plot turn? Which teammates deserve a mention? Answering those questions gets people talking about the sprint as one story, including how it felt, before anyone jumps to fixes.
The board has four sections. Genre captures the overall tone: a sprint that felt like a mystery or a horror story tells you something a status report won't. Plot Twists are the turning points, like a surprise requirement or the bug that changed the plan. Key Characters is where people thank the teammates who carried the sprint. Next Chapter turns all of it into what you'll do differently next time.
It works well when your usual format has gone stale, or when people find it hard to talk about problems head-on. Calling a sprint a horror story is often easier than saying it went badly, and it still opens the conversation.
## Topics
- **Genre**: If the last sprint was a book, what genre was it and why?
- **Plot Twists**: What were the turning points in the last sprint?
- **Key Characters**: Which teammates do you want to recognize for their part in the sprint?
- **Next Chapter**: What do we want to write into our next chapter?
## When to use
- When your team is tired of the usual retrospective formats and wants a change
- After a sprint full of connected events that make more sense told as a story
- When people find it hard to raise problems directly and a metaphor gives them some distance
- When you want to thank individual teammates as part of the retro
## Tips and tricks
- Give a couple of genre examples at the start so people see how loosely they can use the metaphor
- Let people build on each other's notes so the board reads as one story
- Use the metaphor to raise hard topics in a way that feels less confrontational
- Make sure Next Chapter ends with real actions that someone owns, so the story leads somewhere
- Keep a record of each sprint's genre so you can see how the story changes over several sprints
- Read a few notes aloud in a narrator's voice if the room is up for it
## Icebreaker questions
- If you could be any book character, who would you be and why?
- What's your favorite plot twist from a book or movie?
---
# Sprint Clinic Retrospective
URL: https://www.teamretro.com/retrospective-templates/sprint-clinic-retrospective/
The Sprint Clinic retrospective runs your retro like a visit to the doctor. Your team lists the symptoms it felt during the sprint, works out what's causing them, and agrees on a treatment, a follow-up and some prevention so the same problems don't come back.
The board has five columns, in the order a consultation runs. Symptoms is where people describe the pains: long standups, constant context switching, rework. Diagnosis digs into root causes, often with a quick round of 5 Whys. Treatment holds the practical fixes. Follow Up sets how you'll check the fix worked, and Prevention covers the habits that keep the team healthy.
Splitting the symptom from the diagnosis stops the team from jumping straight to a fix for the wrong problem. Use it after a rough sprint, or when the same issues keep showing up retro after retro and you want to get underneath them.
## Topics
- **Symptoms**: What pains did you have in the last sprint?
- **Diagnosis**: What could be the root causes?
- **Treatment**: How can we treat or manage this?
- **Follow Up**: How can we track progress and improvement?
- **Prevention**: What can we do to stay well?
## When to use
- When the same issues keep coming back and you want to find out what's causing them
- After a rough sprint where several problems need attention at once
- When your retros tend to jump straight to fixes without agreeing on the cause
- When the team needs both quick fixes and longer-term habits
## Tips and tricks
- Keep the medical theme light. It's there to give the discussion an order, not to make the session feel clinical
- Ask everyone to add to every column, since different people notice different symptoms and suggest different fixes
- Use Prevention for habits the team will keep, not one-off fixes
- Give every agreed action an owner so someone follows it through
- Track the Follow Up measures over a few sprints so you can see whether the treatment is working
- Keep the diagnosis on how the work is set up, not on individual performance
## Icebreaker questions
- If your last sprint was a patient, what would its health be on a scale of 1 to 10?
- What's your favorite home remedy for fixing a broken process?
---
# RPG Retrospective
URL: https://www.teamretro.com/retrospective-templates/rpg-retrospective/
The RPG (role-playing game) Retrospective is a retrospective game built on ideas most gamers already know. Wins are completed quests, improvements are skills to level up, unplanned work earns bonus XP, and the next big challenge is a boss fight. It gives your team a playful way into the usual questions without changing what the retro is for.
The board has four areas. For The Win is for the sprint's achievements, big and small. Level Up covers the skills, processes and tools the team wants to improve. Side Quests is for useful work that wasn't part of the plan, like helping another team or tidying up code while fixing a bug, and Boss Fight looks ahead to the big challenges coming your way.
It works especially well with software teams and anyone who plays games, but keep the references simple so nobody feels left out. Because Boss Fight looks forward, you finish knowing what's ahead as well as what's behind you, and the Level Up items turn naturally into actions.
## Topics
- **For The Win**: What were our achievements in the last sprint?
- **Level Up**: What attributes should we level up next?
- **Side Quests**: What side quests did we complete?
- **Boss Fight**: What are the big challenges coming our way?
## When to use
- When team morale needs a lift and you want a more playful retrospective
- With teams that enjoy games or need a fresh way to look at their work
- When you want the team to think creatively about the challenges ahead
- For teams that respond well to metaphors and other ways of framing a discussion
## Tips and tricks
- Keep the gaming references simple, since not everyone plays games
- Track action items with health bars or experience points to show progress over time
- Keep the theme in proportion: it should make the retro easier to run, not distract from it
- Create a character sheet for the team to track improvements over several sprints
- Play quiet game music or sound effects to set the atmosphere
- Rotate the 'Game Master' role so different team members get to facilitate
## Icebreaker questions
- If your current project was a video game, what genre would it be and why?
- What's your favorite power-up or special ability in a game, and how could we apply that concept to our team?
---
# News Magazine Retrospective
URL: https://www.teamretro.com/retrospective-templates/news-magazine-retrospective/
The News Magazine retrospective asks your team to cover the last sprint the way journalists would. People write headlines, report on current issues and pick the quotes that sum up how the sprint felt. Writing a headline makes you decide what the story actually was, which is half the work of a good retrospective.
The board has five sections. Headlines captures what the team wants everyone to know. Current Issues covers the topics that are pressing right now. Fake News is for assumptions that turned out to be false, Quotes for the lines that capture the sprint and Next Issue for the ideas you want to try in the coming sprint. Patterns are easier to spot when the same problem keeps making the news, and the format gives people a creative way to say things they might hold back in a plain list.
It works well for teams with retrospective fatigue, or for anyone who wants a less formal way to talk about both the achievements and the areas that need work.
## Topics
- **Headlines**: What do we want to tell everyone?
- **Current Issues**: What topics are important and relevant?
- **Fake News**: What assumptions turned out to be false?
- **Quotes**: What would be a quote for the last sprint?
- **Next Issue**: What ideas do we have for the next sprint?
## When to use
- When your team has retrospective fatigue and needs a more creative format
- After a significant milestone or project phase, when there's a lot to review
- When some team members hold back in traditional formats and a creative prompt might draw them out
- For teams that want to practice describing and documenting their work in new ways
## Tips and tricks
- Encourage creative headlines. A memorable headline usually leads to a better discussion
- Give people time to 'research' their stories by reviewing sprint metrics and feedback before the session
- Rotate the role of editor-in-chief so each issue gets a different perspective
- Use the journalist's five W's (who, what, when, where, why) to structure the discussion
- Keep an archive of past issues to track patterns and progress over time
- Try making a simple magazine cover, physical or digital, to show off the team's biggest achievements
## Icebreaker questions
- If your last sprint was a newspaper headline, what would it be?
- What's the most surprising 'breaking news' you encountered during this sprint?
---
# Psychological Safety Retrospective
URL: https://www.teamretro.com/retrospective-templates/psychological-safety-retrospective/
The Psychological Safety retrospective helps your team talk about trust directly: what makes it easy to speak up, and what makes people keep quiet. Amy Edmondson, who researches the topic at Harvard Business School, describes psychological safety as the belief that you won't be punished or humiliated for speaking up with ideas, questions, concerns or mistakes.
The board has three questions. What have we done to create team safety? collects the behaviors that already help, like a manager who admits their own mistakes. What would make our team feel unsafe? names the situations that shut people down, such as public criticism of ideas or concerns that go nowhere. What can we do to improve team safety? turns all of that into specific changes the team agrees to try.
Because the middle question is sensitive, it helps to collect answers anonymously and keep the discussion on behaviors, not people. Run it when a team forms, after a conflict, during a reorg, or every quarter as a check on how safe people feel. The trend over several sessions tells you more than any single one.
## Topics
- **What have we done to create team safety?**: What actions or behaviors have helped you feel safe speaking up?
- **What would make our team feel unsafe?**: Which situations or behaviors might prevent people from speaking up?
- **What can we do to improve team safety?**: What specific actions could help build a more supportive environment?
## When to use
- When a new team forms or new people join, to set healthy norms from the start
- After a conflict or a stretch of poor communication within the team
- During organizational changes that could shake people's trust
- Every quarter, as a regular check on how safe people feel speaking up
## Tips and tricks
- Agree on a few ground rules at the start, such as no comments on who said what
- Run it anonymously if your team is only starting to build psychological safety
- Talk about behaviors and situations, not individuals, when discussing what makes people feel unsafe
- Open the next session by reviewing the actions from the last one, so people see the team follows through
- Split larger groups into breakout rooms, where people are more likely to speak candidly
## Icebreaker questions
- Share a time when someone helped you feel more confident at work.
- What's one thing that makes you feel appreciated by your teammates?
---
# Music Band Retrospective
URL: https://www.teamretro.com/retrospective-templates/music-band-retrospective/
The Music Band retrospective helps musical groups look back on a performance, a rehearsal or how the band has been working together. It uses the language musicians already share (rhythm, timing, the moment a song gives you goosebumps) so band members can talk about what happened on stage and in the practice room.
The board has four columns. Rhythm And Flow asks what helped you find your rhythm. Off-Beat asks what threw you off. Goosebumps captures the moments that gave you chills, and Next Session is where you decide what to try at the next jam. Talking about timing and feel gives the band a way to raise problems in the music and in the relationships behind it, without it turning personal.
It's built for bands and ensembles, but any creative team can use it to look at how it works together. Swap the gig for a launch or the rehearsal for a sprint, and the questions still apply.
## Topics
- **Rhythm And Flow**: What helped you find rhythm?
- **Off-Beat**: What made you play off beat?
- **Goosebumps**: What was your goosebump moment?
- **Next Session**: What should we try for our next jam?
## When to use
- After a significant gig or recording session, to talk through what worked and what didn't
- When the band is struggling with coordination or communication
- As a regular check-in during rehearsals, so small problems get fixed early
- Before starting new material, to agree on the approach and what everyone expects
## Tips and tricks
- Make it safe for every member to speak, whatever their role or experience
- Use specific moments from recent gigs or rehearsals to make feedback concrete
- Balance talk about the music itself with talk about how the band works together
- Keep a record of action items and review them at the next session
- Ask everyone to contribute, since the drummer and the singer often hear different problems
## Icebreaker questions
- What's your favorite song we've performed together and why?
- If our band was a famous group from history, who would we be and why?
---
# Plus Delta Retrospective
URL: https://www.teamretro.com/retrospective-templates/plus-delta-retrospective/
The Plus Delta retrospective asks your team two things: what's working (Plus) and what should change (Delta). It takes a minute to explain, and it still ends with specific changes to try.
The two-column structure suits teams new to retrospectives and meetings where time is short. The Plus column records what went well so you keep doing it. The Delta column takes its name from the Greek letter used in math for change, so it asks what you'd do differently instead of listing what went wrong. That keeps the tone away from a 'pros and cons' list.
Looking at pluses and deltas side by side gives you a fair picture of the sprint: progress gets acknowledged, and problems become next steps. With only two columns the conversation stays focused, and it's easy to see which one or two changes to commit to.
## Topics
- **Plus**: What went well in the last sprint?
- **Delta**: What changes could we make?
## When to use
- When you need a quick format everyone understands without explanation.
- For teams new to retrospectives, as a gentle first step into structured feedback.
- When time is short and you only need the essentials.
- During a period of change, to protect what's working while you adjust the rest.
## Tips and tricks
- Turn each delta into a specific change. A problem with no proposed fix is hard to act on.
- Ask quieter team members to share first so the loudest voices don't set the agenda.
- If the delta column fills up, use dot voting to pick what to tackle first.
- Phrase deltas as what you'd do next time, not as criticism of what happened.
- Write down the agreed changes and check on them at the next retrospective.
## Icebreaker questions
- What's one positive change you've noticed in the team since our last retrospective?
- If you could instantly change one thing about our work process, what would it be?
---
# Sports Day Challenge Retrospective
URL: https://www.teamretro.com/retrospective-templates/sports-day-challenge-retrospective/
The Sports Day Challenge Retrospective treats your last sprint like a school sports day. Your team celebrates its personal bests, owns up to the hurdles it tripped on, checks how well people passed the baton, and decides what to train for before the next race.
The board has four columns. Personal Bests is for the wins, big and small. Hurdles covers the blockers and obstacles that slowed you down. Team Spirit looks at collaboration and morale: how smoothly work passed between people and whether everyone felt supported. Next Race turns the discussion into a short list of actions with owners.
The sporting theme keeps the tone light, which helps quieter people speak up about what went wrong. It suits a sprint retrospective, a project wrap-up or a quarterly review when the team needs to reconnect as much as it needs to review the work. Use a stopwatch to timebox each column and the theme does the rest.
## Topics
- **Personal Bests**: What were our standout wins and achievements?
- **Hurdles**: What obstacles slowed us down or tripped us up?
- **Team Spirit**: How well did we work and support each other as a team?
- **Next Race**: What should we train for and improve before next time?
## When to use
- When morale is low and you want a change from your usual retrospective format.
- At the end of a sprint or project, to celebrate wins and still name the blockers.
- For a team-building session where you want quieter members to join in.
- At a quarterly or milestone review, when reconnecting as a group matters as much as reviewing the work.
## Tips and tricks
- Use a stopwatch to timebox each column and treat each one as an event on the program.
- Start with Personal Bests so the team is warmed up before it gets to Hurdles.
- Keep any competition friendly. Nobody should be ranked against a teammate.
- Give remote participants the same time to add ideas, and use voting to find the priorities the whole team shares.
- Group similar Hurdles to spot repeat problems, then turn the top ones into actions under Next Race.
- Finish with a round of shout-outs so the session ends on a good note.
## Icebreaker questions
- If you could compete in any Olympic sport, which one would you pick and why?
- What's your go-to victory celebration when you achieve something at work?
---
# Fantasy Football League Retrospective
URL: https://www.teamretro.com/retrospective-templates/fantasy-football-league-retrospective/
Every fantasy football season has its bold drafts, lucky waiver pickups, heartbreaking injuries and trades that made someone look like a genius or a chump. The Fantasy Football League Retrospective gives your league a structured way to look back on it together: celebrate the wins, laugh at the losses and agree on how to make next season better. The trash talk can stay.
The board has four columns. What helped us win is for the picks, trades and moves that made someone's season. What flopped covers the busted picks and regrettable trades. League rules and format is where you debate scoring, roster sizes, the trade deadline and the playoff format. Next season goals collects ideas for the draft, prizes and the last-place punishment.
Each member adds their thoughts, the league votes on what matters most, and the commissioner leaves with a list of changes to lock in before kickoff. Whether you run a serious dynasty league or play for bragging rights, it beats settling rule changes by shouting over each other in the group chat.
## Topics
- **What helped us win**: Which moves, picks or wins made your season?
- **What flopped**: Which picks, trades or decisions backfired badly?
- **League rules and format**: What rules, scoring or settings need to change?
- **Next season goals**: What should we try or change for the next game?
## When to use
- At the end of the fantasy football season to review results before everyone moves on.
- During your pre-draft league meeting to lock in rule and format changes for the year ahead.
- When the commissioner needs structured input from members instead of chaotic group-chat debates.
- After a controversial trade, ruling, or playoff finish that the league needs to discuss as a group.
## Tips and tricks
- Keep it light. This isn't a corporate meeting, so lean into the trash talk and inside jokes.
- Use anonymous brainstorming so members feel free to call out unpopular rules or admit their own blunders without judgment.
- Give every member equal airtime, and don't let the loudest or most competitive players dominate the discussion.
- Turn rule and format suggestions into clear action items, and use a league vote for anything that affects everyone.
- Set a time limit per topic so the session stays snappy and you don't get stuck relitigating one controversial trade.
- Capture the season's best and worst moments to build a fun league history that you can revisit year after year.
## Icebreaker questions
- If your fantasy team had a walk-up song this season, what would it be and why?
- What's the one waiver wire pickup or trade you'd undo if you had a time machine?
---
# Independence Day Celebration Retrospective
URL: https://www.teamretro.com/retrospective-templates/independence-day-celebration-retrospective/
Independence Day is a natural point to stop and look at how far your team has come. The Independence Day Celebration retrospective borrows the holiday's themes of freedom and fresh starts and points them at your work: the milestones you've reached, the autonomy you've earned, the people who made it possible and where you want to go next.
The board has four columns. Declarations is where people name the wins and milestones they're proud of. Freedoms Won covers the places you gained more trust, ownership or flexibility, such as fewer approval steps or a decision the team got to make on its own. Unsung Heroes is for specific thanks to the people and habits that rarely get noticed. Future Horizons turns the conversation forward, to the goals and new freedoms you want to work toward.
It leans further toward celebration than a standard sprint retro, but it still ends with decisions. Run it around a national holiday, at the close of a big project or whenever morale needs a lift. In TeamRetro, people add ideas privately, group similar notes, vote on what matters most and turn the top Future Horizons items into actions with owners.
## Topics
- **Declarations**: What big wins or milestones should we declare and celebrate?
- **Freedoms Won**: Where did we gain more autonomy, trust, or flexibility?
- **Unsung Heroes**: Who or what deserves recognition for our success?
- **Future Horizons**: What do we want to achieve next?
## When to use
- Around Independence Day or another national holiday, when you want a themed session that lifts morale.
- At the close of a major project or milestone, to celebrate what the team delivered and thank the people behind it.
- When energy is low and the team needs to refocus on its wins and shared goals.
- As a quarterly or end-of-year review, to mark progress and set goals for what comes next.
## Tips and tricks
- Open with appreciation. This format is meant to lift the team, so celebrate before you move on to improvements.
- Ask for specific recognition in Unsung Heroes. Naming what someone actually did means more than general praise.
- Timebox each column so the session keeps its energy and you still have time for Future Horizons.
- Turn on anonymous ideas if your team is shy about praising its own work, then discuss the grouped themes together.
- Invite each person to add at least one declaration or shout-out so the quieter voices are heard too.
- Turn Future Horizons ideas into action items with owners so the momentum lasts after the celebration.
## Icebreaker questions
- If your team had its own flag, what symbol or color would be on it and why?
- What's one freedom, big or small, that makes your workday better?
---
# Mother's Day Reflection
URL: https://www.teamretro.com/retrospective-templates/mothers-day-retrospective/
Mother's Day is a good moment to recognize the people who raised, guided and supported us, at home and at work. The Mother's Day Reflection brings your team together to share stories, say thank you and talk about what those people taught you, whether that's patience, resilience or a way of caring for others. It welcomes mothers and mother-figures of every kind, and colleagues often leave knowing each other a little better.
The board has three columns. Gratitude asks who you're thankful for and why. Lessons learned asks what wisdom a mother-figure passed on to you. Future memories asks how you'll pay that kindness forward. Each person adds memories, words of thanks and small commitments, and because everyone contributes in the same space, remote and in-office colleagues take part on equal terms.
As facilitator, you get a simple structure for a conversation that can be light one moment and moving the next. Keep sharing optional and gentle, since the day is hard for some people, and close by turning the pay-it-forward ideas into small actions people will actually do.
## Topics
- **Gratitude**: Who are you thankful for and why?
- **Lessons learned**: What wisdom did a mother-figure pass on to you?
- **Future memories**: How will you pay this kindness forward?
## When to use
- Marking Mother's Day with your team as a community or culture-building activity.
- Recognizing the mothers, caregivers and mentors in and around your team in a warm, inclusive way.
- Giving people a chance to share personal stories and say thank you, which brings the team closer.
- Marking a seasonal occasion together, whether your team is remote or in the same room.
## Tips and tricks
- Set an inclusive tone at the start. Say that Mother's Day looks different for everyone and that every kind of mothering and caregiving is welcome.
- Remember the day can be emotional for some people. Let everyone share as much or as little as they want.
- Share your own reflection first. It encourages openness and sets the tone.
- Keep the session light and celebratory, and leave room for the moving moments alongside the funny ones.
- Capture the ideas from Future memories as actions so the appreciation carries on after the meeting.
- Leave plenty of time for stories. That's where people connect.
## Icebreaker questions
- If you could give every mom in the world one gift, what would it be?
- What's a phrase your mom (or a mother-figure) said so often you can still hear it?
---
# Hike to a Waterfall Retrospective
URL: https://www.teamretro.com/retrospective-templates/waterfall-hike-retrospective/
The Hike to a Waterfall Retrospective treats your last sprint or project phase as a hike. There were steep sections, things in your pack that kept you going, and a view at the end that made the effort worth it. Talking about a steep climb is often easier than talking about a failed plan, so people tend to be more candid.
The board has four areas. The Steep Climb is for the obstacles and blockers that slowed the team down. The Trail Supplies covers the tools, people and habits that helped. The Waterfall is for the wins you reached, big or small, and The Next Trail is where the team decides what to do differently next time.
It suits a sprint or phase that was hard but ended well, because it gives the struggle and the result the same airtime. Finish on The Next Trail with two or three actions, each with an owner.
## Topics
- **The Steep Climb**: What obstacles slowed us down on the way?
- **The Trail Supplies**: What tools or support helped us along the way?
- **The Waterfall**: What wins did we reach that made the climb worth it?
- **The Next Trail**: What should we prepare for or do differently next time?
## When to use
- After a hard sprint or project phase where the team hit real obstacles but still reached its goal.
- When morale is low and you want to recognize the wins without glossing over what was difficult.
- Between major milestones, to look at what kept the team going before you start the next phase.
- When the usual formats have gone stale and a simple outdoor metaphor will get people talking.
## Tips and tricks
- Explain the hike at the start so everyone knows which part of the trail each area stands for.
- Ask for specific obstacles. "Communication issues" is vague; "two days waiting on design approval" is something you can fix.
- Give the climb and the waterfall similar time, so the session doesn't turn into a list of complaints or skip over real struggles.
- Treat the waterfall as a real celebration and name who made each win possible.
- Start with a few minutes of silent writing so quieter people get their ideas on the board before the discussion starts.
- Close by asking what the team will pack differently for the next hike, then turn the answers into owned actions.
## Icebreaker questions
- What's the most memorable hike or outdoor adventure you've ever been on, and what made it special?
- If you could hike to any waterfall in the world, where would it be and who would you bring with you?
---
# Tour de France Challenge Retrospective
URL: https://www.teamretro.com/retrospective-templates/tour-de-france-challenge-retrospective/
The Tour de France Challenge Retrospective looks at your last sprint or project as a stage of the race. Some stretches were hard climbs, some were fast descents, and somewhere along the way you probably got a puncture.
The board has four columns. The Climbs are the toughest challenges the team ground through. The Descents are where momentum picked up and work flowed. The Punctures are the unexpected breakdowns that stopped you, and The Yellow Jersey, named after the jersey the race leader wears, goes to the people and moments that deserve recognition.
Separating the climbs from the punctures is the useful part. A climb is work that was always going to be hard, while a puncture is something that shouldn't have happened, like flaky tests or a dependency that wasn't ready. Treating them differently helps you decide which problems need an action and which deserve credit for the effort. It's a good fit when your team is tired of the usual format, or while the real race is on each summer.
## Topics
- **The Climbs**: What were the toughest uphill challenges we faced?
- **The Descents**: Where did we gain momentum and things flowed easily?
- **The Punctures**: What slowed us down or caused us to stop unexpectedly?
- **The Yellow Jersey**: Who or what deserves recognition this stage?
## When to use
- When your team needs a change from its usual retrospective to beat retro fatigue.
- After a demanding sprint or project with both big wins and tough challenges to talk through.
- When you want recognition and team spirit to get time alongside honest talk about blockers.
- During themed sessions, such as while the real Tour de France is on.
## Tips and tricks
- Explain each cycling metaphor at the start so everyone knows what belongs in each column.
- Use cycling language through the session to keep the theme going.
- Timebox each stage so the team doesn't spend the whole session on The Climbs.
- Keep The Punctures on root causes and fixes, not on who caused them.
- Give everyone a chance to award a Yellow Jersey so recognition doesn't come only from the loudest voices.
- Turn the biggest climbs and punctures into actions with an owner so the next stage goes more smoothly.
## Icebreaker questions
- If your week were a Tour de France stage, would it be a flat sprint, a brutal mountain climb, or a relaxing recovery ride?
- What's one thing that would have made your ride smoother this sprint: a better bike, a stronger team, or a clearer route?
---
# Rings of Power Quest Retrospective
URL: https://www.teamretro.com/retrospective-templates/rings-of-power-quest-retrospective/
The Rings of Power Quest retrospective treats your team's recent work as a fantasy quest. It asks which powers carried the team, which dragons got in the way, who helped along the road and where the quest goes next. The story gives people a little distance from the problems, so they're easier to name without anyone feeling blamed.
The board has four areas. Rings of Power is for the strengths and tools that gave the team an edge. Dragons & Perils covers the obstacles and risks that slowed the work. Fellowship & Allies is where you thank the people and teams who helped, and The Road Ahead turns the discussion into next steps.
Use it after a big milestone or epic, when your regular retro has gone flat, or when you want a session that doubles as team-building. Keep the theme light and finish with a few actions from The Road Ahead, each with an owner, so the next sprint starts with a clear direction.
## Topics
- **Rings of Power**: What strengths and tools gave the team an edge?
- **Dragons & Perils**: What obstacles or dangers threatened the mission?
- **Fellowship & Allies**: Who or what helped the team along the way?
- **The Road Ahead**: Where should the quest lead us next?
## When to use
- When standard sprint retrospectives have become routine and you want a change of format.
- After a major milestone or epic that felt like the end of a long quest.
- For a team-building session where you want to thank people for their help.
- When morale is low and a story-based format could get people talking again.
- For remote or distributed teams who want a lighter way to reflect together.
## Tips and tricks
- Set the scene with a short intro that frames the sprint as a quest, so people know how to use the theme.
- Keep the fantasy framing light. The metaphor is there to make honest feedback easier, not to replace it.
- Timebox each area so the team moves steadily and everyone gets heard before the discussion goes deep.
- Start with Rings of Power or Fellowship & Allies. Quieter team members often find praise easier to share than problems.
- Group similar dragons and perils to spot patterns, so you're not fighting the same battle every sprint.
- Close with clear actions and owners from The Road Ahead.
## Icebreaker questions
- If you could wield one magical power at work, what would it be and why?
- Which fantasy character best represents how your week went, and why?
---
# Post-Launch Retrospective
URL: https://www.teamretro.com/retrospective-templates/post-launch-retrospective/
A post-launch retrospective is a meeting to review how a major project or product release actually went. Your team looks at what worked, what didn't and what customers are saying, while the details are still fresh.
The format covers four areas: what went well, challenges faced, customer feedback, and improvements for next time. Putting customer feedback on the same board as the team's own view shows whether the problems you felt inside the team were the ones customers noticed. The improvements column turns all of it into specific changes for the next launch.
Bring in the people from marketing, sales, support and engineering who worked on the launch. Each group saw a different part of it, and the retro gives them a set time to compare notes.
## Topics
- **What Went Well?**: What aspects of the launch were successful?
- **Challenges Faced**: What obstacles or difficulties did we encounter?
- **Customer Feedback**: What feedback did we receive from customers?
- **Improvements for Next Time**: What can we do better for future launches?
## When to use
- After launching a new product, service or major feature, to judge how it went and what to change.
- After a large project or initiative, to capture lessons before the team moves on.
- On a regular schedule across launches, so lessons from one release carry into the next.
## Tips and tricks
- Make it safe to be honest. Agree up front that this is about the launch, not about blame.
- Invite people from every function that worked on the launch, plus the main stakeholders.
- Have a note-taker capture the main points and actions.
- Spend more time on what to change than on past mistakes.
- Pick the improvements with the biggest payoff that you can realistically make before the next launch.
- Track those improvements and review them when planning for the next launch starts.
## Icebreaker questions
- If you could describe the launch experience in one word, what would it be?
- Share a moment from the launch that sums up how it went.
---
# Yellowstone Expedition Retrospective
URL: https://www.teamretro.com/retrospective-templates/yellowstone-expedition-retrospective/
The Yellowstone Expedition Retrospective casts your team as explorers crossing Yellowstone. Along the way you hit geysers, run into grizzlies, find hidden trails and reach a few summits. Framing the sprint or project as an expedition gives people a lighter way to talk about what went wrong as well as what went right.
The board has four areas. Geysers is for sudden bursts of energy and breakthroughs. Grizzlies covers the risks and obstacles that caught the team off guard. Hidden Trails is for unexpected discoveries, like a new tool or a shortcut worth exploring, and Summits is for the goals the team reached and wants to celebrate.
It suits teams tired of the standard format, and the end of a long project where there's plenty to look back on. Tie your actions to what came up in Grizzlies and Hidden Trails: one tells you what to watch for next time, the other what to try.
## Topics
- **Geysers**: What moments gave us a sudden burst of energy or breakthrough?
- **Grizzlies**: What risks or obstacles caught us off guard along the way?
- **Hidden Trails**: What unexpected discoveries or opportunities did we find?
- **Summits**: What goals did we proudly reach and want to celebrate?
## When to use
- When your team is tired of the standard sprint retrospective and a themed format would get people talking.
- After a long or difficult project, when there's a lot of ground to look back on.
- When you want a playful, low-pressure session that helps the team bond.
- When quieter team members would find it easier to contribute through a metaphor.
## Tips and tricks
- Explain each landmark at the start so everyone knows what goes where before they add notes.
- Keep the Grizzlies discussion blame-free. Focus on lessons and early warning signs, not who was at fault.
- Use anonymous brainstorming in TeamRetro to get honest input, then group and vote on the main themes.
- Timebox each area so you reach action planning with time to spare.
- Finish with actions tied to the discoveries in Hidden Trails and the obstacles in Grizzlies.
- Take time over the Summits. Recognizing wins matters as much as finding improvements.
## Icebreaker questions
- If you could explore any national park or wilderness in the world, where would you trek first?
- What's the most adventurous or unexpected thing you've done outdoors?
---
# Fairy Tale Adventure Retrospective
URL: https://www.teamretro.com/retrospective-templates/fairy-tale-adventure-retrospective/
The Fairy Tale Adventure retrospective retells your sprint or project as a storybook adventure, with heroes, dragons, a bit of magic and a moral at the end. Casting real events as parts of a story makes them easier to talk about, especially the awkward ones.
The board has four columns. Our Heroes is for the people, decisions and tools that saved the day. Dragons & Obstacles covers the challenges and blockers you had to fight. Magic & Surprises collects the lucky breaks and things that worked better than expected. The Moral of the Story is where you agree on the lessons and actions you'll carry into the next chapter.
The story gives quieter team members an easy way in, since naming a hero or a dragon feels lower-stakes than raising a problem in a standard retro. Keep every hero and dragon tied to something that actually happened, and make sure the moral ends in actions with owners.
## Topics
- **Our Heroes**: Who or what saved the day during this adventure?
- **Dragons & Obstacles**: What dragons did we have to battle along the way?
- **Magic & Surprises**: What unexpected magic or luck helped us along?
- **The Moral of the Story**: What lessons will we carry into the next chapter?
## When to use
- When your team needs a break from standard retrospective formats.
- At the end of a sprint, milestone or major project, when telling it as a story could bring out more detail.
- When you want quieter or newer team members to contribute in a low-pressure way.
- When you want to celebrate wins and acknowledge struggles in a way people will remember.
## Tips and tricks
- Open with a short narrative so everyone settles into the storybook theme.
- Keep the fun tied to real events. Every dragon and hero should map to something that happened.
- Timebox each chapter so you still reach The Moral of the Story with time to agree on actions.
- Invite quieter people to name a hero or a dragon, so the story reflects the whole team.
- Don't let the metaphor turn into finger-pointing. Dragons are shared obstacles, never individuals.
- Close by turning each moral into an action with an owner for next sprint.
## Icebreaker questions
- If you were a character in a fairy tale, who would you be and what would be your superpower?
- What's a childhood story or fairy tale that has stuck with you, and why?
---
# Norm Kerth's Prime Directive Retrospective - Original Four
URL: https://www.teamretro.com/retrospective-templates/norm-kerth-original-four-prime-directive/
Norm Kerth set out the Prime Directive in his 2001 book *Project Retrospectives: A Handbook for Team Reviews*, and this retrospective is built on it. You open by reading the Prime Directive aloud, then work through Kerth's original four questions: what did we do well, what did we learn, what should we do differently, and what still puzzles us.
The Prime Directive asks everyone to accept that each person did the best job they could, given what they knew at the time, their skills and abilities, the resources available and the situation at hand. Starting from that assumption takes blame off the table. People can talk honestly about what happened and why without getting defensive, and that's where the useful lessons come from.
The format is a good choice after a hard project or a difficult transition, when feelings may be running high. It keeps the discussion on learning, so your team can agree on concrete improvements and still trust each other at the end. Many later retrospective formats borrow from these four questions.
## Topics
- **What did we do well?**: What achievements are you most proud of from this period?
- **What did we learn?**: What insights or discoveries will you carry forward?
- **What should we do differently?**: What changes would improve our performance next time?
- **What still puzzles us?**: What questions or uncertainties remain unresolved?
## When to use
- After a significant milestone or release, to capture lessons while they're still fresh.
- After a setback, when the team needs a blame-free way to talk about what happened.
- With teams new to retrospectives, because four plain questions are easy to follow.
- When trust needs rebuilding. The Prime Directive's assumption of good intent makes it safer to speak up.
## Tips and tricks
- Begin by reading Norm Kerth's Prime Directive aloud: 'Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.'
- Take 'What still puzzles us?' last. It often builds on the other answers and points to what needs looking into.
- Ask for specific examples instead of generalizations so the discussion leads somewhere.
- If people are hesitant, go around the room and ask each person for at least one item per question.
- Once everything is on the board, rank the 'What should we do differently?' items and give the top ones an owner and a date.
## Icebreaker questions
- If you could have one superpower to help the team perform better, what would it be and why?
- What's one unexpected thing you learned during our last work cycle that surprised you?
---
# Anchors & Engines Retrospective
URL: https://www.teamretro.com/retrospective-templates/anchors-engines-retrospective/
The Anchors & Engines retrospective asks two questions: what's slowing your team down, and what's moving it forward? Anchors are the drag, such as unclear priorities, too many meetings or tools that get in the way. Engines are the practices and conditions that give you speed. Seeing both on one board helps you decide what to cut loose and what to protect.
The format uses a speedboat metaphor. Picture the team heading for an island, with the boat standing for the outcome or deliverable you're working toward. Some facilitators add urgency by imagining people on the island waiting for food and medical supplies, so arriving on time matters.
Everyone adds notes to both columns, then the team groups them, votes and talks through the ones with the most impact. You leave with a few actions: an anchor or two to remove and an engine or two to keep running.
Use it when you're facing roadblocks or inefficiencies, or when things are going well and you want to understand why so you can keep the momentum.
## Topics
- **Anchors**: What factors are slowing us down or holding us back?
- **Engines**: What factors are driving us forward and enabling our success?
## When to use
- When bottlenecks or roadblocks are slowing your team and you need to find the biggest ones.
- When things are going well and you want to name the practices behind it so they don't slip.
- When you want to hear from everyone on the team about what's helping and what's hurting.
- After a sprint with mixed results, when both the drag and the drive deserve a look.
## Tips and tricks
- Give everyone a few minutes to add notes on their own before discussion starts, so every view reaches the board.
- Talk about anchors as conditions and processes, not people, so nobody holds back.
- Vote on anchors and engines by impact and by how easily the team can act on them.
- Write an action for the top anchor and the top engine, each with an owner and a date.
- Check those actions at your next retrospective to see whether the anchor has gone.
- If an anchor sits outside the team, invite the stakeholder or expert who can actually move it.
## Icebreaker questions
- If our team were a vehicle, what kind would it be and why?
- Share a recent 'anchor' or 'engine' moment you experienced outside of work.
---
# Roller Coaster Retrospective
URL: https://www.teamretro.com/retrospective-templates/roller-coaster-retrospective/
The Roller Coaster Retrospective treats your last sprint like a ride: there were climbs, drops and a few loops nobody saw coming. Most sprints feel like that from the inside, so the metaphor gives people a simple way to talk about the highs and the lows in the same conversation.
The board has five areas. Ups is for the high points and Downs for the low ones. Loops captures the surprises, good and bad. Again, Again is for the practices the team wants to keep, and Next Ride is for the experiments to try in the coming sprint.
It works best after a sprint with clear highs and lows, or when the team is tired of the usual format. Talking about drops and loops makes hard topics feel less personal, and the last two areas make sure the session ends with something to keep and something to try.
## Topics
- **Ups**: What were the high points of our last sprint?
- **Downs**: What were the low points of our last sprint?
- **Loops**: What surprised us?
- **Again, Again**: What do we want to continue doing?
- **Next Ride**: What do we want to try next?
## When to use
- When team morale needs a lift and you want to keep the energy up during the retro
- After a sprint with clear highs and lows
- When your team has meeting fatigue and the standard format has stopped getting people talking
- For teams that like working through problems with a metaphor
## Tips and tricks
- Open by explaining how a roller coaster maps to a sprint: the climbs, the drops and the loops you didn't see coming
- Use roller coaster sound effects or images to set the theme
- Ask for specific moments, not general feelings
- Timebox each topic to 5–7 minutes to keep the session moving
- End with concrete improvement actions, each with an owner
- For remote sessions, invite people to use a roller coaster virtual background
## Icebreaker questions
- What's your favorite amusement park ride and why?
- If your last sprint was a roller coaster ride, what would you name it?
---
# YouTube Creator's Corner Retrospective
URL: https://www.teamretro.com/retrospective-templates/youtube-creators-corner-retrospective/
Running a YouTube channel means filming, editing, thumbnails, titles, analytics and community replies, often all in the same week. It's easy to keep publishing without stopping to learn from what's already out. The YouTube Creator's Corner Retrospective gives your content team a set time to look at which videos landed, which didn't, and why.
The board has four areas. Top Performers is for the content that resonated with your audience. Missed the Mark covers videos that underperformed, discussed without blame. Fresh Ideas is the brainstorm for new content, formats and experiments, and Production & Workflow is where the team names what's slowing the pipeline down. Bring watch time, click-through rate, retention and comments into the session so the discussion rests on data, not hunches.
It works for a solo creator with a small crew and for a media team publishing several videos a week. Run it after a content sprint or campaign, or once a month, and finish with a few owned actions for the next batch of uploads.
## Topics
- **Top Performers**: Which videos or content resonated most with our audience?
- **Missed the Mark**: What content underperformed or didn't land as hoped?
- **Fresh Ideas**: What new content, formats or experiments should we try?
- **Production & Workflow**: What's slowing down our content pipeline or could run smoother?
## When to use
- After publishing a batch of videos or completing a content sprint, to review what performed and plan the next round.
- On a regular monthly cadence to keep your channel strategy aligned and learn from recent analytics.
- Following a campaign, product launch or major collaboration to capture lessons while they're fresh.
- When growth has plateaued and the team needs to diagnose what's working and what isn't.
- When onboarding new creators or editors and you want to align everyone on content goals and workflow.
## Tips and tricks
- Bring real channel analytics (watch time, retention curves, CTR and subscriber growth) so the discussion rests on data, not gut feeling.
- Keep the Missed the Mark discussion blame-free and treat underperformance as something the whole team learns from.
- Timebox the Fresh Ideas brainstorm so it doesn't sprawl. Capture everything, then pick the top few to act on.
- Ask editors and thumbnail designers directly for their view; they often see workflow problems nobody else does.
- Turn the strongest ideas and workflow fixes into actions with an owner and a due date.
- Rotate the facilitator between creators and crew so different people shape the session.
## Icebreaker questions
- If your channel could collaborate with any creator on YouTube, who would it be and why?
- What's the most random video you've fallen down a rabbit hole watching this week?
---
# Vision and Mission Alignment
URL: https://www.teamretro.com/retrospective-templates/vision-and-mission-alignment/
The Vision and Mission Alignment retrospective checks whether your team's day-to-day work still lines up with what the organization says it's for. You start by putting the vision and mission statements on the board, then look at what has moved you toward them and what has pulled you away.
The board has four columns. Guiding Vision & Mission is where the team restates the statements and says how well they capture the purpose of its work. Progress & Achievements collects the decisions and results that moved you closer. Obstacles & Misalignment is for the gaps between what the organization says and what it does, and Path Forward asks what to start, stop or continue doing to close them.
It's a useful check after a reorganization or a change in strategy, or whenever people start to feel that the stated values and the real decisions have drifted apart. You come away with a shared view of the mission and a short list of changes, each with an owner.
## Topics
- **Guiding Vision & Mission**: What are our organization's core vision and mission statements?
- **Progress & Achievements**: What key accomplishments have moved us closer to our vision and mission?
- **Obstacles & Misalignment**: What factors or decisions have pushed us away from our vision and mission?
- **Path Forward**: What should we start, stop, or continue doing to live up to our vision and mission?
## When to use
- When the team needs to reconnect its day-to-day work with the organization's vision, mission and strategic goals.
- After a reorganization, a strategy shift or a period of fast growth, to confirm what still guides the team.
- When people need a clearer sense of why their work matters.
- When there's a gap between the stated values and the decisions or results people actually see.
- Before strategic planning, to feed what you've learned into the next set of priorities.
## Tips and tricks
- Explain the purpose of the session up front so people know honest challenge is welcome.
- Keep the vision, mission and values statements visible throughout the discussion.
- Make it safe for people to respectfully question decisions, including ones made by leadership.
- Invite people from different roles and levels. Different viewpoints reveal blind spots.
- Use a neutral facilitator to keep the conversation focused and stop it turning into a debate.
- Finish by agreeing on a short action plan for the biggest gaps, with an owner for each.
## Icebreaker questions
- If our organization was a vehicle, which one would it be and why?
- Share a quote or personal motto that sums up our vision and mission for you.
---
# Ada Lovelace Retrospective
URL: https://www.teamretro.com/retrospective-templates/ada-lovelace-retrospective/
[Ada Lovelace](https://en.wikipedia.org/wiki/Ada_Lovelace) was a mathematician who worked with Charles Babbage on his Analytical Engine, a mechanical computer that was never built. Her 1843 notes on the machine include what is often called the first published computer program, and she saw that it could work with symbols as well as numbers. The Ada Lovelace Retrospective uses her story as the theme for an engineering retro. It fits Ada Lovelace Day, held on the second Tuesday of October, and it works in any sprint.
The board has four columns. Breakthroughs is for the coding wins and clever solutions from the sprint. Bugs in the System covers the mistakes that crept into your code or your process. Infinite Loops is for the blockers that kept the team going round in circles, and Next Algorithm is where you decide what to design or improve in the next iteration. The coding language gives engineers a familiar way to talk about problems that go beyond the code, like an unclear API contract or a week lost to meetings.
Use it with development teams that want something other than a plain "what went well, what didn't" board. The theme gives you a light way in, and the four columns still end with actions the team owns.
## Topics
- **Breakthroughs**: What coding wins or innovations did we achieve?
- **Bugs in the System**: What bugs or mistakes crept into our process or code?
- **Infinite Loops**: What blockers or obstacles kept us stuck in a loop?
- **Next Algorithm**: What should we design or improve in our next iteration?
## When to use
- After a sprint with notable technical wins or setbacks, when the team would get more from a themed format than the usual board.
- Around Ada Lovelace Day, the second Tuesday of October, for engineering and development teams that want to mark it.
- When technical debt, process bugs or blockers keep coming back and the team needs a safe place to raise them.
- When morale needs a lift. Starting with Breakthroughs puts the wins on the table before the problems.
- In any sprint where your team wants a change from the standard formats and enjoys a bit of story.
## Tips and tricks
- Set the scene with one fact about Ada Lovelace, such as her 1843 notes on Babbage's Analytical Engine, which include what's often called the first published computer program.
- Keep Bugs in the System blame-free. The question is what the team can learn from a bug, not who caused it.
- Timebox each column to 10–12 minutes, and give Next Algorithm a little longer for action planning.
- Make sure Next Algorithm ends with assigned action items, not vague intentions. Capture owners and due dates in TeamRetro before the session ends.
- Watch for a board full of code bugs and nothing about how people work together. Ask the team: "Are there any bugs in how we work together?"
- With a large team, group similar ideas before discussion and use dot voting to decide which bugs and blockers to tackle first.
## Icebreaker questions
- If you could give your code from this sprint a dramatic Ada Lovelace-era title, like 'A Note Upon the Analytical Engine's Capacity for Infinite Loops', what would it be?
- If Ada Lovelace could join your team for a day, which part of your tech stack do you think would impress her most, and which would horrify her?
---
# Definition of Ready Retrospective
URL: https://www.teamretro.com/retrospective-templates/definition-of-ready-retrospective/
A sprint goes better when the work in it was ready before planning started. A Definition of Ready (DoR) is your team's list of entry criteria a backlog item has to meet before it's pulled into a sprint, such as acceptance criteria, an estimate and known dependencies. The Definition of Ready Retrospective checks whether that list is doing its job.
The board has four columns. Our Current DoR sets out what the criteria actually are today, which often turns out to differ from person to person. When It Works collects examples of ready stories going smoothly. When It Breaks Down covers what happened when unready work got into a sprint. Improve Our DoR is where you agree on changes.
Use it when planning keeps running long, stories keep stalling mid-sprint, or nobody has looked at your DoR in months. It works for Scrum and Kanban teams alike. In TeamRetro people can add ideas anonymously, so problems with refinement come out even when they're awkward to raise.
## Topics
- **Our Current DoR**: What does our Definition of Ready look like today?
- **When It Works**: What goes well when stories meet our Definition of Ready?
- **When It Breaks Down**: What problems arise when stories aren't truly ready?
- **Improve Our DoR**: What changes should we make to strengthen our Definition of Ready?
## When to use
- Your team keeps hitting mid-sprint blockers, scope creep or stories that can't be finished in the sprint, which often means work wasn't ready when it was planned.
- Sprint planning runs long or feels chaotic because the backlog wasn't refined before the team commits.
- You're onboarding new team members and want to write down what 'ready' means for your team.
- Your team has a Definition of Ready but hasn't reviewed it in a while, and it may not match how you work now.
- After a hard sprint where unclear requirements or missing information caused delays or rework.
## Tips and tricks
- Share your current DoR before the session so people arrive with real examples.
- Talk about process gaps, not individual mistakes, so people can describe what went wrong without blame.
- Timebox each column. DoR discussions easily turn into refining individual stories, so keep the retro on the criteria themselves.
- Agree on 1–3 changes per session. A DoR that tries to cover everything gets too long to follow.
- Involve the whole team, not only the Scrum Master or Product Owner. Developers, QA and designers each feel unready stories in different ways.
- Check at the next retrospective whether the changes made planning and delivery easier.
## Icebreaker questions
- If your backlog were a kitchen, would it be a well-stocked, organized pantry or a chaotic fridge full of mystery leftovers, and why?
- What's one thing you wish you knew at the start of a task that you always seem to find out halfway through?
---
# World Mental Health Day Retrospective
URL: https://www.teamretro.com/retrospective-templates/world-mental-health-day-retrospective/
The World Mental Health Day Retrospective gives your team a structured, low-pressure way to talk about mental health at work. World Mental Health Day falls on October 10 each year, which makes it a natural prompt, but the format works any time.
The board has four areas. Mental Health Challenges is for the workplace factors wearing people down, like deadlines, meeting load or isolation. Current Support Systems covers what already helps, formal or informal. Improvement Ideas is where the team suggests changes, and Personal Commitments asks each person for one realistic thing they'll do for their own mental health or a colleague's.
Set ground rules before anyone writes: sharing is optional, nobody has to disclose personal details, and the discussion stays on work. Have your company's support resources ready to share, and follow up privately with anyone who seems to need more than a team conversation can give.
## Topics
- **Mental Health Challenges**: What at work is affecting your mental health?
- **Current Support Systems**: What resources or practices help support your mental health?
- **Improvement Ideas**: What changes could better support mental health at work?
- **Personal Commitments**: What actions will you take to support mental health?
## When to use
- Around World Mental Health Day or a mental health awareness week, as a prompt to start the conversation
- When your team is under sustained stress or going through changes that affect well-being
- As part of regular check-ins, so mental health support doesn't only come up once a year
- After a long crunch or incident-heavy stretch, before the team settles back into normal work
## Tips and tricks
- Agree on ground rules for respectful discussion before anyone writes a note
- Remind everyone that sharing is optional and nobody needs to disclose personal information
- Have your company's mental health resources ready to share
- Keep the conversation moving toward changes the team can make, so it doesn't stay on problems
- Follow up privately with anyone who might need more support than a team session can give
## Icebreaker questions
- What's one small thing you did recently that helped your well-being?
- What's a wellness habit that has worked for you in the past month?
---
# Content Strategy Retrospective
URL: https://www.teamretro.com/retrospective-templates/content-strategy-retrospective/
A content strategy retrospective is a meeting where your content team looks back at what it published and how it got made. Traffic and engagement numbers tell you what happened. This conversation is where the team works out why, and what to do differently next quarter.
The board has four columns. Audience Engagement asks how well your content connected with the people it was meant for, using both metrics and the comments you've heard. Content Quality looks at accuracy, depth and fit with your brand guidelines. Channel Effectiveness compares where your content performed, from email and search to social and partner sites. Workflow Optimization covers the planning and production process: briefs, approvals, calendars and the handoffs between writers and designers.
Run it after a major campaign, at the end of each quarter, or before you change channels or audiences. Bring the numbers, but give equal room to what people noticed while doing the work, since that's usually where the fixes come from.
## Topics
- **Audience Engagement**: How well did our content land with our target audiences?
- **Content Quality**: How well did our content meet quality standards and expectations?
- **Channel Effectiveness**: How effective were our content distribution channels?
- **Workflow Optimization**: How can we improve our content planning and creation processes?
## When to use
- When you want to check whether your content strategy is working and where it falls short.
- After a major content initiative or campaign, to look at its impact and learn from it.
- At regular intervals, such as quarterly, to keep your strategy in line with your goals and audience.
- When new team members or stakeholders join, to share how things work and hear fresh perspectives.
- Before significant changes to your strategy, channels or target audiences.
## Tips and tricks
- Make it safe to give honest feedback about work people put a lot into.
- Use data to support observations, and give equal weight to what people saw and heard while doing the work.
- Ask someone to take notes on the main discussion points and action items.
- Invite people from teams that use or promote your content, such as sales or product, for a wider view.
- Celebrate what worked as well as discussing what didn't.
- Finish with a short list of actions, each with an owner.
## Icebreaker questions
- If our content strategy was a movie, what genre would it be and why?
- Share a recent piece of content (from any source) that you found particularly engaging or memorable, and explain what made it stand out.
---
# WRAP Retrospective
URL: https://www.teamretro.com/retrospective-templates/wrap-retrospective/
WRAP is a four-part retrospective named for its columns: Wishes, Risks, Appreciations and Puzzles. It's based on an idea by Nick Oostvogels, and it covers more ground than a two- or three-column retro without getting complicated.
Wishes is where people describe what they'd change in a perfect world, from small fixes to long-term hopes. Risks is for the threats that could derail the team, such as burnout, knowledge silos or growing technical debt. Appreciations gives people a place to thank colleagues and teams for specific help, and Puzzles collects the open questions nobody has answered yet.
Wishes and Risks point forward, while Appreciations and Puzzles cover where the team is now, which makes WRAP a good fit after a milestone or release. Finish by turning the biggest risks and puzzles into actions with an owner.
## Topics
- **Wishes**: Wishes for a perfect world going forward.
- **Risks**: Things that could bring chaos.
- **Appreciations**: People, teams or things you want to recognize.
- **Puzzles**: Questions that remain unanswered.
## When to use
- When you want recognition and problem-solving in the same session
- After completing a significant project milestone or release
- When the team needs to talk about opportunities and risks together
- When you want the team to think about what could go wrong next, not only what already did
## Tips and tricks
- Start with Appreciations so the team opens on what went right before the harder topics
- Keep a parking lot for items that need more discussion or don't fit any column
- Use dot voting to choose which items to discuss in detail when time is short
- Ask everyone to add something to every column so you hear from the whole team
- Split larger teams into small groups for the first round of brainstorming
- Finish with specific actions for the top risks and puzzles
## Icebreaker questions
- If you could have one wish granted for the team right now, what would it be?
- What's something you've been puzzled about lately that turned out to have a simple solution?
---
# Strategic Alignment Review
URL: https://www.teamretro.com/retrospective-templates/strategic-alignment-review/
A Strategic Alignment Review is a structured session where a leadership team checks whether its strategy still holds together. You look at the vision, the goals and priorities that follow from it, and whether the organization has what it needs to deliver, then agree on what to change.
The board has six columns. Vision asks whether your direction is still relevant. Goals checks that objectives are specific and achievable. Current Priorities looks at where effort and money are going and whether that matches the goals. Organizational Capabilities asks if you have the skills and processes to execute. Stakeholder Engagement covers customers, employees, partners, investors and regulators. Risks and opportunities closes on what could knock the plan off course and what you might be missing.
Running through the columns in order shows where the chain breaks: a vision nobody disputes but goals that don't follow from it, or priorities the organization can't staff. Run it during annual planning, after a merger or leadership change, or when a shift in your market makes last year's plan look shaky.
## Topics
- **Vision**: Is our strategic vision still relevant and inspiring?
- **Goals**: Are our strategic goals well-defined and achievable?
- **Current Priorities**: Are our strategic priorities clearly defined and aligned?
- **Organizational Capabilities**: Do we have the right capabilities to execute our strategy?
- **Stakeholder Engagement**: Are we engaging well with key stakeholders and keeping them on board?
- **Risks and opportunities**: Are we effectively identifying and mitigating risks and seizing opportunities?
## When to use
- During annual or twice-yearly planning, to review and reset the organization's priorities.
- When a market shift or a new competitor makes the current strategy look shaky.
- After a merger, acquisition or leadership change, to check the new organization is pulling in one direction.
- As part of a wider transformation program, to get agreement on direction at every level.
- Before launching a major initiative or entering a new market, to check you have what it takes to deliver.
## Tips and tricks
- Let people add notes anonymously before discussion, so junior voices aren't drowned out by senior ones.
- Bring data to the session, such as market research, customer feedback and performance metrics, so the discussion rests on evidence.
- Invite people from across functions who know where the capability gaps really are.
- Consider an outside facilitator if the leadership team is too close to the strategy to question it.
- End with clear actions and owners for each gap the review uncovers.
- Book follow-up sessions to track progress and catch new issues as the organization changes.
## Icebreaker questions
- If our organization were an animal, what animal would it be and why?
- If you could add one word to our organization's vision statement, what would it be and why?
---
# Organizational Communication Review
URL: https://www.teamretro.com/retrospective-templates/organizational-communication-review/
An Organizational Communication Review is a retrospective about how information moves through your team and the groups around it. It skips the usual "what went well this sprint" and asks a narrower question: where do messages, decisions and context get lost, and what would stop that happening?
The board has four areas. Communication Channels covers the tools you use, from email and chat to video calls and your project tracker. Information Flow looks at whether updates reach the right people in time. Collaboration and Feedback is about how the team works together and how honestly it gives feedback. Interpersonal Dynamics covers trust, friction and how disagreements get settled.
Run it when the same miscommunication keeps coming back, after a reorg changes who talks to whom, or once a quarter as a check on habits that drift. You'll finish with a short list of changes to channels and habits, each with an owner.
## Topics
- **Communication Channels**: How effective are our current communication channels?
- **Information Flow**: How well does information flow within and across teams?
- **Collaboration and Feedback**: How well do we collaborate and provide constructive feedback?
- **Interpersonal Dynamics**: How well do we navigate interpersonal dynamics and conflicts?
## When to use
- When the same communication breakdowns or misunderstandings keep coming up, inside the team or with other groups
- After a reorg or restructure that changed who talks to whom and through which channels
- As a quarterly or yearly check on communication habits, before small problems settle in
- When onboarding new people or merging teams, to agree on communication norms early
- When teams start working in silos or decisions arrive without any explanation
## Tips and tricks
- Have everyone add notes privately first, so candid points about communication aren't filtered by who's in the room
- Invite someone from each team you hand work to or receive work from, so you hear both ends of the handoff
- Keep notes anonymous when the topic touches managers or other departments; people are more candid that way
- Pick the top two or three issues and give each action an owner and a date
- Repeat the review every few months, because communication habits drift as the team and its tools change
- When a channel or habit works well, write it down and share it with other teams
## Icebreaker questions
- If our team was a communication channel, which one would it be and why?
- Share a funny or memorable miscommunication story from your experience.
---
# Mid-Year Retrospective
URL: https://www.teamretro.com/retrospective-templates/mid-year-retrospective/
Halfway through the year, there's still time to change course. The Mid-Year Retrospective gives your team a structured way to look at the first six months and decide what to focus on for the rest of the year, instead of saving the review for December.
The board has four columns. Wins to celebrate covers goals met and milestones reached, big and small. Challenges faced names the setbacks and blockers, with the focus on situations and systems. Lessons learned turns those two into advice the team would give its past self. Priorities for the second half is where the team agrees on a short list of goals, each with an owner.
Start by sharing the goals you set at the beginning of the year, so the discussion is anchored to real objectives. It works for a single team, a department or a cross-functional group, and fits well just before second-half planning begins.
## Topics
- **Wins to celebrate**: What achievements and progress are we most proud of so far?
- **Challenges faced**: What obstacles or setbacks slowed us down this year?
- **Lessons learned**: What insights have we gained that should guide us going forward?
- **Priorities for the second half**: What should we focus on to finish the year strong?
## When to use
- At the midpoint of the year, to check progress against annual goals and adjust before the second half.
- After a busy first half, when the team needs to celebrate wins and talk through the hard parts together.
- When priorities have shifted and you need everyone aligned on what matters for the rest of the year.
- As an alternative to waiting for an end-of-year review, while there's still time to change course.
## Tips and tricks
- Open by sharing the goals or themes you set at the start of the year, so reflections are anchored to real objectives.
- Start with wins before moving to challenges. Celebrating first makes it easier to talk honestly about what went wrong.
- Use anonymous brainstorming so quieter people and dissenting views come through, which reduces groupthink.
- Timebox each column so you reach planning instead of getting stuck in reflection.
- Close by turning priorities into actions with owners and due dates.
- Keep the priority list short. A handful of commitments is far more achievable than a long wish list.
## Icebreaker questions
- If the first half of your year had a movie title, what would it be?
- What is one word you'd use to describe your year so far, and why?
---
# Summer Adventure Retrospective
URL: https://www.teamretro.com/retrospective-templates/summer-adventure-retrospective/
Picture your team around a campfire at the end of a long hike, swapping stories about the peaks you reached, the trails that nearly beat you and the gear that saved the day. The Summer Adventure Retrospective runs your retro the same way, with the last sprint or quarter as the expedition.
The board has four columns. Sunny Summits is for the high points and wins. Rocky Trails holds the obstacles that slowed you down, like unclear requirements or a test environment that kept falling over. Trusty Gear is for the practices and tools that worked and are worth packing again. Next Destination is where you pick the experiments and improvements for the next leg, and it becomes your action list.
Trusty Gear is the column teams tend to skip in other formats, and it's what stops a good habit from quietly disappearing. Use this format at the end of a sprint or quarter, during the summer months, or any time morale is low and the team could use a lighter session that still ends in actions.
## Topics
- **Sunny Summits**: What high points did we reach this time?
- **Rocky Trails**: What obstacles slowed us down on the trail?
- **Trusty Gear**: What essentials worked well and should we keep?
- **Next Destination**: Where do we want to explore or improve next?
## When to use
- At the end of a sprint or project, when you want a themed change from your usual retrospective format.
- During the summer months, to give team reflection a seasonal feel.
- When engagement is low and you want a lighter way into an honest conversation.
- At a quarterly or milestone review, to look back on the trip so far and plan the next leg.
- For a team-building session where you still want the team to leave with actions.
## Tips and tricks
- Set a relaxed tone at the start with some summery visuals or a holiday-themed icebreaker.
- Timebox each column so you leave enough time to agree on actions.
- Use silent brainstorming before discussion so quieter team members get their ideas on the board.
- Keep Rocky Trails about obstacles and what you learned from them, not about who caused them.
- Turn the best Next Destination ideas into actions with owners and due dates.
- Open by checking the last retro's actions so the team can see what changed.
## Icebreaker questions
- If this past sprint were a vacation destination, where would it be and why?
- What's the one item you'd never leave behind on a summer adventure?
---
# Mountain Climber Retrospective
URL: https://www.teamretro.com/retrospective-templates/mountain-climber-retrospective/
The Mountain Climber retrospective frames your team's work as a climb. You start by agreeing where you are now (base camp), then look up the mountain at the obstacles in the way, the gear that will get you past them and what reaching the summit would actually mean.
Your team maps its progress the way mountaineers plan an ascent. Base Camp is an honest look at your current position. Obstacles Ahead lists the risks and challenges between you and the goal. Climbing Gear covers the tools, skills and support you have or need, and Summit Goals defines what success looks like at the top. Putting a vague goal on a mountain makes it concrete, and the team leaves with a shared picture of the route.
Because most of the board looks forward, the format suits teams on complex, long-term projects, or teams starting a new phase of work. It gets people thinking about the whole climb and about the next few steps, which is where most of the actions come from.
## Topics
- **Base Camp**: Where are we now on the climb?
- **Obstacles Ahead**: What challenges do we see on our path to the summit?
- **Climbing Gear**: What tools and resources will help us succeed?
- **Summit Goals**: What does success look like at the peak?
## When to use
- When the team needs to picture a long-term goal and break it into milestones it can reach
- After finishing a major project phase, to plan the next big challenge
- When morale needs a lift and a shared goal would give the team something to climb toward
## Tips and tricks
- Ask the team to think about both the next few steps and the summit goal
- Use the climbing metaphor to talk about how team members support each other on the hard stretches
- Keep a parking lot for ideas that belong to a later climb
- Focus on actions the team can take in the next sprint or phase
- Save each board so later sessions can look back at how far the team has climbed
## Icebreaker questions
- What's the most challenging goal you've ever achieved, and what helped you reach it?
- If you could climb any mountain in the world, which would it be and why?
---
# Team Icebreaker
URL: https://www.teamretro.com/retrospective-templates/team-icebreaker-retrospective/
The Team Icebreaker is a short warm-up you run before a meeting or retrospective. It takes your team through four rounds of light questions that get people talking, share a little about each other's lives, and help everyone arrive properly before the real work starts.
The rounds get gradually more personal without ever feeling like an interrogation. Set the Scene asks for one word on how people arrived. Share a Story invites a small win or fun moment from the week. Discover Common Ground asks what people want to learn or try this year, which often turns up shared interests. Look Ahead Together closes on what the team is looking forward to, which leads straight into your agenda.
Five to ten minutes is usually enough. It works best with new teams, remote teams who rarely meet in person, and before a hard conversation, when people need to hear each other's voices before they're asked to be candid. People who have just shared a laugh are more likely to speak up when the real discussion starts.
## Topics
- **Set the Scene**: What's one word to describe how you arrived today?
- **Share a Story**: What's a small win or fun moment from your week?
- **Discover Common Ground**: What's something you'd love to learn or try this year?
- **Look Ahead Together**: What are you most looking forward to as a team?
## When to use
- At the start of a meeting or retrospective, to get people present before the work begins.
- With a newly formed team that is still getting to know each other.
- With remote teams who rarely meet in person and need a reason to talk about more than work.
- When energy is low or people have stopped joining in.
- Before a difficult conversation, so everyone has spoken once before the hard part.
## Tips and tricks
- Keep it to five to ten minutes so the warm-up doesn't eat into the main agenda.
- Answer first yourself to show the level of openness you're after and put quieter people at ease.
- Ask everyone to take part, but never push anyone to overshare. Keep prompts low-stakes and optional.
- Match the questions to the team. A brand-new group may need gentler prompts than a team that's worked together for years.
- Point out shared interests as they come up.
- Rotate who picks the questions each session so different people shape it.
## Icebreaker questions
- If you could instantly master one skill for your next adventure, what would it be?
- What's the most memorable trip or expedition you've ever been on?
---
# Aussie Outback Escape Retrospective
URL: https://www.teamretro.com/retrospective-templates/aussie-outback-escape-retrospective/
Grab a backpack and head bush. The Aussie Outback Escape retrospective turns your sprint review into a trek across the red dirt: the ground your team covered, the watering holes that kept it going, the dangers lurking in the scrub and the horizon you're heading for next. It's a change of scenery from the standard retrospective, and the story gives people something to hang honest reflections on.
The board has four topics. Trails Blazed celebrates progress and wins. Watering Holes recognizes the practices, people and rituals that kept the team going. Dangers in the Scrub surfaces the risks and blockers that slowed you down. The Next Horizon turns all of it into specific actions. Talking about a problem as a snake on the trail is often easier than naming it outright, so quieter team members tend to contribute more.
Use it at the end of a long or tough sprint, or whenever your team needs a creative break from the usual format. Framing setbacks as part of an expedition keeps the tone light while still leaving room for candid conversation.
## Topics
- **Trails Blazed**: What progress and wins did we make this journey?
- **Watering Holes**: What kept us refreshed, supported and going strong?
- **Dangers in the Scrub**: What risks, blockers or hazards slowed us down?
- **The Next Horizon**: Where do we head next and what should we change?
## When to use
- When your team is tired of the same retrospective format and needs a different way in.
- At the end of a long or difficult sprint or project phase, to map the journey and reset.
- When you want a playful, metaphor-driven conversation that helps the team relax and open up.
- When you want to celebrate wins and still be honest about risks and blockers.
## Tips and tricks
- Set the scene with a short outback story so everyone is in the mood before they add notes.
- Timebox each stage so Dangers in the Scrub and The Next Horizon get as much time as the wins.
- Use anonymous brainstorming for Dangers in the Scrub so quieter or newer members feel safe raising hard truths.
- Group and vote before discussing, so the team spends its time on the highest-impact themes.
- Close by turning horizon ideas into owned action items with due dates.
- Keep the metaphor light. If it gets in the way of clarity, ask people to speak plainly.
## Icebreaker questions
- If you could survive the outback with only one item from your desk, what would it be and why?
- What's the most adventurous or unexpected place you've ever worked from?
---
# Witches and Warlocks Retrospective
URL: https://www.teamretro.com/retrospective-templates/witches-and-warlocks-retrospective/
The Witches and Warlocks Retrospective gives your sprint review a magical theme. It works well around Halloween, and the playful framing makes it easier for people to say what they'd change.
The board has five areas. Love Potion is for what the team loved about the last sprint. Magic Wand asks what you'd change if you had magical powers. The Perfect Spell turns those wishes into specific goals to aim for, and Crystal Ball looks further ahead at where the team wants to be. Owl is for shout-outs: thank-yous to the people who helped.
The theme keeps the mood light, but underneath it's a standard retrospective, so you still finish with actions. Use The Perfect Spell to pick the two or three goals worth committing to, and give each one an owner.
## Topics
- **Love Potion**: What did we love about the last sprint?
- **Magic Wand**: What do we want to transform?
- **The Perfect Spell**: What should we aim for?
- **Crystal Ball**: What do we see in our future?
- **Owl**: What shout-outs do we want to send?
## When to use
- When the team has retrospective fatigue and needs a change of scene
- Around Halloween, or any time you want a themed retro to break up the routine
- When you're introducing new team members to retrospectives and want the first one to feel relaxed
- When the team needs a nudge to think more freely about solutions
## Tips and tricks
- Use themed virtual backgrounds or a few sound effects to set the scene
- Invite people to describe their experiences in magical terms; it often makes hard feedback easier to say
- Keep the theme in proportion: it should get people talking, not take over the meeting
- Keep a spell book of action items and check it at the next retrospective to see what changed
- Give Owl its full time, since shout-outs are the first thing cut when a meeting runs long
- Rotate who facilitates each area so more people share ownership of the session
## Icebreaker questions
- If you could have any magical power to improve our team's work, what would it be and why?
- What's your favorite magical creature and how does it represent your role in the team?
---
# Fuel Shortage Retrospective
URL: https://www.teamretro.com/retrospective-templates/fuel-shortage-retrospective/
Running on empty? The Fuel Shortage retrospective treats your team's time, energy and motivation like fuel in a tank. It gives people a plain way to say what's using up their capacity and what puts it back, which makes it a good fit when the team is showing signs of burnout, stretched resources or a pace nobody can keep up.
The board has four columns. Fuel Drains is for the meetings, processes and situations that burn energy without giving much back. Fuel Sources is for what restores it. Conservation Strategies asks how to get the same results with less effort, and Refueling Actions turns the discussion into specific commitments. Everyone knows the worry of watching a fuel gauge drop, so the metaphor needs almost no explanation.
Use it when your team faces tight deadlines, limited resources or growing exhaustion. The aim is practical: by the end you'll have agreed on a few concrete changes to cut waste and protect energy, so the team has enough fuel to finish what it started.
## Topics
- **Fuel Drains**: What's consuming our energy and resources unnecessarily?
- **Fuel Sources**: What gives us energy and helps us perform at our best?
- **Conservation Strategies**: How can we use our limited resources more efficiently?
- **Refueling Actions**: What specific actions will help us replenish our energy?
## When to use
- Your team is showing signs of burnout, exhaustion or falling motivation, and you want to deal with it before it gets worse.
- The team is facing tight resources, deadlines or competing priorities that are stretching capacity to its limit.
- You've noticed falling productivity, more errors or people working long hours, and you want to find the causes.
- After an intense stretch, such as a major release, a crunch or an organizational change, you want to help the team recover.
- You need an honest conversation about workload, capacity and what's realistic with the people and time you have.
## Tips and tricks
- Say at the start that talking about fuel shortages is maintenance, not complaining. Running on empty helps no one.
- Give Fuel Sources as much time as Fuel Drains, so the team remembers what's working and what gives them energy.
- Ask for specific drains. "Meetings are draining" is hard to act on; "the 9am standup runs 30 minutes over and eats my morning focus time" is something you can fix.
- Pick two or three refueling actions and commit to those first. A tired team won't finish a long list.
- Check the conservation strategies and refueling actions at later retrospectives to see whether the team actually feels less drained.
- Bring in leadership when a drain is systemic or outside the team's control. Some resource problems need support from above to fix.
## Icebreaker questions
- If your energy level right now was a fuel gauge, where would the needle be pointing, and what would get you back to full?
- What's one thing outside of work that refuels you when you're running low on energy?
---
# Fantasy Quest Retrospective
URL: https://www.teamretro.com/retrospective-templates/fantasy-quest-retrospective/
The Fantasy Quest retrospective retells your sprint or project as a heroic expedition. Your team looks back at the treasures it gathered, the dragons it fought and the allies who helped, then looks ahead to the lands it hasn't reached yet. The story puts a little distance between people and the work, and that often makes it easier to say what really happened.
The board has four topics. Treasures Found holds the wins. Dragons Faced holds the problems and blockers. Fellow Adventurers is where you thank the people, inside and outside the team, who helped. The Road Ahead is for next steps and experiments. Under the theme these are familiar retrospective questions, so you still leave with a short list of actions.
Run it at the end of a sprint, after a milestone or when your team is tired of the usual "what went well, what didn't" board. It suits creative teams and community groups who like a bit of play, and the themed prompts give quieter people an easy way in.
## Topics
- **Treasures Found**: What wins did we collect on our quest?
- **Dragons Faced**: What challenges threatened our quest?
- **Fellow Adventurers**: Who helped us along the way and how can we thank them?
- **The Road Ahead**: What lands and quests await us next?
## When to use
- When your retros have gone stale and the team needs a different way in.
- At the end of a sprint, a major milestone or a finished project.
- When quieter team members need a playful prompt to start talking.
- With creative teams or community groups who enjoy a story-based format.
## Tips and tricks
- Set the scene first: ask everyone to picture the sprint as a quest before they add ideas.
- Keep the theme light. If someone prefers plain language, their ideas sit next to the themed ones just fine.
- Timebox each topic so the storytelling doesn't run long.
- In Dragons Faced, talk about problems, not people, so the discussion stays blame-free.
- Turn the strongest ideas from The Road Ahead into actions with an owner before you close.
- Rotate the facilitator so a different person plays the storyteller each time.
## Icebreaker questions
- If you were a character in a fantasy quest, would you be the warrior, the wizard, the rogue, or the healer, and why?
- What's one magical power you wish you had during the last sprint?
---
# Battlefield Strategy Retrospective
URL: https://www.teamretro.com/retrospective-templates/battlefield-strategy-retrospective/
The Battlefield Strategy retrospective borrows the language of military strategy and treats your sprint or project as a campaign: terrain to cross, enemies to outmaneuver and ground to take. Looking at the work through that lens helps your team see what helped it advance, what slowed it down and where to concentrate its forces next.
The board has four topics. Victories Won covers the wins and breakthroughs. Enemy Forces names the obstacles that fought back. Allies & Arsenal recognizes the people, processes and tools that gave you an edge. Battle Plan turns everything into the next set of moves. The metaphor pushes people toward systems thinking: instead of listing isolated issues, they talk about position, momentum and the alliances that decide whether the team gains or loses ground.
It's a good way to make a retrospective decisive. The framing gives quieter team members an easy way in and turns vague frustrations into specific decisions. In TeamRetro, you capture ideas, group them by theme, vote on priorities and finish with a clear plan of attack for the next iteration.
## Topics
- **Victories Won**: What battles did we win this campaign?
- **Enemy Forces**: What obstacles fought back against us?
- **Allies & Arsenal**: What support and tools gave us an edge?
- **Battle Plan**: What is our strategy for the next campaign?
## When to use
- When your team wants an energetic alternative to a standard sprint retrospective.
- After a major project or release with big challenges and big wins.
- When the team needs to think strategically about obstacles and prioritize where to focus next.
- To re-engage a team that has grown bored with routine retrospective formats.
- When you want to turn recurring frustrations into a concrete plan with owners.
## Tips and tricks
- Treat enemy forces as situations and systems, never individuals, so the conversation stays safe.
- Timebox each theme so the battle plan gets the time it deserves.
- Use dot voting to choose which obstacles to tackle first. You can't fight every battle at once.
- Give every action in the Battle Plan an owner and a target date.
- Invite quieter team members to contribute first, since the metaphor makes speaking up easier.
- Open by reviewing the last campaign's Battle Plan to see what advanced.
## Icebreaker questions
- If your team were a military unit, what would your battle cry be?
- Which historical or fictional commander would you want leading your next sprint, and why?
---
# Incident Response Retrospective
URL: https://www.teamretro.com/retrospective-templates/incident-response-retrospective/
An Incident Response Retrospective is a meeting held after an incident, or a run of them, to look at how your team responded. You review what happened, what helped, what got in the way and what to change, so the next response is faster and calmer.
The board has six topics. Incident Overview sets the context with a short summary of each incident. What Went Well and Areas for Improvement cover the response itself, from how quickly people mobilized to whether the monitoring caught the problem. Action Items turns the findings into specific changes, Lessons Learned captures the broader takeaways, and Stakeholder Feedback looks at how well you kept customers and colleagues informed.
Keep it blameless. The aim is to find the causes in your systems and processes, like a missing escalation path or out-of-date runbooks, not to find someone at fault. Run it soon after each significant incident, and on a regular schedule to spot patterns across incidents.
## Topics
- **Incident Overview**: What incidents occurred during the review period?
- **What Went Well**: What aspects of the incident response were effective?
- **Areas for Improvement**: What aspects of the incident response could be improved?
- **Action Items**: What specific actions can we take to improve our incident response capabilities?
- **Lessons Learned**: What lessons can we take away from this incident?
- **Stakeholder Feedback**: How can we improve communication and collaboration with stakeholders during incidents?
## When to use
- After a significant incident or security breach, to review the response and find what to improve.
- On a regular schedule, such as quarterly, to review incident response across several incidents.
- When introducing new technology, systems or processes that change how you respond to incidents.
- After a reorganization that affects incident response teams or processes.
- As part of an incident response training and preparedness program.
## Tips and tricks
- Keep it blameless so people describe what really happened, including their own mistakes.
- Invite people from every team involved in the response, plus key stakeholders.
- Bring data from the incident, such as timelines, alerts and time to resolve, to back up what people say.
- Rank the action items by likely impact and how easy they are to put in place.
- Give every improvement an owner and a deadline.
- Start by checking the action items from your last incident retrospective.
## Icebreaker questions
- If you could have a superpower to help with incident response, what would it be and why?
- Share a funny or memorable incident response experience (without revealing sensitive information).
---
# Year in Review Retrospective
URL: https://www.teamretro.com/retrospective-templates/year-in-review-retro-retrospective/
The end of a year is a good time to stop and look at the whole thing, not only the last sprint. The Year in Review Retrospective gives your team a structured way to look back across twelve months, recognize the milestones that mattered and agree on what to carry into next year.
The board has three areas. Highlights & Wins is for the proudest moments, from big releases to personal growth. Lessons Learned covers what the year taught the team, including the hard parts and the mistakes. Goals for Next Year turns those lessons into specific ambitions. Everyone adds ideas privately first, then the team groups them, votes and discusses the themes that come up most.
It works for product teams, leadership groups and communities alike. Send a prompt a few days before so people can think back to January, and export the board afterward so you have a record of the year to revisit next December.
## Topics
- **Highlights & Wins**: What were our proudest moments this year?
- **Lessons Learned**: What did we learn that we'll carry forward?
- **Goals for Next Year**: What do we want to achieve in the year ahead?
## When to use
- At the end of a calendar or fiscal year, to look back on the past twelve months and set direction for the next.
- When the team has finished a major program or initiative and wants to capture the big-picture lessons.
- To reconnect a team after a long, demanding stretch of work.
- When new leadership joins and wants to understand the team's recent history.
- For communities or organizations that want to celebrate what they achieved together and agree on shared goals.
## Tips and tricks
- Send a prompt a few days ahead so people can think back over the whole year. Memories from January fade fast.
- Start with Highlights & Wins; a positive opening makes the honest conversation about lessons easier.
- Timebox each area so reminiscing doesn't eat the time you need for next year's goals.
- Give everyone quiet time to add ideas privately before the group discussion, so every voice gets on the board.
- Turn Goals for Next Year into clear actions with owners, so the plan survives January.
- Export the board or write a short summary so the team has a record of the year to look back on.
## Icebreaker questions
- If you could sum up your year in a single emoji, which one would it be and why?
- What's one song that would be on the soundtrack of your past year?
---
# Aussie Rules (AFL) Retrospective
URL: https://www.teamretro.com/retrospective-templates/afl-retrospective/
The AFL Retrospective borrows the language of Australian Rules football for your team's retro. Footy clubs review every match, and this format asks your team to do the same with its last sprint or project, using terms most Australians already know.
The board has four columns. Premiership Cup is the big goal: what does winning look like for the team? Goals is for what you achieved, and Tackles is for the obstacles that brought you down. Brownlow Nomination, named after the medal for the AFL's best and fairest player, is where people call out a teammate who played well. Because recognition has its own column, the session gives individual credit as well as covering the team's results.
It goes down best in Australian workplaces and with sports-minded teams, who get the metaphors without explanation. For everyone else, a two-minute primer on the four terms is enough to get started.
## Topics
- **Premiership Cup**: What are we striving to achieve?
- **Goals**: What did we achieve?
- **Tackles**: What obstacles and roadblocks did we encounter?
- **Brownlow Nomination**: Who has performed well?
## When to use
- With teams who follow sport, and Aussie Rules in particular.
- When your regular retros have gone flat and a familiar sporting metaphor would get people talking.
- When you want a retro that recognizes individual effort as well as team results.
- At the end of a season, project or quarter, when the team wants to look at the big goal again.
## Tips and tricks
- Explain the four terms before you start for anyone who doesn't follow the AFL.
- Keep the footy talk light. The metaphors are there to get people talking, not to take over the retro.
- Make sure everyone gets a kick. A team that only goes through one or two players doesn't win many matches.
- Use AFL imagery or the team's colors on the board to set the mood.
- Keep Tackles about problems, not people, so it doesn't turn into a blame game.
- Rotate the team captain role, so a different person facilitates each retro.
## Icebreaker questions
- If our team was an AFL team, what would be our team colors and why?
- What's your most memorable moment of teamwork, either in sports or at work?
---
# Post-Mortem Retrospective
URL: https://www.teamretro.com/retrospective-templates/post-mortem-retrospective/
A post-mortem retrospective is a blame-free review of an incident, project or release after it's over. Your team works out what happened, why it happened and what should change, so the same problem doesn't come back. It works for production incidents and outages, and just as well for a missed deadline or the close of a major initiative.
The board has four columns. Root Causes starts with the timeline: the team lays out what happened and when, before anyone analyzes it, so everyone works from the same facts. What went well? captures what helped, such as alerts that fired quickly or a rollback that worked. What went wrong? covers the gaps and friction that made things worse. Action items turns the discussion into specific fixes with an owner and a date. In TeamRetro, everyone adds observations at the same time, groups related ones, votes on the issues with the most impact and assigns follow-up actions before the meeting ends.
Blameless post-mortems are standard practice in site reliability engineering and incident management. When the team treats a failure as information about the system and not as someone's fault, people describe what really happened, and that's how you find the weak spots in a process. Keep the write-up, and you'll have a record to check the next time something similar breaks.
## Topics
- **Root Causes**: How would you describe the timeline of events?
- **What went well?**: What worked and helped us respond effectively?
- **What went wrong?**: Where did things break down or fall short?
- **Action items**: What will we do to prevent this in future?
## When to use
- After a production incident or outage, to understand the cause and stop it happening again
- At the close of a major project or release, to capture lessons while the details are fresh
- When a deadline was missed or an initiative fell short and the team needs an honest review
- When the same problem keeps coming back and you want to find its real cause
- When you want your teams to treat failures as something to learn from, not someone to blame
## Tips and tricks
- Say up front that the session is blameless, so people feel safe describing what really happened
- Build a shared, factual timeline before anyone starts analyzing
- Use the Five Whys to get past the symptoms to the underlying cause
- Give every action item an owner and a due date so it actually gets done
- Invite the people who were involved, but keep the group small enough to stay focused
- Write up the outcome, and check past action items in later sessions to confirm the fixes stuck
## Icebreaker questions
- What's the most memorable 'oops' moment you've had that turned into a great lesson?
- If this incident were a movie title, what would you call it?
---
# Leadership Effectiveness Retrospective
URL: https://www.teamretro.com/retrospective-templates/leadership-effectiveness-retrospective/
Leadership teams rarely review their own performance the way they ask delivery teams to. The Leadership Effectiveness Retrospective gives a leadership group a structured session to do that, from the wins it can point to through to the way it makes decisions together.
The board has five columns. Our Achievements is for the initiatives and decisions that went well. Areas for Improvement names what the team could do better, with specific examples. Strategic Alignment checks whether recent decisions matched the organization's goals or pulled away from them. Stakeholder Feedback asks how well the team listened to employees, customers, partners and shareholders before deciding. Team Dynamics looks inward, at trust, debate and how disagreements get resolved.
Senior people often hold back in front of peers, so anonymous input matters more here than in most retros, and an outside facilitator can help. End with a small number of commitments the leadership team will report back on.
## Topics
- **Our Achievements**: What were our most significant accomplishments as a leadership team?
- **Areas for Improvement**: What aspects of our leadership could we improve?
- **Strategic Alignment**: Did our actions and decisions match the organization's vision and goals?
- **Stakeholder Feedback**: How well did we incorporate feedback from key stakeholders into our decisions?
- **Team Dynamics**: How well did we work together and use each other's strengths?
## When to use
- When the leadership team wants to step back and look honestly at how it's performing together.
- After a major project, initiative or organizational change, to review how the leadership team handled it.
- On a regular rhythm, such as quarterly or once a year, so problems in the team surface early.
- When new members join the leadership team, to agree on expectations and how you'll work together.
- During a restructure or other transition, to check the leadership team is still aligned.
## Tips and tricks
- Make it safe to be candid. Agree up front that the session is about how the team works, not a performance review of any one person.
- Make sure every voice is heard, regardless of seniority or tenure on the leadership team.
- Push for specific examples and solutions instead of dwelling on past mistakes or assigning blame.
- Consider an external facilitator or coach, so the most senior person isn't also running the session.
- Follow up on the actions at your next leadership meeting, and share progress with the wider organization where it makes sense.
- Celebrate what went well, then spend most of the time on what to change.
## Icebreaker questions
- If our leadership team were a famous band or musical group, which one would we be and why?
- Share a leadership lesson or experience that has significantly shaped your approach as a leader.
---
# Design Team Retrospective
URL: https://www.teamretro.com/retrospective-templates/design-team-retrospective/
Good design depends on how a team works together as much as on pixels and prototypes. The Design Team Retrospective gives designers, researchers and design leads time away from delivery to look at their craft and how they work together. It asks about the quality of design outcomes and the health of your critique culture, as well as the systems that support or slow down creative work.
Each person adds reflections under four topics: design wins, friction points, craft and quality, and ideas to try. That covers strong decisions worth repeating, friction in handoffs and reviews, and chances to improve the design system and tooling. Grouping and voting in TeamRetro take the team from scattered observations to a short list of priorities, and from there to actions someone owns. Anonymous input means quieter designers and critical feedback still get heard.
The aim is better design work and a better design practice. Product design teams inside agile squads, brand studios and UX research groups can all use this design retrospective to agree on craft standards and work more smoothly with engineering and product. Run it at the end of a design sprint, after a major launch or on a regular cadence.
## Topics
- **Design Wins**: Which design decisions or outcomes are we proud of?
- **Friction Points**: Where did our design process or collaboration slow down?
- **Craft & Quality**: How can we raise the bar on our design craft?
- **Ideas & Experiments**: What should we try to improve how we work?
## When to use
- At the end of a design sprint or major project, to review what worked in the design process and what didn't.
- After a big launch, to capture lessons about craft, handoffs and collaboration.
- On a regular cadence, to keep critique healthy and keep raising design quality.
- When friction with engineering or product is hurting design outcomes.
- When you're onboarding new designers or changing your design system and need agreement on standards.
## Tips and tricks
- Critique the work, not the person. Specific, kind feedback keeps the creative culture healthy.
- Use anonymous input so quieter designers can raise criticism without worrying about stepping on toes.
- Invite engineers and PMs now and then to deal with handoff friction directly.
- Timebox each topic and vote, so the discussion goes to the biggest themes instead of every comment.
- Close with clear actions that someone owns, and review them at the start of the next retro.
- Give design wins as much time as problems so the session doesn't feel like a list of complaints.
## Icebreaker questions
- If your design style were a font, which one would it be and why?
- What's one piece of design (an app, poster, or product) that's caught your eye recently?
---
# Baseball Retrospective
URL: https://www.teamretro.com/retrospective-templates/baseball-retrospective/
The Baseball Retrospective borrows the language of America's favorite pastime to help your team look back on its work. Home Runs are the big successes. Strikes are the missed opportunities. Curveballs are the unexpected challenges that threw you off, and Batter Up is the next play: the actions you'll take into the next sprint.
Most people know the basic terms, so the metaphor needs little explanation, and it gives the session a lighter feel without losing focus. Calling a miss a strike makes it easier to raise than calling it a failure. Separating strikes (things you could have done better) from curveballs (things that came at you) also helps the team see which problems it controls.
It works well for teams who enjoy sports analogies, or any team that wants a change from its regular retrospective. If some people don't follow baseball, a one-line explanation of each topic is enough.
## Topics
- **Home Runs**: What were some great outcomes?
- **Strikes**: What did we miss?
- **Curveballs**: What was tricky?
- **Batter Up**: What should be our next play?
## When to use
- When you want a retrospective that the sports fans on your team will enjoy
- After a major project milestone or release, to review how the team performed
- When your regular retrospective format has gone stale
- When you want to separate the misses the team controlled from the surprises it didn't
- When morale is low and a lighter format would help people open up
## Tips and tricks
- Keep the metaphor simple. Stick to the four core terms and don't force every baseball phrase to fit
- Baseball visuals or sound effects can set the mood if your team enjoys them
- Rotate who opens each topic so everyone gets a turn to lead the discussion
- Give people a quiet minute in the dugout to think before they share
- Keep a scorecard of action items and check it at the next retrospective
- Explain each term in a sentence so people who don't follow baseball aren't left out
## Icebreaker questions
- If your last sprint was a baseball game, what position would you have played and why?
- What's your favorite sports memory that taught you something about teamwork?
---
# Social Media Retrospective
URL: https://www.teamretro.com/retrospective-templates/social-media-retrospective/
A Social Media Retrospective is a team meeting to review your social media activity, campaigns and results over a period, such as a quarter or a single campaign. It gives the people who plan, post and report on your channels a set time to look at what's working and agree on what to change.
The board has four areas. "What went well?" is for the campaigns and posts that worked, backed by numbers where you have them. "What could be improved?" covers what underperformed. "What should we start doing?" collects new tactics and platforms to try, and "What should we stop doing?" is for the activities that no longer earn their place.
Bring the data: reach, engagement and conversion numbers keep the discussion grounded, while the team's own observations explain why a post landed or didn't. Run it at the end of a campaign or quarter, around a product launch, or after a big platform change.
## Topics
- **What went well?**: Which social media activities or campaigns were successful?
- **What could be improved?**: Which areas of our social media efforts need attention?
- **What should we start doing?**: What new strategies or tactics should we explore?
- **What should we stop doing?**: Which activities or tactics no longer work or fit our goals?
## When to use
- At the end of a marketing campaign or quarter, to review performance.
- Around a product or service launch, to see how your social strategy is working and adjust it.
- After a big platform change, such as a new algorithm or feature, to rethink your approach.
- On a regular schedule, such as quarterly or twice a year, so your strategy keeps up with your results.
## Tips and tricks
- Make it safe to give honest feedback about content people worked hard on.
- Bring data and metrics to support observations, and add the team's qualitative feedback.
- Assign a note-taker to capture the main insights and actions.
- Invite people from marketing, customer service and product for a wider view.
- Agree on what the retrospective should decide before you start, so the discussion stays focused.
- Follow up on actions at the next session and check whether each change was made.
## Icebreaker questions
- If our brand was a social media influencer, what type of content would they create?
- Share a recent social media trend or meme that caught your attention. How could we use it for our brand?
---
# Project Wrap Up Retrospective
URL: https://www.teamretro.com/retrospective-templates/project-wrap-up-retrospective/
A Project Wrap Up Retrospective is the meeting you hold when a project, epic or major initiative is finished. Your team looks back across the whole project, from kickoff to delivery, and works through five topics: successes, challenges, lessons learned, process improvements and team dynamics.
This kind of project retrospective is where lessons get written down before people scatter to new work. Talk through what went well, what didn't go to plan and what you'd do differently, then turn the useful lessons into a short list of changes with owners. Skip that step and the next project tends to repeat the same estimation misses and handoff problems.
It suits agile teams finishing long or complex projects, and it gives you a clean handover point: the lessons you agree on here become the starting checklist for whatever comes next.
## Topics
- **Successes and Wins**: What went particularly well during this project?
- **Challenges and Obstacles**: What were the biggest hurdles or pain points?
- **Lessons Learned**: What did we learn that we'd use again?
- **Process Improvements**: Which practices should we change or start using?
- **Team Dynamics and Culture**: What would make this team better to work in?
## When to use
- At the end of a major project, epic or initiative, while the details are still fresh.
- When moving to a new phase or project, to carry lessons from the last one forward.
- On a regular cadence (quarterly or yearly, for example) to review the projects you've completed.
- After a project hit serious problems, to find the root causes and what would prevent them next time.
## Tips and tricks
- Agree up front that the review is about the work, not about blaming people.
- Have someone outside the project facilitate, so the project lead can take part as a team member.
- Use anonymous input if the project was tense, so the hard feedback still comes out.
- Leave with two or three actions, each with an owner, instead of a long list of lessons.
- Name the people and moments that carried the project. Specific thanks lands better than general praise.
- Bring the actions to the next project's kickoff so the lessons get used.
## Icebreaker questions
- If this project were a movie, what genre would it be and why?
- Share a fun or memorable moment from this project that brought the team together.
---
# The Good Gardener Retrospective
URL: https://www.teamretro.com/retrospective-templates/the-good-gardener-retrospective/
The Good Gardener Retrospective uses the planting cycle to look at your team's work. The board has three columns: Sow for new ideas and experiments you want to start, Grow for practices already underway that need more care, and Harvest for the results you've already gained.
Thinking in seasons suits teams working on longer-term improvement. Not every idea pays off within a sprint, and the Grow column gives you a place to keep backing something that's showing promise before it has results to point to. It also makes it easier to admit that some seeds won't come up.
Because the columns run from first idea to finished result, the conversation covers both where the team is investing its effort and what that effort has returned. That helps when the team feels busy but can't say what it has to show for it.
## Topics
- **Sow**: What should we start or experiment with?
- **Grow**: What do we want to continue investing in?
- **Harvest**: What have we gained?
## When to use
- When you want to talk about longer-term improvement, not only the last sprint
- During organizational change, when you need to balance new initiatives against work already underway
- When the team needs a fresh way to look at its progress
- When you have several experiments running and need to decide which ones to keep backing
## Tips and tricks
- Explain the three stages with a quick gardening example so everyone knows what belongs in each column
- For each Sow item, ask what it needs to take root, whether that's time, people or tools
- Give Grow items more than one sprint before you judge them. Some take longer to show results
- If your team's work has seasons, such as a release cycle or a busy quarter, use them to decide when to sow and when to harvest
- Accept that some seeds won't grow. A dropped experiment still taught the team something
## Icebreaker questions
- If your team were a garden, what kind of plant would each person be and why?
- What's your favorite season, and how does it reflect your approach to work?
---
# Easter Egg Hunt Retrospective
URL: https://www.teamretro.com/retrospective-templates/easter-egg-hunt-retrospective/
The Easter Egg Hunt Retrospective turns a look back at a sprint, project or quarter into a hunt. Your team searches for four kinds of egg: good eggs for wins worth celebrating, cracked eggs for what went wrong, golden eggs for the unexpected delights, and eggs still hidden for the opportunities you haven't chased yet.
Framing feedback as things people found, instead of answers to pointed questions, makes it easier for quieter team members to join in. Once the eggs are collected, group them in TeamRetro, vote on the ones that matter most and turn the best finds into actions with owners.
It suits the Easter season, but it works any time your retros feel a little stale and the team could use a lighter session that still deals honestly with problems.
## Topics
- **Good Eggs**: What went well and deserves to be celebrated?
- **Cracked Eggs**: What broke, went wrong, or caused frustration?
- **Golden Eggs**: What pleasant surprises or unexpected wins did we find?
- **Eggs Still Hidden**: What opportunities or next steps are waiting to be found?
## When to use
- Around Easter, when you want a seasonal theme.
- When energy in retros has dropped and you want a lighter format.
- After a sprint or project, to celebrate wins while still being honest about problems.
- When you want a low-pressure way to get quieter team members contributing.
- At the end of a quarter or milestone, to balance celebration with planning ahead.
## Tips and tricks
- Open with a short, light intro to the theme so people relax into the metaphor.
- Timebox each hunt so you don't spend too long in any one basket.
- Start with Good Eggs and Golden Eggs before you get to Cracked Eggs.
- Group similar eggs and use dot voting to focus on the finds that matter most.
- Close by turning the best Eggs Still Hidden into actions with owners, so the hunt leads to change.
- Keep Cracked Eggs blameless. Talk about the process, not the person.
## Icebreaker questions
- What's the best hidden treasure or unexpected gift you've ever stumbled upon?
- If you could hide one 'golden egg' surprise for your team, what would be inside it?
---
# Mad Sad Glad Retrospective
URL: https://www.teamretro.com/retrospective-templates/mad-sad-glad-retrospective/
The Mad Sad Glad retrospective looks at how your team felt during the last sprint, which makes it a good way to spot what's helping or hurting morale and job satisfaction. Each person shares what frustrated or annoyed them (mad), what disappointed them (sad), and what made them happy or proud (glad).
Talking about feelings out loud makes your team more aware of how the work lands on each other, and it shows familiar problems from a different angle. Start by reading out the retrospective prime directive, and keep the conversation on events, behaviors and processes, not on blaming or guilting individuals.
Run a mad sad glad retro every few sprints and you'll notice when the mood shifts before it becomes a bigger problem. Patterns in the mad and sad columns usually point at the process fixes worth making, and the glad column tells you what to protect.
## Topics
- **Mad**: What is driving you crazy?
- **Sad**: What is disappointing you?
- **Glad**: What is making you happy?
## When to use
- After a sprint or project, when you want an open conversation about how the work felt.
- When frustrations are building and you want them raised constructively, not in side conversations.
- When the team has done good work that deserves to be called out.
- When morale feels off and you want to find out why.
- When you want every perspective heard in a format that feels safe.
## Tips and tricks
- Read out the prime directive first so people know this isn't about blame.
- Get input from everyone, including introverts and new hires. Silent writing before discussion helps.
- Look for patterns and root causes behind the frustrations and disappointments.
- Don't get defensive or explain away a 'Mad' item. Ask questions until you understand it.
- Capture the main points and actions, but don't try to solve every issue in one retro.
- Finish with the 'Glad' column so the meeting ends on what's working.
## Icebreaker questions
- If you could add one 'rule' that everyone had to follow, what would it be?
- What's the most 'mad', 'sad', or 'glad' movie you've seen recently?
---
# Hopes & Fears Retrospective
URL: https://www.teamretro.com/retrospective-templates/hopes-and-fears-retrospective/
The Hopes and Fears retrospective asks your team two questions about an upcoming project, change or initiative: what do we want to happen, and what don't we want to happen? Everyone writes their own answers first, so the quiet worries get onto the board alongside the excitement.
The board has two columns, Hopes and Fears. Hopes shows what people are looking forward to, which often turns into shared goals. Fears shows the risks people can already see, from not having enough resources to burning out before the deadline. Grouping similar notes shows which concerns are widely shared, and those are the ones to plan around first.
Run it at the start of a project or during a period of change, while there's still time to act on what you hear. Saying a fear out loud in front of the team takes some trust, and seeing others share the same worry builds more of it.
## Topics
- **Hopes**: What do we want to happen?
- **Fears**: What don't we want to happen?
## When to use
- When kicking off a new project or initiative, to understand how the team feels and deal with concerns early
- During organizational change, to bring worries into the open while there's still time to address them
- Before a significant process change, to gather input and get the team on board
- When morale seems low and you want to understand what's behind it
## Tips and tricks
- Start with Hopes to set a positive tone, then move to Fears
- Group similar notes to see which hopes and fears are widely shared
- Create specific actions that address the biggest fears and support the strongest hopes
- Revisit earlier hopes and fears in later retrospectives so the team can see what changed
- Use round-robin sharing so quieter team members get a turn
- Keep the discussion on what the team can do, not on how bad things might get
## Icebreaker questions
- What was your biggest fear that turned out to be not so scary after all?
- What's one hope you had that came true in your career?
---
# DevOps Retrospective
URL: https://www.teamretro.com/retrospective-templates/devops-retrospective/
DevOps (a portmanteau of "development" and "operations") is a set of practices and tools that help an organization deliver applications and services faster than traditional software development processes. A DevOps retrospective brings developers and operations people into one meeting to look back at recent releases, incidents and the way they worked together.
The board has four columns. Successful Deployments covers what went well in recent releases. Areas for Improvement collects the problems, from gaps in automated testing to missing runbooks. Collaboration and Culture looks at how dev and ops work together, including on-call, handoffs and postmortems. Tools and Processes is for changes to your pipeline, infrastructure and monitoring.
Run it after a major release or outage, or on a regular monthly or quarterly schedule. Keep it blameless so people talk about what really happened, and leave with a few changes that each have an owner. The next round of deployments will tell you whether they worked.
## Topics
- **Successful Deployments**: What went well during recent deployments?
- **Areas for Improvement**: What challenges did we face, and how can we do better?
- **Collaboration and Culture**: How can we improve teamwork and build a DevOps culture?
- **Tools and Processes**: How can we optimize our tools, technologies, and processes?
## When to use
- After a major release or deployment, to review how it went.
- Every month or quarter, to keep improving how you build and run software.
- When the same bottlenecks or failures keep showing up in your build and deployment pipeline.
- After you introduce new tools, technologies or processes, to check whether they're helping.
- After a significant incident or outage, to find root causes and agree on prevention.
## Tips and tricks
- Keep it blameless so people share what really happened during incidents and deployments.
- Invite both development and operations. Each side sees problems the other doesn't.
- Spend most of the time on what to change, and only enough on past mistakes to understand them.
- Give every agreed action an owner and a date.
- Name the people behind smooth releases and incident fixes. That work often goes unnoticed.
- Change the format now and then so the retrospective doesn't go stale.
## Icebreaker questions
- If you could automate one manual task, what would it be and why?
- Share a recent 'aha' moment or learning experience related to DevOps practices.
---
# Friday the 13th Horror Sprint Retrospective
URL: https://www.teamretro.com/retrospective-templates/friday-the-13th-horror-sprint-retrospective/
Every sprint has its jump scares, its lurking monsters and a few survivors who lived to tell the tale. The Friday the 13th Horror Sprint Retrospective gives your team review a horror-movie theme. Setbacks become frights and wins become survivors, and that small shift makes uncomfortable issues easier to say out loud.
The board has four topics. The Frights is for what scared you or went badly wrong. The Survivors is for what went well and got you through. Lurking Monsters covers risks and problems that haven't struck yet, and Protective Spells is where the team agrees on improvements for next sprint. The theme keeps the mood light, so people are less defensive about the hard topics.
Under the costumes it's a full retrospective: you surface hidden risks, recognize the people who held things together and leave with actions that have owners. Run it around Halloween, on an actual Friday the 13th, or any time your team needs a break from the usual format.
## Topics
- **The Frights**: What scared us or went terribly wrong this sprint?
- **The Survivors**: What went well and helped us live to tell the tale?
- **Lurking Monsters**: What risks or problems are still hiding in the shadows?
- **Protective Spells**: What actions or improvements will keep us safe next sprint?
## When to use
- Around Halloween or on an actual Friday the 13th, when you want a seasonal twist on your usual sprint review.
- When your retrospectives have become routine and the team needs a different format to get people talking.
- After a chaotic or difficult sprint, when a playful theme helps the team discuss tough issues without getting defensive.
- When you want to celebrate wins and also flush out hidden risks before they turn into real problems.
## Tips and tricks
- Set the mood with costumes, virtual backgrounds or eerie music.
- Use the metaphor, but make sure each fright and monster maps to a real problem the team can act on.
- Timebox each topic so the fun doesn't run away with you and you still reach Protective Spells.
- Tell the team the horror framing is there to make scary or sensitive issues easier to raise without blame.
- Give everyone time to add ideas on their own before grouping and discussing, so quieter voices aren't drowned out.
- Finish by giving each Protective Spell an owner and a due date so the improvement actually happens.
## Icebreaker questions
- If this sprint were a horror movie, what would its title be and who would be the first to go?
- What's the scariest bug, outage or surprise you've ever survived at work?
---
# Ice Cream Dream Sprint Retrospective
URL: https://www.teamretro.com/retrospective-templates/ice-cream-dream-sprint-retrospective/
Looking for a lighter way to look back on your last sprint? The Ice Cream Dream Sprint retrospective turns it into a dessert menu. Your team names the sweet wins, the melting messes, the toppings that made things better and the new flavors it wants to try next.
Each topic maps to a familiar retrospective question. The Sweet Scoops is what went well. The Melting Mess is what slowed you down. The Tasty Toppings covers the tools, people and habits that helped, and New Flavors to Try is where you pick experiments for the next sprint. The imagery takes the edge off, so people tend to be more candid and less defensive about the messes.
It's a good pick when your sprint retrospectives have started to feel the same every time, or when the team needs a lighter meeting after a hard sprint. In TeamRetro you brainstorm, group and vote together, then turn the best new flavors into actions for the next iteration.
## Topics
- **The Sweet Scoops**: What went really well and tasted great this sprint?
- **The Melting Mess**: What turned into a sticky mess or slowed us down?
- **The Tasty Toppings**: What extras or support made things better and sweeter?
- **New Flavors to Try**: What new ideas or experiments should we taste next?
## When to use
- When your regular sprint retrospectives feel repetitive and you want a themed change of pace.
- After an intense or stressful sprint, when a lighter tone helps the team reflect honestly without getting defensive.
- When onboarding new team members and you want a welcoming, low-pressure way to hear from everyone.
- For end-of-quarter or celebratory retros, when you want to recognize wins and still plan improvements.
## Tips and tricks
- Set the theme early with an ice cream image in the intro so people relax into the playful tone.
- Timebox each topic so the fun doesn't crowd out the substance, and leave enough time to agree on actions.
- Remind quieter team members that even a small scoop of feedback is worth adding.
- Keep The Melting Mess focused on issues and systems, not individuals.
- Vote on New Flavors to Try so the team commits to a realistic number of experiments.
- Close by giving each action an owner. A themed retro still needs follow-through.
## Icebreaker questions
- If this sprint were an ice cream flavor, what would it be and why?
- What's your all-time favorite ice cream topping, and what does it say about your work style?
---
# Cyber Security Ops Retrospective
URL: https://www.teamretro.com/retrospective-templates/cyber-security-ops-retrospective/
The Cyber Security Ops retrospective brings your security operations team together to look back at the last cycle: what you detected, how you responded and how you recovered. It's written for SOC analysts, incident responders, threat hunters and security engineers who want the lessons from alerts, incidents and near-misses to turn into fixes.
The board has four columns. Threats & Incidents sets out what happened. Controls & Wins records the tools and processes that worked. Gaps & Vulnerabilities covers the blind spots and weaknesses that showed up. Actions & Hardening is where you agree what to change, with an owner for each item. If you already work with MITRE ATT&CK or NIST CSF, map findings to them so you can track progress from one cycle to the next.
Keep it blameless. People will only talk about the alert they missed or the near-miss they caused if they know the discussion is about systems and process. Run it after a major incident, at the end of an on-call rotation or on a regular schedule, and check last cycle's actions before you add new ones.
## Topics
- **Threats & Incidents**: What threats or incidents did we handle this cycle?
- **Controls & Wins**: Which defenses, tools, or processes worked well?
- **Gaps & Vulnerabilities**: Where did we have blind spots or weaknesses?
- **Actions & Hardening**: What will we do to improve our security posture?
## When to use
- After a significant security incident or breach, to capture lessons without blame.
- At the end of an on-call or SOC shift rotation, to review the alerts and handovers.
- Every month or quarter, to track recurring gaps and whether last cycle's fixes held.
- After a tabletop exercise, red team engagement or penetration test, to agree on what the findings mean for your team.
- When you've rolled out new SecOps tooling or practices and want to check they're working.
## Tips and tricks
- Keep it blameless. Talk about systems and processes, not individuals, so people admit to mistakes and near-misses.
- Map findings to a framework such as MITRE ATT&CK or NIST CSF so improvements are easy to track over time.
- Invite analysts, responders, engineers and a manager. Each role sees blind spots the others miss.
- Have people add notes privately or anonymously first, so junior analysts can flag problems without deferring to seniority.
- Timebox each column and keep the last part of the session for turning gaps into actions with owners and dates.
- Track actions from one retrospective to the next so recurring vulnerabilities don't quietly carry over.
## Icebreaker questions
- If you were a hacker for a day, what would be your weapon of choice and why?
- What's the most creative phishing attempt you've ever seen, and did it almost work?
---
# Technical Debt Retrospective
URL: https://www.teamretro.com/retrospective-templates/technical-debt-retrospective/
A Technical Debt Retrospective is a focused session where your team maps the debt in its codebase or system, agrees on what it's costing, and decides what to pay down first. It ends with a plan that has owners and dates.
Technical debt is the build-up of shortcuts and less-than-ideal solutions in a codebase. Some of it comes from choosing short-term delivery over long-term quality, some from gaps in understanding, and some from refactoring that kept getting pushed back. Left alone, it makes every change slower and riskier.
The board has four columns. Sources of Debt is where people name the specific problem areas: tangled modules, duplicated code, missing tests, outdated frameworks. Impact and Risks covers what that debt is doing to delivery, quality, onboarding and morale. Prioritization ranks the items by impact, effort and importance. Action Plan turns the top items into work with owners, timelines and check-ins, such as a fixed share of each sprint set aside for paydown. Run it every quarter or so, or whenever the team feels debt is slowing it down, so the debt stays visible and small.
## Topics
- **Sources of Debt**: What areas of the codebase have accumulated technical debt?
- **Impact and Risks**: How is this technical debt impacting the team and product?
- **Prioritization**: Which areas of debt should be tackled first?
- **Action Plan**: How can we systematically address the prioritized debt?
## When to use
- When your codebase is getting harder to maintain and extend with every change.
- When the team spends its time fighting fires and new features keep slipping because of instability.
- When onboarding new developers is slow because some areas are convoluted or undocumented.
- When maintenance and bug fixes take up more time than new work.
- When developers are frustrated by the same problem areas sprint after sprint.
## Tips and tricks
- Keep the discussion blame-free. Every codebase builds up debt; the question is what to do about it now.
- Make sure non-technical people in the room understand what technical debt is and why it matters to delivery.
- Rank debt by impact, effort and importance instead of trying to fix everything at once.
- Give the plan timelines, owners and regular check-ins so it doesn't stall.
- Set aside a fixed share of each sprint or cycle for paying down debt.
- Automate linting, testing and parts of code review so less new debt gets in.
## Icebreaker questions
- If our codebase were a building, what would it look like and why?
- What's the funniest or most painful run-in with technical debt you've had?
---
# Haunted House Halloween Retrospective
URL: https://www.teamretro.com/retrospective-templates/haunted-house-halloween-retrospective/
The Haunted House Halloween Retrospective takes your team on a tour of five rooms, each holding a different kind of lesson from your sprint. You celebrate the wins, drag neglected problems into the light and chase out the ghosts of old habits.
Each room has a job. The Hall of Mirrors is for miscommunication and mismatched expectations. The Cobwebbed Corridor holds the issues that have been ignored or postponed. The Dungeon is for what's trapping the team or blocking progress. The Secret Lab is for experiments, both the quiet wins you've already tried and the ideas worth testing next. The Graveyard Garden is where you bury habits, tools and rituals that no longer earn their place.
The spooky setting gives people a lighter way into hard topics, with less finger-pointing and more ghost-busting. Run it in October or around Halloween, or whenever your team is tired of the usual retrospective and needs something different to get people talking.
## Topics
- **Hall of Mirrors**: What reflections do we see about ourselves and our teamwork?
- **Cobwebbed Corridor**: Which tasks or processes have gathered dust and need clearing out?
- **The Dungeon**: What's been dragging us down or haunting our progress?
- **The Secret Lab**: What weird and wonderful experiments should we try next?
- **Graveyard Garden**: What old habits, tools, or rituals should we finally bury?
## When to use
- Your team has retrospective fatigue and needs a different format to get people talking honestly again.
- You're running a retrospective in October or around Halloween and want to use the seasonal theme.
- The team needs to discuss difficult or uncomfortable topics, and a playful setting would make that easier.
- You want the team to look at familiar problems from new angles, one haunted room at a time.
- Your remote team needs a memorable themed session that gives everyone a shared experience.
## Tips and tricks
- Set the mood with Halloween virtual backgrounds, eerie music or costumes for anyone who wants to dress up.
- Start with a quick tour of the rooms, explaining each metaphor before anyone adds ideas.
- Keep the theme playful but treat what people share seriously, especially in the Dungeon and the Cobwebbed Corridor.
- If the Dungeon fills up with complaints, move the energy to the Secret Lab and ask which experiments might help the team escape.
- Frame the Graveyard Garden as making room for something new instead of dwelling on failure. Letting go of a familiar practice takes some courage.
- Don't skip the Cobwebbed Corridor even when it's uncomfortable. Neglected issues rarely fix themselves, and it's normal for a few to pile up.
## Icebreaker questions
- What's your favorite Halloween candy, and does your preference reveal anything about your personality?
- If you had to spend a night in one room of a real haunted house, which would you choose and why?
---
# Plus Minus Interesting (PMI)
URL: https://www.teamretro.com/retrospective-templates/plus-minus-interesting-pmi/
Plus Minus Interesting (PMI) is a thinking tool Edward de Bono developed to stop people judging an idea too quickly. Before anyone decides, the group lists the idea's positives (Plus), its negatives (Minus) and anything that's neither but worth exploring (Interesting).
The Interesting column is the difference between PMI and a pros and cons list. It holds the neutral points, open questions and "what if" ideas that a two-column list has no place for, and that's often where the most useful thinking turns up.
PMI comes from de Bono's work on lateral thinking, the same body of work that produced the Six Thinking Hats, and it's part of his CoRT thinking program. He called it an attention-directing tool. You move your attention through all three columns in turn, so you can't stop as soon as you've confirmed what you already believed, and that's why it helps with confirmation bias.
To make a PMI chart, draw three columns and give everyone a few minutes to add points to each one in turn. Say your team is weighing a switch to a four-day work week. A Plus might be "more focus, less burnout", a Minus "harder to cover support on Fridays", and an Interesting "would clients even notice?" or "could we trial it for one quarter?". Only once all three columns are full does the team weigh up and decide, and that's often when the best idea turns out to be sitting in Interesting.
## Topics
- **Plus**: What are the positive aspects?
- **Minus**: What are the negative aspects?
- **Interesting**: What is unknown or makes us curious?
## When to use
- When you're weighing a significant change or new initiative that affects the team or organization
- When a decision involves several stakeholders who see it differently
- When a complex problem needs breaking into parts before anyone can judge it
- When the group is about to decide too quickly and you want every angle considered first
## Tips and tricks
- Ask everyone to add to all three columns, even if their first reaction is strongly for or against
- Timebox each column so each one gets the same attention
- Dot vote after collecting to find the points that matter most in each column
- Hold the debate until every point is on the board
- Keep the tone neutral during Minus so people feel safe raising concerns
- Save the chart afterward, since the Interesting column often holds ideas worth coming back to
## Icebreaker questions
- What's the most interesting decision you've made that initially seemed negative but turned out positive?
- If you could instantly know the outcome of any decision, what would you want to evaluate first?
---
# Voyage to the New World Retrospective
URL: https://www.teamretro.com/retrospective-templates/voyage-to-the-new-world-retrospective/
The Voyage to the New World retrospective frames your team's recent work as an ocean crossing toward unexplored land. Your team looks back at what carried the ship forward and what nearly sank it, then decides where to sail next.
The board has four columns. Favorable Winds covers the people, practices and circumstances that helped the team make progress. Stormy Seas is for the blockers and frustrations that slowed you down or threw you off course. Treasure Found collects the wins, lessons and pleasant surprises, and Uncharted Horizons looks ahead to the improvements and experiments you want to try.
The expedition theme suits the end of a big project or a quarter, when there's a full voyage to look back on. Because the last column looks forward, the session ends with a course to follow, written as actions with an owner and a due date.
## Topics
- **Favorable Winds**: What propelled the team forward this voyage?
- **Stormy Seas**: What slowed us down or threw us off course?
- **Treasure Found**: What wins and discoveries are worth celebrating?
- **Uncharted Horizons**: Where should we explore or improve next?
## When to use
- When your team wants a story-driven alternative to its standard sprint retrospective.
- At the end of a major project or milestone, to look back on the whole voyage.
- When morale needs a lift and you still want to surface real issues.
- With a newly formed team, to map its shared experience and agree on a direction.
- For quarterly or release reviews where you want to balance celebration with planning ahead.
## Tips and tricks
- Introduce the voyage metaphor at the start so everyone knows what belongs in each column.
- Timebox each section so you reach the action planning in Uncharted Horizons.
- Let people add ideas silently and independently before discussion, so quieter crew members are heard.
- Keep the Stormy Seas discussion on situations and systems, not individuals.
- Group similar ideas and dot-vote so you act on the issues that matter most.
- Turn Uncharted Horizons ideas into actions with an owner and a due date.
## Icebreaker questions
- If you were an explorer in any era, which voyage would you most want to join and why?
- What's one 'treasure' you'd want to bring back from a journey to a brand new world?
---
# Zombie Apocalypse Retrospective
URL: https://www.teamretro.com/retrospective-templates/zombie-apocalypse-retrospective/
When a sprint gets chaotic, the Zombie Apocalypse Retrospective turns it into a survival story. Your team looks back at what kept it alive, what came at it, what it's short of, and how to be ready for the next wave. Calling a problem a zombie makes it something the team faced together, not someone's fault, so blockers are easier to name.
The board has four areas. Survival Wins is for the practices, tools and decisions that helped the team succeed. Zombie Horde covers the obstacles that attacked: unclear requirements, technical debt, context switching. Survival Supplies is where the team lists the resources, training or support it needs, and Fortify the Base turns all of that into concrete improvements with owners.
It suits teams with retrospective fatigue, a rough sprint that needs talking through, or a new team that would remember a themed first retro. Keep the zombies systemic: if a note starts pointing at a person, steer it back to the situation.
## Topics
- **Survival Wins**: What helped us survive and succeed this sprint?
- **Zombie Horde**: What obstacles and challenges attacked us?
- **Survival Supplies**: What resources or support do we need?
- **Fortify the Base**: How can we strengthen our defenses and improve?
## When to use
- When your team has retrospective fatigue and needs a format that gets people talking again.
- After a hard sprint or project, when the metaphor makes it easier to discuss difficult issues without blame.
- When you want some team bonding in the retro and still need real actions out of it.
- For creative or gaming-oriented teams who enjoy themes and storytelling.
- When introducing retrospectives to a new team and you want the first one to stick.
## Tips and tricks
- Lean into the theme: call yourself the survivor leader and use apocalypse language, but don't force anyone to stay in character.
- Watch for blame dressed up as zombie talk. If someone says "the zombie that is John's code," steer back to the situation. Keep zombies external and systemic.
- Timebox each area and use a visible timer, so the urgency of the theme keeps discussions short.
- Limit Fortify the Base to the two or three improvements that matter most. You can't build every wall at once.
- Use dot voting to pick the most threatening zombies and the most urgent fortifications.
- End on Survival Wins: the team got through another sprint, and saying so sets up the next one.
## Icebreaker questions
- If the zombie apocalypse started right now, what one item from your desk would you grab as your survival tool?
- Which teammate would you most want in your zombie apocalypse survival group, and what special skill would they bring?
---
# Magical Hogwarts Retrospective
URL: https://www.teamretro.com/retrospective-templates/magical-hogwarts-retrospective/
The Magical Hogwarts Retrospective takes the setting of the Harry Potter books by J.K. Rowling and uses it to frame a normal team retro. The spells that worked are your wins, the dark arts are your blockers, and the Sorting Hat hands out wishes for the next sprint. People who know the books get an extra layer of fun, and everyone else still has clear prompts to answer.
The board has four columns, each matching a standard part of a retrospective. Spells That Worked is what went well. The Dark Arts covers the problems and blockers that held the team back, and it's a good column to run anonymously. Lessons from Dumbledore is for the insights the team would pass on to its past self. Wishes from the Sorting Hat is where the team picks the changes and experiments it wants to try, then turns the top-voted ones into actions with owners.
Use it when the team is tired of the usual format, around a milestone or a team social, or when a hard topic needs a lighter way in. It works the same way for remote and co-located teams.
## Topics
- **Spells That Worked**: What magic helped the team succeed this time?
- **The Dark Arts**: What problems or blockers cast a shadow over us?
- **Lessons from Dumbledore**: What wisdom or insights did we gain along the way?
- **Wishes from the Sorting Hat**: What magic do we want to conjure for next time?
## When to use
- When your team has retro fatigue and needs a fresh, playful format.
- At milestone or end-of-quarter celebrations where you want to recognize wins in a memorable way.
- When a new or cross-functional team is forming and you want a low-pressure way to start talking.
- Around themed events, holidays or team socials where a story-driven retro fits the mood.
- When difficult issues need raising and a light metaphor makes it easier to be honest.
## Tips and tricks
- Set the scene before you start. A quick 'sorting' of the team into houses or a themed background gets people in the mood.
- Keep the metaphor light and explain each column in plain terms, since not everyone is a fan.
- Timebox each column to keep energy up and stop the theme from drifting into off-topic chat.
- Use anonymous input for The Dark Arts so people feel safe raising sensitive issues.
- Group and vote before you discuss, so the team spends its time on the issues that matter most.
- Turn Wishes from the Sorting Hat into actions with owners so the ideas lead to change.
## Icebreaker questions
- Which Hogwarts house would the Sorting Hat place you in, and why?
- If you could cast one real-life spell to improve your workday, what would it do?
---
# Vacation Retrospective
URL: https://www.teamretro.com/retrospective-templates/vacation/
The Vacation Retrospective takes the retro format your team already knows and points it at a trip. It works for a family holiday, a team offsite or a business trip: anything where several people traveled together and you'd like the next one to go more smoothly.
The board has four columns. The Destination covers what the place was like compared with what you expected. Packing looks at the preparation, from documents to the shoes you wished you'd brought. Lost Luggage is for everything that went wrong on the way, like delays, missing bookings or jet lag, and Vacation Snaps collects the highlights.
Because everyone adds their own notes, you hear about the trip from each person's point of view. That matters when the kids, the planners and the people who went along for the ride had very different experiences. You finish with a short list of things to do differently, and a few good memories on the record.
## Topics
- **The Destination**: Where were we traveling to?
- **Packing**: What needed to be done beforehand?
- **Lost Luggage**: What issues did we encounter on the way?
- **Vacation Snaps**: What were the highlights of our journey?
## When to use
- After a team retreat or business trip, to plan the next one better
- After a family vacation, to capture lessons and favorite moments
- Before planning a new trip, so you don't repeat past problems
- When you want feedback from a group about how a trip was organized
## Tips and tricks
- Run it within a week of getting back, while memories are fresh
- Ask people to bring photos to jog memories and start conversations
- Make it clear that both good and bad experiences are welcome
- Spend your time on what you can change next time, not on things nobody could have controlled
- Write down specific recommendations for the next trip, such as a shared packing list
- Expect different views. Travelers often care about different things, and each perspective counts
## Icebreaker questions
- If you could instantly teleport to any destination right now, where would you go and why?
- What's the most unusual food you've ever tried while traveling?
---
# Brainstorm Blitz
URL: https://www.teamretro.com/retrospective-templates/brainstorm-blitz-retrospective/
Brainstorm Blitz is a short, fast ideation session. Your team writes down as many ideas as it can without judging any of them, then narrows the list to the few worth acting on. The speed is deliberate: with no time to second-guess, people put forward the odd, ambitious ideas they'd normally keep to themselves.
The format builds on the brainstorming rules that advertising executive Alex Osborn popularized in the 1950s: go for quantity, welcome wild ideas, build on each other's and hold criticism until later. The board has four rounds. Big Ideas is the divergent round, where nothing is too far-fetched. Quick Wins picks out what you could start this week. Roadblocks names what could get in the way. Next Steps is where the team votes and commits to a few ideas with owners.
Use it for a product problem, a campaign or any time the team's thinking has gone stale. Because everyone adds ideas privately before the group sees them, quieter people and remote teammates contribute as much as the loudest voice in the room.
## Topics
- **Big Ideas**: What bold or wild ideas could we explore?
- **Quick Wins**: Which ideas could we act on right away?
- **Roadblocks**: What might get in the way of our ideas?
- **Next Steps**: Which ideas should we commit to and who owns them?
## When to use
- At the start of a new project or quarter, when you need fresh ideas and a short list of priorities.
- When the team is stuck on a problem and the usual approaches aren't working.
- Before planning a campaign, feature or initiative, when you want many options on the table quickly.
- When you want every team member to contribute ideas, including quieter people on distributed teams.
## Tips and tricks
- Set a tight timer for each round. Speed stops people editing their ideas before they share them.
- Hold all criticism during the idea rounds. Critiquing too early makes people stop contributing.
- Ask people to build on each other's ideas as well as adding new ones. Combined ideas are often the strongest.
- Keep idea entry anonymous so seniority doesn't decide which ideas get shared.
- End every session with voting and owned action items, or the ideas stay on the board.
- Put "too big for now" ideas in a backlog so you can pick them up in a later session.
## Icebreaker questions
- If you could instantly master any new skill to use at work tomorrow, what would it be?
- What's the most creative idea you've ever had, at work or otherwise, that you wish you'd acted on?
---
# Christmas Retrospective
URL: https://www.teamretro.com/retrospective-templates/christmas-retrospective/
The Christmas retrospective gives your end-of-year reflection a festive theme. Underneath, it's a standard retrospective, with five holiday categories in place of the usual columns.
Gifts are the things the team learned or received, like new skills or useful feedback. Joy covers the moments that made people happy at work. Grinches are the problems that got in the way, Elves are the people and tools that helped, and Wishes are what the team wants for the next stretch of work.
The theme lowers the stakes, so it's easier to talk about setbacks as well as successes. It works well as the last retrospective before the holidays, or when your team needs a lift at the end of a hard stretch, and the Wishes column gives you a natural place to agree on actions for the new year.
## Topics
- **Gifts**: What have we learned and received as gifts during this period?
- **Joy**: What has brought us happiness and joy in our work?
- **Grinches**: What has caused us troubles or issues during this period?
- **Elves**: Who or what has helped us succeed in our work?
- **Wishes**: What do we wish for in our future work together?
## When to use
- At the end of the year, to reflect together and close the year on a positive note
- When team morale needs a lift and a lighter retrospective would help
- After finishing a milestone or project phase during the holiday season
- When you want a fresh theme that still covers learning, wins, problems and next steps
## Tips and tricks
- Add festive touches like holiday icons or a winter virtual background
- Make sure the festive mood still ends in action items people will follow up
- Ask people to think about each category before the session so discussion time goes further
- Start with Gifts and Joy before moving on to the Grinches
- Close by turning Wishes into actions with owners and dates
- Add a short festive activity at the start or end to bring the team together before the break
## Icebreaker questions
- If your recent work experience was a Christmas movie, which one would it be and why?
- What's one 'gift' (skill or knowledge) you'd like to receive to help you in your role next year?
---
# Man of Steel Retrospective
URL: https://www.teamretro.com/retrospective-templates/man-of-steel-retrospective/
The Man of Steel Retrospective uses Superman's story as a frame for your team's review. Superman draws his strength from the sun and is weakened by kryptonite, and the board borrows both ideas: what makes your team strong, what drains it and what keeps it going.
The board has four columns. Superpowers is for the strengths, wins and habits that helped the team succeed. Kryptonite names the weaknesses and blockers that slowed you down, kept to processes and situations, not people. Source of Power asks what motivates the team, from seeing users benefit to having a say in how you work. Call to Action turns the discussion into two or three concrete steps for the next sprint.
Source of Power is the column that sets this format apart from a standard retro. It gives the team time to talk about motivation and energy, which rarely gets airtime. Use it after a big release, during a long project, or whenever your usual retros have started to feel flat.
## Topics
- **Superpowers**: What strengths and wins powered the team forward?
- **Kryptonite**: What weakened the team or slowed us down?
- **Source of Power**: What energizes and motivates the team to keep going?
- **Call to Action**: What heroic steps will we take next?
## When to use
- When standard retrospectives feel stale and your team needs a themed format to get people talking again.
- After a major release or milestone, to celebrate the wins and be open about what held the team back.
- With newer or distributed teams, where a playful metaphor makes it easier to share honestly.
- When you want to check in on motivation as well as delivery, using the Source of Power column.
## Tips and tricks
- Introduce the superhero theme at the start so everyone understands the metaphor before adding ideas.
- Keep Kryptonite focused on processes and situations, not individuals, so people feel safe.
- Timebox each column to keep the energy up and stop the session dragging.
- Use anonymous input if the team is new or sensitive topics may come up.
- Limit Call to Action to two or three items so the team can deliver them before the next retro.
- Start by reviewing the previous Call to Action items to keep the team accountable and show progress.
## Icebreaker questions
- If you could have one superpower at work, what would it be and why?
- What's your personal kryptonite, the one thing that instantly derails your productivity?
---
# Build-a-Bear Workshop Retrospective
URL: https://www.teamretro.com/retrospective-templates/build-a-bear-workshop-retrospective/
The Build-a-Bear Workshop retrospective borrows the steps of making a stuffed bear: pick the body, add the heart, dress it up, give it a name. Each step lines up with part of how your team worked, which gives people a light way into conversations that can feel heavy when asked head-on.
The board has four stages. Choose the Body covers the foundations your work rested on, such as planning, tooling and clear goals, and where they wobbled. Add the Heart is about what motivated the team. Dress It Up collects the finishing touches and improvements you want next time, and these usually become your action items. Name and Celebrate closes on the wins and the people behind them.
It suits newer teams, cross-functional groups and anyone tired of the standard sprint retrospective. Ending on celebration means people leave on a good note, while the Dress It Up stage keeps the session tied to real changes.
## Topics
- **Choose the Body**: What foundations supported our work this time?
- **Add the Heart**: What motivated and energized us the most?
- **Dress It Up**: What finishing touches and improvements should we add?
- **Name and Celebrate**: What achievements deserve to be celebrated?
## When to use
- When you want a creative change from your usual sprint retrospective.
- With newer or cross-functional teams that are still building trust and rapport.
- After a significant project or milestone you want to celebrate while looking at how it was built.
- When morale is low and you want a lighthearted format that still produces actions.
## Tips and tricks
- Play along with the metaphor. Talk of building, stuffing and dressing the bear keeps the mood light.
- Use anonymous brainstorming in TeamRetro so quieter people feel safe raising concerns about the foundations.
- Timebox each of the four stages so the first one doesn't use up all your energy.
- Give Name and Celebrate enough time. Ending on real celebration lifts morale and reminds the team which habits to keep.
- Group and vote on the Dress It Up ideas to pick the finishing touches that become action items.
- Rotate the facilitator each session so the metaphor stays fresh and the whole team owns the improvements.
## Icebreaker questions
- If your team were a stuffed animal, what would it be and why?
- What was the first soft toy you remember owning, and did it have a name?
---
# Customer Feedback Retrospective
URL: https://www.teamretro.com/retrospective-templates/customer-feedback-retrospective/
A Customer Feedback Retrospective puts what customers have actually said in front of the whole team. You bring in feedback from surveys, reviews, support tickets and sales calls, then work through it together so it doesn't sit unread in a dashboard.
The board has four columns. Positive Feedback captures what customers praised, so you know what to protect. Areas for Improvement collects their complaints and friction points. Innovative Ideas holds the suggestions and feature requests customers sent in. Action Plan is where the team agrees what it will change, and who owns each change.
Reading feedback as a group works better than having one person summarize it. Support hears different things from product, and recurring themes are easier to spot when several people have read the same comments. Finish with a short list of owned actions, and check on them at the next session.
## Topics
- **Positive Feedback**: What positive feedback did we receive from customers?
- **Areas for Improvement**: What areas did customers identify as needing improvement?
- **Innovative Ideas**: What new ideas or suggestions did customers propose?
- **Action Plan**: What specific actions can we take to address customer feedback?
## When to use
- After a product launch, feature release or marketing campaign, once customer reactions start coming in.
- Every quarter, to go through survey results, reviews and support tickets together.
- When satisfaction scores or reviews drop and you need to find out why.
- When product, support and marketing hear different things from customers and need one shared picture.
- Before roadmap planning, so customer requests shape what you build next.
## Tips and tricks
- Pull feedback from more than one channel, such as surveys, reviews, support tickets and social media, so one loud channel doesn't set the agenda.
- Share the raw comments before the session so people arrive having read them.
- Invite people from product, support and marketing. Each group hears different complaints.
- Separate one-off complaints from patterns. Count how often a theme comes up before you act on it.
- Give every action an owner and a date, and review progress at the next session.
- Tell customers what you changed because of their feedback. It shows them it was worth giving.
## Icebreaker questions
- If you could change one thing about our product or service, what would it be?
- Share a recent positive or negative experience you had as a customer with any company.
---
# Cross-Functional Strategy Planning
URL: https://www.teamretro.com/retrospective-templates/cross-functional-strategy-planning/
A Cross-Functional Strategy Planning session brings people from different teams onto one board to agree on where the organization is heading and what each team will do to get there. Strategy set by one group and handed to the rest tends to stall at the first dependency. Planning it together surfaces those dependencies while there's still time to plan around them.
The board has four columns, worked in order. Mission and Vision checks that everyone shares the same understanding of the organization's purpose. Strategic Priorities narrows a long list to the few areas that matter most over the next 12–18 months. Cross-Team Collaboration looks at how teams will work together, from shared working groups to a common knowledge base. Action Planning turns the priorities into steps with owners and deadlines.
Run it once or twice a year, when launching a product or initiative that needs several teams, or during a reorganization. Share the purpose and expected outcomes before the session, and book the follow-up check-ins before everyone leaves.
## Topics
- **Mission and Vision**: What is our organization's mission and vision?
- **Strategic Priorities**: What are our top strategic priorities for the next 12–18 months?
- **Cross-Team Collaboration**: How can we better collaborate across teams to achieve our goals?
- **Action Planning**: What specific actions and timelines should we set to execute our strategy?
## When to use
- When your organization needs to set or revisit its strategic direction and priorities.
- When teams or departments are pulling in different directions and need to agree on shared goals.
- When launching a new product, service or initiative that needs coordination and buy-in from several teams.
- During organizational change, so everyone is working toward the same goals.
- Once or twice a year, to review progress, adjust course and plan the next period.
## Tips and tricks
- Include every team and stakeholder group the strategy depends on.
- Share the purpose and desired outcomes of the session in advance.
- Make it safe to disagree. Objections raised in the room cost far less than ones raised after launch.
- Capture ideas and action items on a shared board so everyone sees the same picture.
- Give every follow-up task an owner and a deadline.
- Schedule regular check-ins to track progress and clear roadblocks.
## Icebreaker questions
- If our organization was an animal, what would it be and why?
- Share a time when you experienced exceptional cross-team collaboration, and what made it successful.
---
# Bug Fixing Retrospective
URL: https://www.teamretro.com/retrospective-templates/bug-fixing-retrospective/
The Bug Fixing Retrospective is a focused meeting for reviewing the bugs from your last sprint and working out why they happened. Instead of fixing each defect and moving on, your team traces the important ones back to the gaps in testing, standards or process that let them in, and agrees on changes that stop the same kind of bug coming back.
The board has five columns. Recent Bugs lists the defects that mattered most, especially high-impact or recurring ones. Root Causes uses the 5 Whys: keep asking why until you reach a cause in how the team works rather than in a line of code. Preventative Actions turns those causes into changes. Quality Targets sets measurable goals, such as fewer production defects or higher test coverage, so you can tell whether the changes worked. Our Learnings captures what the team takes away.
Keep it blameless. The 5 Whys stops working the moment an answer is a person's name, so steer every "why" toward the system: a missing test, an unclear requirement or a deadline that squeezed out review.
## Topics
- **Recent Bugs**: Which bugs caused the most trouble in the last sprint?
- **Root Causes**: What were the underlying reasons behind each major bug?
- **Preventative Actions**: What steps can we take to prevent similar bugs going forward?
- **Quality Targets**: What metrics or goals should we set to measure improvement?
- **Our Learnings**: What lessons are we taking away from this retrospective?
## When to use
- After a sprint or project phase with a high number of reported bugs.
- When technical debt or a growing defect backlog is hurting productivity and release quality.
- When the same kinds of issues keep recurring and you suspect a process problem behind them.
- As a focused quality exercise for a team struggling with code quality.
## Tips and tricks
- Keep the session blameless. The goal is learning, not finding who's at fault.
- Invite QA, DevOps and product owners as well as developers, since each sees bugs from a different angle.
- Prioritize high-impact or frequent bugs over minor one-off issues.
- Use the 5 Whys to get past the symptom to the root cause.
- Give every preventative action and quality target an owner and a deadline.
- Review progress on these commitments at your next retrospectives.
## Icebreaker questions
- If you could eliminate one bug from existence, which would it be and why?
- Share a funny or embarrassing experience involving a bug you've encountered.
---
# Down the Rabbit Hole Retrospective
URL: https://www.teamretro.com/retrospective-templates/down-the-rabbit-hole-retro/
The Down the Rabbit Hole Retrospective borrows from Alice's fall into Wonderland. Instead of collecting a long list of issues, your team picks one curious problem or surprise and follows it down, asking why at each level until the real cause shows up.
The board has four columns. The Rabbit Hole is where you choose what to explore: a bug that keeps coming back, a target you hit while everyone burned out, a fix that didn't stick. Falling Deeper is for the chain of "why" answers. Wonderland captures what you found along the way, good or bad. Finding the Way Out turns those findings into actions with owners.
It works like the 5 Whys with more room for side discoveries, and it suits a team that keeps stopping at the obvious answer. Keep the story light and the discussion blameless, and timebox each stage so the team makes it back out with something to do.
## Topics
- **The Rabbit Hole**: What curious problem or surprise should we explore?
- **Falling Deeper**: Why did it happen? Keep asking why beneath the surface.
- **Wonderland**: What did we discover along the way, good or bad?
- **Finding the Way Out**: How do we act on what we found and climb back up?
## When to use
- When a recurring problem keeps coming back despite earlier fixes and you need the real root cause.
- When the team tends to stop at symptoms and you want to push the analysis further.
- When you want a lighter alternative to a standard root cause analysis session.
- When a surprising result, good or bad, deserves a proper look before you decide what to do.
## Tips and tricks
- Use the Wonderland theme to keep things light, but make sure each rabbit hole ends at a root cause instead of a fun tangent.
- In Falling Deeper, keep asking why until you hit something you can act on. The first plausible answer is rarely the cause.
- Pick one or two rabbit holes. This format works best when it goes deep.
- Keep it blameless by talking about systems and processes, not individuals.
- Timebox each stage so the team doesn't get lost and still leaves with clear actions.
- Record discoveries even when they don't lead to an action yet. Over a few sessions they can show a pattern.
## Icebreaker questions
- If you could follow any white rabbit into a mystery, what would you most want to discover?
- What's one thing you were endlessly curious about as a child?
---
# Sesame Street Shuffle Retrospective
URL: https://www.teamretro.com/retrospective-templates/sesame-street-shuffle-retrospective/
The Sesame Street Shuffle is a lighthearted retrospective built around the characters of Sesame Street. Many people grew up with them, so the prompts need no explanation, and the playful framing makes it easier to share a frustration you might otherwise keep to yourself.
The board has four areas. Sunny Days is for what made the team happy. Grouchy Bins, in the spirit of Oscar the Grouch, is the place to vent about frustrations and blockers. Curious Questions is for the open questions and ideas the team wants to explore, and Count On It, a nod to Count von Count, is where you tally up a few actions to commit to.
It suits new or distributed teams still building rapport, teams coming off a tough sprint, and anyone tired of their usual format. In TeamRetro, people add ideas on their own, group and vote on them, and finish with two or three actions that have owners.
## Topics
- **Sunny Days (What made us happy?)**: What brought sunshine and good vibes to our work?
- **Grouchy Bins (What frustrated us?)**: What felt grumpy, annoying, or got in our way?
- **Curious Questions (What do we want to learn?)**: What are we curious about or want to explore further?
- **Count On It (What should we commit to?)**: What actions can we count on and commit to next?
## When to use
- After an intense sprint, when your team needs a lighter retrospective.
- With new or distributed teams that are still building trust.
- When quieter team members need an easier way into the conversation.
- When your standard retro format feels stale and participation is dropping.
## Tips and tricks
- Lean into the theme at the start. It gives people permission to be candid.
- Timebox each character topic so the fun doesn't crowd out the discussion and the actions.
- Use anonymous idea entry in TeamRetro for Grouchy Bins so people are honest about their frustrations.
- Group similar ideas before voting so the discussion stays on the themes that matter most.
- Limit Count On It to two or three actions with clear owners so they actually get done.
- Watch who's talking, and invite quieter people in so the loudest characters don't take over.
## Icebreaker questions
- Which Sesame Street character best matches your mood this sprint, and why?
- If your team were a Sesame Street duo, who would you be and who's your partner?
---
# Top Gun Squadron Retrospective
URL: https://www.teamretro.com/retrospective-templates/top-gun-squadron-retrospective/
The Top Gun Squadron retrospective runs your sprint review like a squadron debrief after a mission. Pilots go over what happened while it's fresh, credit the people who flew well and agree on what changes before the next flight. Your team does the same.
The board has four stations. Top Guns is for standout wins and the people behind them. Turbulence covers the friction and problems that slowed the team down. Wingman Support looks at how well people backed each other up, and Next Mission turns everything into actions, each with a pilot who owns it.
The aviation theme gives the meeting some energy without getting in the way of the substance. Turbulence is easier to talk about when it's framed as part of every mission, and the Wingman station gives a sprint's quieter teamwork the attention it usually misses. Use it when your retros have gone stale, or after a release that had both big wins and rough patches.
## Topics
- **Top Guns**: What were our standout wins this mission?
- **Turbulence**: Where did we hit friction or run into trouble?
- **Wingman Support**: How well did we back each other up as a team?
- **Next Mission**: What actions will set us up for the next flight?
## When to use
- When your retrospectives feel stale and you want a themed format to get people talking.
- After a high-stakes release or sprint, when the wins and the problems both deserve time.
- When you want to look at how well the team backs each other up, not only at what it delivered.
- For teams that open up more when a metaphor puts some distance between them and the problem.
## Tips and tricks
- Set the scene with a quick callsign round so everyone gets into the theme.
- Keep the metaphor light and the takeaways concrete. The theme is there to support honest reflection.
- Use anonymous contributions so Turbulence surfaces real issues without anyone feeling singled out.
- Timebox each station so the debrief keeps moving.
- Give every Next Mission action a pilot (owner) and a due date so nothing stalls on the runway.
- Rotate the facilitator between sessions so the squadron shares ownership of the debrief.
## Icebreaker questions
- If you had a fighter pilot callsign, what would it be and why?
- What's one mission (project or task) you felt like an ace flying through recently?
---
# Fast & Furious Pit Stop Retrospective
URL: https://www.teamretro.com/retrospective-templates/fast-and-furious-pit-stop-retrospective/
The Fast & Furious Pit Stop retrospective treats your team like a racing crew coming in for a pit stop. A pit crew has seconds to refuel, change tires and get the car back on the track. Your team takes a short, focused stop to look at what's keeping you fast, what's slowing you down and what to adjust before the next lap.
The board has four lanes. Full Speed Ahead is for the wins and habits that gave you momentum. Drag & Friction is for the blockers and delays that cost you time. Hazards on the Track looks ahead to risks that haven't hit yet, and Tune-Ups is where the team agrees on changes. Because the conversation is about the car and the race, it's easier to talk about friction without anyone feeling blamed.
You finish with a short list of tune-ups, each with an owner. The format works well in a rotation of retrospective styles, especially for teams who have run "what went well, what didn't" so often that the answers come out the same every sprint.
## Topics
- **Full Speed Ahead**: What gave us speed and momentum this sprint?
- **Drag & Friction**: What slowed us down or created resistance?
- **Hazards on the Track**: What risks or obstacles are coming up ahead?
- **Tune-Ups**: What adjustments will make us faster next lap?
## When to use
- When your usual retrospectives have gone stale and you want a themed change of pace.
- At the end of a sprint where the team wants to look at speed, friction and the changes to make next.
- When you want to raise blockers and upcoming risks without the session turning into blame.
- For teams who rotate retrospective formats to keep people contributing.
## Tips and tricks
- Open with a quick scene-setter that casts the team as a pit crew between laps.
- Timebox each lane so the session keeps moving, like a real pit stop.
- Keep Drag & Friction blame-free by talking about the system and the process, not individuals.
- Give every Tune-Up an owner and a realistic next step so it actually happens.
- Have people add ideas privately first, so quieter crew members contribute before the louder voices take over.
- Start by checking last sprint's tune-ups to see which ones made the team faster.
## Icebreaker questions
- If your work this sprint were a vehicle, would it be a Formula 1 car, a reliable sedan, or a car running on fumes, and why?
- What's one thing that would have made your sprint feel like crossing the finish line first?
---
# Aladdin's Agile Adventure Retrospective
URL: https://www.teamretro.com/retrospective-templates/aladdin-agile-adventure-retrospective/
Aladdin's Agile Adventure turns your sprint or project review into a story most people already know. Each column borrows part of the tale: the treasure in the Cave of Wonders, the traps along the way, the genie's three wishes and the magic carpet that carries Aladdin on. The theme gets the team out of its usual retro habits and makes it easier to talk honestly.
The board has four columns. Treasures Found is for your wins. Traps and Tricks covers the obstacles and blockers that slowed you down. Three Wishes asks what the team would improve if a genie granted it, and Magic Carpet Ride turns those wishes into next steps with owners. The playful framing lowers people's guard and gives quieter team members an easy way in, and it keeps a long-running team from getting bored of the same format.
Stories are how most people make sense of what happened, which is why a themed retro like this often brings out things a standard one misses. Whether you run sprints, a kanban flow or project milestones, it gives the retro a fresh setting and still ends with concrete actions.
## Topics
- **Treasures Found**: What wins or successes did we discover this sprint?
- **Traps and Tricks**: What obstacles, blockers or sneaky problems slowed us down?
- **Three Wishes**: If the genie granted three wishes, what would we improve?
- **Magic Carpet Ride**: Where do we want to go next and what's our first step?
## When to use
- When your standard sprint retro has gone stale and the team needs a new setting to get talking.
- After a major milestone or release, to look back on it in a way people will remember.
- When you want quieter team members to open up. A story lowers people's guard.
- For end-of-quarter or seasonal retros, where a themed format adds a sense of celebration.
- When you're introducing a newer team to retrospectives and want something approachable.
## Tips and tricks
- Open with a line or two of story so everyone knows how each column maps to the Aladdin theme.
- Keep it light without losing focus. Timebox each column, since the goal is still real actions.
- Ask for specifics in Treasures Found and Traps and Tricks, so wins can be repeated and obstacles fixed.
- Dot-vote the Three Wishes so the team puts its energy into the improvements that matter most.
- Make sure every Magic Carpet Ride action has a clear owner and a due date before you close.
- Rotate the facilitator each time you run a themed retro, so the sessions don't all feel the same.
## Icebreaker questions
- If a genie granted you one work-related wish right now, what would you ask for?
- Which fictional character would you most want on your team and why?
---
# Three Wishes Retrospective
URL: https://www.teamretro.com/retrospective-templates/three-wishes-retrospective/
If your team could change three things about how it works, what would it ask for? The Three Wishes retrospective puts that question on the board. Framing ideas as wishes makes it easier for people to say what they want without it sounding like a complaint, which helps when a team has fallen into a habit of griping.
Each person makes three wishes, and each one has its own prompt. The first wish is the one thing they most want to change. The second is whatever would make day-to-day work easier, which tends to surface small, fixable friction. The third is about how the team could grow or feel better, and that's where the bigger, people-focused wishes show up. In the fourth column, Granting the Wishes, the team groups and votes on everything and turns the top wishes into actions.
It works for sprint retrospectives and project wrap-ups, and as a gentle way into a conversation about team health. In TeamRetro, people add wishes privately, then you group, vote and assign actions in the same session, so the best wishes leave the room with an owner.
## Topics
- **My First Wish**: What is the one thing you most want to change?
- **My Second Wish**: What would make your day-to-day work easier?
- **My Third Wish**: What would help the team grow or feel better?
- **Granting the Wishes**: Which wishes can we turn into action right now?
## When to use
- When your team keeps falling into complaints and you want a more forward-looking way to reflect.
- At the end of a sprint or project, to collect what people want and turn it into specific improvements.
- Alongside a team health check or a conversation about how the team works, when you want people to say what they really want.
- When a team is new or you're restarting retrospectives, because the wish framing makes it easier to speak up.
## Tips and tricks
- Tell the team there are no bad wishes, and let people think big before you narrow down to what's actionable.
- Use anonymous brainstorming so quieter people can share wishes they might otherwise keep to themselves.
- Group similar wishes to show shared themes and avoid discussing the same idea twice.
- Use dot voting so the team spends its time on the wishes that matter most.
- Be honest about wishes that can't be granted right away. Park them where everyone can see them.
- Close by assigning owners and next steps, so the wishes turn into changes.
## Icebreaker questions
- If you found a magic lamp today, what's the first non-work wish you'd make?
- What's one childhood wish that actually came true for you?
---
# Escape Room Challenge Retrospective
URL: https://www.teamretro.com/retrospective-templates/escape-room-challenge/
The Escape Room Challenge retrospective borrows the setup of an escape room, where a group has to work together and solve puzzles against the clock to get out. Your team treats its recurring problems the same way: as locks to open together, without blaming anyone for the locked door.
The board has four columns. Locked In is for the blockers and recurring problems trapping the team. Found the Key covers the strategies, tools and behaviors that helped you get past them. Hidden Clues is for the signals you noticed but didn't act on, like a flat burndown or a quiet complaint that keeps coming back. Escape Plan turns all of that into experiments and actions for next sprint.
Hidden Clues is the column teams most often rush, and it's often where the most useful discussion happens. Give it real time, keep a visible timer running for each column, and finish with actions that each have an owner and a follow-up date. It works for a sprint retrospective, a project post-mortem or a quarterly check-in.
## Topics
- **Locked In**: What blockers or recurring problems are trapping the team?
- **Found the Key**: What strategies, tools, or behaviors helped the team escape challenges?
- **Hidden Clues**: What subtle signals or insights should the team pay more attention to?
- **Escape Plan**: What experiments or actions will help the team level up next sprint?
## When to use
- When the team keeps hitting the same blockers and needs a fresh way to tackle them.
- When energy in retrospectives has dropped and you want a format with a bit of play in it.
- After a hard sprint or project phase, when the team needs to reset.
- When new team members are joining and you want to set a habit of solving problems together.
- When your retros stay at the surface and you want to dig into systemic issues.
## Tips and tricks
- Set the scene with a short intro to the metaphor: everyone's in the room together, and the only way out is as a team.
- Use a visible timer for each column. Escape rooms run against the clock, and the timer stops one topic taking over.
- Push for specifics. 'Communication could be better' is hard to act on, so ask for a concrete example. The more specific the clue, the easier it is to find the key.
- Don't skip Hidden Clues. Teams often jump to solutions before looking at the signals they've been ignoring.
- Give every Escape Plan action an owner and a follow-up date, and track them in TeamRetro between sessions.
- Use anonymous idea submission and dot voting so dominant voices don't drown out quieter team members.
## Icebreaker questions
- If your team were actually locked in an escape room together, who would be the first to solve a puzzle, and who would be the one accidentally making things harder?
- What's one 'cheat code' or shortcut you wish existed in your day-to-day work life?
---
# Portugal Day Celebration Retrospective
URL: https://www.teamretro.com/retrospective-templates/portugal-day-celebration-retrospective/
Portugal Day, or Dia de Portugal, falls on June 10 and celebrates Portuguese culture, history and the Portuguese communities spread around the world. This session brings that occasion into your team: a short, relaxed reflection on what people admire about the culture, the traditions they grew up with, and what makes your own team feel like a community. Whether your team sits in Lisbon or Porto or works across several time zones, it's a chance to stop and hear each other's stories.
The board has four areas. What We Celebrate is for what people value about Portuguese culture and heritage, from fado to hospitality. Traditions & Stories collects personal memories, family recipes and festivals. Our Team Connection asks how the same sense of belonging shows up in your team, and Keeping the Spirit Alive turns the conversation into a few ideas the team can act on during the rest of the year.
In TeamRetro, people add ideas anonymously or under their name, group related themes and vote on the ones that land most, so the person with the most stories doesn't take over. You don't need Portuguese roots to take part. Teammates from other backgrounds often bring traditions of their own, and that's part of the point.
## Topics
- **What We Celebrate**: What aspects of Portuguese culture or heritage make you proud?
- **Traditions & Stories**: What traditions, foods, or stories would you like to share?
- **Our Team Connection**: How does our team reflect a sense of community and belonging?
- **Keeping the Spirit Alive**: How can we keep celebrating culture and connection year-round?
## When to use
- On or around June 10, to mark Dia de Portugal and Portuguese heritage with your team
- When you want a diverse or distributed team to feel more like a community
- As a culturally themed team-building session that gets people sharing personal stories
- Whenever you want to recognize the cultural backgrounds people bring to your team
## Tips and tricks
- Welcome everyone, with or without Portuguese heritage, so nobody feels the session isn't for them
- Set the mood with Portuguese music, imagery or a virtual background
- Ask for personal stories and traditions; they're what people remember afterward
- Use anonymous input and give everyone equal time to speak, so quieter people contribute
- Capture specific actions from Keeping the Spirit Alive so the celebration leads to something that lasts
- Keep it relaxed and timeboxed so it feels like a celebration, not another meeting
## Icebreaker questions
- If you could visit any place in Portugal right now, where would you go and why?
- What is one dish, song, or tradition from your own culture that you would love to share with the team?
---
# Rock 'n' Retrospective
URL: https://www.teamretro.com/retrospective-templates/rock-n-retrospective/
The Rock 'n' Retrospective runs your retro like a band reviewing its last gig. The music theme gives people an easy way into the conversation: it's simpler to say a handoff was off-key than to say a process broke down, and a win becomes a hit worth playing again.
The board has four areas. Greatest Hits is for the wins and practices you want to repeat. Off-Key Notes covers what fell flat or caused friction. New Tracks collects ideas and experiments to try, and Encore is where the team commits to a small set of actions for the next sprint.
Use it when your team has retro fatigue, or at the end of a sprint, release or milestone. Nobody needs to know anything about music. Keep the Encore to two or three actions with owners so the momentum carries into the next sprint.
## Topics
- **Greatest Hits**: What went well that we'd love to play again?
- **Off-Key Notes**: What fell flat or didn't quite hit the right note?
- **New Tracks**: What new ideas or experiments should we try?
- **Encore**: What actions do we commit to bringing back next sprint?
## When to use
- When your team has retro fatigue and a new format could get everyone talking again.
- At the end of a sprint, release or project milestone, to celebrate wins and pick improvements.
- When you want a low-pressure structure that makes it easier for quieter team members to contribute.
- For teams that like themed retros and want to vary their regular cadence.
## Tips and tricks
- Play some music as people join to set the mood before the session starts.
- Make Greatest Hits specific. Naming the people and contributions behind a win makes the recognition count.
- Keep Off-Key Notes about the work, not the people, so the conversation stays on improvement.
- Limit your Encore to two or three actions so the team can actually follow through.
- Rotate the facilitator each time you run it so more people share ownership of the retro.
- Use dot voting when there are more ideas than you have time to discuss.
## Icebreaker questions
- If our last sprint had a theme song, what would it be and why?
- What's the first concert you ever attended, or the one you wish you had?
---
# Scrum Values
URL: https://www.teamretro.com/retrospective-templates/scrum-values/
The Scrum Values retrospective asks your team how well it lives the five values at the heart of Scrum: Courage, Focus, Openness, Respect and Commitment.
You take each value in turn and look at how it shows up in daily work. Splitting them out makes the conversation concrete. Instead of asking whether the team is 'doing Scrum well', you're asking whether people speak up about problems, protect their focus time and follow through on what they agreed.
The five values are set out in the Scrum Guide by Ken Schwaber and Jeff Sutherland. They're what make the events and artifacts work, because practices like daily stand-ups and retros depend on trust and honesty. This retrospective helps your team look past the mechanics of the process at how people actually work together.
## Topics
- **Courage**: How do we tackle tough problems?
- **Focus**: How can we improve focus on our goals?
- **Openness**: How do we stay open to new things?
- **Respect**: How do we respect each other?
- **Commitment**: How can we make our commitments a reality?
## When to use
- When your team is new to Scrum and needs to understand the values in practice.
- When team dynamics or performance problems suggest people have drifted from the values.
- As part of a quarterly team health check, alongside your regular sprint retros.
- Before a big change or a hard stretch that will test how the team works together.
## Tips and tricks
- Ask for specific examples. They're easier to act on than general statements.
- Have each person rate the team on each value and plot the results on a radar chart.
- Make it safe to be honest. No team lives all five values perfectly, and saying so up front helps.
- Try discussing one value a day in the run-up to the retro, so people arrive with examples.
- Record a concrete action for each value so you can track progress.
- Use real moments from recent sprints to show where a value was lived, or wasn't.
## Icebreaker questions
- Which Scrum value do you find easiest to practice and why?
- Share a recent moment when you saw a teammate show one of these values.
---
# Father's Day Reflections
URL: https://www.teamretro.com/retrospective-templates/fathers-day-reflections-retrospective/
Father's Day Reflections gives your team a break from work topics to talk about the dads, grandfathers, mentors and other father figures who shaped them. People share a memory, a lesson they still use and a thank-you, and the session usually ends with colleagues knowing each other a little better than when it started.
The board has four prompts: Favorite Memories, Lessons Learned, Qualities We Admire, and Appreciation & Thanks. Everyone adds their own thoughts, the team votes on the ones that stand out, and you talk through the themes that come up. The tone is light but sincere, and the prompts are broad enough that people with very different family situations can take part on their own terms.
It's also a reminder that the advice people carry from home shows up at work. A lesson like "keep your word, even when it's hard" often turns into a conversation about how the team works together. It runs the same way whether your team is remote or in one room.
## Topics
- **Favorite Memories**: What is a favorite memory of your dad or a father figure?
- **Lessons Learned**: What lesson did a father figure pass on to you?
- **Qualities We Admire**: What qualities of a great father figure do you most admire?
- **Appreciation & Thanks**: Who would you like to thank and what would you say?
## When to use
- Around Father's Day, to celebrate dads, father figures and mentors as a team.
- When you want a human break from work-focused retrospectives.
- When your team would benefit from knowing more about each other through personal stories.
- As a seasonal activity that brings remote and in-person colleagues together.
## Tips and tricks
- Say at the start that "father figure" can mean a dad, grandfather, uncle, mentor or anyone who offered guidance.
- Not everyone has a positive or present father figure, so keep every prompt optional and judgment-free.
- Keep it warm and informal. Humor and stories make the session stick.
- Use an icebreaker to ease people in before the more personal prompts.
- Leave enough time for sharing. These conversations are better when nobody is rushed.
- Share a short summary of the highlights afterward so people can look back on what was said.
## Icebreaker questions
- What's the best (or cheesiest) 'dad joke' you've ever heard?
- If you could give your dad or a father figure any gift in the world, what would it be?
---
# Back to the Future Retrospective
URL: https://www.teamretro.com/retrospective-templates/back-to-the-future-retrospective/
The Back to the Future retrospective takes your team on a short trip through time. You revisit what happened in the last sprint or period, take stock of where things stand today, and picture where you want to be. The time-travel framing gives an ordinary review a bit of story, which helps people stay engaged through the whole session.
It works because it ties lessons learned directly to forward-looking action. The board has four topics. The Past surfaces the wins and missteps that got you here. The Present grounds the conversation in how the team is doing right now. The Future lets people describe what they'd like to change, and The Action Plan turns that into specific, owned commitments. Covering all three time periods in one session makes it a good fit for sprint reviews, project milestones and quarterly planning.
In TeamRetro, the facilitator guides the team through each topic, groups similar ideas, runs a vote and captures action items. Whether you're celebrating a release or recovering from a tough sprint, the format gives everyone a structured way to learn from what happened and decide what comes next. Nobody needs to have seen the movie.
## Topics
- **The Past**: What happened that shaped where we are now?
- **The Present**: Where do we stand right now as a team?
- **The Future**: Where do we want to go from here?
- **The Action Plan**: What will we do to make that future happen?
## When to use
- At the end of a sprint or project milestone, when you want to connect lessons learned with future goals.
- During quarterly or annual planning, to balance reflection with forward-looking commitments.
- When team energy feels flat and a themed format could get people talking again.
- After a major release or significant change, to see how far you've come and where to head next.
## Tips and tricks
- Introduce the time-travel theme briefly so the session feels relaxed from the start.
- Timebox the past, present and future so you leave enough room for the action plan.
- Have everyone add ideas privately before discussion, so quieter voices are on the board too.
- Keep the past focused on learning, not blame, so people stay open.
- Use dot voting to prioritize future ideas and actions so the team works on what matters most.
- Give every action item a clear owner and due date so the future you pictured actually arrives.
## Icebreaker questions
- If you had a time machine, which moment in your career would you go back and relive?
- What's one piece of future technology you wish existed to make your work easier today?
---
# Stranger Things: The Upside Down Retrospective
URL: https://www.teamretro.com/retrospective-templates/stranger-things-the-upside-down-retro/
The Upside Down Retrospective borrows the two-world setup of the Netflix series Stranger Things. Your team looks at the sprint from both sides: the normal world where things worked, and the Upside Down, where problems quietly dragged everyone down.
The board has four columns. The Real World is for wins and processes that ran smoothly. The Upside Down holds the blockers and frustrations that drained energy. The Demogorgons are the risks ahead, like a single point of failure or a release date under threat from scope creep. The Party's Arsenal is where you gather the tools, allies and actions to fight back, and it becomes your action list.
Calling a risk a monster makes it easier to raise in front of the team, and the Demogorgons column means you talk about what could go wrong next, not only what already did. Run it around Halloween, after a chaotic sprint, or when the usual format has gone flat. In TeamRetro you can run it live or asynchronously, group similar ideas and vote on which monsters to tackle first.
## Topics
- **The Real World**: What went well and kept us grounded this sprint?
- **The Upside Down**: What problems dragged us down or felt darker than expected?
- **The Demogorgons**: What monsters, risks or threats are lurking ahead?
- **The Party's Arsenal**: What tools, allies or actions will help us fight back?
## When to use
- Around Halloween, or whenever you want a themed change from your regular sprint retrospective.
- After a tough or chaotic sprint, when problems feel hard to raise. The playful frame lowers the stakes.
- When energy is low and you want a format that gets more people adding notes.
- With newer or quieter team members, who may find it easier to raise risks and blockers as monsters.
## Tips and tricks
- Open with a quick intro to the four areas (the Real World, the Upside Down, the Demogorgons and the Party's Arsenal) so everyone knows where each note goes.
- Keep the theme light but take every concern seriously. A monster label shouldn't make a real risk sound trivial.
- Vote on which Demogorgons and Upside Down problems to tackle first.
- Close by turning the Party's Arsenal ideas into actions, each with an owner and a due date.
- Timebox brainstorming and invite quieter members to share their monsters and wins.
- Use a themed video background or some synth music as people arrive to set the mood.
## Icebreaker questions
- If you could have one Stranger Things character on your team this sprint, who would it be and why?
- What's one 'monster' (work or otherwise) you defeated recently that you're proud of?
---
# Motivation & Development Sprint Retrospective
URL: https://www.teamretro.com/retrospective-templates/motivation-and-development-sprint-retrospective/
Keeping a team motivated and helping each person grow can look like two separate jobs, but they're closely linked. The Motivation & Development Sprint Retrospective puts both on the same board, so your team can talk about what energized them, what drained them and where they want to grow next.
The board has four questions: What energized us? What drained us? Where can we grow? What will we commit to? Answering them opens up topics a standard sprint retrospective tends to skip, like workload, recognition and career progression. You end up talking about how the sprint felt as well as what got delivered, and about the skills people want to build next. What drained us? tends to fill up fastest, so timebox it and protect time for growth and commitments.
Agile teams, people managers and Scrum Masters use it when engagement matters as much as output. Your team leaves knowing what keeps people motivated, with a few specific commitments (some for the whole team, some for individuals) that you can check on at the next retro.
## Topics
- **What energized us?**: What lifted your motivation this sprint?
- **What drained us?**: What sapped your energy or motivation?
- **Where can we grow?**: What skills or areas do you want to develop?
- **What will we commit to?**: What actions will sustain motivation and growth?
## When to use
- When morale or engagement feels low and you want to understand the cause and turn it around.
- At the end of a sprint, when you want to pair a review of the work with personal growth planning.
- During quarterly check-ins, to connect individual development goals with what motivates the team.
- After a period of intense delivery or burnout, to help the team recharge and refocus.
## Tips and tricks
- Make it safe up front, so people can say what drained them without fear of blame.
- Don't let What drained us? take over. Give equal time to energy and growth.
- Ask for development goals that are specific and personal. Generic goals rarely get followed through.
- Give every commitment an owner and a deadline so the conversation leads to real change.
- Watch for dominant voices, and use anonymous input so quieter or more junior team members get an equal say.
- Open each session by revisiting the previous commitments, so accountability builds over time.
## Icebreaker questions
- If your energy this sprint were a weather forecast, what would it be?
- What's one small thing that always puts you in a good mood at work?
---
# Innovation Lab Retreat
URL: https://www.teamretro.com/retrospective-templates/innovation-lab-retreat/
Most brainstorms end with a wall of sticky notes and no follow-through. The Innovation Lab Retreat is built to avoid that. It gives your team a set block of time away from delivery work to come up with new ideas and leave with a short list of experiments that someone owns.
The session moves through four stages in order. Wild Ideas is the divergent part, where nothing is too big or strange and criticism waits. What's Holding Us Back names the barriers, from no protected time to slow approvals. Worth Pursuing narrows the field: the team votes and weighs impact against effort. Launch Plan turns the shortlist into next steps with owners and dates. Anonymous ideas and voting in TeamRetro mean a junior person's idea is judged on its merits, not on who suggested it.
Use it for an offsite, at the start of a product cycle or when the team has been heads-down on delivery for too long. You'll leave with a shortlist of ideas, the obstacles you need to clear and the first steps to test what's most promising.
## Topics
- **Wild Ideas**: What bold or unconventional ideas could we explore?
- **What's Holding Us Back**: What barriers stop us from innovating today?
- **Worth Pursuing**: Which ideas show the most promise and potential?
- **Launch Plan**: What concrete next steps will we commit to?
## When to use
- At a team offsite or retreat where new ideas are the main goal.
- At the start of a product cycle, quarter or strategic initiative that needs a fresh direction.
- After a long stretch of delivery work, when the team hasn't had time to think beyond the backlog.
- When you want a repeatable way to generate ideas, judge them and act on the best ones.
## Tips and tricks
- Protect Wild Ideas from criticism. Say up front that every idea is welcome and judgment comes later, so people share the bold ones.
- Use anonymous ideas to reduce the pull of seniority, so junior voices and unusual ideas get equal attention.
- Timebox each stage tightly. Innovation sessions sprawl, so keep moving from ideas to barriers to priorities.
- Give the realists in What's Holding Us Back the same weight as the dreamers in Wild Ideas. You need both.
- Close with action items that have owners and dates. The biggest risk of an innovation retreat is leaving inspired and changing nothing.
- Keep a backlog of parked ideas so promising but premature ones can come back in a later cycle.
## Icebreaker questions
- If you had unlimited budget and no fear of failure, what's the first thing you'd build?
- What's the most creative idea you've ever had that never saw the light of day?
---
# FLAP Retrospective
URL: https://www.teamretro.com/retrospective-templates/flap-retrospective/
The FLAP retrospective covers four areas: Future considerations, Lessons learned, Accomplishments and Problem areas. Three of them look back at what happened and one looks ahead, so your team celebrates what went well and deals with what didn't before it plans the next stretch of work.
Each quadrant has a job. Accomplishments is for the wins people are proud of. Problem areas is for what the team struggled with. Lessons learned asks what those experiences taught you, and Future considerations turns them into specific next steps. Moving from what happened to what it means keeps the discussion from ending as a list of complaints.
FLAP works well after a milestone or release, or at a quarterly review, when you want one meeting that covers both reflection and planning. Start with Accomplishments to give the conversation some energy, then work around to the future.
## Topics
- **Future considerations**: What direction do we want to take?
- **Lessons learned**: What have our experiences taught us?
- **Accomplishments**: What are we proud of?
- **Problem areas**: What have we struggled with?
## When to use
- When you want one session that covers both looking back and planning ahead
- After a significant project milestone or release
- When the team needs to tackle ongoing problems without losing sight of what's going well
- At a quarterly review, to check progress and plan improvements
## Tips and tricks
- Start with Accomplishments so the team has some energy before it gets to the problems
- Use dot voting to choose which items to discuss in detail
- Turn each Future consideration you keep into a specific action with an owner
- Keep a parking lot for discussions that need to continue after the retrospective
- Record lessons learned in a shared space so later projects can use them
- Timebox each quadrant so no single one takes over
## Icebreaker questions
- What's one thing you learned last week that surprised you?
- If you could instantly master one new skill, what would it be and why?
---
# Treasure Hunt Retrospective
URL: https://www.teamretro.com/retrospective-templates/treasure-hunt-retrospective/
The Treasure Hunt Retrospective is a planning session dressed as an expedition. Your team agrees on the treasure it's after, then works out what could sink the voyage and what it needs to get there.
The board has four columns. Treasure is the goal, described specifically enough that you'll know when you've reached it. Rocks are the risks and issues that could get in the way, from technical debt to a third-party dependency. Navigation covers the practices and principles that will keep you on course, and Crew is for the skills and tools the team has or still needs.
Because it looks forward more than back, it works best at the start of a project, a new quarter or any planning session where the team needs to agree on a target. Naming the rocks and the crew gaps early gives you a short list of risks to manage and resources to ask for before the work begins.
## Topics
- **Treasure**: What is our ultimate treasure?
- **Rocks**: What risks and issues could we face?
- **Navigation**: What will guide our way forward?
- **Crew**: What skills and tools do we need?
## When to use
- At the start of a new project or initiative that needs a clear goal and an early look at risks
- During a strategic planning session, when you want the whole team involved in setting direction
- When the team needs to agree on its objectives and what it will take to reach them
- When you want a planning session that people remember
## Tips and tricks
- Use maritime or adventure language through the session to keep the theme going
- Keep all four columns in view so people can see how the rocks, navigation and crew connect to the treasure
- Go around the room for each column so everyone contributes
- Keep a parking lot for detailed discussions that would derail the main session
- Record each action with an owner and a timeline
- Finish by drawing a treasure map that shows the path forward
## Icebreaker questions
- If you could discover any treasure in the world, what would it be and why?
- What's the best thing you've ever found by accident?
---
# Birthday Bash Retrospective
URL: https://www.teamretro.com/retrospective-templates/birthday-bash-retrospective/
Birthdays bring people together, and the Birthday Bash Retrospective uses that same spirit for a team reflection. Use it to mark a team anniversary, a project launch, a year of working together, or someone's actual birthday. Your team looks back on how far it has come and sets intentions for the period ahead, in a lighter mood than a regular sprint review.
The board has four party-themed topics. Gifts are what the team is grateful for. Candles are the wishes for the future. The Cake holds the sweet wins worth savoring, and Party Spoilers are the things that didn't go to plan. Each metaphor makes honest conversation a little easier while keeping the mood upbeat. In TeamRetro, everyone adds their thoughts independently, then the team groups and votes on the themes that matter most before turning them into actions.
A themed session like this helps a team that's tired of routine retrospectives. Celebrating achievements next to the problems keeps recognition and improvement in the same conversation, and it's a good way to close a significant period on a high note while still capturing what you learned.
## Topics
- **Gifts**: What are you grateful for from this period?
- **Candles**: What do you wish for in the period ahead?
- **The Cake**: Which sweet wins are worth savoring?
- **Party Spoilers**: What didn't go to plan and how can we improve?
## When to use
- Marking a team anniversary, project launch or a full year of working together.
- Closing out a major milestone where celebration and reflection belong side by side.
- Re-energizing a team that's tired of routine sprint retrospectives.
- Building morale and trust through gratitude and recognition.
- Setting shared intentions and wishes for the period ahead.
## Tips and tricks
- Lean into the theme with a festive virtual background, party emojis or even a real cake.
- Start with Gifts to set a positive tone before you look at what didn't go well.
- Keep Party Spoilers blameless by focusing on situations and systems, not individuals.
- Timebox each topic so the session keeps moving and no single section takes over.
- Turn every wish and improvement worth pursuing into a clear, owned action before you close.
- Invite quieter members to share first, or use anonymous entry, so everyone gets recognized.
## Icebreaker questions
- What's the best birthday gift you've ever received, and why did it mean so much?
- If our team threw a party to celebrate this milestone, what would the theme be?
---
# Employee Engagement Retrospective
URL: https://www.teamretro.com/retrospective-templates/employee-engagement-retrospective/
An Employee Engagement Retrospective gives your team a structured way to talk about what keeps them motivated at work and what wears them down. It's a retrospective about the work environment instead of the work itself: priorities, recognition, autonomy, workload and the support people get.
The board has four columns, each a question. What energizes you? and What drains your energy? collect the positives and the frustrations. How can we improve teamwork? looks at collaboration inside the team. How can leadership support us? gathers feedback for managers, so agree beforehand how that feedback will be shared.
Anonymous input matters here more than in most retros, since people are being asked about their managers and their own motivation. Close with a few changes the team can make itself, plus clear requests for leadership, and come back to them at the next session so people see their feedback led somewhere.
## Topics
- **What energizes you?**: What aspects of your work or team environment make you feel motivated and engaged?
- **What drains your energy?**: What workplace factors or experiences leave you feeling disengaged or demotivated?
- **How can we improve teamwork?**: What changes would improve collaboration, communication and team dynamics?
- **How can leadership support us?**: What could managers or leadership do to better engage and enable the team?
## When to use
- To find out early what's affecting motivation, job satisfaction and retention.
- After a period of high turnover, low morale or signs of disengagement.
- During organizational changes that could affect how people feel about their work.
- As part of regular team health checks, to track engagement over time.
- When people need a structured way to say what they'd change about their work environment.
## Tips and tricks
- Set ground rules up front so people know the conversation is judgment-free.
- Make sure everyone contributes, including quieter people and remote team members.
- Have a neutral facilitator keep the discussion constructive and on track.
- Collect ideas anonymously so people don't hold back for fear of repercussions.
- Pair each criticism with a suggested improvement so the session doesn't turn into a list of complaints.
- Turn the main themes into concrete actions with owners, so people see their feedback lead to change.
## Icebreaker questions
- If you could switch roles with anyone on the team for a day, whose job would you want and why?
- What's one small change that would make a big impact on your engagement and motivation?
---
# Incident Response Planning
URL: https://www.teamretro.com/retrospective-templates/incident-response-planning/
Incident Response Planning is a tabletop exercise for the time before anything goes wrong. Your team brainstorms the incidents that could hit your operations, from a security breach to a power outage, then works out how you'd respond, who would do what and how you'd get back to normal.
The board has six topics: Potential Incidents, Response Strategies, Roles and Responsibilities, Communication Protocols, Recovery and Continuity, and Continuous Improvement. Working through them in order turns a vague sense of risk into a written plan with names against each role. Bringing in people from IT, legal, communications and leadership shows where responsibilities overlap or nobody owns a step.
The result is a team that has already rehearsed the first hour of an incident. When something does break, people spend less time deciding who's in charge and more time fixing it.
## Topics
- **Potential Incidents**: What types of incidents could potentially impact our operations?
- **Response Strategies**: How should we respond to these potential incidents?
- **Roles and Responsibilities**: Who should be involved in incident response, and what are their roles?
- **Communication Protocols**: How should we communicate during an incident?
- **Recovery and Continuity**: How can we ensure business continuity and recovery after an incident?
- **Continuous Improvement**: How can we learn and improve from incidents?
## When to use
- When writing or updating your organization's incident response plan.
- After a significant incident or near miss, to find gaps in how you'd respond next time.
- As part of regular risk management and business continuity planning.
- When new team members or stakeholders take on a role in incident response.
- When introducing new systems, processes or technology that change how you'd respond.
## Tips and tricks
- Invite people from every function involved in a response, so the plan reflects how incidents really unfold.
- Keep the discussion blame-free so people are open about weak spots.
- Review the plan regularly as your business, technology and the threats you face change.
- Run practice drills and simulations to test the plan before you need it.
- Agree on communication channels and a named spokesperson before an incident, not during one.
- Rank critical systems, functions and stakeholders so you know what to restore first.
## Icebreaker questions
- If you could have any superpower during an incident response, what would it be and why?
- Share a memorable incident or crisis you've experienced (personal or professional) and how it was handled.
---
# Red Alert Retrospective
URL: https://www.teamretro.com/retrospective-templates/red-alert-retrospective/
When something feels off, it pays to sound the alarm before a small problem becomes a crisis. The Red Alert retrospective is a short, urgent format for finding the risks, blockers and warning signs that threaten your team's goals. It doesn't try to review the whole sprint. It goes straight to what's broken or about to break, and who's going to deal with it.
The board has four areas, worked through in order. Critical Emergencies is for the active, high-severity problems that need action now, like a failing deployment with no rollback plan. Warning Signs covers the smoke before the fire: slowing code reviews, falling test coverage, morale that's lower than usual. Defuse & Stabilize asks what quick safeguards or temporary fixes would lower the temperature. Action Plan & Owners turns all of it into next steps, each with an owner and a deadline.
Use it during or right after an incident, on a project that's slipping, or as a regular risk check in a high-stakes period. Naming risks out loud, in a session where raising an alarm is welcome, makes it less likely that a serious problem stays hidden until it's too late. In TeamRetro the team adds alerts privately, votes on the most critical and leaves with a response plan everyone can see.
## Topics
- **Critical Emergencies**: What is on fire right now and needs immediate action?
- **Warning Signs**: What early signals suggest trouble could be coming?
- **Defuse & Stabilize**: What can we do to reduce risk and regain control?
- **Action Plan & Owners**: Who will do what, and by when, to resolve these alerts?
## When to use
- During or right after an incident or outage, when the team needs to work out what's wrong and stabilize things quickly
- When a project is slipping and you need to surface the critical risks and blockers before they derail delivery
- During a period of rapid change, when hidden problems are likely to escalate if nobody looks for them
- As a regular risk check for teams working in volatile or high-stakes conditions
## Tips and tricks
- Say at the start that raising alarms is welcome and blame-free; people won't name a serious issue if they expect to be blamed for it
- Keep the session tightly timeboxed. A Red Alert works best when it stays short and focused
- Use dot voting to pick the most critical items so you don't try to fix everything at once
- Close with clear owners and deadlines. A Red Alert without follow-up actions only adds to the anxiety
- Watch for the loudest voices taking over, and ask quieter people what warning signs they've noticed
- Check unresolved alerts at the next retrospective so critical items don't quietly disappear
## Icebreaker questions
- What's the most dramatic 'red alert' moment you've experienced in a movie, game, or TV show?
- If your week had a warning light on a dashboard, what color would it be flashing right now?
---
# Tennis Retrospective
URL: https://www.teamretro.com/retrospective-templates/tennis/
The Tennis Retrospective reviews your last sprint or project the way a player reviews a match. Your team looks at the basics that held up, the winners it hit, the points it gave away, the calls that could still go either way and the surprises nobody saw coming.
The board has five columns. Ground Strokes covers the foundational practices that kept you steady, like code reviews and stand-ups. Aces are the clear wins. Unforced Errors are the preventable mistakes, such as skipping a test or leaving someone out of a decision. Deuce holds the open questions where the team is split or unsure, like refactor versus rebuild. Wild Cards are the unexpected events, from a sudden change in requirements to a competitor's launch.
The Deuce column is the unusual one. Most formats only look at what already happened; Deuce gives the team a place to air decisions it hasn't made yet. Use the format after a release or milestone, or when your regular retro has gone stale and the team would enjoy a sporting frame.
## Topics
- **Ground Strokes**: What set us up for success?
- **Aces**: What great wins did we deliver?
- **Unforced Errors**: What mistakes did we make?
- **Deuce**: What things could go either way?
- **Wild Cards**: What unknowns did we encounter?
## When to use
- When your regular retrospective has gone stale and the team needs a different format
- After a major milestone or release, when there's a lot to review
- When you want successes and mistakes to get equal time
- When the team has open decisions it keeps putting off and needs a place to air them
## Tips and tricks
- Use tennis language throughout the session to keep the theme going
- Ask people to think about individual and team performance, the way tennis has singles and doubles
- Encourage a rally: let people build on each other's ideas before moving on
- Set a match length for each column so all five get time
- Try tennis scoring (15, 30, 40) to rank action items
- Keep Unforced Errors blame-free so people own up to mistakes
## Icebreaker questions
- If your last sprint was a tennis match, what would the score be and why?
- Which tennis player's qualities (persistence, precision, adaptability) best describe your team's current strengths?
---
# Lean Coffee
URL: https://www.teamretro.com/retrospective-templates/lean-coffee/
Lean Coffee is a meeting format with structure but no set agenda. At the start, everyone proposes topics they'd like to discuss. The group votes, and the topics with the most votes go first, so the conversation follows what people actually care about.
Each topic gets a short timebox, often 5–8 minutes. When the timer ends, the group votes with a thumbs up or down on whether to keep going or move on. Cards move across three columns (To Discuss, In Progress and Discussed), so you can see what's been covered and what's left.
The Lean Coffee format suits team retrospectives, community of practice meetups and any session where you don't know the right topics in advance. Jim Benson and Jeremy Lightsmith started it in Seattle in 2009, and it's now a common retrospective format for agile teams.
## Topics
- **To Discuss**: What topics should we discuss?
- **In Progress**: This is currently being discussed.
- **Discussed**: These topics have been discussed.
## When to use
- When you want an open discussion and don't know in advance which topics matter most.
- When the team has a backlog of ideas, challenges or questions to work through.
- For community of practice or knowledge-sharing sessions where people bring their own topics.
- When you'd like the group, not the facilitator, to set the agenda.
## Tips and tricks
- Ask for a mix of topics, technical and non-technical.
- Use a timer for every topic and let the group vote on whether to extend it.
- Rotate the facilitator role so the same person isn't always running the meeting.
- Write down decisions and action items in the Discussed column before moving on, then follow them up.
- Run it on an online board when your team is remote, so people can add and vote on topics from anywhere.
## Icebreaker questions
- If you could learn any new skill instantly, what would it be?
- What's the most interesting or unusual hobby you've tried?
---
# Rose Bud Thorn Retrospective
URL: https://www.teamretro.com/retrospective-templates/rose-bud-thorn-retrospective/
The Rose Bud Thorn retrospective uses a garden metaphor to help your team look at a stretch of work from three angles. Roses are the things that went well, Buds are early ideas or opportunities that could grow, and Thorns are the problems that caused pain.
Because every board has positives, possibilities and problems on it, the conversation stays balanced. Nobody leaves with only a list of complaints, and the Buds point to what you could build on next. The metaphor needs no explanation, so the activity works well for teams new to retrospectives and for cross-functional groups that don't share a vocabulary.
You'll see this activity written as both "Rose Bud Thorn" and "Rose Thorn Bud." They're the same exercise listed in a different order, and the meaning of each term never changes: the Rose is a success or highlight, the Thorn is a challenge or pain point, and the Bud is an opportunity showing early promise. Some facilitators prefer the "Rose Thorn Bud" order because it ends the reflection on the forward-looking Bud. Use whichever order your team finds most natural.
LUMA Institute lists Rose, Thorn, Bud as one of its human-centered design methods, adapted from a Boy Scouts of America practice, and it travels well beyond software retrospectives. Teachers use Rose Thorn Bud as a daily classroom check-in, managers use it to open one-on-ones, and families use it around the dinner table. After a project sprint, for example, a team member's Rose might be "we shipped the new onboarding flow on time," their Thorn "QA was rushed in the last two days," and their Bud "the new analytics could tell us which step loses users."
## Topics
- **Rose**: What went well, big or small?
- **Bud**: What's starting to grow that we could build on?
- **Thorn**: What's causing us pain right now?
## When to use
- When you want a balanced view of how the team is doing, positives included
- At a project milestone, to check progress and spot course corrections
- With a team new to retrospectives that needs an easy format to start with
- When you need to talk about problems without the meeting turning negative
- As a quick check-in activity for a workshop, class or one-on-one
## Tips and tricks
- Start with Roses so the team warms up on what's working before it gets to the hard parts
- Ask for specific examples. "The release went fine" tells you less than "the release checklist caught two bugs"
- Give each category similar time so Thorns don't take over
- Look for links between Thorns and Buds. A recurring problem often has a fix already sprouting somewhere
- Leave with actions: one Bud to grow and one Thorn to remove
- Use dot voting to pick which Buds are worth the team's time
## Icebreaker questions
- If your week was a garden, what would be growing in it right now?
- What's your favorite flower and why does it represent you?
---
# Starfish Retrospective
URL: https://www.teamretro.com/retrospective-templates/starfish-retrospective/
Patrick Kua developed the Starfish retrospective so teams could reflect on degrees of change, instead of the usual split between what went well and what didn't. Your team sorts its ideas into five areas: start (new practices to begin), more of (strengths to build on), continue (what works and should stay), less of (activities to scale back) and stop (habits that cost more than they give).
Each idea already points to an action, so it's quick to see where to change course and to agree a plan for the next iteration. The two middle categories are what set the starfish retro apart. A practice that's useful in moderation, like status meetings or client check-ins, can be dialed down without being dropped entirely.
## Topics
- **Start**: What new practices or initiatives should we start?
- **More of**: What existing strengths should we do more of?
- **Continue**: What positive aspects should we continue?
- **Less of**: What areas need to be scaled back or reduced?
- **Stop**: What unproductive practices should we stop?
## When to use
- At the end of a project or major milestone, to decide what to change for the next phase.
- During a process review, when you want to cut waste from how work flows.
- After a team restructure or a change in leadership, to reset goals and habits.
- Every quarter or so, as a deeper check than your regular sprint retro.
## Tips and tricks
- Make it safe to be honest. Agree ground rules before anyone writes a card.
- Have one person facilitate so every voice gets heard.
- Keep the focus on what to do next, not on past mistakes or who caused them.
- Vote on the items that matter most and turn only those into actions.
- Review the last retro's actions at the start of the next one.
## Icebreaker questions
- If our team was a type of fish, what kind would we be and why?
- What's one thing you've learned recently that has made you more effective at work?
---
# KFC Bucket Challenge Retrospective
URL: https://www.teamretro.com/retrospective-templates/kfc-bucket-challenge-retrospective/
The KFC Bucket Challenge is a food-themed retrospective that uses a bucket of fried chicken as the metaphor for your team's recent work. A good bucket comes down to the recipe and how it's cooked, and so does a good sprint. The silly framing makes it easier for quieter people to say what they really think.
The board has four columns: the Secret Recipe (what made you successful), the Soggy Pieces (what didn't quite work), the Extra Crispy (standout moments worth celebrating) and the Refill (what you want more of next time). In TeamRetro, people add ideas privately, then the team groups them, votes and turns the top items into action items.
Use it when your usual retro has gone stale and you want a fun retrospective template that still ends in actions. It suits sprint reviews, project wrap-ups and any meeting where you want the wins to get as much airtime as the problems.
## Topics
- **The Secret Recipe**: What practices made us successful this time?
- **The Soggy Pieces**: What didn't quite work or left a bad taste?
- **The Extra Crispy**: Which standout moments are worth celebrating?
- **The Refill**: What do we want more of next time?
## When to use
- When your regular retrospectives feel stale and the team needs a change of format.
- At the end of a sprint or project, when you want to celebrate wins and find improvements in the same meeting.
- For distributed or hybrid teams that could use a lighthearted theme to get everyone talking.
- When quieter team members hold back, since a playful metaphor makes honest feedback feel lower stakes.
## Tips and tricks
- Set the scene with the food theme at the start. A bit of silliness helps people relax and speak more openly.
- Timebox each column so you don't spend the whole meeting on the Soggy Pieces.
- Give the Extra Crispy column real attention. Naming what went well tells the team what to repeat.
- Use dot voting to pick which Soggy Pieces and Refill ideas matter most before turning them into action items.
- Keep it blame-free: talk about practices and processes, not individuals.
- Finish by giving each action an owner and a due date, so the Refill ideas actually make it onto next sprint's menu.
## Icebreaker questions
- If you could only eat one fast food meal for the rest of your life, what would it be?
- What's your secret ingredient that makes you a great teammate?
---
# F-1 Grand Prix Retrospective
URL: https://www.teamretro.com/retrospective-templates/f1-grand-prix-retrospective/
The F-1 Grand Prix Retrospective treats your sprint as a Formula 1 race. Where did you go flat out, what made you slow down, what needs fixing in the pits, and what will get you over the line faster next time?
The board has four columns. Full Throttle is for the moments the team had momentum. Yellow Flags covers the hazards and blockers that forced you to slow down, named without blaming any driver. Pit Stop is where you decide what needs a tune-up, from tooling and process to skills and team health. Finish Line turns the discussion into a few actions for the next race.
Racing gives the team a shared language for momentum and friction, and the pit crew idea brings collaboration into the conversation naturally. It suits motorsport fans and competitive teams, and anyone else once each column has been explained in a sentence. Keep a tight timebox on each column so the session moves at race pace.
## Topics
- **Full Throttle**: Where did we accelerate and gain speed?
- **Yellow Flags**: What slowed us down or caused caution?
- **Pit Stop**: What needs a tune-up or repair to keep racing?
- **Finish Line**: What will help us cross the line and win next time?
## When to use
- When your standard sprint retrospectives feel stale and the team would enjoy a themed format.
- At the end of a fast or high-pressure sprint where speed, blockers and recovery shaped the result.
- When wrapping up a project and you want a memorable way to capture wins, obstacles and next steps.
- With teams that follow motorsport or enjoy a bit of competition.
- As a quarterly or milestone review of the team's momentum before the next leg.
## Tips and tricks
- Use racing language like laps, pit crew and racing line to keep the framing consistent.
- Set a timebox for each column so the session keeps moving instead of idling on one point.
- Keep Yellow Flags blameless. Talk about obstacles and conditions, not individual drivers.
- Make sure Finish Line ends with a small number of concrete actions, each with an owner.
- Start with anonymous brainstorming so quieter team members get an equal say before group discussion.
- Group and vote on similar ideas to focus on the pit stops that will make the biggest difference.
## Icebreaker questions
- If your work week were a race track, would it be a smooth straightaway or a series of hairpin turns?
- Which Formula 1 driver or team best represents how you tackled this sprint, and why?
---
# Definition of Done
URL: https://www.teamretro.com/retrospective-templates/definition-of-done-retrospective/
Ever shipped something only to find it wasn't really finished? A Definition of Done (DoD) is your team's shared list of criteria that every piece of work has to meet before anyone calls it complete. It applies to every user story, feature and increment, so "done" means the same thing whoever did the work.
In Scrum, the Definition of Done is the quality bar for each increment. Writing it down ends the "is this finished?" debates at review time and stops hidden work, like missing tests or docs, from rolling into the next sprint. This session gets developers, testers, designers and product owners to build the list together, so it covers the steps each of them knows tend to get skipped.
The board has four columns: Quality Criteria, Documentation & Communication, Testing & Validation, and Deployment & Readiness. Everyone adds criteria, then the team groups and votes on them to agree the list. Treat the result as a living document and revisit it as your tooling and standards change. For background, see the [Scrum.org guide to the Definition of Done](https://www.scrum.org/resources/blog/done-understanding-definition-done).
## Topics
- **Quality Criteria**: What quality standards must work meet to be done?
- **Documentation & Communication**: What needs to be documented or shared before done?
- **Testing & Validation**: How do we verify the work actually works?
- **Deployment & Readiness**: What must be true to safely release the work?
## When to use
- When a new team is forming and needs to agree on quality standards from the start.
- When work keeps getting reopened or bugs are reaching production, which usually means people disagree on what finished looks like.
- Before a new project starts, so the team agrees on the bar before work begins.
- When onboarding new members who need to learn the team's quality expectations.
- When a retrospective shows that people on the team treat completion differently.
## Tips and tricks
- Build the Definition of Done with the whole team so everyone owns it. Don't let one person write it alone.
- Keep the criteria realistic. A DoD the team never meets gets ignored.
- Make each criterion specific enough to check, so there's no argument about whether it's been met.
- Revisit it every few sprints as your standards and tooling change.
- Give everyone time to add ideas on their own before the group discussion, so quieter people contribute.
- Keep it separate from acceptance criteria. The DoD applies to all work, while acceptance criteria belong to one story.
## Icebreaker questions
- If 'done' had a personality, what would it be like: perfectionist, pragmatist or last-minute hero?
- What's the most surprising thing you once discovered wasn't actually finished?
---
# Anime Adventure Retrospective
URL: https://www.teamretro.com/retrospective-templates/anime-adventure-retrospective/
In most adventure anime, the hero faces trials, gains allies, fights villains and levels up along the way. The Anime Adventure retrospective tells your team's sprint the same way: wins become power-ups, obstacles become bosses, and the people who helped become the party. Wrapping the conversation in a story makes it easier to raise frustrations without pointing fingers, and it gives a tired team something different from the usual columns.
The board has four topics. Power-Ups & Victories covers the wins and breakthroughs. Villains & Obstacles names the blockers and recurring problems. Allies & Teamwork recognizes the people, teams and tools that helped. The Next Quest sets goals and experiments for the next sprint. Once ideas are added and grouped in TeamRetro, the team votes on the themes that matter most and turns them into action items you can track.
It suits teams who like gaming or storytelling and want a playful session that still ends with real actions. Nobody needs to watch anime to take part, because every prompt maps to an ordinary sprint experience.
## Topics
- **Power-Ups & Victories**: What wins and breakthroughs powered the team forward?
- **Villains & Obstacles**: Which bosses and challenges blocked the team's progress?
- **Allies & Teamwork**: Who and what supported the team on the journey?
- **The Next Quest**: What's the mission and plan for the next adventure?
## When to use
- When your team is tired of the usual retrospective formats and would enjoy something more playful.
- After a challenging or eventful sprint that already feels like a story.
- For teams that like anime, gaming or storytelling and respond well to themed activities.
- With newer teams, where framing problems as bosses to defeat makes them easier to raise.
## Tips and tricks
- Set the scene by framing the sprint as an anime arc in a sentence or two.
- Let people play with the language, but make sure each note points to something real the team can act on.
- Use the villain framing to keep problems impersonal, so people can raise frustrations without blaming anyone.
- Timebox each topic so the session keeps moving and quieter voices get equal airtime.
- Group similar ideas before voting to spot recurring bosses or repeated power-ups.
- Turn the top themes from The Next Quest into owned action items before you close.
## Icebreaker questions
- If your team were an anime party, which character archetype would you be: the hero, the strategist, the comic relief or the wise mentor?
- What anime power or special ability would help you most in your day-to-day work?
---
# Oscar Academy Retrospective
URL: https://www.teamretro.com/retrospective-templates/oscar-academy-retrospective/
The Oscar Academy retrospective borrows the format of a film awards night. Instead of a plain list of what went well, your team nominates the people, decisions and moments that deserve recognition, and talks about why they worked.
The board has four award categories. Best Performance is for standout achievements. Best Actions covers the decisions and practices that led to good outcomes. Best Story is for the experiences the team learned from, including the ones that went wrong. Best Supporting Roles recognizes the tools, people and other teams that helped behind the scenes.
The awards framing makes it easier for people to give specific praise, and the Best Story category leaves room for mistakes without turning the session into a post-mortem. Use it after a milestone or a hard stretch, when the team has earned some recognition and you still want to leave with a couple of things to repeat.
## Topics
- **Best Performance**: What should we shine a light on?
- **Best Actions**: What contributed strongly to our outcomes?
- **Best Story**: What stories did we learn from?
- **Best Supporting Roles**: What tools, people or resources supported us?
## When to use
- When your usual format has gone stale and you want a lighter session that still ends in actions
- After a project milestone or launch that deserves recognition
- When morale is low and the team needs to hear what it's doing well
- When quieter people rarely speak up and a structured round of nominations would help
## Tips and tricks
- Make simple awards or certificates for the winners so the recognition sticks
- Rotate the ceremony host role so someone new runs the awards each time
- Keep the tone light, but make sure each category ends with at least one lesson or action
- Use film terms to hold the theme together, like closing the session with "that's a wrap"
- Play a short music cue between categories if your team enjoys it
- Timebox each award category so the ceremony keeps moving
## Icebreaker questions
- If your last sprint was a movie, what would its title be and why?
- Which famous movie quote best describes your work this past week?
---
# Agile Delivery Maturity Model
URL: https://www.teamretro.com/health-check-templates/agile-delivery-maturity-model/
The Agile Delivery Maturity Model rates 11 practices that decide whether your team's delivery is predictable: how ready the backlog is, how work gets broken down, how much is in progress at once, how stable cycle time is, how often you release, and whether retrospectives and metrics feed back into the next iteration. Each practice sits on a five-stage scale from Ad Hoc through Emerging, Defined and Managed to Optimized, and every stage has a written description, so people rate against the same picture.
The practices fall into four groups: Planning & Prioritization, Delivery Flow, Team Collaboration, and Continuous Feedback & Improvement. When everyone rates on their own first, you see where the team agrees and where it doesn't. A wide spread on Release Cadence or Decision-Making Efficiency usually means people are working from different assumptions, and that's the conversation to have before you pick what to improve.
## Planning & Prioritization
How well the team prepares, decomposes, and aligns on the work it takes on.
- **Backlog Readiness**: How prepared and refined is the team's backlog for upcoming work?
- **Work Decomposition**: How effectively does the team break down work into manageable pieces?
- **Prioritization Alignment**: How well aligned is the team on priorities with stakeholders and business goals?
## Delivery Flow
How smoothly and predictably work moves from start to released value.
- **Work-in-Progress Management**: How well does the team manage the amount of work in progress?
- **Cycle Time Predictability**: How predictable is the time from starting work to completion?
- **Release Cadence**: How regularly and reliably does the team release working software?
## Team Collaboration
How effectively the team works together, shares knowledge, and makes decisions.
- **Cross-Functional Cooperation**: How well do team members with different skills collaborate?
- **Knowledge Sharing**: How effectively does the team share knowledge and reduce silos?
- **Decision-Making Efficiency**: How quickly and effectively does the team make decisions?
## Continuous Feedback & Improvement
How consistently the team reflects, learns, and uses data to get better over time.
- **Retrospective Effectiveness**: How valuable and actionable are the team's retrospectives?
- **Metrics-Driven Improvement**: How well does the team use data and metrics to guide improvement?
---
# Agile Manifesto Principles
URL: https://www.teamretro.com/health-check-templates/agile-manifesto-principles/
The Agile Manifesto Principles health check turns each of the 12 principles behind the Agile Manifesto into a statement about your team, such as *Our working software is the primary measure of progress.* Everyone rates each statement on a five-point scale from Strongly disagree to Strongly agree, so you can see which principles describe how the team really works and which ones it only agrees with on paper.
The statements cover the whole list: early and continuous delivery, welcoming late changes, frequent releases, daily collaboration with the business, motivated individuals, face-to-face conversation, working software, sustainable pace, technical excellence, simplicity, self-organization and regular reflection. The lowest-rated principles, and the ones where the team disagrees most, make a ready-made agenda for your next retrospective.
## Agile Principles
The twelve principles behind the Agile Manifesto, rated by how strongly your team agrees that each reflects the way you actually work.
- **Continuous Delivery**: *Principle 1*. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- **Openness to Change**: *Principle 2*. We welcome changing requirements, even late in development. Our agile processes harness change for the customer’s competitive advantage.
- **Frequent Releases**: *Principle 3*. We deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- **Collaboration**: *Principle 4*. Our business people and developers work together daily throughout the project.
- **Team Enablement**: *Principle 5*. We build projects around motivated individuals. We give them the environment and support they need, and trust them to get the job done.
- **Communication**: *Principle 6*. We have efficient and effective face-to-face conversations to convey information to and within a development team.
- **Working Software**: *Principle 7*. Our working software is the primary measure of progress.
- **Sustainable Development**: *Principle 8*. Our agile processes promote sustainable development. Our sponsors, developers, and users can maintain a constant pace indefinitely.
- **Quality**: *Principle 9*. We pay continuous attention to technical excellence and good design to enhance agility.
- **Simplicity**: *Principle 10*. We embrace simplicity – the art of maximizing the amount of work not done.
- **Self-Organization**: *Principle 11*. The best architectures, requirements, and designs emerge because we are a self-organizing team.
- **Continuous Improvement**: *Principle 12*. At regular intervals, our team reflects on how to become more effective, then tunes and adjusts our behavior accordingly.
---
# Agile Manifesto Values
URL: https://www.teamretro.com/health-check-templates/agile-manifesto-values/
The Agile Manifesto Values health check takes the four values from the Agile Manifesto and asks your team where it really sits on each one. Every dimension runs from the agile value at one end to its traditional counterpart at the other, with a balanced midpoint: individuals and interactions or processes and tools, working software or documentation, customer collaboration or contract negotiation, responding to change or following a plan.
The manifesto itself says the items on the right have value too, so a perfect agile score isn't the goal. What you're looking for is whether the team leans where it means to, and whether people agree. When one person rates Responding to Change as fully agile and another places it near following a plan, you've found a tension worth talking through.
## Agile Manifesto Values
The four foundational values from the Agile Manifesto that guide how agile teams prioritize their work and collaborate.
- **Individuals and Interactions**: Reflects whether the team prioritizes people and direct communication over rigid processes and tooling.
- **Working Software**: Reflects whether the team prioritizes delivering functional software over producing extensive documentation.
- **Customer Collaboration**: Reflects whether the team prioritizes ongoing collaboration with customers over fixed contract terms.
- **Responding to Change**: Reflects whether the team prioritizes adapting to change over strictly adhering to a predefined plan.
---
# Agile Team Assessment
URL: https://www.teamretro.com/health-check-templates/agile-teams/
The Agile Team Assessment asks your team to rate 28 statements about how it works, such as *Backlog refinement keeps upcoming work understood and ready* or *The team addresses technical debt proactively*. Each one sits on a five-level scale from Ad Hoc through Emerging, Defined and Managed to Optimized. The statements are grouped into six areas: teamwork and collaboration, agile ways of working, planning and prioritization, technical excellence and quality, product delivery and customer value, and agile mindset and culture.
Rating on your own first shows where the team agrees and where it doesn't, and the gaps often point to blockers nobody has said out loud. Run it as a recurring agile health check and you'll see whether the practices you chose to work on actually moved up a level. The results also give your next retrospective a clear starting point.
## Teamwork & Collaboration
How well the team communicates, shares ownership, and works together to deliver value.
- **Team Communication**: Team members communicate openly and effectively.
- **Collaborative Problem Solving**: The team collaborates to solve problems rather than working in silos.
- **Raising Blockers Early**: Team members are comfortable raising blockers and challenges early.
- **Cross-Functionality**: The team is cross-functional enough to deliver work end-to-end.
- **Self-Organization & Ownership**: The team is self-organizing and takes ownership of how work gets done.
## Agile Ways of Working (Processes & Ceremonies)
How effectively the team uses agile ceremonies and processes to stay aligned and keep work flowing.
- **Daily Standups**: Daily standups help us synchronize effectively.
- **Backlog Refinement**: Backlog refinement keeps upcoming work understood and ready.
- **Sprint Reviews & Demos**: Sprint reviews (or demos) help us share progress and gather feedback.
- **Retrospectives & Improvement**: Retrospectives lead to useful insights for improving how we work.
- **Flow of Work**: Work items flow smoothly through our process without unnecessary delays.
## Planning & Prioritization
How well the team plans, prioritizes, and forecasts work to maximize value and predictability.
- **Value-Driven Backlog**: The product backlog is prioritized and reflects customer value.
- **Team Involvement in Planning**: The team participates meaningfully in planning work.
- **Estimation & Forecasting**: The team's estimates or forecasts help guide realistic commitments.
- **Adaptive Planning**: Plans adapt based on new information without excessive disruption.
- **Definition of Done**: We understand what "done" means and use it consistently.
## Technical Excellence & Quality
How consistently the team builds in quality, manages technical debt, and sustains a healthy codebase.
- **Quality Built-In**: Quality is built into our work through testing and review practices.
- **Technical Debt Management**: The team addresses technical debt proactively.
- **Test Automation**: Automated tests or checks support our development process.
- **Continuous Integration**: We integrate and test code frequently to avoid large integration issues.
- **Maintainable Codebase**: The team maintains a sustainable, maintainable codebase.
## Product Delivery & Customer Value
How frequently and reliably the team delivers valuable increments and learns from customer feedback.
- **Delivery Frequency**: We deliver working software or product increments frequently.
- **Value Alignment**: Our work directly contributes to customer or business value.
- **Feedback Loops**: We gather customer or stakeholder feedback regularly.
- **Speed to Release Change**: Changes and improvements can be released quickly when needed.
## Agile Mindset, Culture & Continuous Improvement
How deeply the team lives agile values: sustainable pace, learning, adaptability, and a drive to keep improving.
- **Sustainable Pace**: The team maintains a sustainable work pace.
- **Continuous Improvement Mindset**: We actively look for ways to improve our process or outcomes.
- **Learning from Mistakes**: Mistakes are treated as learning opportunities rather than blame events.
- **Embracing Change**: The team embraces change and adapts when needed.
---
# AI Maturity Assessment for Teams
URL: https://www.teamretro.com/health-check-templates/ai-adoption-maturity/
Getting AI tools into a team is the easy part. What decides whether they help is everything around them: which use cases you pick, whether people check the output, what never gets pasted into a prompt, and whether anyone measures the effect. The AI Maturity Assessment for Teams has your team rate 36 statements on those habits, grouped into nine areas that run from AI strategy and leadership to impact measurement.
Each statement sits on a five-stage scale from Ad Hoc to Optimized, with a not-applicable option for any that don't fit your work. Statements like *We verify AI-generated information before using it* and *We document when, how, and why AI is used for important work* keep the ratings concrete, so the discussion is about specific practices instead of general enthusiasm or worry. Compare how far adoption (tools, skills, daily use) has moved against the guardrails (governance, privacy, human oversight); the two should advance together.
## AI Strategy & Leadership
How clearly AI use connects to goals, how use cases are chosen, and how actively leaders support and own responsible adoption.
- **Strategic Alignment**: Our use of AI clearly supports our team, department, or organizational goals.
- **Use Case Prioritization**: We choose AI use cases based on value, feasibility, and risk.
- **Leadership Support**: Leaders actively encourage and guide responsible AI adoption.
- **Ownership & Accountability**: Responsibilities for AI decisions, usage, and outcomes are clearly defined.
## Tool Adoption & Access
Whether the team can get the right AI tools, whether those tools fit the work, and how consistently they're used.
- **Tool Availability**: Team members can access the AI tools they need to do their work well.
- **Tool Fit**: Our AI tools fit the tasks, workflows, and needs of our team.
- **Adoption Consistency**: Team members use AI tools consistently where they add value.
- **Tool Awareness**: We stay informed about new AI capabilities relevant to our work.
## AI Skills & Confidence
The team's understanding of AI, its prompting and critical-thinking skills, and how deliberately it grows them.
- **AI Literacy**: We understand what AI can and cannot do.
- **Prompting Skill**: We give AI clear instructions, context, and constraints.
- **Critical Thinking**: We question, check, and refine AI-generated outputs.
- **Learning & Development**: We invest deliberately in growing our AI skills.
## Workflow Integration
How naturally AI fits into daily work, standard processes, the human-AI balance, and redesigned ways of working.
- **Daily Use**: AI is naturally part of our everyday work.
- **Process Integration**: AI is built into our standard processes, not bolted on.
- **Human-AI Balance**: We know when to rely on AI and when human judgment, expertise, or review is essential.
- **Work Redesign**: We rethink tasks, roles, and workflows to take advantage of AI.
## Data, Knowledge & Context
Whether the team feeds AI reliable data, can reach the knowledge it needs, provides good context, and stewards its assets.
- **Data Quality**: The information we use with AI tools is reliable, accurate, and up to date.
- **Knowledge Access**: We can easily access the internal knowledge needed for AI-assisted work.
- **Context Provision**: We provide AI with the right background, examples, and constraints.
- **Data Stewardship**: We manage ownership, accuracy, and appropriate use of data and knowledge assets.
## Governance, Risk & Compliance
Awareness of AI policy, protection of privacy, attention to bias and fairness, and the auditability of AI use.
- **Policy Awareness**: We understand the organization's AI policies, boundaries, and approvals.
- **Privacy & Confidentiality**: We avoid entering sensitive, personal, or restricted information into AI tools.
- **Bias & Fairness**: We consider bias, fairness, and potential harm in AI-assisted outputs.
- **Auditability**: We document when, how, and why AI is used for important work.
## Output Quality & Human Review
How well the team verifies accuracy, upholds quality standards, applies human oversight, and learns from AI errors.
- **Accuracy Checking**: We verify AI-generated information before using it.
- **Quality Standards**: AI-assisted outputs meet our standards for clarity, accuracy, and professionalism.
- **Human Oversight**: We have clarity on when human review or approval is required.
- **Error Learning**: We learn from AI mistakes, hallucinations, and poor outputs.
## Collaboration & Knowledge Sharing
Whether the team shares practices, experiments safely, learns across teams, and builds reusable AI assets.
- **Shared Practices**: We share useful prompts, examples, workflows, and lessons learned.
- **Experimentation Culture**: Team members feel safe and encouraged to experiment with AI responsibly.
- **Cross-Team Learning**: We learn from other teams, departments, and external examples of AI adoption.
- **Reusable Assets**: We build reusable AI templates, prompt libraries, checklists, and playbooks.
## Impact Measurement & Improvement
Whether the team measures AI's effect on productivity, quality, and business value, and uses what it learns to improve.
- **Productivity Impact**: We assess whether AI saves time or increases team capacity.
- **Quality Impact**: We assess whether AI improves the quality, consistency, and usefulness of our work.
- **Business Value**: We connect AI use to measurable outcomes such as customer value, cost savings, or speed.
- **Continuous Improvement**: We use feedback, results, and lessons learned to improve how we use AI.
---
# AI-Assisted Development Maturity Assessment
URL: https://www.teamretro.com/health-check-templates/ai-assisted-coding-maturity/
Plenty of engineering teams have AI coding assistants installed. Fewer have agreed how to use them: how much context to give, how carefully to review the output, and what should never leave the codebase. The AI-Assisted Development Maturity Assessment has your team rate 28 statements across seven areas: tool adoption, prompting skills, output validation, workflow integration, security and compliance, knowledge sharing, and impact measurement.
Each statement, such as *We review AI-generated code as carefully as human-written code* or *We can tell when a defect originated from AI-assisted code*, is rated on a five-stage scale from Ad Hoc to Optimized, with a not-applicable option where it doesn't fit. The results show where AI is helping, where it adds risk the team hasn't dealt with, and where training or tooling will pay off. Run it quarterly to set a baseline and track how your practice changes.
## Tool Adoption
How broadly and thoughtfully AI coding tools are taken up, configured, and kept current across the team.
- **Tool Coverage**: We use AI coding tools consistently across our daily development work.
- **Configuration Quality**: Our AI tools are well-configured for our codebase, workflows, and project context.
- **Onboarding Support**: New team members get up to speed quickly on our AI tooling and practices.
- **Tool Awareness**: We stay informed about new AI coding capabilities and reassess our toolchain.
## Prompting Skills
How well the team communicates with AI tools: clear prompts, good context, refinement, and right-sized tasks.
- **Prompt Clarity**: We describe tasks to AI tools clearly and precisely.
- **Context Provision**: We give AI tools the right context (code, constraints, and intent) to do their best work.
- **Iterative Refinement**: We refine and redirect AI responses effectively when the first try misses.
- **Task Decomposition**: We break complex work into AI-sized pieces that produce reliable results.
## Output Validation
How rigorously the team reviews, tests, and questions AI-generated code before trusting it.
- **Code Review Rigor**: We review AI-generated code as carefully as human-written code.
- **Test Coverage**: Our AI-generated code is backed by automated tests.
- **Critical Evaluation**: We question and verify AI output rather than accepting it at face value.
- **Bug Attribution**: We can tell when a defect originated from AI-assisted code.
## Workflow Integration
How naturally AI assistance fits into daily habits, the toolchain, team processes, and the human-AI balance.
- **Daily Habit**: AI assistance is naturally part of our day-to-day engineering work.
- **Pipeline Fit**: AI tools fit smoothly into our development environment and CI/CD pipeline.
- **Process Adaptation**: We have adapted our processes to get the most from AI-assisted development.
- **Human-AI Balance**: We know when to rely on AI and when to lean on our own judgment.
## Security & Compliance
How well the team protects sensitive data, follows policy, and manages IP, licensing, and security risks in AI-generated code.
- **Data Handling**: We avoid exposing sensitive or confidential information to AI tools.
- **Policy Adherence**: We consistently follow organizational AI usage policies.
- **IP & Licensing Awareness**: We understand intellectual-property and licensing risks in AI-generated code.
- **Vulnerability Vigilance**: We actively check AI-generated code for security issues.
## Knowledge Sharing
How openly the team captures prompts, shares wins and failures, collaborates across teams, and grows its AI skills.
- **Prompt Libraries**: We document and share effective prompts and AI patterns.
- **Learning Culture**: We openly share wins, failures, and experiments with AI-assisted development.
- **Cross-Team Collaboration**: We exchange AI coding practices with people outside our immediate team.
- **Skill Development**: We invest deliberately in growing our AI-assisted development skills.
## Impact Measurement
How honestly the team tracks AI's effect on productivity and quality, and folds those lessons back into how it works.
- **Productivity Tracking**: We assess whether AI tools genuinely improve our delivery speed.
- **Quality Metrics**: We evaluate whether AI assistance helps or hurts the quality of our work.
- **Retrospective Integration**: We reflect on AI-assisted development during our retrospectives.
- **Continuous Improvement**: We adjust our AI usage based on feedback, outcomes, and lessons learned.
---
# AI in Customer Service Maturity
URL: https://www.teamretro.com/health-check-templates/ai-in-customer-service-maturity/
Support teams use AI to deflect tickets, triage, draft replies, summarize threads and flag churn risk. Used carelessly, it also produces confident wrong answers, off-brand replies, and customer data in tools that shouldn't see it. The AI in Customer Service Maturity model has your team rate 25 practices across seven areas: adoption in service workflows, daily tool use, reply quality and brand voice, escalation and oversight, accuracy and grounding, customer data boundaries, and measurement.
Each practice moves through five stages from Ad Hoc to Optimized, and each stage is described in service terms, such as whether agents edit AI drafts properly before sending or rubber-stamp them. There's a not-applicable option for practices that don't apply to your setup. The result is a team-owned view of where AI has earned its place in your support work and where it still needs guardrails.
## AI Adoption in Service Workflows
How deliberately and completely AI is woven into the service workflows where it can genuinely help, with the right automation stance and clarity on customer-facing touchpoints.
- **Workflow Coverage**: AI is deployed across the service workflows where it can plausibly help (deflection, triage, agent-assist, summarization, churn signals, knowledge surfacing).
- **Workflow-Fit of Tools**: The AI tools we use are well-suited to the service tasks we actually do.
- **Automation Stage**: We have a clear, deliberate stance on which workflows AI advises, which AI drafts, and which AI handles end-to-end.
- **Customer-Facing AI Touchpoints**: The team knows where AI shows up directly in the customer's experience versus only in the agent's tools.
## Tool Usage & Daily Practice
Whether AI tools are embedded in agents' everyday work: used consistently, inside the tools where work happens, and with licenses used by the people who need them.
- **Daily Adoption Rate**: AI tools are part of agents' day-to-day work, not a side experiment.
- **Habit Consistency Across the Team**: AI usage patterns are similar across agents and shifts, not dependent on individual preference.
- **License Utilization**: The AI licenses we pay for are used by the people they were intended for.
- **In-Workflow vs Side-of-Desk**: AI is used inside the helpdesk, CRM, or chat tool where the work happens, rather than copy-pasted to and from a separate window.
## Reply Quality & Brand Voice
Whether AI-touched replies sound like your brand, match the emotional register of each conversation, and read with clear, plain-language clarity.
- **Voice Consistency on AI-Touched Replies**: AI-drafted or AI-touched replies sound like our brand, not like a generic AI.
- **Empathy & Tone Calibration**: AI replies match the emotional register of the conversation rather than sounding flat or chirpy.
- **Customer Readability**: AI-touched replies are clear, plain-language, and free of model-isms (filler phrases, hedging, "I'm an AI assistant…", etc.).
## Escalation & Oversight
How reliably AI knows its limits: handing off when unsure, staying out of sensitive cases, getting meaningful human review, and learning from overrides.
- **Confidence-Aware Handoff**: AI replies only when its confidence in the answer warrants it, and hands off cleanly when it doesn't.
- **Crisis & Edge-Case Handling**: Sensitive, escalated, or high-risk cases are kept out of AI's hands by design.
- **Human Review Before Send**: Agents review AI-drafted replies meaningfully before sending, rather than rubber-stamping them.
- **Override Patterns**: When agents override AI recommendations, that signal is captured and used to improve the system.
## Accuracy & Grounding
Whether the team treats AI output with calibrated skepticism, grounds answers in trusted sources, and trusts AI signals at the right level.
- **Hallucination Awareness**: The team understands that AI can confidently invent facts, and treats output with appropriate skepticism.
- **Knowledge-Base Grounding**: AI replies are grounded in our knowledge base, product docs, and policies rather than generated from the model's training data alone.
- **Signal Reliability (Churn, Risk, Sentiment)**: AI-generated signals (churn predictions, account-health scores, sentiment ratings) are trusted appropriately: neither ignored nor over-relied on.
## Customer Data Boundaries
How well the team keeps sensitive customer data away from AI, discloses AI use appropriately, and scopes each tool's data access to what it genuinely needs.
- **Sensitive-Case Carve-Outs**: Customer data classes that should not reach AI (health info, payment data, regulated identifiers, internal-only context) are kept out by design.
- **Consent & Disclosure**: Customers know when AI is involved in their interaction, in line with our policy and applicable regulation.
- **AI Data Access Scope**: The team knows what data each AI tool can see (tickets, CRM, billing, internal notes) and limits scope to what each tool actually needs.
## Measurement & Improvement
Whether the team measures AI's operational impact, captures failures into an improvement loop, understands ROI, and iterates on its AI setup on a regular cadence.
- **Operational Metrics for AI**: We track the operational signals that tell us whether AI is helping (deflection rate, draft-accept rate, time-to-resolution delta, CSAT delta).
- **Failure Capture Loop**: When AI fails (wrong answer, bad tone, missed escalation), the failure is captured and feeds an improvement loop.
- **ROI & Cost Awareness**: We know what we're spending on AI and what we're getting back, well enough to make sensible scale-up and scale-down decisions.
- **Iteration Cadence**: The team revisits how it uses AI on a regular cadence: prompts, rules, tool choices, off-limits topics.
---
# Community of Practice
URL: https://www.teamretro.com/health-check-templates/community-of-practice/
A Community of Practice runs on goodwill. People show up while they're learning something and drift off when they aren't, usually without saying why. The Community of Practice health check asks members to rate five areas on a three-level scale: Knowledge Sharing, Alignment, Collaboration, Feedback, and Motivation and Fun.
Each level is described in plain terms, so Knowledge Sharing runs from No sharing to Sharing thrives, and Motivation and Fun from Bored to Energized. The results show where the community is working and where a small change, such as a regular sharing slot or a clearer shared goal, could bring quieter members back in.
## Community of Practice
Explore the health of your Community of Practice across knowledge sharing, alignment, collaboration, feedback, and motivation.
- **Knowledge Sharing**: Gauges whether members have the opportunity, means, and willingness to share and learn from one another.
- **Alignment**: Reflects how clearly the community shares a common focus on its goals and challenges.
- **Collaboration**: Measures how effectively members work together to solve complex problems.
- **Feedback**: Assesses whether members feel safe and are encouraged to give and receive feedback.
- **Motivation and Fun**: Captures how engaged and inspired members feel to learn and grow within the community.
---
# Customer Support & Success
URL: https://www.teamretro.com/health-check-templates/customer-support/
Fast replies are only part of a good customer experience. The rest is consistent processes, success plans that lead somewhere, help content customers can actually use, and feedback that reaches the people who build the product. The Customer Support & Success maturity assessment has your support and customer success teams rate 12 practices in four groups: Support Operations, Customer Success Outcomes, Knowledge & Enablement, and Voice of Customer.
Each practice, from escalation management to renewal and retention, is rated on a five-level scale from Ad Hoc to Optimized. Ad Hoc means reactive and inconsistent; Optimized means proactive and built to scale. When support and success staff rate the same practice differently, talk that through before you agree which gaps to close first.
## Support Operations
Evaluate how efficiently and consistently the team resolves customer issues, applies support workflows, and manages escalations.
- **Issue Resolution Effectiveness**: How quickly and effectively customer issues are resolved.
- **Support Workflow Consistency**: Quality and consistency of support processes across the team.
- **Escalation Management**: How well the team handles complex or high-severity issues.
## Customer Success Outcomes
Assess how well the team drives customer adoption, monitors account health, and manages renewals and retention.
- **Success Planning & Goal Alignment**: How well success plans guide customers toward meaningful outcomes.
- **Account Health Monitoring**: Visibility into customer health and risk indicators.
- **Renewal & Retention Management**: How effectively the team retains customers and manages renewals.
## Knowledge & Enablement
Examine the quality of customer-facing knowledge, enablement resources, and how insights are shared internally.
- **Knowledge Base Quality**: Accuracy, usefulness, and accessibility of customer-facing knowledge resources.
- **Customer Enablement Resources**: How effectively customers are taught to use the product.
- **Internal Knowledge Sharing**: How well support and success teams share insights internally.
## Voice of Customer (VOC)
Gauge how systematically customer feedback is captured, shared across teams, and used to track and improve satisfaction.
- **Feedback Collection & Analysis**: How effectively customer feedback is gathered, processed, and understood.
- **Cross-Functional Insight Sharing**: How VOC insights influence product, engineering, and business decisions.
- **Customer Satisfaction Tracking**: How effectively customer sentiment is monitored and acted upon.
---
# Data & Analytics
URL: https://www.teamretro.com/health-check-templates/data-and-analytics/
The Data & Analytics maturity model rates 15 capabilities across the data lifecycle, in five groups: Data Quality & Governance, Reporting & Insight, Infrastructure & Accessibility, Experimentation & Optimization, and Data Literacy & Culture. Each one, from data accuracy to self-service access and insight-to-action speed, is rated on a five-stage scale from Ad Hoc to Optimized.
Data teams and the people who use their work can see the same capability very differently. A report the BI team considers reliable may be the one product managers have quietly stopped opening. Rating separately and then comparing brings those gaps into the open, and gives you a shared basis for deciding which investment comes next.
## Data Quality & Governance
How accurate, well-governed, and secure your data is across the organization.
- **Data Accuracy & Reliability**: How trustworthy, consistent, and error-free data is across systems.
- **Data Governance & Ownership**: How clearly data responsibilities, rules, and standards are defined.
- **Data Security & Access Control**: How well data is protected while remaining accessible to authorized users.
## Reporting & Insight
How reliably reporting, dashboards, and insights support confident decisions.
- **Reporting Reliability**: How consistently reporting is available, accurate, and timely.
- **Dashboard & Insight Usability**: How easy it is for teams to interpret and act on insights.
- **Decision Support**: How effectively data informs strategic and operational decisions.
## Infrastructure & Accessibility
How well data infrastructure scales, integrates, and serves the people who need it.
- **Data Infrastructure Scalability**: How well data systems scale and perform as the business grows.
- **Self-Service Accessibility**: How easily teams can access the data they need without bottlenecks.
- **System Integration**: How well data flows between tools, systems, and teams.
## Experimentation & Optimization
How rigorously the organization tests, measures, and acts to improve outcomes.
- **Experiment Framework & Rigor**: How structured and rigorous experimentation practices are.
- **Conversion & Funnel Analysis**: How well the organization measures and optimizes user journeys.
- **Insight-to-Action Speed**: How quickly insights lead to changes in product or process.
## Data Literacy & Culture
How confidently and consistently people across the organization use data in their work.
- **Data Literacy Across Teams**: How confident teams are in reading, interpreting, and using data.
- **Cultural Adoption of Analytics**: How deeply data-driven decision-making is embedded in the culture.
- **Continuous Improvement Mindset**: How actively teams seek to improve using data and insights.
---
# Developer Experience Survey (DevEx)
URL: https://www.teamretro.com/health-check-templates/developer-experience/
A developer experience survey asks developers how their everyday work feels: how fast they get feedback, how hard it is to understand the code and tools, and how often they get to focus. This one is based on the DevEx framework from Abi Noda, Margaret-Anne Storey, Nicole Forsgren and Michaela Greiler, published in [ACM Queue in 2023](https://queue.acm.org/detail.cfm?id=3595878). It groups developer friction into three dimensions: feedback loops, cognitive load and flow state.
Each person rates 12 statements privately. The team then looks at the results together and turns the lowest scores into actions in a retrospective. For a broader view of developer productivity, use the [SPACE Framework Health Check](/health-check-templates/space-framework/). For software delivery, use the [DORA Metrics Self-Assessment](/health-check-templates/dora-metrics/).
## Feedback Loops
How quickly people get useful responses to their work, from tools and from each other.
- **Build & Test Speed**: Our builds and tests run fast enough that we rarely wait on them.
- **Review Turnaround**: Code reviews come back quickly enough to keep work moving.
- **Release Confidence**: We can release a change confident that it won't break something.
- **Getting Help**: When we're stuck, we know who to ask and get help quickly.
## Cognitive Load
How much mental effort it takes to get work done in our code, tools and processes.
- **Understandable Code**: Our codebase is easy to understand and safe to change.
- **Finding Information**: We can find the documentation or information we need without hunting for it.
- **Helpful Tools**: Our development tools help us more than they get in our way.
- **Light Process**: Our processes, such as tickets, approvals and handoffs, are no heavier than they need to be.
## Flow State
How often people can focus fully on meaningful work.
- **Deep Focus**: Most days we have long stretches of time to concentrate on our work.
- **Few Interruptions**: We're rarely pulled away from our work by interruptions or switching between tasks.
- **Clear Goals**: We know what we're working on and why it matters.
- **Autonomy**: We have real freedom to decide how we do our work.
---
# Development Practices Radar
URL: https://www.teamretro.com/health-check-templates/development-practices-radar/
The Development Practices Radar is a short health check for software teams. Your team rates six statements on a five-point scale from Strongly disagree to Strongly agree: scope is clear, coding standards are agreed and followed, people have time to focus, technical debt is monitored and managed, time-consuming and high-stakes features have automated tests, and deployment is automated and reliable.
Six dimensions keep it quick enough to run every quarter, and a weak spot is easy to see. If Ability to Focus scores low across the team, that's a specific problem to raise with whoever sets priorities. Use the results to agree on one or two changes, then check at the next run whether they stuck.
## Development Practices
Core engineering practices that influence how effectively the team plans, builds, tests, and delivers quality software.
- **Clarity of Scope**: Our scope of work is clear and well-defined.
- **Shared Coding Standards**: We have an agreed set of coding standards that are defined and adhered to.
- **Ability to Focus**: We have the time and opportunity to focus on the work we have planned.
- **Managing Technical Debt**: We monitor and manage our technical debt.
- **Testing Practices**: We have functional test automation for time consuming, high stake features.
- **Deployment Process**: We have automated deployment that is reliable and quality assured.
---
# DevOps Maturity Assessment
URL: https://www.teamretro.com/health-check-templates/devops-continuous-delivery/
The DevOps Maturity Assessment covers the path from commit to production in five groups: CI/CD Pipeline, Release & Deployment, Reliability & Operations, Security & Compliance Automation, and Platform & Infrastructure. Your team rates 15 capabilities, such as integration frequency, deployment risk reduction, on-call sustainability and compliance as code, on a five-level scale from Ad Hoc to Optimized.
Teams that ship rarely tend to know the symptoms: manual steps in every release and an on-call rotation that wears people out. The ratings show which capability is the real bottleneck. Because each level has a written description, developers, SREs and product people rate the same capability against the same picture, and the gaps between their views show where to look first.
## CI/CD Pipeline
How effectively the team builds, integrates, and gains feedback through automated pipelines.
- **Build Automation**: How reliably and automatically software builds are generated and validated.
- **Integration Frequency**: How often developers integrate changes into the shared codebase.
- **Pipeline Feedback**: Speed and clarity of information returned to developers from the pipeline.
## Release & Deployment
How safely, predictably, and frequently the team ships changes to users.
- **Deployment Automation**: Level of automation and repeatability of deployments.
- **Deployment Risk Reduction**: How effectively the team minimizes risk during release.
- **Delivery Frequency**: How often value is shipped to users.
## Reliability & Operations
How well the team observes, responds to, and sustains the health of running systems.
- **Monitoring & Observability**: How well the team understands system health and behavior.
- **Incident Response**: How efficiently the team responds to and resolves incidents.
- **On-Call Sustainability**: Fairness and effectiveness of on-call processes.
## Security & Compliance Automation
How deeply security and compliance are automated and embedded across the delivery pipeline.
- **Security Integration**: How effectively security practices are embedded into development workflows.
- **Vulnerability Management**: How quickly and effectively vulnerabilities are discovered and addressed.
- **Compliance as Code**: Use of automation to enforce regulatory, security, and policy requirements.
## Platform & Infrastructure
How automated, consistent, and resilient the underlying platform and infrastructure are.
- **Infrastructure Automation**: How infrastructure is provisioned, managed, and scaled.
- **Environment Consistency**: How consistent development, staging, and production environments are.
- **Platform Reliability**: System uptime, resilience, and fault tolerance.
---
# DORA Metrics Self-Assessment for Teams
URL: https://www.teamretro.com/health-check-templates/dora-metrics/
[DORA](https://dora.dev/guides/dora-metrics-four-keys/) (DevOps Research and Assessment), the research program now part of Google Cloud, identified a small set of software delivery metrics that predict how well teams perform. Three measure throughput: how often you deploy, how long a change takes to reach production, and how quickly you recover from a failed deployment. Two measure instability: how often deployments fail, and how many deployments are unplanned fixes.
Most teams don't have these numbers on a dashboard. This self-assessment is a team version of DORA's one-person [Quick Check](https://dora.dev/quickcheck/): everyone picks the range that matches their experience of the last three months. The answer ranges are TeamRetro's, not DORA's official benchmarks. Where people pick different ranges, that gap is the first thing to talk about. Take the weakest metric into your retrospective and agree on one change to improve it.
## Throughput
How quickly and how often changes reach production.
- **Deployment Frequency**: How often does our team deploy to production?
- **Change Lead Time**: How long does it take a committed change to reach production?
- **Failed Deployment Recovery Time**: When a deployment fails and needs immediate attention, how long does it take us to recover?
## Instability
How often deployments go wrong and need fixing.
- **Change Fail Rate**: What share of our deployments need immediate intervention, such as a rollback or hotfix?
- **Deployment Rework Rate**: What share of our deployments are unplanned, made to fix a problem in production?
---
# Engineering Excellence Maturity Model
URL: https://www.teamretro.com/health-check-templates/engineering-excellence/
Engineers usually know where the codebase hurts. What's harder is agreeing as a team which problems matter most and how far along you are in fixing them. The Engineering Excellence Maturity Model has your team rate 12 practices in four groups (Code Quality & Standards, Architecture & Scalability, Technical Debt Management, and Engineering Collaboration & Enablement) on a five-level scale from Ad Hoc to Optimized.
Because every level is described, the ratings turn vague feelings about quality into something specific: code review that catches bugs but doesn't spread knowledge, or technical debt everyone knows about but nobody tracks. That shared language helps engineers and leaders agree on what to improve first. Run it regularly and you'll see whether the changes you made moved the practices up a level.
## Code Quality & Standards
How consistently the team writes clean, maintainable, well-reviewed code guided by shared standards.
- **Coding Standards Consistency**: How consistently the team applies shared coding guidelines.
- **Code Maintainability**: The ease with which code can be read, understood, modified, and extended.
- **Code Review Quality**: How effectively code reviews improve quality and team learning.
## Architecture & Scalability
How clearly the system is architected and how well it scales, performs, and manages technical risk.
- **Architectural Clarity**: How well the system's architecture is defined, documented, and understood.
- **Scalability & Robustness**: Ability of the system to handle growth, performance demands, and reliability needs.
- **Technical Risk Management**: How effectively engineering risks are identified, assessed, and mitigated.
## Technical Debt Management
How visibly technical debt is tracked, reduced, and connected to its impact on delivery.
- **Debt Visibility**: How technical debt is identified, tracked, and communicated.
- **Debt Reduction Practices**: How effectively the team addresses and reduces technical debt.
- **Impact Awareness**: Understanding of how technical debt affects velocity, quality, and risk.
## Engineering Collaboration & Enablement
How effectively the team shares knowledge, spreads skills, and equips developers with the tools to do great work.
- **Knowledge Sharing**: How effectively engineering knowledge and expertise are shared across the team.
- **Skill Breadth & Flexibility**: The team's ability to work across multiple areas of the system.
- **Developer Enablement**: Quality of tools, processes, and environment supporting developer productivity.
---
# Extreme Programming Values
URL: https://www.teamretro.com/health-check-templates/extreme-programming-values/
Extreme Programming (XP) rests on five values: Communication, Simplicity, Feedback, Courage and Respect. The practices XP is known for, like pair programming, continuous integration and test-driven development, are hard to sustain when those values are weak. Pairing doesn't work without respect, and nobody refactors a risky module without some courage.
The Extreme Programming Values health check turns each value into a plain statement, such as *We aim for simplicity and avoid waste* or *We are willing to do the right thing and work on tough problems*, and asks your team to rate how consistently it lives up to it, from Rarely to Consistently. Start the discussion with the lowest-scoring value: it's often the one holding the others back.
## Extreme Programming Values
The five core values that underpin Extreme Programming and shape how the team collaborates, builds, and improves.
- **Communication**: We communicate well and in a way that achieves our goals.
- **Simplicity**: We aim for simplicity and avoid waste.
- **Feedback**: We ask for, receive and give feedback to improve our practice.
- **Courage**: We are willing to do the right thing and work on tough problems.
- **Respect**: We respect and encourage one another.
---
# Feedback and Innovation Culture
URL: https://www.teamretro.com/health-check-templates/feedback-and-innovation-culture/
Good ideas often die quietly. Someone holds back early feedback because the last suggestion went nowhere, or an idea gets built before anyone tests the assumption behind it. The Feedback and Innovation Culture health check asks each team member to rate 10 statements about those everyday moments, such as *My feedback on ideas is actionable and helps improve the idea* and *I can share my learnings, including failures without fear or judgment*.
Ratings use a five-point scale from Strongly disagree to Strongly agree, and because the statements are written in the first person, people answer for their own experience. The results show where ideas move freely and where psychological safety, ownership or evidence-based decisions need work. Use them to talk about how an idea gets from first mention to delivery, and how the team recognizes the people who take the initiative.
## Feedback and Innovation
How the team gives and receives feedback, validates ideas, and takes ownership to drive innovation.
- **Early Feedback**: When an idea arises, I can give early feedback that is positive and constructive, even if not all feedback is accepted.
- **Motivation to Give Feedback**: I can easily give feedback that is appreciated and well-received.
- **Benefit from Feedback**: My feedback on ideas is actionable and helps improve the idea.
- **Validate Ideas Early**: I focus on removing uncertainty and proving assumptions before I implement ideas.
- **Openness to Evidence**: I have the opportunity to test and gather data for ideas and to provide evidence within certain constraints.
- **Objectivity**: My decisions are weighted more toward objective results rather than individual opinions.
- **Individual Agency**: I am free to own and implement ideas and solutions independently, without undue barriers.
- **Taking Responsibility**: I am happy to take full responsibility for the implementation of our projects.
- **Appreciation for Taking Responsibility**: I experience open appreciation for taking responsibility and initiative.
- **Learning from Mistakes**: I can share my learnings, including failures without fear or judgment to help others avoid making the same mistake.
---
# Financial Management Maturity Model
URL: https://www.teamretro.com/health-check-templates/finance-maturity-model/
A financial management maturity model shows how reliable your finance practices are today and what the next level looks like. This one covers nine areas in three groups: planning and forecasting, control and compliance, and cash flow and financial health. Each area has five written levels, from Ad Hoc (no formal budget, costs hard to predict) to Optimized (scenario planning, automated controls and continuous monitoring).
Everyone rates on their own first, so you can see where finance and the rest of the business disagree. Those gaps are usually the best place to start, for example when the finance team rates forecast accuracy as Defined and department heads rate it Emerging. Run it again each planning cycle and compare, so you can see whether the changes you made moved the scores.
## Financial Planning & Forecasting
Evaluate how well budgets, forecasts, and financial decisions are connected to strategic priorities and reliable enough to guide the business.
- **Budgeting Process**: How clearly budgets are created and followed.
- **Forecast Accuracy**: How well financial forecasts predict actual performance.
- **Strategic Financial Alignment**: How well finances support strategic goals.
## Financial Control & Compliance
Gauge the strength of expense management, internal controls, and audit readiness that keep the organization compliant and protected from risk.
- **Expense Management**: Effectiveness of tracking and controlling expenses.
- **Compliance & Audit Readiness**: How well financial processes meet compliance standards.
- **Internal Controls**: Strength of internal financial controls.
## Cash Flow & Financial Health
Assess how confidently the organization manages cash, revenue, and costs to stay resilient and fund sustainable growth.
- **Cash Flow Management**: Effectiveness of managing cash inflows and outflows.
- **Revenue Management**: How effectively revenue is tracked, recognized, and optimized.
- **Cost Optimization**: How effectively costs are optimized without sacrificing value.
---
# The Five Ideals of DevOps
URL: https://www.teamretro.com/health-check-templates/five-ideals-of-devops/
The Five Ideals come from Gene Kim's 2019 novel The Unicorn Project, the follow-up to The Phoenix Project. They describe what developers need to do their best work: code they can change locally without breaking someone else's, focus and flow, improvement of daily work, psychological safety, and customer focus.
Each ideal becomes one statement your team rates from Strongly disagree to Strongly agree. The low scores show where developers are blocked by complexity, slowed by technical debt or unsure whether it's safe to raise a problem. Use the results to pick one ideal to work on before the next check.
## The Five Ideals
The five guiding principles from The Unicorn Project that shape high-performing DevOps cultures.
- **Local and Simple**: We can make local code changes in a simple way without impacting others.
- **Focus and Flow**: Our work environment is engaging and even joyful. We have small batching, single piece flow with continual feedback.
- **Improvement of Daily Work**: We have limited technical debt and our architecture lets us work efficiently, deliver value faster, and benefit the business.
- **Psychological Safety**: Our team members feel safe to talk about problems openly and to address issues without fear.
- **Customer Focus**: We value the context (systems that deliver the core product) to the customer as essential and resource them appropriately, but also understand the core (what customers are willing and able to pay for).
---
# Flow Metrics Self-Assessment for Teams
URL: https://www.teamretro.com/health-check-templates/flow-metrics/
Flow is how work moves through a team from started to finished. [The Kanban Guide](https://kanbanguides.org/english/) names four flow metrics that every Kanban team must track: work in progress, throughput, work item age and cycle time. Most teams can already get these numbers from tools such as Jira, Azure DevOps, Linear or GitLab.
This check asks how the team experiences flow, not what the numbers are. Each person rates 10 statements privately, covering shared definitions, visible work, limiting work in progress, stuck work and predictability. Put your tool's flow charts next to the results when you discuss them, then turn the lowest scores into actions in a retrospective.
## Definitions & Visibility
Whether the team agrees on what its work is and can see all of it.
- **Started & Finished**: We all agree on when a piece of work counts as started and when it counts as finished.
- **Visible Work**: All of our work, including unplanned requests, is visible in one place.
## Limiting Work in Progress
Whether the team keeps unfinished work low enough for items to keep moving.
- **Finish Before Starting**: We finish work already in progress before we start something new.
- **Work in Progress Limits**: We keep the amount of work in progress low enough that items keep moving.
## Stuck Work
Whether aging and blocked work gets noticed and dealt with.
- **Oldest Items First**: We regularly check our oldest unfinished items and act on them.
- **Blockers Cleared**: Blockers are raised as soon as they appear and cleared quickly.
- **Worked On, Not Waiting**: Our work items spend more time being worked on than sitting and waiting.
## Predictability
Whether the team knows how long work usually takes and finishes it at a steady rate.
- **Known Timeframes**: We know how long similar work usually takes and plan around it.
- **Steady Finishing Rate**: We finish items at a steady rate rather than in big bursts.
## Learning From Flow
Whether the team uses its flow data to improve how it works.
- **Flow Data in Retros**: We look at our flow data in retrospectives and change how we work because of it.
---
# Gallup Q12 Questions: Engagement Survey
URL: https://www.teamretro.com/health-check-templates/gallup-q12/
Gallup's Q12 grew out of interviews with over a million employees: twelve drivers that consistently predict engagement, retention and performance, arranged as a four-level hierarchy from basic needs up to growth. These twelve drivers map into a team engagement pulse you can run and discuss together. (Wording here is TeamRetro's own, mapped to the framework; the official Q12 is Gallup's.)
## Basic needs (What do I get?)
The foundational conditions people need before anything else: clarity on expectations and the resources to deliver.
- **Expectations**: I'm clear on what's expected of me in my role.
- **Resources**: I have the tools and resources I need to do my job well.
## Support (What do I give?)
Whether people feel their contribution is valued, through strengths, recognition, care and development.
- **Strengths**: My role lets me use my strengths every day.
- **Recognition**: Good work here gets noticed and acknowledged.
- **Caring**: My manager and teammates care about me as a person.
- **Development**: Someone here actively supports my growth.
## Belonging (Do I belong?)
Whether people feel heard, connected to a shared purpose, and part of a team that cares about quality.
- **Voice**: My opinions are heard and taken into account.
- **Purpose**: Our team's purpose makes my work feel meaningful.
- **Quality commitment**: My teammates are committed to doing high-quality work.
- **Belonging**: I have strong, supportive relationships at work.
## Growth (How do we grow?)
Whether people see progress and real opportunities to learn and develop over time.
- **Progress**: I get regular, useful feedback on my progress.
- **Learning**: I have real opportunities to learn and grow here.
---
# Great Teams
URL: https://www.teamretro.com/health-check-templates/great-teams-health-check/
The Great Teams health check asks each person to rate five statements about how their team works: psychological safety, dependability, role clarity, meaning and value. Each one is rated from 1 (Never) to 5 (Always), so the answers tell you how often each condition is true for people.
The five areas closely match the team dynamics Google described in its Project Aristotle research. With one statement per area, the check takes a few minutes, which makes it easy to run every month or quarter and watch the trend. Start the discussion with the lowest average or the widest spread, and agree one or two actions.
## Team Effectiveness
The core conditions that enable a team to do meaningful, dependable, and high-impact work together.
- **Psychological Safety**: I feel safe voicing my opinion freely and honestly. I can ask questions without judgment.
- **Dependability**: I produce high-quality work in a timely manner.
- **Role Clarity**: I have specific and clear performance standards and understand my role, objectives, and key results.
- **Meaning**: I find that my work has meaning and a purpose.
- **Value**: My efforts, along with the team, help advance our goals, missions, and vision.
---
# Individual AI Maturity Assessment
URL: https://www.teamretro.com/health-check-templates/individual-ai-self-assessment/
Each person rates their own AI practice on 36 statements in nine areas, from strategy and tool access through prompting skill, data handling and governance to measuring the impact of their AI use. Every statement has five levels, from Ad Hoc to Optimized, with a written description at each step, so you can see exactly what the next level looks like.
It works best as a personal development tool. Run it individually, then look at the team's combined results to see which skills are common and which are rare, for example a team that prompts well but rarely checks AI output before using it. A Not applicable option covers statements that don't fit someone's role, so nobody has to guess.
## AI Strategy & Leadership
How well your AI use is aligned to organizational goals, prioritized thoughtfully, and owned with accountability.
- **Strategic Alignment**: I use AI in ways that clearly support my team, department, or organizational goals.
- **Use Case Prioritization**: I choose where to apply AI based on value, feasibility, and risk, not on novelty.
- **Leadership Awareness**: My manager and leadership know how I use AI and have given clear expectations about it.
- **Personal Ownership**: I take responsibility for what AI does on my behalf: the outputs, the decisions, and the consequences.
## Tool Adoption & Access
Whether you have the right AI tools, use them consistently, and stay current on new capabilities relevant to your work.
- **Tool Availability**: I have access to the AI tools I need to do my work well.
- **Tool Fit**: The AI tools I use fit the tasks I actually do.
- **Personal Adoption Consistency**: I use AI consistently in the places it adds value, rather than reaching for it only occasionally.
- **Awareness of New Capabilities**: I keep myself current on what AI can newly do that is relevant to my work.
## AI Skills & Confidence
Your ability to understand AI, craft effective prompts, think critically about outputs, and grow your skills over time.
- **AI Literacy**: I understand what AI can and cannot do, and where its limits sit.
- **Prompting Skill**: I give AI clear instructions, context, and constraints to get useful output.
- **Critical Thinking**: I question, check, and refine AI-generated outputs rather than taking them at face value.
- **Personal Learning & Development**: I invest deliberately in growing my AI skills.
## Workflow Integration
How deeply AI is embedded in your daily work, standard processes, and the balance between AI and human judgment.
- **Daily Use**: AI is naturally part of my everyday work.
- **Process Integration**: AI is built into my standard ways of working, not bolted on at the edges.
- **Human–AI Balance**: I know when to rely on AI and when my own judgment, expertise, or review is essential.
- **Work Redesign**: I rethink how I work to take advantage of what AI changes, not just add AI to old habits.
## Data, Knowledge & Context
The quality of information you bring to AI, your access to internal knowledge, and how responsibly you handle data.
- **Data Quality**: The information I use with AI tools is reliable, accurate, and up to date.
- **Knowledge Access**: I can easily get to the internal knowledge I need for AI-assisted work.
- **Context Provision**: I give AI the right background, examples, and constraints so its output fits my situation.
- **Personal Data Stewardship**: I manage the data and knowledge I work with responsibly: accuracy, ownership, and appropriate use.
## Governance, Risk & Compliance
Your awareness of AI policy, privacy obligations, bias risks, and your ability to account for how AI was used.
- **Policy Awareness**: I know my organization's AI policies, boundaries, and approval requirements.
- **Privacy & Confidentiality**: I keep sensitive, personal, or restricted information out of AI tools that shouldn't see it.
- **Bias & Fairness**: I think about bias, fairness, and potential harm in AI-assisted output before using it.
- **Auditability**: I keep enough of a trail to explain when, how, and why I used AI for work that matters.
## Output Quality & Human Review
How rigorously you verify AI-generated content, maintain your quality standards, and learn from AI errors.
- **Accuracy Checking**: I verify AI-generated information before relying on it.
- **Personal Quality Standards**: My AI-assisted output meets my standards for clarity, accuracy, and professionalism.
- **Human Oversight**: I have a clear sense of when human review or approval is required for AI-assisted work.
- **Error Learning**: I learn from AI mistakes, hallucinations, and poor outputs rather than just moving on.
## Collaboration & Knowledge Sharing
How actively you share AI knowledge, experiment with new approaches, learn from others, and build reusable assets.
- **Sharing What Works**: I share useful prompts, examples, workflows, and lessons with my team rather than hoarding them.
- **Personal Experimentation**: I feel safe trying new things with AI and learning from what doesn't work.
- **Learning From Others**: I learn from how other people, teams, and external examples use AI well.
- **Reusable Personal Assets**: I build reusable AI templates, prompt libraries, checklists, or playbooks for the work I do often.
## Impact Measurement & Improvement
Whether you track the real impact of your AI use on productivity and quality, and continuously improve your practice.
- **Personal Productivity Impact**: I notice whether AI is actually saving me time or increasing my capacity.
- **Quality Impact**: I notice whether AI improves the quality, consistency, or usefulness of my work.
- **Outcome Connection**: I can connect my AI use to outcomes that matter: customer value, time saved, mistakes avoided, work shipped.
- **Continuous Improvement of My AI Practice**: I use feedback, results, and lessons to keep improving how I use AI.
---
# Leadership Maturity Model
URL: https://www.teamretro.com/health-check-templates/leadership-maturity-model/
A leadership maturity model describes how leadership capabilities develop, from Ad Hoc habits to practices that are consistent and keep improving. This one covers 12 capabilities in four groups: vision and strategic alignment, communication and influence, team development and support, and adaptability and innovation. Each has five written levels, from Ad Hoc to Optimized.
Leaders can rate themselves, but the results are more useful when their teams rate too. The gap between how leaders see their own communication or coaching and how their people experience it is usually the conversation worth having. Pick one or two capabilities to work on each cycle, then run it again to see what moved.
## Vision & Strategic Alignment
How clearly leaders set direction, align teams to strategy, and make effective decisions.
- **Clarity of Vision**: How clearly leadership communicates direction and purpose.
- **Strategic Alignment**: How well teams and leaders align to strategic goals.
- **Decision-Making Effectiveness**: How effectively leaders make timely, informed decisions.
## Communication & Influence
How effectively leaders communicate, collaborate with stakeholders, and inspire others.
- **Communication Quality**: How effectively leaders communicate with their teams.
- **Stakeholder Collaboration**: How well leaders collaborate with other departments and stakeholders.
- **Influence & Motivation**: How well leaders inspire and influence others positively.
## Team Development & Support
How well leaders coach, develop talent, and recognize and support their people.
- **Coaching & Mentoring**: How well leaders support employee growth.
- **Talent Development**: How effectively leaders develop future leaders and capabilities.
- **Recognition & Support**: How effectively leaders provide recognition and support.
## Adaptability & Innovation
How effectively leaders guide change, encourage innovation, and drive continuous improvement.
- **Change Leadership**: How effectively leaders guide teams through change.
- **Innovation Support**: How well leaders encourage new ideas and experimentation.
- **Continuous Improvement Leadership**: How committed leaders are to improving processes and outcomes.
---
# Atlassian Leadership Team Health Monitor
URL: https://www.teamretro.com/health-check-templates/leadership-team-health-monitor/
The Leadership Team Health Monitor is Atlassian's version of its Health Monitor for leadership groups. On a leadership team, the problems are more often trust, candor and pulling in the same direction than delivery. So this version rates eight attributes that matter at the top, including team cohesion, encouraging difference, suitable ways of working and continuous improvement. Everyone rates each one red, amber or green, and the reds set the agenda for the conversation.
## Eight attributes
The eight attributes that distinguish a high-performing leadership team, from cohesion and candor through to continuous improvement.
- **Team cohesion**: We have the trust, respect and connection to work as one leadership team, not a group of individuals.
- **Balanced team**: We have the right people, skills and clearly defined roles around this table.
- **Encouraging difference**: We actively seek different viewpoints and work through disagreements with respect.
- **Shared understanding**: We're aligned on our mission, priorities and the milestones that matter.
- **Value and metrics**: We're clear on the value we're accountable for and use metrics to make decisions.
- **Suitable ways of working**: Our meetings, decisions and tools help us lead well rather than get in the way.
- **Engagement and support**: We're engaged and present, and we back each other and our teams.
- **Continuous improvement**: We regularly step back to reflect on and improve how we lead together.
---
# Marketing Maturity Assessment
URL: https://www.teamretro.com/health-check-templates/marketing-maturity/
A marketing maturity assessment shows how consistently your marketing team plans and measures its work. This one rates 12 areas in four groups: strategy and positioning, content and messaging, campaign execution, and analytics and performance. Each area has five written levels, from Ad Hoc to Optimized.
Everyone on the team rates on their own first. Where scores differ, you'll usually find different expectations, for example a marketing lead who rates attribution as Managed while the analysts rate it Emerging. Use the lowest scores to decide where to invest next quarter, and run it again to see whether that work paid off.
## Strategy & Positioning
Examine how clearly marketing strategy, value proposition, and market understanding guide decisions and differentiate the business.
- **Marketing Strategy Clarity**: How clearly marketing goals and strategy are defined and understood.
- **Value Proposition Strength**: How clearly the product's value is articulated.
- **Market Understanding**: Depth of understanding of market size, trends, and competitive landscape.
## Content & Messaging
Assess how well content and messaging align to the customer journey and reinforce a consistent, high-quality brand voice.
- **Content Strategy Alignment**: How well content supports the customer journey.
- **Messaging Consistency**: How consistent messaging is across channels.
- **Content Quality & Production**: Quality and cadence of content creation.
## Campaign Execution
Review how campaigns are planned and run, how channels perform, and how effectively leads are qualified and nurtured.
- **Campaign Planning & Execution**: How well campaigns are scoped, planned, and executed.
- **Channel Effectiveness**: Effectiveness of chosen channels in reaching target audiences.
- **Lead Quality & Nurturing**: How effectively leads are qualified and nurtured.
## Analytics & Performance
Gauge how marketing performance is measured, attributed to ROI, and improved through structured experimentation.
- **Marketing Metrics & Reporting**: How consistently marketing performance is measured and reported.
- **Attribution & ROI Clarity**: Understanding of which activities drive results.
- **Experimentation & Optimization**: How effectively experiments improve marketing performance.
---
# AI Readiness & Adoption Maturity Assessment
URL: https://www.teamretro.com/health-check-templates/organizational-ai-adoption-maturity/
Adopting AI across an organization takes strategy, leadership, skills, data, governance and a clear view of what AI is delivering. The tools are the easy part. This assessment gives a leadership team a structured way to rate the rest: 25 dimensions in seven areas, from AI strategy and executive sponsorship through adoption across functions, people and capability, data and foundations, and governance, to value realization.
Each dimension is rated on a five-stage scale from Ad Hoc to Optimized. The results show where AI is part of how work gets done, where it's improvised, and where governance has fallen behind adoption. Use it to set a baseline, get leaders to agree how much risk they'll accept for how much ambition, and track progress as adoption deepens.
## AI Strategy & Vision
Whether the organization has a clear, shared direction for AI: why it matters, how far to push it, and which use cases to back.
- **Strategic Direction on AI**: The organization has a clear, articulated view of why AI matters, where it fits, and what it is meant to change.
- **Ambition vs Risk Posture**: The organization has settled how far it is willing to push AI adoption and how much risk it accepts in doing so.
- **Use-Case Portfolio**: The organization knows which AI use cases it is investing in across functions and why those cases were chosen.
## Leadership & Sponsorship
Whether senior leaders own AI, fund it credibly, use it themselves, and coordinate it across the business.
- **Executive Ownership**: A senior leader is accountable for AI as a whole, with the authority to make decisions across functions.
- **Investment Commitment**: The organization invests in AI at a level matched to its stated ambition, and the investment is funded predictably.
- **Visible Leadership Use**: Leaders use AI themselves and talk about it openly; AI adoption isn't something they ask of others without doing.
- **Cross-Function Coordination**: AI work is coordinated across functions rather than each team buying tools, writing policy, and running pilots on its own.
## Adoption Across Functions
How broadly and deeply AI is actually used across the business, and whether adoption is balanced across customer-facing and internal work.
- **Breadth of Function Coverage**: AI is in active use across the major functions of the business (people, finance, operations, sales, marketing, support, product), not just one or two.
- **Depth Within Functions**: Where AI is used, it is used substantively: embedded in workflows, not bolted on at the edges.
- **Front-Office vs Back-Office Balance**: AI adoption is balanced between customer-facing work and internal operations, rather than concentrated in one side of the business.
## People & Capability
Whether the organization has the AI literacy, specialist skills, shared learning, and talent pathways to do AI well and keep getting better.
- **Baseline AI Literacy**: Employees across the organization have the baseline AI literacy expected of their role: they can use AI tools sensibly and know their limits.
- **Specialist Capability**: The organization has the specialist AI capability it needs (data, ML/ops, prompt design, governance) to do AI well in the areas that warrant it.
- **Internal Community & Knowledge Sharing**: People learning about AI find each other, share what works, and lift the organization's collective skill faster than individuals could alone.
- **Hiring & Career Pathways**: The organization hires for AI capability where it matters and offers career pathways that retain the people it develops.
## Data & Foundations
Whether the data, platforms, and vendor estate AI depends on are ready, shared, and managed at the organization level.
- **Data Readiness**: The data AI needs to do useful work (accurate, accessible, well-governed) is in a state to support the AI use cases the organization has chosen.
- **Technology Foundations**: The platforms, integrations, and tooling AI relies on are in place, not improvised under each new initiative.
- **Vendor & Tool Management**: AI vendors and tools are chosen, integrated, and rationalized at the organization level, not bought one team at a time.
## Governance, Risk & Compliance
Whether AI is governed responsibly: clear policy, managed risk, regulatory compliance, and ethics applied in real decisions.
- **AI Policy & Acceptable Use**: The organization has a clear, current, and known policy on what AI tools people can use, on what data, and for what purposes.
- **Risk Management**: AI-specific risks (hallucination, bias, data leakage, model drift, vendor dependency) are recognized, assessed, and managed alongside other organizational risks.
- **Regulatory & Compliance Posture**: The organization tracks the regulations that apply to its AI use, complies with them, and adapts as the rules change.
- **Ethics & Responsible Use**: The organization has a working position on AI ethics (fairness, transparency, human oversight, impact on people) and applies it in actual decisions.
## Value Realization
Whether the organization measures what AI actually delivers, understands its cost and ROI, learns from failure, and keeps improving its AI practice.
- **Outcome Measurement**: The organization measures what AI is actually delivering (productivity, quality, revenue, cost, customer experience), not just adoption metrics.
- **Cost & ROI Visibility**: The organization knows what it is spending on AI in total and what it is getting back, well enough to make sensible scale-up and scale-down decisions.
- **Failure Capture & Learning**: When AI initiatives underperform or fail, the organization captures what happened and uses it to improve later work.
- **Continuous Improvement of AI Practice**: The way the organization does AI work (strategy, governance, capability, delivery) is itself reviewed and improved as the field changes.
---
# People Operations Maturity Model
URL: https://www.teamretro.com/health-check-templates/people-operations-maturity-model/
An HR or people operations maturity model shows how well developed your people practices are across the employee lifecycle. This one rates 15 areas in five groups: hiring and onboarding, performance and growth, culture and engagement, people operations excellence, and workforce planning and capability. Each area has five written levels, from Ad Hoc to Optimized.
Ask HR, managers and a sample of employees to rate on their own. HR may rate a process by how it's designed, while managers and employees rate it by how it works in practice, and that gap shows where to focus. Use the lowest scores to set priorities, give each one an owner, and run it again after the next planning cycle.
## Hiring & Onboarding
How effectively the organization attracts, selects, and integrates new talent into the team.
- **Hiring Process Effectiveness**: How consistently and effectively the organization attracts and selects qualified candidates.
- **Candidate Experience**: How positive and clear the hiring experience is for candidates.
- **Onboarding Quality**: How well new hires are integrated into their roles and the organization.
## Performance & Growth
How clearly performance is managed and how well employees are supported to grow and develop.
- **Performance Management Process**: The clarity, fairness, and effectiveness of performance evaluation.
- **Feedback & Coaching**: How regularly and constructively feedback is exchanged.
- **Career Development**: How well employees understand and pursue growth opportunities.
## Culture & Engagement
How connected, safe, and collaborative people feel within the organization.
- **Employee Engagement**: How connected, motivated, and committed employees feel.
- **Psychological Safety**: How safe employees feel to speak up, take risks, and raise concerns.
- **Collaboration & Team Dynamics**: How well teams work together to achieve shared goals.
## People Operations Excellence
How well HR policies, systems, and retention practices support a reliable, fair employee experience.
- **Policy Clarity & Consistency**: How well HR policies are documented, communicated, and applied.
- **HR Systems & Tools**: How effectively HR technologies support people operations.
- **Retention & Workforce Stability**: How well the organization retains strong talent.
## Workforce Planning & Capability
How well the organization plans staffing, builds skills, and prepares for future role transitions.
- **Strategic Workforce Planning**: How well staffing plans align with long-term organizational needs.
- **Capability Development**: How effectively the organization builds required skills and competencies.
- **Succession & Role Coverage**: How well the organization prepares for role transitions and continuity.
---
# Product Management Maturity
URL: https://www.teamretro.com/health-check-templates/product-management/
A product management maturity model shows how consistently your team sets direction, chooses what to build and learns from customers. This one rates 15 practices in five groups: vision and strategy, roadmapping and prioritization, execution and collaboration, data and customer insight, and market and stakeholder alignment. Each has five written levels, from Ad Hoc to Optimized.
The aim is to see whether your team delivers outcomes or only ships features. Have product, engineering, design and business stakeholders rate on their own, then compare. If engineers rate requirement clarity as Emerging while product managers rate it Managed, you've found your first conversation. Turn the lowest scores into a short improvement plan with owners.
## Vision & Strategy
How clearly the product direction is defined, aligned to business goals, and measured for success.
- **Product Vision Clarity**: How clearly the long-term product direction is articulated and understood.
- **Strategic Alignment**: How effectively product goals map to business objectives.
- **Success Metrics**: How well outcomes are defined, measured, and used to guide decisions.
## Roadmapping & Prioritization
How effectively the team communicates direction, sequences work by value, and keeps stakeholders aligned.
- **Roadmap Clarity**: How clearly the roadmap communicates direction and expectations.
- **Prioritization Discipline**: How effectively the team selects work based on value and trade-offs.
- **Stakeholder Alignment**: Quality of alignment between product, engineering, and business stakeholders.
## Execution & Collaboration
How well the team turns clear requirements into incremental value through strong cross-functional teamwork.
- **Requirement Clarity**: How well the team understands the problems to solve and the intended outcomes.
- **Cross-Functional Collaboration**: How effectively PMs, engineering, and design collaborate.
- **Incremental Delivery**: Ability to break work into small, testable, valuable increments.
## Data & Customer Insight
How deeply the team grounds decisions in evidence, customer understanding, and ongoing feedback.
- **Evidence-Based Decision Making**: Use of analytics, measurements, and insights in product planning.
- **Customer Understanding**: Depth of understanding of customer needs, context, and behaviors.
- **Feedback Integration**: How effectively customer and stakeholder feedback informs product direction.
## Market & Stakeholder Alignment
How well the team reads the market, validates product–market fit, and communicates with stakeholders.
- **Competitive Awareness**: Understanding of market trends, competitor activity, and opportunities.
- **Stakeholder Communication**: Clarity, transparency, and effectiveness of communication with stakeholders.
- **Market Fit Validation**: How effectively product decisions are validated with real market needs.
---
# Product Maturity Model
URL: https://www.teamretro.com/health-check-templates/product-strategy-customer-value/
A product maturity model rates how well an organization turns product strategy into customer value across the whole lifecycle. This one covers 25 practices in five groups: product strategy and customer value; discovery, innovation and experimentation; engineering excellence, platform and DevOps; customer success and market performance; and data, measurement and enterprise operations. Each practice has five written levels, from Ad Hoc to Optimized.
Because it spans product, engineering, customer success and data, run it with people from all of those groups. The results show where ideas go untested or where the technical and operational base is holding delivery back, and they give everyone the same picture to plan from.
## Product Strategy & Customer Value
How clearly product direction is set, how deeply customers are understood, and how reliably work is prioritized around value and outcomes.
- **Product Vision & Direction**: Product direction is clear, strategic, and aligned with customer needs.
- **Customer Understanding**: Teams deeply understand user needs, behaviors, and motivations.
- **Value Prioritization**: Work is prioritized based on customer and business value.
- **Outcome Measurement**: Success defined by outcomes rather than output volume.
- **Market & Stakeholder Alignment**: Product decisions consider competition, trends, and stakeholder needs.
## Discovery, Innovation & Experimentation
How well teams test assumptions, validate ideas early, share learning, and create the conditions for innovation to thrive.
- **Hypothesis & Experimentation Discipline**: Teams test assumptions through structured experiments before committing to solutions.
- **Prototype & Concept Validation**: Teams validate ideas early through prototypes and user tests.
- **Insight Sharing & Knowledge Management**: Research insights are captured, shared, and used across teams.
- **Learning Culture**: Teams and leaders embrace learning, reflection, and adaptation.
- **Innovation Enablement**: The organization encourages experimentation, creativity, and new ideas.
## Engineering Excellence, Platform & DevOps
How strong the technical foundations are across code quality, automation, delivery pipelines, architecture, and technical debt.
- **Code Quality & Maintainability**: Engineering teams write clean, maintainable code aligned to standards.
- **Automation & Test Coverage**: Automated tests ensure quality, reduce regression, and support rapid delivery.
- **Continuous Integration & Deployment**: Teams integrate and deploy frequently with minimal risk.
- **Architecture & Scalability**: Systems are robust, scalable, and designed for long-term sustainability.
- **Technical Debt Management**: Technical debt is visible, prioritized, and intentionally reduced.
## Customer Success & Market Performance
How effectively the organization listens to customers, drives engagement and retention, supports users, and positions itself in the market.
- **Customer Feedback & Voice of Customer**: Feedback is gathered regularly and informs product and service decisions.
- **Customer Engagement & Retention**: Customers actively use and gain value from the product or service.
- **Support Efficiency & Quality**: Customer issues are resolved quickly and effectively.
- **Customer Health Insights**: The organization monitors and understands customer risk and adoption.
- **Market Positioning & Fit**: The organization understands its competitive landscape and product-market fit.
## Data, Measurement & Enterprise Operations
How well data is governed and trusted, how insights and experiments inform decisions, and how efficiently operations run at scale.
- **Data Quality & Governance**: Data is accurate, accessible, and trusted across the organization.
- **Reporting & Insights**: Performance is measured with meaningful, timely dashboards and reports.
- **Experimentation & Data-Driven Decisions**: Data and experiments inform decisions across teams.
- **Operational Efficiency**: Processes are standardized, efficient, and continuously improved.
- **Automation & Tooling**: Automation supports quality, scalability, and operational excellence.
---
# Google Project Aristotle Team Assessment
URL: https://www.teamretro.com/health-check-templates/project-aristotle/
Google's People Analytics team studied 180 of its own teams to answer one question: what makes a team effective? The research, code-named Project Aristotle, found that how a team works together matters far more than who is on it. Five dynamics stood out: psychological safety, dependability, structure and clarity, meaning, and impact. Psychological safety mattered most, and Google described it as the base the other four rest on.
Your team rates all five, two statements each, so you can see which dynamic is holding the rest back and agree what to change. The statements are TeamRetro's own wording, based on the dynamics Google published through re:Work.
## Psychological safety
Whether people feel safe to take interpersonal risks in front of each other: to admit a mistake, ask a question or offer an idea.
- **Owning mistakes**: When I get something wrong on this team, it isn't used against me.
- **Speaking up**: I can raise a half-formed idea or an awkward question without worrying how it will look.
## Dependability
Whether teammates reliably deliver quality work on time, so people can count on each other.
- **Follow-through**: When someone on this team commits to something, it gets done.
- **Reliable work**: I can rely on my teammates' work being good and on time.
## Structure and clarity
Whether roles, plans and goals are clear, and everyone knows how decisions get made.
- **Clear roles**: I know what is expected of me and what each of my teammates is responsible for.
- **Clear goals**: Our goals are specific, and I know how they will be measured.
## Meaning
Whether the work matters personally to each person on the team.
- **Personal meaning**: I care about the work I do on this team, not just about getting it done.
- **Motivation**: What I work on here connects to something I value.
## Impact
Whether people can see that the team's work makes a difference.
- **Contribution**: I can see where our team's work shows up in what the organization is trying to achieve.
- **Difference made**: Our work makes a real difference to the people it is for.
---
# Google Project Oxygen Manager Assessment
URL: https://www.teamretro.com/health-check-templates/project-oxygen/
Google's Project Oxygen set out to prove managers didn't matter, and found they mattered enormously. Its research identified ten behaviors that consistently separate great managers, from strong coaching to sound decision-making (Google expanded the list from eight to ten in 2018). Run this as an upward-feedback check: a manager's direct reports rate them anonymously on all ten behaviors. What comes back is honest feedback aimed at development, not a performance score. Use it to show a manager where they're strong and where they can grow, and to start a better-informed conversation about how they lead.
## Ten behaviors of great managers
The ten behaviors Google's Project Oxygen research found consistently distinguish great managers, rated by their direct reports.
- **Is a good coach**: My manager gives me actionable feedback that helps me improve.
- **Empowers, doesn't micromanage**: My manager trusts me to own my work without micromanaging.
- **Inclusive, cares about wellbeing**: My manager shows they care about me as a person and includes different perspectives.
- **Productive & results-oriented**: My manager keeps us focused on the results that matter.
- **Communicates & listens**: My manager listens, and shares the information we need.
- **Supports career development**: My manager has had a meaningful conversation with me about my career recently.
- **Clear vision & strategy**: My manager sets clear goals and direction for the team.
- **Key technical skills**: My manager has the expertise to advise the team effectively.
- **Collaborates across the org**: My manager works well across team boundaries.
- **Strong decision-maker**: My manager makes tough decisions clearly and in good time.
---
# Psychological Safety Assessment for Teams
URL: https://www.teamretro.com/health-check-templates/psychological-safety-check/
Psychological safety is a shared belief that it's safe to take interpersonal risks on your team: to admit a mistake, raise a problem, ask for help or offer a half-formed idea. Amy Edmondson defined it in her 1999 study of work teams and built a seven-item scale to measure it.
This assessment covers all seven items, one statement each, in TeamRetro's own wording: learning from mistakes, raising tough issues, feeling heard, risk taking, asking for help, team support, and skills and talents. Everyone answers anonymously on a five-point scale. The combined result shows which items are strong and which need work, and the spread shows whether some people feel much less safe than others. Run it every quarter to see whether what you changed made a difference.
## Psychological Safety
How safe team members feel to take interpersonal risks, share ideas, and be their authentic selves.
- **Learning and Growth**: Mistakes are treated as opportunities to learn rather than reasons for blame.
- **Tough Issues**: Team members can openly raise problems and difficult topics without hesitation.
- **Feeling Heard**: Every voice is respected, and no one is dismissed or rejected for being different.
- **Risk Taking**: It feels safe to try new approaches and take risks without fear of negative consequences.
- **Asking for Help**: Team members can comfortably reach out to one another for support when needed.
- **Team Support**: Colleagues act with good intent and do not undermine each other's efforts.
- **Skills and Talents**: Each person's unique strengths are recognized, valued, and put to good use.
---
# Quick Pulse Check
URL: https://www.teamretro.com/health-check-templates/quick-pulse-check/
A pulse check is a short survey you run often, so you can see how your team's mood moves over time. This one asks five questions: how people feel about the speed and quality of the work, their freedom to do the job well, how the team works together, learning and growth, and the value the team creates. Each is a three-point rating, so it takes a minute or two to answer.
Run it every week or two, or at the start of each retrospective, and watch the trend more than any single result. When a score drops, ask why in your next retro, before a small frustration turns into a real blocker.
## Team Pulse
Capture how the team feels across the core drivers of a healthy, productive working environment.
- **Speed and Quality**: How do you feel about the speed and quality of our work?
- **Autonomy**: How do you feel about the freedom you have to do your job well?
- **Team Work**: How do you feel about how well the team is working together?
- **Learning**: How do you feel about the sharing and growth opportunities in the team?
- **Value**: How do you feel about the value that the team creates?
---
# Remote Team Happiness
URL: https://www.teamretro.com/health-check-templates/remote-team-happiness/
Remote work gives people flexibility, but it makes it harder to notice when someone is struggling. Roles blur, people hear from each other less, and nobody sees who's working late. The Remote Team Happiness check asks your team to rate eight areas of remote work: Role Clarity, Autonomy, Impact, Engagement, Support, Connectedness, Psychological Safety and Personal Well-being.
Each person rates on a simple three-point scale from wherever they work, so you get an honest read without getting everyone onto the same call. Low scores on Connectedness or Personal Well-being are often the first sign of isolation or burnout, and they're far easier to act on early. Run it every month or quarter and watch how the scores move.
## Remote Team Happiness
Explore the factors that shape how happy, engaged, and supported people feel while working remotely, from role clarity and autonomy to connection and personal well-being.
- **Role Clarity**: Reflects how clearly each person understands their role and what is expected of them.
- **Autonomy**: Captures whether people have the freedom and flexibility to do their job without unnecessary blockers.
- **Impact**: Measures how meaningful and valuable people feel their work is toward shared goals.
- **Engagement**: Indicates whether people can deliver outcomes effectively with the right time and resources.
- **Support**: Reflects how well people feel supported by colleagues, processes, tools, and resources.
- **Connectedness**: Captures how connected people feel to their team and the wider organization.
- **Psychological Safety**: Measures the level of trust and safety people feel in their everyday team interactions.
- **Personal Well-being**: Reflects whether people have routines that support positive mental and physical health.
---
# SaaS Growth & Lifecycle
URL: https://www.teamretro.com/health-check-templates/saas-growth-lifecycle/
The SaaS Growth & Lifecycle check rates how mature your team's growth practices are across five areas: Acquisition & Activation, Engagement & Retention, Monetization & Billing, Analytics & Lifecycle Optimization, and Growth Strategy & Market Fit. Each area has three dimensions, such as onboarding effectiveness, retention practices, billing reliability and experimentation capability, for 15 in all.
Every dimension is rated on a five-level scale from Ad Hoc to Optimized, and each level has its own description, so everyone rates against the same picture of what good looks like. Product, growth and customer success see the same gaps at the same time. Use the results to pick two or three dimensions for next quarter's plan, then run it again to check progress.
## Acquisition & Activation
Assess how well the team attracts the right customers and successfully guides them to initial product value.
- **Ideal Customer Profile Clarity**: How well the team understands who the product is designed for and why.
- **Onboarding Effectiveness**: How well onboarding helps users reach initial value.
- **Activation Metrics & Tracking**: How activation is measured and used to drive improvements.
## Engagement & Retention
Evaluate how effectively the team monitors user engagement, reduces churn, and maintains long-term customer health.
- **Customer Engagement Insight**: Visibility into how users interact with the product over time.
- **Retention Practices**: Processes and mechanisms supporting long-term user retention.
- **Customer Health Visibility**: How well the team understands account health and risk signals.
## Monetization & Billing
Assess the maturity of pricing strategy, billing operations, and the team's ability to identify and capture expansion revenue.
- **Pricing Clarity & Fit**: How well pricing aligns with customer value and market expectations.
- **Billing Reliability**: Consistency and effectiveness of subscription and billing operations.
- **Expansion Opportunity Identification**: How effectively upsell and cross-sell opportunities are identified and acted upon.
## Analytics & Lifecycle Optimization
Evaluate the team's ability to instrument funnels, run experiments, and personalize the customer lifecycle using data.
- **Funnel Visibility**: How well acquisition, activation, retention, and revenue funnels are understood.
- **Experimentation Capability**: The team's ability to run meaningful A/B tests, trials, and lifecycle experiments.
- **Lifecycle Personalization**: How well the experience adapts to user stage, segment, and behavior.
## Growth Strategy & Market Fit
Assess the clarity of market positioning, the repeatability of the growth strategy, and how rigorously product-market fit is validated.
- **Market Positioning**: How clearly the product is positioned relative to competitors and market needs.
- **Growth Framework & Strategy**: The clarity and execution of a repeatable growth strategy.
- **Market Fit Validation**: How effectively product-market fit is measured and strengthened over time.
---
# Sales & Marketing AI Maturity Model
URL: https://www.teamretro.com/health-check-templates/sales-marketing-ai-maturity/
Most sales and marketing teams adopted AI quickly, for prospect research, outreach drafts, content, lead scoring and call analysis. Getting the tools is the easy part. Running them with discipline, so the output stays accurate and within the rules, is harder, and that's what this maturity model measures.
It has seven dimension groups: AI Adoption in Sales & Marketing Workflows, Tool Usage & Daily Practice, Brand Voice & Content Integrity, Personalization & Targeting, Accuracy & Fairness, Outbound Compliance & Data Boundaries, and Measurement & Improvement. Each dimension is scored on a five-stage scale from Ad Hoc to Optimized, and every stage is described, so your team rates against the same picture.
The results show where AI is helping and where volume has outrun quality. Use them to decide where to scale AI and where to hold back.
## AI Adoption in Sales & Marketing Workflows
How deliberately AI is applied across the sales and marketing workflows where it can genuinely help, and how well the automation level fits each one.
- **Workflow Coverage**: AI is deployed across the sales and marketing workflows where it can plausibly help (prospect research, outreach drafting, content generation, lead scoring, call analysis, personalization).
- **Workflow-Fit of Tools**: The AI tools we use are well-suited to the sales and marketing tasks we actually do.
- **Automation Stage**: We have a clear, deliberate stance on which workflows AI advises, which AI drafts, and which AI handles end-to-end.
- **Outbound Volume Discipline**: AI's ability to generate volume is matched by deliberate limits on what we send, so output stays purposeful.
## Tool Usage & Daily Practice
How deeply AI tools are woven into everyday work across roles, kept lean and consolidated, and used inside the systems where work actually happens.
- **Daily Adoption Across Roles**: AI tools are part of the daily work of sellers, marketers, and support roles across the team, not the preserve of a few enthusiasts.
- **Tool Sprawl vs Consolidation**: We use a sensible number of AI tools, not a sprawling collection that overlaps and confuses.
- **In-System vs Side-of-Desk**: AI is used inside the primary system of record (CRM, marketing automation platform, support tool), not in a separate browser tab.
- **License Utilization**: The AI licenses we pay for are used by the people they were intended for.
## Brand Voice & Content Integrity
Whether AI-touched content stays on-brand, original, properly attributed, and honestly disclosed to the people who receive it.
- **Voice Consistency on AI-Touched Outbound**: AI-drafted or AI-touched outbound (email, ads, posts, chat) sounds like our brand, not like generic AI.
- **Originality & Attribution**: AI-generated content is sufficiently original and properly attributed where required; we don't republish model output as if it were ours when it isn't.
- **AI Disclosure to Recipients**: We disclose AI involvement in outbound and on-site content where policy, regulation, or audience expectations call for it.
## Personalization & Targeting
Whether AI-driven personalization rests on clear audiences and real signals, optimizing for relevance and reply quality rather than raw volume.
- **Audience & Segment Discipline**: AI-driven personalization rests on clear audience and segment definitions, not on whatever fields happen to be in the CRM.
- **Signal-Driven Personalization**: AI uses real signals (behavior, company data, intent) to personalize, not just to merge in a name and company.
- **Relevance Over Volume**: We optimize AI-driven outreach for relevance and reply quality, not raw volume.
## Accuracy & Fairness
Whether AI-generated claims are verified, lead scoring is checked for bias, and models are caught when they drift from the current audience and positioning.
- **Hallucinated Prospect Facts**: AI-generated claims about prospects, companies, and markets are verified before they reach a customer-facing channel.
- **Bias in Lead Scoring & Routing**: AI-driven lead scoring and routing are checked for systematic bias against segments that should be in scope.
- **Model Drift on Audience Fit**: We notice when AI scoring or content generation drifts away from our current target audience and product positioning, and we correct it.
## Outbound Compliance & Data Boundaries
Whether AI outbound stays within regulation, respects opt-outs, uses data with known provenance, and keeps sensitive customer data out of reach by design.
- **Regulatory Posture**: AI-generated outbound complies with the regulations that apply to our markets: data protection, anti-spam, consent, AI disclosure, and any rules specific to AI-generated voice or content.
- **Opt-Out Hygiene**: AI doesn't re-engage opted-out prospects, send to suppressed domains, or otherwise undo the team's preference work.
- **Training-Data Provenance**: We know what data the AI tools were trained on or are using at runtime, and we're comfortable with the provenance (own data, licensed sources, public web, customer data with consent).
- **Customer Data Boundaries**: Customer and prospect data classes that should not reach AI (regulated identifiers, payment data, sensitive company detail) are kept out by design.
## Measurement & Improvement
Whether the team measures how AI affects content engagement, the funnel, and ROI, and feeds failures back into a loop that makes AI sharper over time.
- **Content & Outbound Engagement Tracking**: We track how AI-touched content and outbound actually perform (open rate, reply rate, content engagement, deliverability) and act on what we see.
- **Funnel & Pipeline Impact**: We can say how AI changes the funnel (lead volume and quality, conversion at each stage, win rate, deal velocity), not just vanity metrics.
- **Failure Capture Loop**: When AI fails (off-brand content, bad email, broken targeting, compliance miss), the failure is captured and feeds an improvement loop.
- **ROI & Cost Awareness**: We know what we're spending on AI tools and what we're getting back in pipeline and revenue terms.
---
# SCARF Model Assessment for Teams
URL: https://www.teamretro.com/health-check-templates/scarf-model/
The SCARF model, published by David Rock in 2008, names five social needs the brain treats much like survival needs: Status, Certainty, Autonomy, Relatedness and Fairness. When one is under threat, people pull back. When they're met, people commit.
This assessment turns the model into a read on your team's climate. Everyone rates how well the team meets each of the five, from Strongly disagree to Strongly agree, and then you talk about the one that scores lowest.
## The five domains
David Rock's five brain-based social drivers (Status, Certainty, Autonomy, Relatedness and Fairness) that shape how threatened or rewarded people feel at work.
- **Status**: People on this team feel their contribution is recognized and valued.
- **Certainty**: We have enough clarity about what's coming to feel secure about our work.
- **Autonomy**: People here have real say over how they do their work.
- **Relatedness**: This team feels like a group who trust and look out for one another.
- **Fairness**: Decisions, workload and recognition on this team feel fair.
---
# Scrum Ceremonies Radar
URL: https://www.teamretro.com/health-check-templates/scrum-ceremonies-radar/
Scrum events drift. Stand-ups start running long, and retros turn into routine. The Scrum Ceremonies Radar asks your team to rate five parts of its Scrum practice: Backlog Grooming, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.
Each event has one statement, such as "Our stand-ups are short, to the point, and helpful," rated from 1 (Strongly Disagree) to 5 (Strongly Agree). Because everyone rates on their own, the radar shows where the team agrees an event is working and where people see it differently. Pick the lowest-scoring event, agree on one change to try next sprint, and run the radar again to see whether it helped.
## Scrum Ceremonies
Evaluate how effectively each core Scrum event supports your team's flow, alignment, and ability to deliver.
- **Backlog Grooming**: Our approach and tools keep the backlog up to date and prioritized for future sprints.
- **Sprint Planning**: Our planning sets our team up for success throughout our sprints.
- **Daily Scrum**: Our stand-ups are short, to the point, and helpful.
- **Sprint Review**: Our showcases reflect the sprint goals and the team's effort and velocity.
- **Sprint Retrospective**: Our retros are meaningful and enable us to continuously improve and overcome obstacles.
---
# Scrum Health Check
URL: https://www.teamretro.com/health-check-templates/scrum-health-check/
Scrum tends to break down in specific places: a backlog nobody has refined, events that have lost their point, technical debt that slows every sprint. The Scrum Health Check asks your team to rate five areas of how it runs Scrum: Product Ownership, Team Work, Events, Product and Technical Debt, and Tooling.
Each area is rated from 1 to 5 between two plain anchors, such as "Ineffective" and "Highly effective" for Events. Your team sees where it agrees things are working and where they're breaking down, and the lowest score gives your next retrospective a clear starting point.
## Scrum Practices
Assess the core pillars of how your team applies the Scrum framework day to day, from product ownership through to delivery and tooling.
- **Product Ownership**: Rate the current state of our product backlog, user stories, acceptance criteria, and relevance to the business.
- **Team Work**: Rate the current state of our collaboration, communication, participation, and our ability to own the process and overcome impediments.
- **Events**: Rate the cadence and effectiveness of our meetings including standups, planning, reviews, retrospectives, and refining.
- **Product and Technical Debt**: Rate our burn rate, the definition of done, the value of increments, and technical debt.
- **Tooling**: Rate our ability to use agile tools and to automate testing.
---
# Scrum Values Radar
URL: https://www.teamretro.com/health-check-templates/scrum-values-radar/
The Scrum Guide names five values: Commitment, Focus, Openness, Respect and Courage. They're easy to agree with and easy to forget in a busy sprint. The Scrum Values Radar asks each person to rate how often the team lives each value, from 0 (Never) to 5 (Always), against statements like "We are willing to do the right thing and work on tough problems."
Rating on your own first, then comparing, shows where the team agrees and where people see things differently. Use it inside a sprint retrospective or as a regular pulse, and pick one value to work on before the next run.
## Scrum Values
The five foundational values that guide how a Scrum team works together and builds trust.
- **Commitment**: We personally commit to achieving the goals of the scrum team.
- **Focus**: We focus on the work of the sprint and the goals of the scrum team.
- **Openness**: We are open about all the work and challenges we face during the sprint.
- **Respect**: We respect and encourage one another.
- **Courage**: We are willing to do the right thing and work on tough problems.
---
# Atlassian Service Team Health Monitor
URL: https://www.teamretro.com/health-check-templates/service-team-health-monitor/
This is the Health Monitor variant in Atlassian's Team Playbook for service, support and ops teams, where success means a service people can rely on rather than a shipped project. It covers eight attributes: Team leadership, Balanced team, Service mandate, Service levels, Customer centricity, Tools and processes, Effective partnerships, and Reporting and analytics.
Your team votes each attribute red, amber or green, then talks about the reds first. Run it when service quality starts slipping, or every quarter to see whether the reds are turning green.
## Eight attributes
The eight attributes of a high-performing service team, scored together as a red/amber/green health monitor.
- **Team leadership**: We have clear, effective leadership for this service team.
- **Balanced team**: We have the right people, skills and clearly defined roles to deliver our service.
- **Service mandate**: The services we offer are defined and documented, with success metrics agreed with our stakeholders.
- **Service levels**: Our service levels (SLAs) are defined and visible to the people who rely on us.
- **Customer centricity**: We understand our customers, resolve their needs with empathy, and use their feedback to improve.
- **Tools and processes**: We have the tools we need, and our processes are documented with clear workflows and owners.
- **Effective partnerships**: We know our vendors and partners, with key relationships and agreements documented.
- **Reporting and analytics**: We track the right service metrics and use dashboards to drive improvement.
---
# The Six Team Conditions: Hackman's Team Effectiveness Model
URL: https://www.teamretro.com/health-check-templates/six-team-conditions/
J. Richard Hackman spent his career on one question: why do some teams thrive and others fail? The answer he and Ruth Wageman landed on is the Six Team Conditions: three essentials (a real team, a compelling purpose, the right people) and three enablers (sound structure, supportive context, team coaching). Their research suggests these account for a large share of the difference in team effectiveness. This check diagnoses your team against all six.
## The Essentials
The three foundational conditions that must be in place before any team can perform: a real team, a compelling purpose, and the right people.
- **Real Team**: We have clear, stable membership, and everyone knows who's on this team and who isn't.
- **Compelling Purpose**: We have a clear, challenging purpose that we genuinely care about.
- **Right People**: We have the mix of skills and perspectives the work needs.
## The Enablers
The three supporting conditions that let a well-founded team reach its potential: sound structure, a supportive context, and timely coaching.
- **Sound Structure**: Our size, tasks and norms are set up well for getting the work done.
- **Supportive Context**: We get the information, resources, rewards and support we need from the wider organization.
- **Team Coaching**: We get helpful coaching at the right moments to work better together.
---
# SPACE Framework Health Check
URL: https://www.teamretro.com/health-check-templates/space-framework/
The [SPACE framework](https://queue.acm.org/detail.cfm?id=3454124) was published in 2021 by Nicole Forsgren, Margaret-Anne Storey and colleagues at GitHub and Microsoft Research. Its argument is that no single number captures developer productivity, so it looks at five dimensions instead: Satisfaction and well-being, Performance, Activity, Communication and collaboration, and Efficiency and flow.
This survey covers the part of SPACE that only your team can tell you: how the work feels. Everyone rates two statements per dimension, from Strongly disagree to Strongly agree. Read the results next to your delivery data, or pair it with the [DORA Metrics Self-Assessment](/health-check-templates/dora-metrics/). Take the lowest-scoring dimension into your retrospective and agree on what to change. Use it to improve how the team works, never to rank individuals.
## Satisfaction & Well-being
How fulfilled and healthy people feel in their work, their team and their tools.
- **Satisfaction**: We find our work here satisfying and worthwhile.
- **Well-being**: Our workload is sustainable, and people here rarely burn out.
## Performance
The outcomes of the work: its quality, its reliability and the difference it makes for customers.
- **Quality**: We're confident in the quality and reliability of what we ship.
- **Customer Impact**: What we deliver makes a real difference for our customers.
## Activity
Where the team's time and effort go. Counts such as commits and deployments come from your tools; this group asks how the effort feels.
- **Time on Valuable Work**: Most of our time goes on building and improving the product, not on overhead.
- **Delivery Pace**: We finish and ship work at a steady pace.
## Communication & Collaboration
How well people share knowledge, review each other's work and help each other.
- **Reviews & Help**: We get timely reviews and answers from each other when we need them.
- **Shared Knowledge**: Knowledge is shared and easy to find, not stuck in one person's head.
## Efficiency & Flow
How easily work moves without interruptions, waiting or handoffs.
- **Focus Time**: We get enough uninterrupted time to focus.
- **Flow**: Work moves from idea to production without getting stuck waiting on people, tools or approvals.
---
# Squad Health Check
URL: https://www.teamretro.com/health-check-templates/squad-health-check/
The Squad Health Check is adapted from the model Spotify shared publicly in 2014 for its agile squads. Each person rates 11 areas of squad life, including Delivering Value, Health of Codebase, Fun, Mission and Pawns or Players, on a simple three-point scale.
Because everyone rates on their own first, the results show where the squad agrees and where it doesn't, and that gap is usually the conversation worth having. Run it every month or quarter to see trends over time, and compare squads to spot where one needs support without flattening the differences between teams.
## Squad Health
The core dimensions of squad health, spanning what the team delivers, how it works, and how it feels to be part of the squad.
- **Delivering Value**: How proud the squad is of what it delivers and how happy stakeholders are with the results.
- **Easy to Release**: How simple, safe, and automated it is for the squad to ship its work to production.
- **Fun**: How much the squad enjoys coming to work and collaborating together.
- **Health of Codebase**: How clean, readable, and well-tested the squad's code is, and how much technical debt it carries.
- **Learning**: How much time and opportunity the squad has to learn new and interesting things.
- **Mission**: How clear and inspiring the squad finds its higher purpose and focus.
- **Pawns or Players**: How much control the squad has over what it builds and how it builds it.
- **Speed**: How quickly the squad gets work done without waiting, delays, or blocking dependencies.
- **Suitable Process**: How well the squad's way of working fits the team and the work it does.
- **Support**: How readily the squad gets the help and support it needs when it asks for it.
- **Team Work**: How well the squad collaborates and looks out for one another as a team.
---
# Team Barometer
URL: https://www.teamretro.com/health-check-templates/team-barometer/
Process tells you how work moves through a team. The Team Barometer looks at the people doing it. Your team rates seven areas: Trust, Collaboration, Participation, Responsibility, Relationships, Passion and Integrity. Each statement, such as "There is a high level of trust in our team. People can speak their mind freely," is rated on a five-point scale with a plain description at every step.
The results open conversations that are hard to start cold, like whether people feel they can speak up and whether the load is shared. Run it every quarter or every few sprints to see how the scores change, and pick one area to work on each round.
## Team Health
The core relational and behavioural qualities that determine how effectively your team works together day to day.
- **Trust**: There is a high level of trust in our team. People can speak their mind freely.
- **Collaboration**: We work together well on issues that come up and can solve complex problems.
- **Participation**: We are engaged and active in our Agile ceremonies and everyone is contributing.
- **Responsibility**: We take ownership of our tasks and actions and can depend on each other to get the job done.
- **Relationships**: We support and boost each other and provide backup and motivation to help each other.
- **Passion**: We take pride in our work and are driven by our work and our outcomes.
- **Integrity**: We behave in a way that demonstrates good decision-making, communication, and respect.
---
# Five Dysfunctions of a Team Assessment
URL: https://www.teamretro.com/health-check-templates/team-dysfunction-radar/
Patrick Lencioni's book The Five Dysfunctions of a Team (2002) describes five problems that build on each other: Absence of Trust, Fear of Conflict, Lack of Commitment, Avoidance of Accountability and Inattention to Collective Results. A team that can't admit mistakes won't argue honestly, and a team that doesn't argue won't really commit to its decisions.
This assessment is TeamRetro's own adaptation of that model. Each person rates the five privately on a 1 to 5 scale, with a description at every step, from "We hide weaknesses and mistakes" to "We are openly vulnerable and trusting." The combined scores and the spread show which dysfunction is strongest, and the conversation that follows turns it into specific steps.
## Team Dysfunctions
The five interrelated behaviors that determine whether a team builds trust and delivers results together.
- **Absence of Trust**: The fear of being vulnerable stops us from building trust with each other.
- **Fear of Conflict**: There is artificial harmony which can stifle constructive conflict in the team.
- **Lack of Commitment**: Team members do not follow through on actions due to the lack of clarity or buy in.
- **Avoidance of Accountability**: We do not hold each other accountable for behaviors and performance because we want to avoid interpersonal issues.
- **Inattention to Collective Results**: There is a focus on individual goals, rather than the collective success of the whole team.
---
# Team Effectiveness Assessment
URL: https://www.teamretro.com/health-check-templates/team-effectiveness-health-check/
The Team Effectiveness Assessment asks your team to rate seven areas: Team Collaboration, Differentiation, Performance Metrics, Data Gathering, Team Dynamics, Needs Assessment and Psychological Safety. Some look at how you work together day to day. Others ask whether you measure your performance at all, and whether you know what the team needs to do better.
Each person rates on a simple three-point scale, so it's quick to run in a retrospective or an offsite. The results show where people agree the team is strong and where views split, and the split is where to start the conversation. Pick one or two of the lowest scores and agree on a change before the next check.
## Team Effectiveness Factors
Explore the collaboration, dynamics, and measurement practices that shape how effectively your team performs together.
- **Team Collaboration**: Team collaboration and addressing team dynamics are critical for success in any organization.
- **Differentiation**: Workgroups are less reliant on each other, while teams rely on strong collaboration for project success.
- **Performance Metrics**: Effective teams can be assessed using various evaluations and metrics, while recognizing differing perspectives on what makes a team effective.
- **Data Gathering**: Collecting and analyzing data to assess team effectiveness combines both quantitative and qualitative methods.
- **Team Dynamics**: Effective team dynamics emerge from examining critical factors and acknowledging that team size and consensus-based decisions have limited impact.
- **Needs Assessment**: Gauging our team's needs through surveys and valuable discussions with our leaders helps us improve.
- **Psychological Safety**: I feel confident sharing my ideas within the team, unafraid of making mistakes as I see them as opportunities for learning, and I'm comfortable asking questions openly.
---
# Team Health Check
URL: https://www.teamretro.com/health-check-templates/team-health-check/
Teams rarely say out loud how they're doing. This team health check gives your agile team a shared way to talk about it across nine areas: ownership, value, goal alignment, communication, team roles, velocity, support and resources, process, and fun.
Each person rates every area on a three-point scale. The results show where people agree and, more usefully, where they don't. A low or split score turns a vague feeling that something's off into a specific conversation, and that conversation leads to an action.
Run it every few sprints or once a month and you'll see trends build up. A score that drops after a reorganization, or climbs after the team fixed its handoffs, tells you whether the changes you made are working.
## Team Health Dimensions
Core dimensions that shape how a team performs, collaborates, and stays motivated, from clear ownership and shared goals through to process, support, and the enjoyment of working together.
- **Ownership**: The team has clear ownership or a dedicated product owner who is accountable for the team's results and champions the mission inside and outside of the team.
- **Value**: We can define and measure the value we provide to the business and the user.
- **Goal Alignment**: Everyone understands why they are here, supports the idea, and believes they have what it takes to create solutions that add value.
- **Communication**: We have clear and consistent communication that ensures that issues are shared, conflict is reduced, and everyone can work with greater efficiency.
- **Team Roles**: The current team skill set is right for the current stage and there are clear roles and responsibilities for each person in the team.
- **Velocity**: We learn and implement lessons leading to incremental progress in iterations and production as we go.
- **Support and Resources**: We are equipped with the right tools and resources and can easily access support from within and outside the team.
- **Process**: Our processes are aligned, effective, and free of unnecessary delays and blocks. We have metrics in place to measure our goals.
- **Fun**: We enjoy our work and working as a team. We are being challenged and can develop our skill set or acquire new ones.
---
# Atlassian Team Health Monitor
URL: https://www.teamretro.com/health-check-templates/team-health-monitor/
The Team Health Monitor comes from Atlassian's Team Playbook. It lists eight attributes that healthy project teams tend to share: Full-time owner, Balanced team, Shared understanding, Value and metrics, Proof of concept, One-pager, Managed dependencies and Velocity.
There's no score out of five. Your team votes each attribute red, amber or green, because the point is the conversation about why something isn't green. This version describes the eight attributes in TeamRetro's own words, so your team can run it in minutes and track how the colors change between sessions.
## Eight attributes
The eight attributes that healthy, high-performing project teams tend to share, drawn from Atlassian's Team Playbook. Vote each one red, amber or green and talk through the reds together.
- **Full-time owner**: We have one clearly accountable lead, dedicated enough to champion this work.
- **Balanced team**: We have the right skills and clearly defined roles to deliver what we own.
- **Shared understanding**: We share a common understanding of our mission and the milestones to get there.
- **Value and metrics**: We know the value we deliver and how we'll measure success.
- **Proof of concept**: We've validated this is worth doing and have a clear path forward.
- **One-pager**: Our purpose and goals are captured somewhere anyone can quickly grasp.
- **Managed dependencies**: We have a clear view of who we depend on and who depends on us, and we manage the risk.
- **Velocity**: We're making steady, visible progress and shipping to stakeholders.
---
# Team Health Radar
URL: https://www.teamretro.com/health-check-templates/team-health-radar/
The Team Health Radar asks your team to rate nine areas: Ownership, Value, Goal Alignment, Communication, Team Roles, Velocity, Support and Resources, Process and Fun. Each is a statement, such as "We can define and measure the value we provide to the business and the user," rated from 1 to 5.
Plotted together, the scores show at a glance which areas are strong, which are pulling the team down, and where people disagree. Run it every few sprints to catch friction before it turns into a blocker, so talking about how the team is doing becomes a habit and not something you only do when things go wrong.
## Team Health
Core dimensions that capture how the team is performing, collaborating, and feeling about their work.
- **Ownership**: The team has clear ownership or a dedicated product owner who is accountable for the team's results and champions the mission inside and outside of the team.
- **Value**: We can define and measure the value we provide to the business and the user.
- **Goal Alignment**: Everyone understands why they are here, supports the idea, and believes they have what it takes to create solutions that add value.
- **Communication**: We have clear and consistent communication that ensures that issues are shared, conflict is reduced, and everyone can work with greater efficiency.
- **Team Roles**: The current team skill set is right for the current stage and there are clear roles and responsibilities for each person in the team.
- **Velocity**: We learn and implement lessons leading to incremental progress in iterations and production as we go.
- **Support and Resources**: We are equipped with the right tools and resources and can easily access support from within and outside the team.
- **Process**: Our processes are aligned, effective, and free of unnecessary delays and blocks. We have metrics in place to measure our goals.
- **Fun**: We enjoy our work and working as a team. We are being challenged and can develop our skill set or acquire new ones.
---
# Team Charter & Working Agreements Check
URL: https://www.teamretro.com/health-check-templates/team-working-agreements/
A team charter says why a team exists and how it works together: its purpose, goals and customers, who owns what, how decisions get made, how people communicate, what done means, and how the team keeps its agreements. Working agreements are the day-to-day part of the charter, the habits everyone signs up to.
This check isn't a fill-in document. Use the sections below as your team charter template, then rate how well your team lives each one. Everyone rates privately, and the lowest scores show which part of the charter to write, rewrite or start following again. In TeamRetro, the [team agreements](https://help.teamretro.com/article/266-team-agreements) you accept stay visible in every retrospective and health check.
## Why we exist
The purpose, goals and customers that the rest of the charter serves.
- **Shared purpose**: Everyone on this team can explain why the team exists.
- **Clear goals**: We share clear goals and know how we'll tell when we've met them.
- **Who we serve**: We know who we serve and what they need from us.
## How we work together
The roles, decisions, communication, quality bar and meetings that shape daily work.
- **Clear roles**: Everyone knows what they own and what others count on them for.
- **Decision making**: We know how decisions get made and who makes them.
- **Communication norms**: We agree on which channels to use and how quickly to respond.
- **Definition of done**: We share the same definition of done for our work.
- **Useful meetings**: Our regular meetings have a clear purpose and are worth the time.
## Keeping agreements alive
Whether the agreements hold up in practice and change when the team does.
- **Following through**: We follow our working agreements in our daily work.
- **Raising breaches**: Anyone can point out a broken agreement without it turning into blame.
- **Handling conflict**: When we disagree, we have an agreed way to work it through.
- **Reviewing agreements**: We review our agreements when the team, goals or way of working change.
---
# Technical Debt Assessment for Engineering Teams
URL: https://www.teamretro.com/health-check-templates/technical-debt-assessment/
Ward Cunningham coined the technical debt metaphor in his [1992 OOPSLA experience report](https://c2.com/doc/oopsla92.html), writing that "shipping first time code is like going into debt." A little debt can speed you up. The trouble starts when it isn't repaid, and every hour spent working around not-quite-right code becomes interest.
Code scanners measure the code. This assessment measures what the team lives with: whether you can see the debt, how much it slows delivery, how healthy the code and systems feel, and whether you're paying it down. Everyone rates each statement privately, then you take the lowest scores into a retrospective and agree on what to fix first.
## Visibility
Whether the team knows where its debt is and treats it as real work.
- **Known hotspots**: We know which parts of our system carry the most debt.
- **Tracked with other work**: Debt is tracked in the same backlog as features and bugs.
- **Known cost**: We can explain what our biggest debts cost us in time or risk.
## Impact on delivery
How much debt slows down the work the team is trying to ship.
- **Feature speed**: Debt rarely slows down the features we're building.
- **Safe changes**: Changing one part of our system rarely breaks an unrelated part.
- **Fast, reliable builds**: Our builds and tests are fast and reliable.
## Code and system health
How easy the code, systems and dependencies are to work with today.
- **Easy to change**: Most of our code is easy to understand and change.
- **Current dependencies**: Our dependencies and platforms are reasonably up to date.
- **Tests support refactoring**: Our tests give us the confidence to refactor.
## Paying it down
Whether the team makes steady, agreed progress on reducing debt.
- **Time set aside**: We set aside regular time to pay down debt.
- **Deliberate debt recorded**: When we take on debt on purpose, we record it with a plan to repay it.
- **Shared priorities**: Product and engineering agree on how to split time between features and debt.
---
# Work Happiness Radar
URL: https://www.teamretro.com/health-check-templates/work-happiness-radar/
The Work Happiness Radar looks at six things that shape how people feel about their work: Clarity, Autonomy, Meaning, Mastery, Support and Engagement. Each is a first-person statement, such as "I have the freedom to do my job and make decisions," rated from Strongly disagree to Strongly agree.
Because each person rates their own experience, the results show what's working and where people are starting to disengage. Talk through the lowest scores together, agree on one or two changes, and run it again each quarter to see the trend.
## Work Happiness Drivers
The core factors that shape how motivated, supported, and fulfilled team members feel in their roles.
- **Clarity**: I have clear understanding of my role, my tasks and what outcomes I have to achieve.
- **Autonomy**: I have the freedom to do my job and make decisions.
- **Meaning**: I find my work meaningful and helps to achieve goals.
- **Mastery**: I can continually develop my skills and expertise in my role to improve my capability.
- **Support**: I am supported, resourced and provided with the things I need to do my job well.
- **Engagement**: I can easily, safely and freely engage in the team processes.
---
## Crawling: every AI crawler and assistant user-agent is welcome on this site. The machine-readable policy is https://www.teamretro.com/robots.txt