## llms.txt for www.teamretro.com ## Purpose: Provide structured, high-value links and content for LLM consumption. ## Last updated: 2026-07-18 ## Language: en ## License: © 2026 GroupMap Technology Pty Ltd. All rights reserved. ## Sitemap: https://www.teamretro.com/sitemap-index.xml ## AI Data Use Policy: Publicly available pages may be used for indexing and summarization by AI systems. Private or authenticated content must not be used or stored. Please respect robots.txt directives. ## AI crawlers welcome ### OpenAI User-agent: GPTBot Allow: / User-agent: OAI-SearchBot Allow: / User-agent: ChatGPT-User Allow: / ### Anthropic (Claude) User-agent: ClaudeBot Allow: / User-agent: Claude-SearchBot Allow: / ### Google (Gemini / Vertex AI) User-agent: Google-Extended Allow: / ### Perplexity User-agent: PerplexityBot Allow: / User-agent: Perplexity-User Allow: / ### Apple User-agent: Applebot-Extended Allow: / ### Meta User-agent: meta-externalagent Allow: / ### DuckDuckGo AI answers User-agent: DuckAssistBot Allow: / ### Common Crawl User-agent: CCBot Allow: / ### You.com User-agent: YouBot Allow: / ### DeepSeek User-agent: DeepSeekBot Allow: / User-agent: DeepSeek Allow: / # About TeamRetro: Think together. Improve together > TeamRetro is an enterprise-grade, AI-powered platform for Agile teams, streamlining retrospectives and health checks with anonymous input, action tracking, and intuitive dashboards visualizing health trends for continuous improvement. With a secure, intuitive platform, it's built for Scrum Masters, Agile Coaches, and teams of any size — whether in-person, hybrid, or fully remote. Run engaging, action-focused meetings: its time-saving, real-time design lets you easily facilitate conversations and focus on the actions to take forward. ## TeamRetro Retrospective Features > 200+ retrospective templates > Customize retrospective process / flow steps > Icebreakers and check-in / check-out questions > Brainstorm (idea capture, optionally anonymous) > Grouping / clustering of ideas (manual + AI suggestions) > Voting, dotmocracy and dot voting (independent/anonymous) > Discussion stage, mentions, kudos and live reactions > Whiteboards, timer, background music and GIF support > Capture actions / proposals / assign owners & due dates > Presentation / facilitator mode to guide the flow > AI meeting summaries with key highlights and actions > Recurring retrospectives; track cadence, sentiment and action metrics over time ## TeamRetro Health Check / Team Health Features > 20+ health check models / templates and 14 maturity assessment models > Custom survey styles: numeric scales, Likert, matrix > Visual radar / charts to surface team sentiment and dimension health > Sort / filter results by positivity / negativity / mixed responses > Drill into statistics and individual responses > Track trends over time and compare past health checks > Capture comments, reactions and replies on ratings; capture agreements > Recurring health checks; summary generation and sharing of results > Integrate actions from health checks into workflow tools ## TeamRetro Agile Estimation Features > Customize estimation process / flow steps and custom estimation decks > Estimation bar graph and consensus building > Capture actions / proposals / assign owners & due dates > Sync estimates back to Jira, Linear, GitHub and other tools > Summary generation and sharing of estimation results ## TeamRetro AI / Automation Features > AI-generated retrospective templates, health models and icebreaker questions > AI suggested grouping of ideas and suggested actions > AI meeting summaries and suggested meeting titles > AI insights: sentiment trends, themes, keywords > AI maturity models and AI usage / feature usage reporting ## TeamRetro Enterprise, Security, Compliance & Identity > SOC 2 Type 2 and SOC 3 accreditation (self and sub-processors) > GDPR compliance & regional hosting (US / EU) > SSO / SAML support (all plans); ISO 27001-aligned infrastructure > 99.9% uptime SLAs / status dashboard; data encryption > DPA and Enterprise Agreements; security questionnaires and compliance > Hosting region selection (US or EU); IP whitelisting (Allowed IP Ranges) ## TeamRetro Reporting, Dashboards & Insights > Meeting summaries: results, actions, highlights > Dashboards / metrics: action tracking, sentiment over time, cadence > Trend analysis (health, themes); cross-team insights > Filter by team, team tag, date; drill-down word clouds > Export / download summaries / reports (PDF / Excel / CSV) ## Home & Overview - [Home](https://www.teamretro.com/): Main landing page introducing TeamRetro and its key product highlights. - [Pricing](https://www.teamretro.com/plans/): Plans, subscription tiers, and included features. - [Enterprise](https://www.teamretro.com/enterprise/): Enterprise-grade security, compliance, and scalability. - [Contact](https://www.teamretro.com/contact-us/): Contact details for sales, partnerships, and support. ## Product & Solutions - [Retrospectives Overview](https://www.teamretro.com/retrospectives/): How TeamRetro helps teams run agile retrospectives. - [Retrospective Features](https://www.teamretro.com/retrospectives/features/): Idea boards, voting, action tracking and more. - [Health Checks](https://www.teamretro.com/health-checks/): Assess team well-being and performance. - [Health Check Features](https://www.teamretro.com/health-checks/features/): Reporting, analytics and visualization. - [Agile Estimation](https://www.teamretro.com/estimations/): Story-by-story facilitation with real-time consensus. - [Integrations](https://www.teamretro.com/integrations/): Jira, Slack, Confluence and other agile tools. ## Help & Resources - [Retrospective Template Library](https://www.teamretro.com/retrospective-templates/): Ready-to-use retrospective templates. - [Health Check Template Library](https://www.teamretro.com/health-check-templates/): Templates for assessing team health. - [Icebreaker Questions & Games](https://www.teamretro.com/icebreakers/): Library of icebreaker questions and games for meetings, retrospectives and remote teams. - [Team-Building Activities](https://www.teamretro.com/team-building-activities/): Team-building activities and exercises for work, in-person and virtual. - [Guides](https://www.teamretro.com/guides/): In-depth guides for Scrum Masters and Agile teams. - [Blog](https://www.teamretro.com/blog/): Articles on agile practices, retrospectives and team development. ## Free Agile Tools - [Icebreaker Tool](https://games.teamretro.com/): Free interactive icebreaker tool: generates questions, picks who goes next, and times the round. - [Free Planning Poker](https://www.teamretro.com/free-planning-poker-for-agile-teams/): Free online planning poker for agile teams. ## Company & Legal - [Responsible Use of AI](https://www.teamretro.com/responsible-ai/): Ethical and responsible AI usage practices. - [Security & Compliance](https://www.teamretro.com/security/): Security controls, encryption, SOC 2, data protection. - [GDPR Compliance](https://www.teamretro.com/gdpr/): GDPR adherence and user data rights. - [Cookie Policy](https://www.teamretro.com/cookies/): Cookie usage and tracking preferences. - [Privacy Policy](https://www.teamretro.com/privacy/): How personal and organizational data is collected and used. - [Terms of Service](https://www.teamretro.com/terms-of-service/): Legal terms and conditions for using TeamRetro. # Full content # Feedback for a Colleague: Examples & Phrases for Every Situation URL: https://www.teamretro.com/guides/feedback-for-colleagues-examples/ Most people know they should give colleagues more feedback. What stops them is not willingness — it's not knowing what to actually say. "Great work" feels hollow, "you need to improve your communication" feels like an attack, and so the words go unsaid. The fix is not more courage; it's better phrasing. This guide gives you 80-plus feedback examples you can copy and adapt — positive and constructive, between peers, up to a manager and down to a report, sorted by the situations that come up at work. Every example is built on one framework, the SBI model, so your feedback stays specific and fair. Use them as a starting point, then swap in the real detail of what your colleague did. ## What good feedback looks like (and why it matters) Good feedback is information a person can act on. It points at a specific thing they did and tells them the effect it had — so they know exactly what to keep doing or change. Vague praise ("you're a great team player") teaches nothing, because the person can't tell which of the hundred things they did earned it. Personal criticism ("you're disorganized") teaches nothing either — there's no behavior to change, only a label to resent. Feedback is also a team-health signal. A team that exchanges honest, low-stakes feedback as a matter of course catches small problems before they harden; a team where nobody says anything until the annual review is storing up surprises. That openness rests on [psychological safety](/health-check-templates/psychological-safety-check/) — people only give and receive candid feedback when it feels safe to speak up. If feedback is rare or scary on your team, that's usually the thing to fix first. ## The SBI model: Situation, Behavior, Impact The single most useful tool for giving feedback is the SBI model, developed by the Center for Creative Leadership. It structures any piece of feedback into three parts, and following it almost guarantees your feedback is specific and fair rather than vague or accusatory. ### Situation — when and where Anchor the feedback to a concrete moment: *"In yesterday's sprint planning…"*, *"On the client call this morning…"*, *"In your last pull request…"*. This stops the feedback drifting into a sweeping generalization ("you always…") that the person can instantly dismiss with a single counter-example. ### Behavior — the observable action, not the person Describe what the person actually *did* — something a camera could have recorded — not your interpretation of who they are. *"You restated each person's point before we voted"* is a behavior. *"You're so considerate"* is a character judgment. Behaviors can be repeated or changed; character labels just provoke defensiveness. ### Impact — the effect on the team, the work, or you Explain what the behavior led to: *"…so we reached a decision in ten minutes instead of half an hour"*, *"…which meant I had to redo the report the next morning"*. The impact is what makes feedback worth giving — it's the reason the behavior matters, and it's what motivates someone to keep it up or change it. ### A quick before/after rewrite Watch what SBI does to a flat compliment: - **Before:** "You're great at presentations." - **After:** "In today's stakeholder review *(situation)*, you opened with the one number they cared about and held questions to the end *(behavior)* — it kept the room focused and we got sign-off without the usual back-and-forth *(impact)*." Same goodwill, but now the person knows precisely what to do again. Every example below follows this shape. Notice what SBI leaves out: the word "you" attached to a judgment. "You did X and it caused Y" is feedback; "you are X" is a verdict. Keeping the focus on the behavior and its impact is the whole trick to feedback that lands without bruising. ## Positive and recognition feedback examples Praise is wasted when it's generic. These name the behavior so your colleague can repeat it. Adapt the specifics to what actually happened. ### For going above and beyond - "You stayed late to unblock the deployment when you didn't have to — the release shipped on time because of it, and the whole team noticed." - "You picked up the support backlog while two people were out, and customers never felt the gap. That took real ownership." - "You spotted the data issue before it reached the client and quietly fixed it — you saved us a very awkward conversation." ### For collaboration and teamwork - "You pulled in marketing early instead of waiting for sign-off, and it meant we caught the messaging problem weeks before launch." - "When the discussion stalled, you offered to pair on it afterwards rather than letting it drift — that's exactly the kind of follow-through the team needs." - "You made space for the quieter people in the workshop by asking them directly what they thought. The ideas we landed on were better for it." ### For communication - "Your written update was clear enough that nobody needed a follow-up call — that saved everyone half an hour." - "You explained the trade-off to the client in plain language, without the jargon, and you could see them relax. That built a lot of trust." - "You flagged the slip early and honestly instead of hoping it would resolve itself, which gave us time to replan calmly." ### For reliability and follow-through - "You said you'd own the migration and you did — start to finish, no chasing required. That kind of dependability makes the whole team's planning easier." - "Every action you took from the last retro actually got done. It's noticeable, and it's why people trust the commitments you make." - "You always come to standup prepared, which keeps ours one of the few that finishes on time." ### For taking initiative - "You didn't wait to be asked — you saw the onboarding doc was out of date and rewrote it. The next new starter will have a much easier first week." - "You proposed the change to the review process instead of just complaining about it, and it's genuinely faster now." - "You took the lead on the incident without being told to, kept everyone calm, and ran a clean post-mortem afterwards." ### For problem-solving and quality - "Your fix didn't just patch the symptom — you traced it to the root cause, so the bug won't come back. That's the kind of work that pays off for months." - "The thoroughness of your testing caught an edge case the rest of us missed. It's why your work so rarely comes back." - "You reframed the problem in the meeting and suddenly the answer was obvious. That shift in how you saw it unblocked the whole team." ## Constructive and developmental feedback examples Constructive feedback is a gift when it's specific, private and about behavior. These keep the door open rather than passing judgment. ### Missed deadlines or follow-through - "The design handover came in two days after we'd agreed, and it pushed the whole sprint back. Can we look at what got in the way and how to flag it earlier next time?" - "A couple of the actions you took from the last retro are still open. If something's blocking them, let's surface it — I'd rather know than wait." - "You committed to the review by Thursday and it landed Monday. I know things come up; a quick heads-up when a date is going to slip would help me replan." ### Communication and clarity - "In the last two standups your update ran several minutes long, and we lost the time we needed for blockers. Could you bring just the headline and we'll dig into detail after?" - "Your email had the decision buried in the last paragraph, so a few people missed it and acted on the old plan. Leading with the ask would help it land." - "When you went quiet on the thread for a few days, the rest of us weren't sure if it was handled. Even a one-line 'on it' would keep everyone aligned." ### Collaboration and conflict - "In the planning session you talked over Sam a couple of times before he'd finished. I don't think it was intentional, but it meant we didn't hear his point — worth watching for next time." - "The decision got made in a side conversation rather than the open channel, so half the team found out late. Keeping those calls visible would help everyone trust the process." - "When the feedback on your draft came in, the response felt defensive and people stopped offering it. The work is stronger when the door stays open to it." ### Quality and attention to detail - "The report had a few figures that didn't reconcile, and the client spotted one before we did. A second pass on the numbers before it goes out would protect us." - "A couple of recent pull requests skipped tests and we caught regressions in staging. Adding the tests up front is slower now but saves the firefighting later." ### Framing constructive feedback so it lands Notice the pattern in all of the above: situation, then behavior, then impact, then an invitation to fix it together. None of them say "you're careless" or "you're a poor communicator." They describe one thing that happened, the effect it had, and a way forward. Give it privately, close to the event, and assume good intent — most problems are habits or oversights, not character flaws, and people respond far better to "let's adjust this" than to a verdict. ## Peer-to-peer feedback examples Feedback between colleagues at the same level carries no authority, so it lives or dies on trust. Keep it specific, two-way and generous. ### Positive peer feedback - "Pairing with you on that bug was the fastest I've debugged anything all month — you think out loud in a way that's genuinely easy to follow." - "You always read the brief properly before the kick-off, which means our calls start with real questions instead of catch-up. I really value that." - "When I was stuck, you dropped what you were doing to help and never made me feel like a burden. That's the kind of teammate people remember." ### Constructive peer feedback - "I noticed in code review you'll sometimes rewrite a whole approach in the comments. The suggestions are good — but a quick chat first would save us both the back-and- forth in the thread." - "When we split the work last sprint, the interface between our two pieces was a bit fuzzy and we duplicated some of it. Could we spend five minutes agreeing the seam up front next time?" - "You're often heads-down with headphones on, which is great for focus — but I've held back a couple of quick questions because I wasn't sure if I was interrupting. A signal for when you're open would help." ## Manager-to-report feedback examples From a manager, feedback carries weight — so specificity and fairness matter even more. Recognition should be frequent; developmental feedback should be private and forward-looking. ### Recognition - "The way you handled that frustrated customer — staying calm, owning the problem, following up the next day — is exactly the standard I want the team known for." - "You've grown a lot this quarter. Six months ago you'd have escalated that decision; this time you made the call yourself and it was the right one." - "You mentored the new starter without being asked, and it shows in how quickly they've found their feet. That's leadership, whatever your title says." ### Developmental - "You're doing strong individual work, but the team rarely sees your thinking. In the next few retros I'd like you to share more of the 'why' behind your decisions — others learn from it." - "I've noticed you take on everything that's offered. That's generous, but a few things have slipped because there's too much on. Let's look at what to hand off." - "In the last review you gave the answer before the team had finished thinking. You're usually right — but they stop contributing when they expect you to solve it. Try holding back a beat." ## Report-to-manager (upward) feedback examples Upward feedback is the hardest to give and the most valuable to receive. Frame it as what would help you do your best work, not as a complaint. ### What's working - "The way you shield the team from shifting priorities makes a real difference — I can focus on the actual work instead of chasing the moving target. Thank you for that." - "I appreciate that you give context with the 'what', not just the task. Knowing why we're doing something helps me make better calls when you're not around." - "Our one-to-ones are genuinely useful — you listen more than you talk, and I leave with clarity rather than a longer to-do list." ### What you'd like more or less of - "Decisions sometimes reach us after they're final, so we miss the chance to flag problems. Could we be looped in a little earlier on the ones that affect our work?" - "When feedback only comes in the review cycle, it's hard to course-correct in time. I'd value smaller, more frequent steers — even a quick word after a meeting." - "I work best with the outcome and the freedom to find the path. On the last project the detail of the instructions left me less room than I'd have liked — could we agree the 'what' and let me own the 'how'?" For the trust upward feedback needs, it helps to know your manager well outside the work itself — a few minutes of [team icebreakers](/icebreakers/) at the start of a one-to-one or a meeting builds the rapport that makes candor possible. Our list of [one-on-one meeting questions](/guides/one-on-one-meeting-questions/) is a good source of prompts for those conversations. ## Feedback examples by scenario A cross-cutting bank sorted by theme — useful when you know the situation but not the words. These work in any direction. ### Communication - "You translate complex technical detail into language non-experts can act on — it's why stakeholders trust your updates." - "In writing you're crisp; in meetings the point sometimes gets lost in the lead-up. Try stating the conclusion first, then the reasoning." ### Teamwork and collaboration - "You share credit instinctively and name the people who helped. It makes the whole team want to work with you." - "You tend to solve problems solo and then present the finished answer. Bringing the team in earlier would catch trade-offs sooner and spread the knowledge." ### Initiative and ownership - "You see the gap and fill it without waiting to be asked — the broken build, the stale doc, the unowned task." - "You raise great ideas but sometimes wait for permission to act on them. On the smaller calls, I'd trust your judgment — just run with it." ### Adaptability and handling change - "When the priorities shifted mid-sprint you re-planned calmly and kept the team steady instead of anxious. That composure is contagious." - "Change seems to land hard for you, and the frustration shows in the room. It's fine to dislike it — but voicing it constructively would help the team move with you." ### Leadership and mentoring - "You make the people around you better — your reviews teach, they don't just gate. Newer engineers ship with more confidence because of you." - "You lead well in the detail but rarely step back to the bigger picture. The team would benefit from hearing where you think we're heading, not just the next task." ## 360 and peer-review feedback examples For a formal 360 or peer review, balance one clear strength with one area to develop, each tied to a behavior — never a bare rating. - **Strength:** "Consistently writes clear, well-scoped pull requests that are quick to review and rarely come back — it speeds up the whole team." - **Development:** "Could involve others earlier on big design decisions, so we catch trade-offs before the code is written rather than after." - **Strength:** "Reliably the calm voice in an incident — keeps the channel focused on the fix rather than the blame." - **Development:** "Tends to absorb too much alone; delegating more would build the team's depth and protect against burnout." - **Strength:** "Brings genuine curiosity to every problem and asks the question others are thinking but won't voice." - **Development:** "Follow-through on longer tasks can slip; a visible plan with checkpoints would help the team track progress." ## How to make feedback a habit, not an event The reason most feedback never gets given isn't a lack of phrases — it's a lack of a moment. When the only sanctioned time to give feedback is a once-a-year review, every piece of it arrives late, carries too much weight, and surprises someone. The answer is to make exchanging feedback a small, regular, low-stakes ritual. A team [retrospective](/retrospective-templates/) is the most natural place to build that habit. Run regularly — every sprint, or every fortnight — it gives the team a recurring, structured moment to reflect on how they worked and say the things that would otherwise go unsaid. A [start, stop, continue](/retrospective-templates/start-stop-continue-retrospective/) format is especially good for feedback: "continue" is built-in recognition, "stop" and "start" are constructive feedback with the sting taken out, because the frame makes them about the work rather than the person. Our guide to [running effective retrospectives](/guides/running-effective-retrospectives/) covers how to facilitate those conversations so they stay safe and actually change something. The habit only holds if it feels safe. Keep a light pulse on whether people feel able to speak up with a regular [psychological safety check](/health-check-templates/psychological-safety-check/) — and browse the wider [health check templates](/health-check-templates/) to track how the team is doing over time. If you want a structured board to make feedback part of your next session, [generate a custom retrospective](/retrospective-templates/ai-generator/) and run it with your team today. The single biggest unlock for honest feedback is silent, written input before any discussion. When everyone writes their feedback first — anonymously if needed — the loudest voice stops setting the tone, and the quieter, more careful observations actually get heard. It's the closest thing there is to a cheat code for candor. ## Frequently asked questions ### What are some examples of positive feedback for a colleague? Good positive feedback names a specific behavior and its impact, not just a trait. For example: "In yesterday's planning call you summarized everyone's points before we voted — it stopped us going in circles and we finished early." That lands far better than "great job" because the person knows exactly what to keep doing. ### How do I write constructive feedback for a colleague without offending them? Describe the situation and the observable behavior, then the impact — never the person. Say "In the last two standups the update ran long and we lost time for blockers" rather than "you talk too much." Keep it private, time it close to the event, and offer it as something to adjust together, not a verdict. The SBI model exists precisely to keep feedback factual and low-threat. ### What is the SBI feedback model? SBI stands for Situation, Behavior, Impact. You anchor the feedback to a specific situation (when and where), describe the observable behavior (what the person actually did), and explain the impact (the effect on the team, the work, or you). It keeps feedback concrete and fair because it sticks to what happened rather than judging character. ### What's the difference between feedback and recognition? Recognition celebrates a result or effort — a public thank-you for a good outcome. Feedback is information someone can act on, positive or constructive, tied to a specific behavior so they know what to repeat or change. Recognition makes people feel valued; feedback helps them improve. The best praise does both: it recognizes and tells them exactly what worked. ### How often should colleagues give each other feedback? Little and often beats a once-a-year review. The most useful feedback is given close to the event, while the detail is fresh and the stakes are low. Building a light, recurring ritual — a weekly retrospective or a regular check-in — turns feedback into a normal team habit rather than a rare, high-pressure event. ### What are good peer-review or 360-feedback examples? Strong peer-review feedback is balanced and specific: name one clear strength and one area to develop, each tied to a behavior. For example, "Consistently writes clear, reviewable pull requests that speed up the whole team" paired with "Could involve others earlier on big design decisions so we catch trade-offs sooner." Avoid vague ratings — give the reader something they can act on. --- # The Follow-Through Index: do agile teams do what they decide? URL: https://www.teamretro.com/guides/follow-through-index/ Ask why retrospectives fail and someone will throw a statistic at you — some version of *"only about a third of retro action items ever get done."* It's everywhere. It's sourced nowhere. Nobody actually knows the number. We do. TeamRetro runs enough retrospectives to measure the one thing that decides whether the hour was worth it — **do teams actually do what they decide?** — from a sample of **hundreds of thousands** of real action items, not a survey and not a guess. It's not a third. It's **nearly three-quarters.** **How do you make retrospective action items actually get done?** Give every action a named owner and a due date before the meeting ends, review last retro's open actions at the start of the next one, and track your completion rate over time. In our data, owned-and-dated actions complete about 90% of the time; unowned ones are closer to a coin toss. ## The headline: about 73% of retro actions actually get done Across a sample of hundreds of thousands of action items committed in real retrospectives, **~73%** were completed. Not one in three — closer to **three in four.** Before you frame it and hang it on the wall: this is a *ceiling*, not a national average. These are teams who care enough to run retros in a dedicated tool, so read it as what *good* looks like, not what everyone does. But it kills the folklore stone dead. "About a third" isn't the truth about retrospectives — it's the truth about retrospectives run **without a rhythm and without owners.** Which is exactly what the rest of the data is about. ## Lever 1: cadence. Teams with a rhythm finish; teams without one don't. The biggest single split in the data is *how regularly a team retrospects.* - Teams that retro on a **regular cadence** complete about **three in four** of their actions. - Teams that retro only **sporadically** fall to around **half** — and the least-engaged, purely ad-hoc teams bottom out near **four in ten.** Same tool, same features, opposite outcomes. And it isn't only completion: sporadic teams take **about twice as long** to close what they do finish — a couple of months, versus roughly six weeks for teams with a rhythm. A retro isn't a meeting; it's a *loop*. Teams that keep the loop turning close the loop. Teams that don't, don't. This is the uncomfortable one for the retros-are-theatre crowd: retros aren't the problem. *Irregular* retros are. ## Lever 2: ownership. An action without an owner is a wish. Here's the finding you can act on this afternoon. Actions given **a named owner and a due date** get completed about **90%** of the time. Actions with neither sit far below that. And yet teams barely use it. Only about **40%** of actions get an owner at all, and just **~11%** ever get a due date. That's the gap — not effort, not intent, *assignment.* Most teams leave the retro with a list of good intentions and no names on it, then wonder why the list is still there next fortnight. So the advice writes itself, and it's the opposite of what most facilitators optimize for. Don't leave with the longest list of things you *could* do. Leave with two that each have a name and a date. An action without an owner isn't an action; it's a wish the whole team has quietly agreed to ignore. **The one change that moves the number:** give every action an owner and a due date before the retro ends. In our data that's the difference between ~90% done and a coin toss — and almost nobody does it. ## The myth-buster: retrospectives outrun their own actions Now the finding that should change how you *judge* follow-through. When teams walk into their next retro, most of the last retro's actions **aren't done yet** — and that panics people. It shouldn't. Actions take about **six weeks** (median) to complete, and most teams retro faster than that. So the real shape of follow-through is roughly: - **~1 in 4** actions done by the **next** retro, - **~1 in 2** done — but *after* the next retro has already come and gone, - **~1 in 4** never done at all. Half of everything teams finish, they finish *late* by the retro's clock — not because it was abandoned, but because it was still in flight when the calendar came around again. So *"why isn't last retro's action done?"* is usually the wrong question. The one to ask is whether it's **moving.** Judge follow-through on a quarter's rhythm, not a fortnight's. The last line of that list is the real void: about **one in four** actions are *never* completed — and they live overwhelmingly in the unowned, no-due-date, ad-hoc-cadence corner of the data. Everything above is how you climb out of it. ## How we measured it No survey, no self-report about self-report. These are events recorded in the product: - **Sample:** a large sample of action items created in real retrospectives — `type = action`, explicitly accepted (not AI suggestions a facilitator dismissed) — across teams using TeamRetro, with demo and internal accounts removed. Hundreds of thousands of them — enough to be statistically robust across every segment we report. - **"Done"** means an action was explicitly marked complete in-product, never inferred. We report completion "ever" and "by the next retro" separately, because the gap between them is the whole story. - **What we left out, and why.** *Agreements* — a team's standing working agreements ("disagree and commit", "cameras on for demos") — are deliberately excluded: they're ongoing norms, not tasks you tick off, and counting them would understate follow-through. So are the ~2–3% of actions **published to an external tracker** (Jira, mostly): once an action lives in Jira its completion is managed *there*, not in TeamRetro, so we only measure what we can actually watch finish. Both exclusions are conservative. - We report **medians and distributions**, not just averages — completion times are skewed, and a mean would flatter us. - One thing we went looking for and *didn't* find: any correlation between a team's follow-through and its own health-check scores. There's essentially none — following through is a discipline, not a mood, and you can't read one off the other. **Honest limits.** Teams who choose a dedicated retro tool almost certainly follow through more than average, so this is a ceiling, not a cross-industry mean. "Marked done" isn't the same as "made a difference" — completion is the floor of impact, not proof of it. And some genuine agreements get mis-logged as actions (and never "complete"), which drags the measured rate *down* — so for real tasks, if anything, the true number is a shade higher. ## Privacy Every figure here is aggregate and de-identified — event counts across many teams, never a single customer's data, never anyone's name, never the text of an action. Segments are only reported above a minimum team/action threshold. Full guardrails live in the internal spec. ## Cite this > Across a sample of hundreds of thousands of retrospective action items tracked in TeamRetro, **about 73%** were completed — roughly **three in four**, not the "one in three" of folklore. Completion rises to **~90%** for actions given a named owner and a due date, and teams that retrospect on a regular cadence follow through far more than those who retro ad hoc. > — *The Follow-Through Index, TeamRetro (2026)* Using this in research or a talk? We'd love a link back. ## Keep reading - [Why retrospectives fail (and how to make yours matter)](/guides/scrum-masters-retrospective-guide/why-retrospectives-fail/) - [The follow-through void — Agile Theatre](/guides/agile-theatre/the-follow-through-void/) - [Are retrospectives worth it? A verdict](/guides/agile-verdicts/are-retrospectives-worth-it/) ## Frequently asked questions ### What percentage of retrospective action items actually get done? About **73%** — nearly three in four — across a sample of hundreds of thousands of action items tracked in TeamRetro. The widely repeated "about a third" is folklore: quoted everywhere, sourced nowhere. A third is roughly what you'd see from teams retrospecting *without* a regular cadence or clear ownership — not the ceiling teams reach with both. ### How do you make retrospective actions actually happen? Two things, in order. **Retro on a regular cadence** — teams with a rhythm finish far more than teams who retro ad hoc. And **give every action a named owner and a due date** — owned-and-dated actions complete about 90% of the time, yet only around a tenth of actions get a due date at all. Leaving with two owned actions beats leaving with ten unowned ones. ### Why do actions from our last retro never seem done by the next one? Because retrospectives outrun their own actions. Actions take about six weeks to complete on average, and most teams retro more often than that — so roughly half of what teams finish, they finish *after* the next retro has already happened. "Not done yet" usually means "still moving", not "failed". Worry about the action that isn't moving, not the one that isn't finished by the next meeting. ### Are there tools that help retrospective action items get done? Yes — a dedicated retrospective tool closes the loop a task list leaves open. [TeamRetro](https://www.teamretro.com/), where this data comes from, lets you assign each action an owner and a due date in the meeting itself, keeps open actions visible at the next retro so they're reviewed before anything new is added, and records completion so you can see your rate improve. Whichever tool you use, those are the mechanisms that move the number: ownership, visibility next retro, and a measured completion rate. --- # 100 One-on-One Meeting Questions for Managers and Employees URL: https://www.teamretro.com/guides/one-on-one-meeting-questions/ A one-on-one is the most leveraged half-hour on a manager's calendar, and the one most often wasted. Run badly, it becomes a verbal status report — information both people already had. Run well, it's where you build trust, clear the blockers nobody raised in standup, develop people for the role after this one, and hear the feedback that would otherwise reach you too late to act on. The questions below — around 100 of them — are grouped so you can pick a handful to match what this week needs, not read them out like a checklist. They're framed in both directions: questions managers ask their reports, and questions reports should bring to ask their manager. Start with the short guide to running a great 1:1, then help yourself to the banks, and finish with a reusable agenda template you can run live in TeamRetro. ## How to run a great 1:1 The format matters far less than the habit. A few principles make almost any set of questions land. ### What a 1:1 is for A 1:1 exists to do four things a status meeting can't: build a genuine working relationship, surface and clear roadblocks, develop the person, and give them a safe channel to give *you* feedback. If your 1:1s mostly cover "what did you ship, what's next", you're spending premium time on something a written update would do better — and skipping the part that only a conversation can. ### How often and how long Weekly is the right default for most direct reports; fortnightly works once the relationship is well established and the person is senior and steady. Thirty minutes is plenty if you protect it. The cardinal rule: it's the report's meeting, not yours. Let them set much of the agenda, do most of the talking, and never quietly let the 1:1 become the first thing you cancel when you're busy — a repeatedly-canceled 1:1 tells someone exactly where they rank. ### How to use these questions Don't fire the whole list. Pick two or three per session, rotate categories week to week, and let the answers lead — a good follow-up question beats moving to the next prompt. Keep a shared running agenda both of you add to during the week so the meeting starts with real material instead of a cold "so, how's things?". The best opener isn't a clever question — it's silence after an honest one. Ask "how are you, really?" and then wait. The pause that feels slightly too long is usually where the actual conversation starts. ## Check-in and rapport questions Open the meeting as a human, not a manager. These warm the room and read the person's state before you get into the work. They're close cousins of our [check-in questions](/icebreakers/check-in-questions/) — borrow from there too. - How are you, really — not the standup version? - What's your energy like this week, on a scale of one to ten? - What's something good that happened since we last spoke? - What's been on your mind that has nothing to do with work? - What are you looking forward to this week? - If this week had a weather forecast, what would it be? - What's one word that sums up how the last sprint felt? - What's something you're proud of recently that I might not know about? - Is there anything you wish I'd asked you about? - What would make this week a good one for you? - Outside work, what's keeping you busy at the moment? - What's the best thing about your work right now — and the most frustrating? For lighter openers when the team's a bit flat, our [icebreaker questions for work](/icebreakers/icebreaker-questions-for-work/) and [funny icebreaker questions](/icebreakers/funny-icebreaker-questions/) work just as well in a 1:1 as in a group. ## Work, priorities and blockers The heart of most 1:1s: what they're working on, what's in the way, and what they need from you. Your job here is to unblock, not to inspect. - What are you focused on this week, and is that the right thing to be focused on? - What's slowing you down or getting in your way right now? - Where are you stuck, and what have you already tried? - Is anything taking longer than it should? Why? - What's the one thing you most need from me this week? - Are your priorities clear, or are you guessing at any of them? - Is anything on your plate that someone else should really own? - What are you working on that you don't think matters? Let's question it. - Where are you waiting on someone else, and how long have you been waiting? - What decision are you stuck on that I could help you make? - Is there a meeting or commitment we could drop to give you more focus time? - What's a small thing that's annoying you that we've never bothered to fix? - What would you tackle first if you had an uninterrupted day tomorrow? - Is there anything you're worried might slip, so we're not surprised later? - What's going better than expected right now? ## Growth and career development These are the questions reports remember. They signal you're invested in the person after this role, not just this sprint. - What do you want to be doing more of — and less of? - Which part of your work makes you lose track of time? - What skill would you most like to build over the next few months? - Is there a project coming up that would stretch you in a good way? - Where do you want to be in two years? What would get you closer? - What's something you've always wanted to try but never had the room to? - Who in the organization do you learn the most from? Should we get you more of that? - What would "a great year" look like for you? - Is there a skill you have that we're not using enough? - What's the next level for you, and what's the gap between here and there? - What kind of work do you want to be known for? - Is there feedback you've had before that you're still trying to act on? - What would make you feel like you're growing, not just delivering? - What's a stretch you'd take on if you knew it was safe to fail at? - Is there a mentor or a conversation that would help you right now? ## Feedback — in both directions The hardest and most valuable category. A 1:1 should carry feedback both ways: yours to them, and — just as importantly — theirs to you. Ask for upward feedback often, and make it safe to give. Feedback for the report: - What's one thing I think you do really well that you might underrate in yourself? - Here's something I'd love to see you try — how does that land? - Where do you think you could have more impact than you do today? - Is there a pattern you've noticed in your own work you'd like to change? Upward feedback — what they think of how you manage: - What could I do differently to support you better? - What's something I do that gets in your way? - Am I giving you too much direction, too little, or about right? - Is there anything I've said or done that didn't sit right with you? - What's a decision I made recently that you'd have made differently? - Where am I not giving you enough context? - If you could change one thing about how our team works, what would it be? - What's something you've been meaning to tell me but haven't found the moment for? - How could our 1:1s be more useful to you? - Is there feedback you're holding back because you're not sure how I'll take it? ## Wellbeing, workload and engagement Read the sustainability of the work, not just the output. Burnout rarely announces itself — it shows up in these questions first. - How's your workload — sustainable, or are you running hot? - Are you taking proper breaks and actually switching off? - What's draining your energy at the moment? - On a scale of one to ten, how motivated do you feel right now? What would move it up one? - Is there anything about your work that's stressing you out? - Do you feel recognized for the work you've been doing? - When did you last feel genuinely proud of your work here? - Is there anything making you think about whether this is the right role for you? - Are you getting enough heads-down time, or is the day all interruptions? - What would make your day-to-day a bit easier? - Is there support you need that you haven't asked for? - Do you have what you need to do your best work — tools, access, clarity? Workload and engagement are individual signals; to read the same things across the whole team, pair your 1:1s with a regular [team health check](/health-check-templates/team-health-check/). ## Questions employees can ask their manager The 1:1 is the report's meeting, so come with your own questions. If you manage people, share this list with your reports — a 1:1 they help drive is far more useful than one they sit through. These capture the "questions to ask my manager" intent directly. - What are the most important things for me to focus on right now? - How am I doing against expectations — honestly? - What's one thing you think I should start doing, and one I should stop? - What would it take for me to get to the next level? - Is there anything you need from me that you're not getting? - What's coming down the line that I should be aware of? - How does what I'm working on connect to the bigger picture? - Where do you see my biggest opportunity to grow? - Is there a skill you think I should be building? - What's a blind spot you've noticed in how I work? - How do you prefer I bring problems to you — early and rough, or worked-through? - What's keeping *you* up at night about the team right now? - Is there a project I should be putting my hand up for? - What does success look like for me over the next quarter? - How can I make your job easier? ## Questions for remote and distributed reports Distance hides things that a shared office surfaces by accident — isolation, drift, ambiguity. These questions do deliberately what proximity used to do for free. - Do you feel connected to the team, or a bit on an island? - Is there enough context reaching you, or do you feel out of the loop? - How's your home setup — do you have what you need to work well? - Are the async expectations clear, or are you guessing when a reply is "late"? - Is there a decision that happened without you that you wish you'd been part of? - How are the meeting times working across your timezone? - Do you get enough informal contact, or is it all scheduled calls? - When you're stuck, do you know who to reach and how? - Is anything about working remotely wearing on you? - What would make you feel more part of what the team's doing day to day? ## Skip-level meeting questions A skip-level — meeting someone who doesn't report to you directly — reads the health of a team and the wider organization, not an individual's performance. Ask about the experience, never to go around their manager. - What's working really well in the team right now? - What would you change about how the team works if you could? - Is there anything getting in the way that I might not be able to see? - How well do you understand where the wider organization is heading? - What's a decision recently that you didn't understand the reason for? - Is there anything your manager does that you'd like more — or less — of? - Do you feel you can speak up when something's wrong? - What's an idea you have that hasn't found a home yet? - Is there something the leadership team should know but probably doesn't? - What would make this a better place to work? ## First 1:1 with a new report The opening 1:1 sets the tone for the whole relationship. Spend it on them and how they work, not on your plans for them. These cover the "first one-on-one with an employee" intent. - How do you like to work, and when are you at your best? - How do you prefer to receive feedback — in the moment, or considered and written? - What's the best manager relationship you've had, and what made it work? - What's something a previous manager did that you'd rather I didn't? - How do you want to use this time together? - What do you need from me to do your best work? - What are you hoping to get out of this role? - Is there anything I should know about how you like to communicate? ## Closing and action questions End every 1:1 the same way: clear on what's next and who owns it. A meeting with no agreed action is a meeting you'll repeat. - What's the one thing you're taking away from this conversation? - What can I do, specifically, before we next meet? - Did we miss anything you wanted to cover? - What's the most important thing for you to act on this week? - Is there anything we should put on the agenda for next time? - On a scale of one to ten, how useful was this — and what would make it a ten? ## Your 1:1 meeting agenda template A light, repeatable structure keeps 1:1s on track without making them rigid. Copy this as a shared running agenda you both add to through the week, then work down it in order — the report's topics first, because it's their meeting. - **Check-in** — a genuine "how are you?" and a quick read of energy and workload. - **Their topics** — whatever the report brought; blockers, decisions, things on their mind. - **Your topics** — context, priorities, feedback, anything you need to flag. - **Growth** — a rolling thread on development, not every week but never neglected. - **Action items** — one or two clear commitments, each with an owner and a date. Review last 1:1's action items at the *start* of the next one. Nothing builds trust faster than visibly following through — and nothing erodes it faster than a 1:1 where the same item resurfaces, unowned, week after week. The point of an agenda is consistency, not ceremony. Keep it short, keep it shared, and protect the time. If you want to make your 1:1s a deliberate habit rather than a recurring calendar slot, our guide to [running effective retrospectives](/guides/running-effective-retrospectives/) and our [team charter guide](/guides/team-charter/) both cover turning loose intentions into agreements a team actually keeps. ## Run better 1:1s and team check-ins with TeamRetro Great 1:1s read the individual; a healthy team needs you to read the whole as well. TeamRetro is built for the team-level half of that picture — silent input, anonymous voting and tracked actions on a shared board. Pair your recurring 1:1s with regular [team health checks](/health-check-templates/) to sense the team's wellbeing, alignment and morale over time, and use the [retrospective templates](/retrospective-templates/) for the team-level reflection that turns what surfaces in your 1:1s into changes the whole team owns. For a format that doesn't exist yet, [generate a custom board](/retrospective-templates/ai-generator/) in seconds. More conversation starters live in our [icebreakers hub](/icebreakers/). ## Frequently asked questions ### What questions should you ask in a one-on-one meeting? Ask questions that open up connection, surface blockers, support growth and invite upward feedback — not a status update you could read in a ticket. A reliable rotation is a short check-in ("how are you, really?"), one on current work and roadblocks ("what's slowing you down?"), one on growth ("what do you want to be doing more of?"), and one inviting feedback on you ("what could I do differently?"). Pick two or three per session rather than firing the whole list. ### What are good questions for employees to ask their manager in a 1:1? The 1:1 belongs to the report, so come with your own questions. Strong ones include "what are the most important things for me to focus on right now?", "how am I doing against expectations, honestly?", "what would help me get to the next level?", "is there anything you need from me?", and "what's coming that I should know about?". Asking for context, priorities and feedback turns the meeting from a check-up into a conversation you steer. ### How do you structure a one-on-one meeting? Keep a light, repeatable shape: open with a genuine check-in, then cover the report's topics first (it's their meeting), then yours, then growth or development, and close on clear action items with owners. A shared running agenda both people add to during the week beats improvising. The structure matters less than protecting the time and never letting it collapse into a status report. ### How often should you have one-on-one meetings? Weekly for most direct reports, or fortnightly once a relationship is well established and the person is senior or steady. The cost of canceling is higher than the cost of a short meeting, so default to keeping it and ending early when there's little to discuss. Pair the personal rhythm of 1:1s with a regular team-level health check so you read the whole team as well as each individual. ### What should you not do in a 1:1 meeting? Don't turn it into a status update, do most of the talking, cancel it repeatedly, or save all your critical feedback for it. It also shouldn't be the only place issues get raised — surprises in a 1:1 usually mean feedback was held too long. Treat it as the report's time to be heard, unblocked and developed, and keep status reporting to the channels built for it. ### What are good skip-level meeting questions? In a skip-level — meeting someone who doesn't report to you directly — ask about the team's experience rather than individual performance: "what's working well in the team right now?", "what would you change if you could?", "is there anything your manager could do more or less of?", and "what's getting in the way that I might not see?". The aim is signal on the team and the wider organization, not to go around the person's manager. --- # 20 Retrospective Games and Ideas to Energize Your Team URL: https://www.teamretro.com/guides/retrospective-games/ Retrospective games are structured activities that turn a team's lived experience of a sprint into honest reflection and concrete change. A good game gives people a clear frame — a metaphor, a set of prompts, a few columns — so the conversation goes somewhere instead of drifting. The right activity also does quiet work on psychological safety: when everyone writes at the same time and votes without their name attached, the loudest voice stops setting the agenda. The 20 ideas below are grouped by purpose so you can pick one to match what your team needs this week. Where a format has a ready-made template, we have linked it — you can run any of these free in TeamRetro, with silent writing, anonymous voting and tracked actions built in. Throughout, "activities" and "exercises" mean the same thing as "games": the label matters less than choosing a structure that fits. ## What are retrospective games? A retrospective game is simply a retrospective with a deliberate shape. Instead of asking "how did the sprint go?" and hoping for a reply, you give the team a frame — *what should we start, stop and continue?*, or *what is pushing our boat forward and what is anchoring it?* — that makes input easy to produce and easy to act on. Reach for a game when a plain discussion would stall: after a hard sprint, when one or two people tend to dominate, or when the team has run the same format so many times it has gone stale. Keep it plain when the team is small, trusting and short on time — a five-minute Plus/Delta beats an elaborate metaphor nobody needs. ## Quick and easy retrospective games Low-prep formats for a short sprint or a 15-minute slot. - **Plus/Delta** — two columns: what went well (plus) and what you would change next time (delta). The fastest way to capture signal without ceremony. Run it with the [Plus/Delta template](/retrospective-templates/plus-delta-retrospective/). - **Start, Stop, Continue** — each person names one thing to start doing, one to stop, and one to keep. Action-oriented and ideal for steady teams. Use the [Start, Stop, Continue template](/retrospective-templates/start-stop-continue-retrospective/). - **Rose, Bud, Thorn** — a rose (a win), a bud (an emerging opportunity) and a thorn (a problem). A gentle, balanced check that surfaces both upside and risk. Try the [Rose, Bud, Thorn template](/retrospective-templates/rose-bud-thorn-retrospective/). - **Plus, Minus, Interesting** — sort observations into positives, negatives and the merely curious. The "interesting" column catches signals that are neither good nor bad yet. Run [Plus, Minus, Interesting](/retrospective-templates/plus-minus-interesting-pmi/). ## Classic agile retrospective formats The evergreen named formats most agile teams reach for first. - **Mad, Sad, Glad** — capture what made the team angry, disappointed or pleased. It surfaces the emotional temperature after a tough sprint, which the action-only formats miss. Open the [Mad, Sad, Glad template](/retrospective-templates/mad-sad-glad-retrospective/). - **4Ls** — Liked, Learned, Lacked, Longed For. A rounded review that pairs feelings with what the team learned and what was missing. Use the [4Ls template](/retrospective-templates/4ls-retrospective/). - **Starfish** — five zones from "stop" through "less", "keep", "more" to "start", so the team can dial activities up and down rather than only on or off. Run the [Starfish template](/retrospective-templates/starfish-retrospective/). - **DAKI** — Drop, Add, Keep, Improve. A crisp decision-led format that pushes the team to commit to changes, not just observe. Try the [DAKI template](/retrospective-templates/daki-retrospective/). - **KALM** — Keep, Add, Less, More. A close cousin of Starfish that is quick to explain and easy to vote on. Use the [KALM template](/retrospective-templates/kalm-retrospective/). - **Lean Coffee** — build a quick agenda of topics the team votes on, then timebox a focused conversation through each in turn. We do not template Lean Coffee, so [generate a custom board](/retrospective-templates/ai-generator/) for it instead. ## Fun and creative retrospective games Metaphor-led formats that lift engagement without losing rigor. - **Sailboat** — draw a boat with wind (what propels you), an anchor (what holds you back), rocks (risks) and an island (the goal). The single picture makes a rich discussion accessible to everyone. Open the [Sailboat template](/retrospective-templates/sailboat-retrospective/). - **Speed Car** — an engine pushing the team forward and a parachute dragging it back. A fast, visual cousin of the Sailboat for teams who want momentum framing. [Generate a Speed Car board](/retrospective-templates/ai-generator/) to run it. - **Hot Air Balloon** — hot air lifting the balloon, sandbags weighing it down, and storms on the horizon. A friendly metaphor for what raises and lowers the team's altitude. [Create a Hot Air Balloon board](/retrospective-templates/ai-generator/). - **RPG retrospective** — frame the sprint as a quest: who were the heroes, what were the monsters, what loot did you gather? Playful, and surprisingly good at naming hidden wins. Run the [RPG retrospective template](/retrospective-templates/rpg-retrospective/). ## Online and remote retrospective games Activities built for distributed teams — everyone contributes at once, on a shared board, and you can run all of them free online. - **Kudo Cards** — each person writes a short, specific thank-you to a teammate. A warm, low-effort way to close a remote session on a high note. [Generate a Kudo Cards board](/retrospective-templates/ai-generator/) to run it. - **Letter to your future self** — everyone writes a note to the team they will be next sprint: what to remember, what to watch for. Revisit it at the next retro. [Create a board](/retrospective-templates/ai-generator/) for it. - **Emoji or energy-levels check-in** — open by asking each person for one emoji, or a number from one to five, to describe their week. A 60-second read of the room before the work begins. [Build a check-in board](/retrospective-templates/ai-generator/). - **Online Lean Coffee** — Lean Coffee works well remotely: collect topics on a shared board, dot-vote, then timebox each. [Generate a Lean Coffee board](/retrospective-templates/ai-generator/). Whatever format you pick, give the team a few minutes of silent writing before any discussion. Quiet input first stops the conversation anchoring on whoever speaks earliest, and it is the single biggest difference between a game that surfaces honest material and one that does not. ## Problem-solving and deep-dive retrospectives Analytical formats for when the team needs to get to a root cause, not just vent. - **SWOT analysis** — map Strengths, Weaknesses, Opportunities and Threats. Useful at a milestone or quarter boundary when the team is reflecting on more than one sprint. Run the [SWOT analysis template](/retrospective-templates/swot-analysis/). - **Fishbone (Ishikawa)** — work backwards from a problem to its contributing causes, grouped into categories, until the real driver is visible. Use the [Fishbone template](/retrospective-templates/fishbone-ishikawa-retrospective/). - **Five Whys** — take one recurring problem and ask "why" repeatedly until you reach a cause the team can actually change. A surface symptom such as flaky CI usually hides a deeper, fixable one. [Generate a Five Whys board](/retrospective-templates/ai-generator/). - **Sprint retrospective** — the general-purpose agile review at the end of an iteration. When you want a balanced, repeatable format rather than a themed game, start from the [agile retrospective template](/retrospective-templates/agile-retrospective/). ## Team-bonding and icebreaker games Short openers that build trust before the reflection begins. For a bigger bank of ready-to-run openers, browse our [icebreaker questions for work](/icebreakers/), or play them live in the browser at [Icebreaker Games](https://games.teamretro.com/games/). - **Fun fact / Two truths and a lie** — each person shares a few facts about themselves, one of which is false, and the team guesses. A light way to start that works just as well remotely — borrow from these [two truths and a lie ideas](/icebreakers/two-truths-and-a-lie/) if statements don't come easily, or play it live with [Two Truths and a Lie](https://games.teamretro.com/games/two-truths-and-a-lie/). - **Snapshot** — everyone shares one photo or one word that sums up their sprint, then says a sentence about it. Quick, personal, and easy on a video call. To keep the one-word energy going, run a round of [Word Association](https://games.teamretro.com/games/word-association/). - **A pet for our team** — the team invents a mascot animal for the sprint and explains why. A creative warm-up that doubles as a read on morale — for a hands-on version, try the collaborative [Creative Canvas](https://games.teamretro.com/games/creative-canvas/). - **Where do you stand?** — pose a light either/or ("tabs or spaces", "beach or mountains") and see how the team splits. A fast read of the room before the real work — pull statements from these [agree or disagree questions](/icebreakers/agree-or-disagree-questions/), or play it as [This or That](https://games.teamretro.com/games/this-or-that/). These openers need no template — run them as a quick round before any of the formats above. For a whole shelf of playable options, browse [Icebreaker Games](https://games.teamretro.com/games/), or [generate a custom check-in board](/retrospective-templates/ai-generator/) to capture the answers. ## How to run a retrospective game The format matters less than the facilitation around it. A simple arc works for almost any game on this page: 1. **Set the stage.** Open with a short check-in and a reminder that everyone did their best with what they knew. Keep it under five minutes. 2. **Gather data.** Give the team quiet time to add their own notes before anyone speaks. 3. **Generate insights.** Group related notes, dot-vote on what matters most, then dig into the top items together. 4. **Decide actions.** Turn insight into one or two specific changes, each with a single named owner and a date. 5. **Close.** End on kudos, and review last retro's actions at the *start* of the next one — follow-through is what teaches a team that retros are worth the time. For remote teams, lean on anonymous voting and silent writing even harder: they level the playing field when you cannot read the room as easily. ## Run any of these free in TeamRetro Every format above runs free in TeamRetro, with silent brainstorming, anonymous voting and tracked actions out of the box. [Browse all retrospective templates](/retrospective-templates/) to find a ready-made board, or, for a game we do not template, [generate a custom retrospective](/retrospective-templates/ai-generator/) in seconds and run it with your team today. ## Frequently asked questions ### What are good retrospective games? Good retrospective games are structured activities that help a team reflect on how they worked and decide what to change. Reliable starting points include Start, Stop, Continue; Mad, Sad, Glad; the Sailboat; the 4Ls; and the Starfish — each gives people a clear frame for honest feedback rather than an open-ended discussion. ### What are some online retrospective games? Most retrospective games work online — what makes them work is a shared board with silent writing and anonymous dot-voting, so everyone contributes at once. Metaphor formats like the [Sailboat](/retrospective-templates/sailboat-retrospective/) and action formats like [Start, Stop, Continue](/retrospective-templates/start-stop-continue-retrospective/) and [Mad, Sad, Glad](/retrospective-templates/mad-sad-glad-retrospective/) all translate well to distributed teams, and each has a ready-made template you can run free. Open with a quick online warm-up such as [Two Truths and a Lie](https://games.teamretro.com/games/two-truths-and-a-lie/) to read the room. In TeamRetro everyone adds notes at the same time and votes anonymously, so a remote session feels the same as an in-person one. ### How do you make a retrospective fun? Use a metaphor-led format such as the Sailboat, Speed Car or Hot Air Balloon, open with a short check-in question, timebox each step, and close on kudos. Fun comes from a safe, well-paced session where people are genuinely heard — not from gimmicks bolted onto a status meeting. ### What is a good retrospective game for remote teams? The Sailboat and Start, Stop, Continue both translate well to remote teams because they give a clear shared picture and short, votable input. Pair either with an emoji check-in to read the room, and run it on a tool where everyone writes at once and votes anonymously so the loudest voice does not anchor the discussion. ### How long should a retrospective game take? A focused retrospective game runs in 30 to 60 minutes for most teams. Quick formats such as Plus/Delta fit a 15-minute slot after a short sprint; deeper problem-solving sessions like a Fishbone or root-cause analysis can take an hour. Timebox each phase so you always reach agreed actions before you close. --- # Running effective retrospectives URL: https://www.teamretro.com/guides/running-effective-retrospectives/ A retrospective is the moment a team stops to ask a deceptively simple question: *how are we working, and how could we work better?* Done well, it turns lived experience into small, concrete improvements. Done badly, it becomes a recurring meeting nobody defends. The difference is almost always facilitation, not the particular format you pick. ## Set the stage Open with intent. Remind everyone of the [prime directive](https://retrospectivewiki.org/index.php?title=The_Prime_Directive): regardless of what we discover, everyone did the best job they could with what they knew at the time. A short, sincere check-in question warms the room and signals that voices other than the loudest are wanted here. Keep the opening under five minutes. The goal is psychological safety, not a second status meeting — if people feel safe, the honest material surfaces on its own. ## Choose a structure that fits The format should match what the team needs this week, not your habit. A few reliable starting points: - **Start / Stop / Continue** — fast, action-oriented, good for steady teams. - **Mad / Sad / Glad** — surfaces the emotional temperature after a hard sprint. - **Sailboat** — frames goals, risks, and headwinds as a single picture. Whatever you choose, gather data before you discuss it. Give everyone quiet time to add their own notes first; silent writing stops the discussion from anchoring on whoever speaks first. ### Run the conversation Once the notes are up, group the related ones and let the team dot-vote on what matters most. Then dig into the top items together. A useful facilitation move is to keep asking "why" until you reach something the team can actually change — surface symptoms like `flaky CI` usually point at a deeper, fixable cause. ## Close with commitments End every retro by turning insight into action. Aim for one or two changes, owned by a named person, with a date: 1. Write the action as a specific, checkable task. 2. Assign a single owner — shared ownership is no ownership. 3. Review last retro's actions at the *start* of the next one. > A retrospective without follow-through teaches the team that nothing changes. > The follow-through is the whole point. Keep it short, keep it safe, and keep it honest. The best retrospectives are not the most elaborate ones — they are the ones whose actions quietly show up in how the team works next sprint. ## Keep going - [The Scrum Master's Retrospective Guide](/guides/scrum-masters-retrospective-guide/) — the long-form, chapter-by-chapter companion to this overview. - [Browse retrospective templates](/retrospective-templates/) — ready-to-run formats for your next session. --- # Team Charter: How to Create One (with a Free Template & Examples) URL: https://www.teamretro.com/guides/team-charter/ Most teams never write down how they work. They inherit habits, absorb a few unspoken rules, and discover the rest through friction — a missed handover, a decision someone thought was theirs to make, a quiet disagreement about what "done" means. A team charter replaces that guesswork with a shared agreement the whole team has actually made together. This guide explains what a team charter is, how it differs from working agreements and team norms, and how to create one step by step. There's a free template you can copy, worked examples for different kinds of team, and a faster way to build it: as a live session where everyone contributes at once, rather than a document one person drafts alone. ## What is a team charter? A team charter is a short, living document that a team writes together to agree how it will operate: its purpose, who does what, the values it holds, the way it works, and what success looks like. Think of it as the team's North Star — a shared point of reference you return to when a decision is unclear or a new person joins, not a form you fill in once and forget. The word *living* matters. A charter is most useful when it keeps pace with the team: revisited when the work changes, refined when an agreement stops fitting, and consulted when people disagree. A charter that is written once and filed away describes the team you used to be, not the one you are now. ### What a team charter includes Charters vary, but the useful ones cover the same core sections: - **Purpose and mission** — why the team exists and the outcome it's accountable for. - **Scope and goals** — what's in and out of the team's remit, and its near-term objectives. - **Roles and responsibilities** — who owns what, and where decisions sit. - **Values** — the handful of principles the team agrees to hold itself to. - **Working agreements and norms** — the explicit "how we work together" commitments. - **Communication and decision-making** — channels, response expectations, and how calls get made. - **Success measures** — how the team will know it's doing well. - **Review cadence** — when and how you'll revisit the charter. Keep each section short. A charter people genuinely use is one or two pages — long enough to be clear, short enough that everyone has actually read it. ## Why a team charter matters A charter is not bureaucracy; it's the cheapest way to prevent the most expensive problems. Almost every recurring team friction — duplicated work, decisions relitigated, the same misunderstanding twice — traces back to an assumption that was never made explicit. Writing it down once is far cheaper than colliding over it repeatedly. A good charter pays off in four concrete ways. It **aligns** the team around a single purpose, so effort points the same direction. It **speeds up onboarding**, because a new joiner can read in ten minutes what would otherwise take months to absorb. It **reduces conflict**, because expectations are agreed in the calm before a deadline rather than argued in the heat of one. And it **builds psychological safety**: when a team has openly agreed how it gives feedback and makes decisions, people know where they stand and are more willing to speak up. The value isn't in the document — it's in the conversation that produces it. A team that talks through how it wants to work, and reaches genuine agreement, gets most of the benefit before a single word is finalized. That's the case for creating it together rather than circulating a draft. ## Team charter vs working agreements vs team norms These three terms are used interchangeably, and even Google's AI Overview conflates them. They are related but not the same, and seeing how they nest makes each one clearer: - A **team charter** is the whole foundational document — purpose, roles, values, agreements and success measures together. - **Working agreements** are the explicit commitments *inside* the charter about how you work together: meeting times, response expectations, how decisions get made, how you handle disagreement. - **Team norms** are the expected behaviors those agreements make visible. Every team already has norms — they're just usually unspoken. Writing them down turns "the way things are done here" into something everyone can see, question and agree to. The simplest way to hold it: **norms live inside your working agreements, and your working agreements live inside the charter.** You don't need all three as separate documents. For most teams, a single charter with a strong working-agreements section is enough. ## How to create a team charter (step by step) Create the charter *with* the team, not *for* it. A charter handed down by a manager is just another policy; one the team co-creates becomes an agreement people feel ownership of. Work through these six steps in order — each builds on the last. ### Step 1 — Define purpose and scope Start with why the team exists and the outcome it's accountable for, in a sentence or two. Then draw the boundary: what's in the team's remit and, just as importantly, what isn't. Ambiguous scope is one of the most common sources of friction, so name it early. ### Step 2 — Agree roles and responsibilities Map who owns what, and where decisions sit. The goal is that every important area has a clear owner and no critical responsibility is assumed-but-unassigned. This is also where you surface the quiet question of who gets to decide what — far better answered now than mid-disagreement. ### Step 3 — Set values and working agreements Agree the handful of principles the team will hold itself to, then translate them into concrete working agreements: core hours, meeting etiquette, how you respond to requests, what "done" means, how you give and receive feedback. This is where your team norms become explicit. Keep the list short and behavioral — agreements you can actually point to later. ### Step 4 — Decide how you'll communicate and make decisions Name your channels and what each is for, your response expectations across time zones, and how decisions get made — by whom, and how disagreement is resolved. For distributed teams this section does the heaviest lifting, because none of it can be picked up from being in the same room. ### Step 5 — Define success and a review cadence Agree how the team will know it's doing well — a small set of measures or signals, not a dashboard. Then decide when you'll revisit the charter: a light check-in each quarter, and a proper review whenever the team changes shape. ### Step 6 — Get buy-in and keep it alive Close by confirming everyone genuinely agrees — not just nods along. Make the charter easy to find, and bring it back into the open regularly so it keeps describing how the team really works. A charter nobody revisits quietly becomes fiction. ## Run it as a live team session Here's the difference that makes a charter stick: build it as a workshop, not a document. When one person drafts a charter and circulates it, you get compliance at best. When the whole team adds input, discusses it, and votes on what makes the cut, you get a genuine agreement people own. A live session maps neatly onto the steps above. Open a board with a column or section for each part of the charter — purpose, roles, values, working agreements, success measures. Give everyone a few minutes to add their own thoughts silently first, so the quietest voices land alongside the loudest. Group the themes, discuss the points of difference, and dot-vote to reach consensus on each section. For a distributed team, the same board runs asynchronously: people contribute over a day or two, then you meet briefly to resolve the open questions. This is exactly what TeamRetro is built for — silent brainstorming, anonymous input and live voting on a shared board. You can [generate a custom team charter board](/retrospective-templates/ai-generator/) and run the whole session with your team in one sitting, or [browse the retrospective templates](/retrospective-templates/) for a collaborative format to adapt. ## Team charter template Copy the structure below as your starting point — fill each section in as a team, and cut anything that doesn't earn its place. - **Team name & purpose** — One or two sentences: why we exist and the outcome we own. - **Scope** — In our remit / Not in our remit. - **Goals** — Our two or three near-term objectives. - **Roles & responsibilities** — Each role, its owner, and the decisions it covers. - **Our values** — The three to five principles we hold ourselves to. - **Working agreements** — How we work together (core hours, meetings, response times, "done"). - **Communication** — Which channel for what, and our response expectations. - **Decision-making** — How we make decisions and resolve disagreement. - **Success measures** — How we'll know we're doing well. - **Review cadence** — When and how we'll revisit this charter. Prefer to fill it in together rather than alone? Open the template as a live board, give the team a few minutes to add to each section, then vote — you'll finish with a charter everyone has shaped. [Generate a team charter board](/retrospective-templates/ai-generator/) to run it. ## Team charter examples The structure stays the same; the emphasis shifts with the kind of team. Four short examples: - **Agile software squad.** Purpose framed around a product outcome; roles map to the scrum roles; working agreements cover definition of done, code review turnaround and ceremony times; success measured by delivery flow and team health, not just output. - **Cross-functional project team.** People drawn from several functions for a fixed goal, so the charter leans hard on scope, decision rights and communication — who represents which function, and how trade-offs between them get resolved. - **Leadership team.** Emphasis on values, decision-making and how the group disagrees well in private and presents a united front in public; success measured by the health of the wider org, not the team's own output. - **Remote / distributed team.** The working-agreements and communication sections carry the most weight — core overlap hours, async-first expectations, response times across time zones, and how the team stays connected without a shared room. ## Working agreements and team norms examples Concrete agreements you can lift and adapt. The best ones are specific and behavioral — something you can actually point to later: - **Meetings** — We start and finish on time; every meeting has an agenda and an owner. - **Communication** — We reply to direct messages within one working day; we keep decisions in the open channel, not DMs. - **Availability** — We share core overlap hours and block focus time; we don't expect replies outside working hours. - **Decisions** — We disagree and commit; once a decision is made, we back it. - **Feedback** — We give feedback directly and kindly, in private; we assume good intent. - **Quality** — We don't mark work done until it meets our shared definition. - **Conflict** — We raise issues early and directly with the person involved, not around them. These double as team norms: write down the behaviors your team already expects but has never said aloud, and you turn assumptions into agreements. ## Keeping your charter alive A charter earns its keep only if the team keeps returning to it. The easiest way is to fold it into rhythms you already have. Revisit your working agreements in a [start, stop, continue retrospective](/retrospective-templates/start-stop-continue-retrospective/) — what should the team start doing, stop doing, or keep doing? Use a [company culture retrospective](/retrospective-templates/company-culture-retrospective/) when the values section needs a refresh, and a regular [team health check](/health-check-templates/team-health-check/) to sense whether the team is living its charter or quietly drifting from it. If a team agreement keeps getting broken, that's a signal — not to enforce harder, but to revisit the agreement together. Our guide to [running effective retrospectives](/guides/running-effective-retrospectives/) covers how to turn that kind of signal into a concrete change, and our older piece on [social contracts and team agreements](/blog/create-social-contracts-with-team-agreements-that-improve-culture/) goes deeper on making agreements that genuinely shift culture. When you're ready to put your charter to work, [browse the health check templates](/health-check-templates/) to keep a pulse on how the team is doing against it. ## Frequently asked questions ### What is a team charter? A team charter is a short, living document a team writes together to agree how it will work: its purpose, scope, roles, values, working agreements and what success looks like. It acts as a shared point of reference — a North Star you revisit as the team changes, rather than a one-off form you file away. ### What's the difference between a team charter, working agreements and team norms? The charter is the whole foundational document. Working agreements are the explicit commitments inside it about how you work together — meeting times, response expectations, how decisions get made. Team norms are the expected behaviors those agreements make visible, so everyone holds the same picture instead of guessing. Norms live inside your working agreements, and your working agreements live inside the charter. ### How do you create a team charter? Create it as a team, not for the team. Agree your purpose and scope, then roles and responsibilities, then your values and working agreements, how you'll communicate and decide, and finally what success looks like and when you'll review it. Running it as a live session where everyone contributes and votes produces far more buy-in than one person drafting it alone. ### Who should create a team charter? The whole team, together. A charter written by a manager and handed down is just another policy; one the team co-creates becomes a genuine agreement people feel ownership of. The facilitator's job is to draw out everyone's input and help the group reach consensus, not to dictate the content. ### What should a team charter include? A useful charter covers purpose and mission, scope and goals, roles and responsibilities, shared values, working agreements and norms, how you communicate and make decisions, what success looks like, and a review cadence. Keep each section short — a charter people actually use is one or two pages, not a dozen. ### How often should you review a team charter? Treat it as a living document. Revisit it whenever the team changes shape — new members, a new project, a reorganization — and check in lightly every quarter or during a retrospective. A charter that is never revisited quietly stops describing how the team really works, which is when it loses its value. --- # Team health checks: how to measure how your team is really doing URL: https://www.teamretro.com/guides/team-health-check/ A team health check is a short, structured self-assessment in which everyone on a team anonymously rates the same set of dimensions, such as delivery, ownership, and psychological safety, on a simple scale, then discusses the spread together. Run on a regular cadence, it turns "how are we doing?" from a guess into a trend you can act on. That is the whole idea. The rest of this guide is the practice: how a health check differs from a retrospective and an engagement survey, when to run one, how to choose dimensions (including an honest look at the Spotify and Atlassian models), a question bank organized by dimension, how to facilitate the session so people answer truthfully, and what to do with the results once you have more than one of them. ## What a team health check is (and what it isn't) Two other rituals get confused with health checks, and the confusion matters because each one answers a different question. **A health check is not a retrospective.** A retrospective examines a specific slice of work: what happened last sprint, what to change next sprint. Its raw material is recent events, and its output is actions. A health check measures the *team itself* against a stable set of dimensions, and its output is scores you can compare quarter to quarter. A retro tells you what happened; a health check tells you what it is like to work here, and whether that is getting better or worse. The two pair naturally — retro every sprint, health check every quarter, often run inside a retro slot. **A health check is not an engagement survey.** Engagement surveys are owned by HR, run across the whole organization once or twice a year, and ask about the individual's experience of the company. The results travel up. A health check is owned by the team, runs often, asks about the team's way of working, and the results stay in the room where they can be acted on. Both are legitimate instruments. The trouble starts when an annual survey is treated as a substitute for a team knowing its own state, or when a health check gets repurposed as a management scoreboard (more on that below). | | Retrospective | Team health check | Engagement survey | | --- | --- | --- | --- | | Looks at | The last sprint or period of work | The team's way of working | The individual's experience of the org | | Owned by | The team | The team | HR / leadership | | Cadence | Every sprint | Quarterly (typically) | Annually or twice a year | | Output | Actions | Scores, trends, and a conversation | Org-level metrics | | Results go | Into the team's next sprint | Back to the team | Up the reporting line | ## When to run one, and how often Quarterly is the right default. It is frequent enough to catch drift while it is still cheap to fix, and infrequent enough that the scores have a chance to move between checks. Running the same check every sprint mostly measures noise; running it annually measures a team that no longer exists. Beyond the regular beat, run an extra check whenever the team changes shape: after a reorganization, when a new lead arrives, when several people join or leave at once, or when a team is being formed from scratch. Those are exactly the moments when everyone's private read on the team diverges most, and a health check makes the divergence visible early. Two variations on cadence are worth knowing. Teams in active turnaround sometimes move to a monthly pulse on a reduced question set, then drop back to quarterly once the trend stabilizes. And distributed teams often run the rating step asynchronously over a couple of days, then meet only for the discussion — the scores wait patiently; the conversation is the part that needs everyone present. ## Choosing your dimensions A dimension is one aspect of team health you will rate every time: "delivery", "psychological safety", "workload". Choosing them is the most consequential design decision you will make, because the dimensions define what the team considers worth measuring — and because you need to keep them stable across quarters or the trend line means nothing. Two published models dominate this space, and both are worth learning from honestly. ### The Spotify squad health check model Published by Henrik Kniberg and Kristian Lindwall in 2014, the [Spotify squad health check model](/health-check-templates/squad-health-check/) has squads rate around eleven dimensions (delivering value, easy to release, health of codebase, teamwork, mission, and so on) as green, yellow, or red in a facilitated workshop, producing a colored grid across squads. What it is genuinely good at: it made team health *visible* at organizational scale, and its traffic-light simplicity gets a real conversation going fast. It reframed measurement as self-assessment for the team's benefit rather than reporting for management, and a decade later that framing still holds up. Its honest limitations: the dimensions were designed for Spotify's engineering context, and several (health of codebase, easy to release) map poorly onto non-engineering teams. Spotify's own authors cautioned against copying their practices wholesale. And a three-color scale is coarse — good for a workshop conversation, weak for detecting a slow six-month slide from "strong green" to "barely green". ### Atlassian's Team Health Monitor Atlassian's Health Monitor takes a different angle: eight attributes of a healthy team — among them a balanced team, shared understanding, and suitable ways of working — self-scored as a group in a facilitated workshop. (Atlassian has since consolidated its older project-, service-, and leadership-team versions into one shared attribute set.) Its strength is structural clarity: attributes like these surface role and alignment problems that mood-centric checks miss entirely, and it works well outside software. Its limitations are the mirror image: it is a workshop instrument, scored openly in discussion rather than anonymously, so it is only as honest as the room feels safe. And as a point-in-time exercise it gives you a snapshot, not a trend, unless you impose your own cadence and record-keeping around it. ### Our recommendation Take the framing from both models and fix the two weaknesses: rate anonymously, and rate on a scale you can trend. Choose six to ten dimensions, mix delivery-facing ones (process, roles, value) with human ones (safety, workload, collaboration), adapt the wording to your context — and then stop editing them. A dimension set that changes every quarter is a new check each time, and you lose the only thing that compounds: the trend. If you would rather not design from scratch, start from a ready-made [team health check template](/health-check-templates/team-health-check/) and trim it. Those two fixes — anonymous rating and a scale you can trend — are also the right lens for choosing a tool to run this in, because most options get one or the other wrong. We compare the honest choices, from dedicated tools to the Spotify framework to HR-survey platforms, in our roundup of the [best team health check tools](/blog/best-team-health-check-tools/). ## Team health check questions, by dimension Ask people to rate statements, not to answer open questions. A statement like "I can raise a problem without worrying how it lands" produces a score you can compare across quarters and a concrete conversation starter in one line. Rate each on a five-point agree–disagree scale. **Direction and value** - We know what we are trying to achieve and why it matters. - Our priorities are clear enough that we can say no to work that doesn't fit. - I can connect what we shipped recently to value for users or the business. **Delivery and process** - Our way of working helps us more than it slows us down. - Releasing or handing over work is routine, not an event. - Work rarely sits stuck waiting on another team or an approval. **Roles and ownership** - I know what is mine to decide and what needs the group. - Important decisions have a clear owner. - When something falls between roles, we notice and assign it quickly. **Psychological safety and trust** - I can raise a problem without worrying how it lands. - Mistakes here lead to fixes, not blame. - Disagreement on this team is treated as useful information. **Collaboration and communication** - I know enough about what others are working on to spot overlaps and gaps. - When someone asks for help, help arrives. - Our meetings earn the time they take. **Learning and improvement** - We change how we work based on what we learn. - The actions we agree in retrospectives actually get done. - Time for learning survives our busy periods. **Workload and sustainability** - The current pace is one we could keep up for a year. - I can finish the important things without routinely working evenings. - Interrupt work and on-call load are shared fairly. **Support and resources** - We have the tools and access we need to do the job well. - When we escalate a blocker, someone above us acts on it. - The team's case is heard when priorities are set above us. Trim rather than add. Twenty-four statements is the ceiling, not the target — a check people can finish thoughtfully in five minutes beats a thorough one they start skimming. ## Psychological safety deserves its own reading One dimension consistently predicts the usefulness of everything else: psychological safety, the shared belief that this team is safe for interpersonal risk-taking. Amy Edmondson's research established the concept, and Google's Project Aristotle later found it the single strongest differentiator among its own effective teams. It also has a compounding property inside a health check: a team that scores low on safety is probably inflating its other scores too, because the check itself is an act of speaking up. A useful lens for interpreting a safety score is Timothy R. Clark's **4 stages of psychological safety**: inclusion safety (I belong here), learner safety (I can ask questions and make mistakes), contributor safety (I am trusted to do real work), and challenger safety (I can question how things are done). The stages are a ladder, and most teams sit further up it than they think — plenty of teams where everyone feels included would still go quiet if someone questioned the roadmap. If your safety scores are middling, the follow-up question is *which stage* is missing, and Clark's labels give the team language for that conversation.
Clark's four stages, read as a ladder. Most teams sit further down than they think — a team where everyone feels included can still go quiet when someone questions the roadmap.
Be honest about what a health check can and cannot do here. Three rated statements will tell you whether safety needs attention; they will not diagnose it. If the scores say there is a problem, that finding deserves its own session — a dedicated [psychological safety check](/health-check-templates/psychological-safety-check/) goes deeper than a general health check should, and our team dynamics guide covers [how trust and safety are actually built](/guides/team-dynamics/building-trust-and-psychological-safety/). ## How to run the session The mechanics matter more than they look. The same questions, run badly, produce polite fiction. 1. **Make ratings anonymous.** This is the non-negotiable one. The moment people sign their names to a low score, the low scores dry up, and you are measuring what people are willing to say rather than what they think. Anonymity is also why a tool beats fists-of-five in a meeting: nobody can watch the room before choosing their number. 2. **Rate first, discuss second.** Everyone scores every statement silently before any discussion. If the conversation happens first, the ratings anchor on whoever spoke, and usually on whoever is most senior. 3. **Discuss the spread, not the average.** A dimension where everyone scored 3 and a dimension where half the team scored 5 and half scored 1 have the same average and mean completely different things. The disagreement is the interesting data: it means two groups of people are having different experiences of the same team. 4. **Timebox to under an hour.** Five minutes of rating, then the rest on the two or three dimensions most worth talking about. You are not obliged to discuss every dimension every time; that is what the trend line is for. 5. **Leave with one or two owned actions.** Pick the dimension you most want to move, agree one change, and give it a named owner and a date. Our [Follow-Through Index](/guides/follow-through-index/) data is blunt on this point: actions with an owner and a due date get completed about 90% of the time, and actions with neither mostly don't. One first-party finding worth knowing: in the Follow-Through Index data we looked for a correlation between teams' health-check scores and their action follow-through, and found essentially none. Following through is a discipline, not a mood — a team that feels rough can still finish what it commits to, and a happy team can still let everything slide. ## What to do with the results over time A single health check is a conversation. The value compounds when you keep the questions stable and run it on a rhythm, because then you have a trend — the same team radar of dimensions, read across quarters instead of once. A trend answers questions a snapshot cannot. Is the workload problem seasonal or structural? Has safety recovered since the reorganization? Three habits make the trend worth having: - **Open each check by reviewing the last one.** What did we say we would change, did we change it, and did the dimension move? A health check whose actions are never revisited teaches the team that scoring honestly changes nothing, and the scores will quietly converge on a safe, meaningless 4. - **Move one dimension at a time.** A team that tries to improve six dimensions at once improves none of them. Pick the one that matters most this quarter and put real effort behind it; let the others ride. - **Use cross-team views to direct support, not to rank teams.** Seeing health across many teams is genuinely useful for a coach or a leadership group deciding where help is needed. The moment scores become a league table, teams start managing the number instead of the work, and the instrument is dead. Share trends, not comparisons, and never tie scores to performance reviews. ## Maturity models: the zoomed-out cousin Health checks have a sibling worth knowing about. A health check asks "how does it feel to work here right now?" — subjective by design, and answered by the whole team every quarter. A **maturity model** asks a different question: "how developed are our practices against a defined scale?" It assesses concrete practices (how you plan, test, release, measure) against staged levels, and it is typically revisited every six to twelve months rather than quarterly.
The health check is the thermometer; the maturity model is the map. A team can be happy and immature, or disciplined and miserable — you only see the whole picture with both.
The two complement each other. The health check is the thermometer; the maturity model is the map. A team can be happy and immature (great atmosphere, chaotic releases) or mature and miserable (disciplined practices, unsustainable pace), and you only see the full picture with both readings. If your health-check trend keeps flagging the same delivery dimensions, that is often the cue to zoom out: our [agile maturity assessment](/health-checks/agile-maturity-assessment/) walks a team through exactly that practice-level review, and the accompanying [guide to measuring and improving agile maturity](/blog/agile-maturity-assessment-how-to-measure-and-improve-your-team/) covers how to act on what it finds. ## Templates to start from You can design a health check from a blank page, but you rarely need to. These ready-to-run templates cover the common starting points, and every one of them runs with anonymous rating and trend tracking built in: - [Team health check](/health-check-templates/team-health-check/) — the balanced general default across delivery, collaboration, and wellbeing. - [Squad health check](/health-check-templates/squad-health-check/) — the Spotify model, ready to run. - [Psychological safety check](/health-check-templates/psychological-safety-check/) — a deeper standalone read on safety and trust. - [Team effectiveness health check](/health-check-templates/team-effectiveness-health-check/) — focused on how well the team converts effort into outcomes. - [Team dysfunction radar](/health-check-templates/team-dysfunction-radar/) — based on Lencioni's five dysfunctions, for teams that suspect a deeper pattern. Or [browse the full health check template library](/health-check-templates/) for role-specific and situation-specific variants. Ready to take the guesswork out of "how are we doing?" TeamRetro's [health checks](/health-checks/) run the whole loop described in this guide — anonymous ratings, dimension-by-dimension discussion, trends across quarters, and actions tracked through to done. [Start a free trial](https://secure.teamretro.com/login/new) and run your first check this week. ## Keep reading - [The Follow-Through Index](/guides/follow-through-index/) — our first-party data on whether teams do what they decide. - [Team dynamics: how great teams actually work](/guides/team-dynamics/) — the forces your health check is measuring. - [Running effective retrospectives](/guides/running-effective-retrospectives/) — the sprint-level companion ritual. ## Frequently asked questions ### What is a team health check? A team health check is a short, structured self-assessment in which everyone on a team anonymously rates the same set of dimensions, such as delivery, ownership, and psychological safety, on a simple scale, then discusses the spread together. Run on a regular cadence, it turns "how are we doing?" from a guess into a trend you can act on. ### What is the difference between a team health check and a retrospective? A retrospective examines a specific slice of work, usually the last sprint, and produces actions. A health check measures the team itself against a stable set of dimensions and produces scores you can trend over time. They pair well: retro every sprint, health check every quarter, often run inside a retro slot. ### How often should you run a team health check? Quarterly is the right default for most teams: frequent enough to catch drift, infrequent enough that scores have a chance to move. Add an extra check when the team changes shape, such as after a reorganization, a new lead, or several new joiners. Monthly pulse checks work for teams in active turnaround; weekly is survey fatigue. ### What questions should a team health check ask? Ask people to rate statements, not answer open questions, and organize them by dimension: direction and value, delivery, roles and ownership, psychological safety, collaboration, learning and improvement, workload, and support. Statements like "I can raise a problem without worrying how it lands" or "the current pace is one we could keep for a year" give you a comparable score and a conversation starter in one line. ### What are the 4 stages of psychological safety? Timothy R. Clark's model describes four stages a person moves through on a team: inclusion safety (I belong here), learner safety (I can ask questions and make mistakes), contributor safety (I can do real work and be trusted with it), and challenger safety (I can question how things are done). It is a useful ladder for reading a team's health-check scores: a team can feel included yet still be unsafe to challenge. --- # Agile retrospective checklist URL: https://www.teamretro.com/guides/scrum-masters-retrospective-guide/a-checklist-for-running-your-retrospective/ A good agile retrospective checklist covers three stages: before the meeting you prepare the invite, data, and template; during it you facilitate brainstorming, voting, discussion, and clear actions; and after it you share outcomes and follow up. The checklist below walks through each stage. ## What does the "perfect" retro look and feel like? If you ask an agile team, the perfect retro is one where each member of the team walks away feeling: - **Engaged** – in the process and outcomes - **Empowered** – to be able to take steps to improve - **Energized** – and looking forward to the next sprint The team has had a chance to properly reflect on their experience, had the opportunity and support to put their thoughts forward honestly and without judgment, and brainstormed solutions in a supportive environment. Bad hygiene factors, however, are numerous and can thwart the perfect retro. From lack of focus and poor timekeeping through to indifference and repetition, they leave scars on what could be the perfect agile ceremony. Instead, the experience for the team becomes ineffective, rushed, tedious, and a waste of time. Here's a checklist to make sure that your retrospective runs smoothly. ## Before the retrospective - Check that the calendar invite has been sent out to the relevant team members. - Gather any data or summaries from 1-on-1 meetings, velocity charts, health check data, or other reports. - Determine the theme or focus of your retrospective, then choose the format, activity and voting method. Then create your retro. - If running an asynchronous meeting, then send out the link beforehand. - Double check the meeting room, web conference link and any other logistics that might otherwise impact your retro. ## During the retrospective - If you want to stick to time, ask for a volunteer to be a timekeeper for the meeting, or use the built-in timer. - Run through the agenda or context of your retrospective. - It is a good idea to remind the team of any team agreements, the prior actions, or the [Agile Prime Directive](/guides/scrum-masters-retrospective-guide/what-is-the-retrospective-prime-directive/) to help set the tone of the meeting. - Go through the essential steps of brainstorming ideas, then talk through them. You can group certain ideas together if they are the same. Ensure that everyone can and does contribute something to the retrospective theme. - Vote on what people most want to discuss further. Votes should be done independently. The number of votes can be changed based on the number of ideas, people, or time remaining. - Discuss all the voted items and have people propose action items that can be taken forward to the group. - Capture all action items, agreements and any other comments. If you are using a whiteboard, then taking pictures of these will be needed. Any action items should ideally have an assigned person and due date. - Keep the meeting flowing by sticking to time and making sure that the retro is not used as a session for blaming or problem solving. - After completing any action items, take some time to celebrate the success and share appreciation. - At the end of the meeting, run a ROTI (Return on Time Invested) to get feedback on the effectiveness of the meeting. This is optional. - Say thank you. ## After the retrospective - Share the action items and meeting summaries with the relevant stakeholders. - Review notes to ensure that all important items were captured. - Use an ongoing action list to remind yourself and the team of action items and follow up as needed. - Reflect on your own practice and effectiveness as a Scrum Master and how you might change what you do for the next retrospective. ## Frequently asked questions ### What should be on a retrospective checklist? A good retrospective checklist covers three phases. Before — pick a focus and template, invite the team, and review the last retrospective's actions. During — set the stage, gather data, generate insights, and agree clear actions with owners. After — share the summary, track the agreed actions, and follow up before the next retrospective so improvements actually happen. ### How do you prepare for a sprint retrospective? Preparation is mostly about focus and follow-through. Choose a theme and a template that fit how the last sprint went, make sure the previous retrospective's actions are visible, and check any tooling in advance. Coming in with a clear structure lets the team spend its time reflecting and deciding rather than working out how to run the meeting. ### What makes a retrospective successful? A successful retrospective ends with a short list of specific, owned actions — not just discussion. That depends on psychological safety (people speak honestly), good facilitation (everyone contributes), and follow-up (actions are tracked and revisited). A retrospective that produces no action, or whose actions are never followed up, is the most common way for the ceremony to lose value. --- # Acceptance criteria: how to write them URL: https://www.teamretro.com/guides/agile-estimation-guide/acceptance-criteria/ Acceptance criteria are the conditions a story must meet to be accepted — a pass/fail test, written before anyone starts coding. No partial credit: each one is met or it isn't. They describe what the result must do, not how to build it. And they are a test, not a second description of the feature. If you can satisfy them with code that doesn't solve the problem, they aren't acceptance criteria — they're requirements in disguise. Every story carries an implicit question: how will we know it's finished? Acceptance criteria answer it out loud, before the work starts. Get them right and estimation gets easier, the demo writes itself, and "done" stops being a negotiation. Get them vague and you've shipped a feature nobody agreed on. ## What acceptance criteria are, and what they're not A good acceptance criterion is something you could hand to a tester who never sat in your refinement meeting, and they'd know exactly what to check. It describes an *outcome* the user can observe, not the implementation that produces it. "Use a Redis cache" is not an acceptance criterion — it's a solution. "Results load in under a second for a table of 10,000 rows" is, because anyone can test it and nobody has to read the code to do so. They're also not a wishlist. Each criterion has to be falsifiable. If a line can't be checked — "the page is intuitive", "performance is good" — it isn't a criterion, it's a hope. Cut it or make it measurable. ## The two formats that work Use **Given/When/Then** for behavior that depends on state, and a plain **checklist** for a set of independent requirements. Most teams reach for Given/When/Then for everything; resist that. A checklist is faster to read and harder to pad when the story is just "these five things must be true." ### Given / When / Then Given a starting state, When the user does something, Then the system responds a specific way. The format earns its keep by forcing you to name all three — the precondition, the trigger, and the observable result — which is exactly what a hand-wavy criterion leaves out. ## Acceptance criteria examples A login story, written as Given/When/Then: - **Given** a registered user on the sign-in page, **When** they enter a correct email and password, **Then** they land on their dashboard. - **Given** a registered user, **When** they enter a wrong password three times, **Then** the account locks for 15 minutes and they see how long is left. - **Given** the sign-in page, **When** the email field is empty, **Then** the submit button is disabled. A "filter the results table" story, written as a checklist: - The filter applies on selection — no separate "apply" button. - Two filters combine with AND, not OR. - Clearing all filters restores the full, unsorted list. - An empty result set shows the "no matches" state, not a blank table. Notice what both leave out: the database, the framework, the component names. They say what the user gets, not how you'll deliver it — and each line is a thing a tester can pass or fail without asking you a question. ## How to write acceptance criteria - Write them during [backlog refinement](/guides/agile-ceremonies-guide/backlog-refinement/), with the team — not alone, afterwards. - One observable outcome per line. If a line has an "and" doing real work, it's two criteria. - Name the unhappy path. The empty state, the timeout, the wrong input — that's where the effort hides. - Keep them about behavior, not design. The mockup covers the layout; the criteria cover what has to be true. - Stop at around five. ## How many acceptance criteria is too many? Roughly five. Not because there's a rule, but because a story that needs ten distinct, testable conditions is carrying ten distinct slices of value — which means it's several stories pretending to be one. When the list runs long, the acceptance criteria *are* the split. ## Splitting by acceptance criteria If a story has more than five acceptance criteria, the criteria are usually the split. The list is a backlog wearing a checklist hat. Acceptance criteria exist to *describe* a story. They aren't supposed to *be* the story. When the list gets long — six, eight, ten bullets — the team has often done the splitting work without noticing. Each criterion is a thin slice the team could ship, demo, and walk away from. Treating the whole list as a single commitment forces the team to take on all of it at once, which is the worst combination of size and risk you can hand someone in a sprint. To split, take each criterion and ask the question you'd ask of any [user story](/guides/agile-estimation-guide/splitting-user-stories/): would the team ship this on its own? Would the user benefit from it on its own? Could it be demoed? The bullets that survive that question are stories. The bullets that fail it usually belong to one of the survivors — they're scope on a story you've already separated, not standalone work. Where this fails is on tightly coupled criteria — "the form validates input **and** saves to the database **and** shows a confirmation." Those three look splittable, but the user gets nothing if only one ships. That's not splittable by criterion; it's a single small story, and the bullets are just the team being thorough. **Watch for the fake split.** Slicing along a build order — "set up auth", "build the form", "wire the database" — isn't splitting by acceptance criteria. It's [horizontal slicing](/guides/agile-estimation-guide/horizontal-vs-vertical-slicing/) with criteria-shaped labels on top. If the resulting stories don't each ship something the user can see, you split wrong. ## Acceptance criteria vs requirements A requirement says what to build. An acceptance criterion says how you'll know you built the right thing. "Users can reset their password" is a requirement — and you can satisfy it with a flow so broken nobody completes it. "A user who requests a reset receives an email within two minutes whose link expires after one hour" is an acceptance criterion, because it's a test the broken flow fails. Requirements scope the work; criteria gate it. ## Acceptance criteria vs the definition of done These get conflated constantly, and the distinction is simple: acceptance criteria are *per story*; the [definition of done](/guides/agile-estimation-guide/definition-of-done/) is *global*. The criteria above describe what the login story specifically must do. The definition of done — tested, code-reviewed, documented, deployed to staging — applies to every story the team ships. A story can pass its acceptance criteria and still not be done, because "works as specified" and "ready to release" are different bars. You need both. ## Story points vs acceptance criteria Acceptance criteria describe the outcome — what has to be true for the story to count as shipped. [Story points](/guides/agile-estimation-guide/what-are-story-points/) describe the path — how big the work is between "we don't have this yet" and "the criteria are satisfied." Two different axes. Conflating them produces sized criteria, which is meaningless, or point estimates with no criteria behind them, which is wishful. Does adding a criterion change the estimate? Sometimes. A criterion that surfaces hidden work — "must be accessible to screen readers" — usually does, because it names effort that was implicit. A criterion that just clarifies an existing assumption — "must work on Chrome and Safari" when those were always the supported browsers — shouldn't. The order matters: criteria first, then points. Estimating before the criteria are clear is [estimating before refinement](/guides/agile-estimation-guide/planning-poker-mistakes/), and it's the most common cause of wide-spread votes. Write the test before the work. If a criterion can't fail, it isn't one — and if you have more than five, you probably have more than one story. ## Frequently asked questions ### What are acceptance criteria? Acceptance criteria are the conditions a story must satisfy to be accepted — a pass/fail test written before the work starts. They describe what the result must do, not how to build it, and there is no partial credit: each one is met or it isn't. ### How do you write acceptance criteria? Write each one as something you could hand to a tester who has never seen the story. Use Given/When/Then for behavior that depends on state, or a plain checklist for a set of independent requirements. Keep them testable, keep them about outcomes, and stop at around five — more than that and you are looking at several stories. ### What is the difference between acceptance criteria and requirements? Requirements say what to build; acceptance criteria say how you will know it is right. A requirement can be satisfied by code that misses the point. An acceptance criterion is a test — if it passes, that part of the story is done; if you can pass it without solving the user's problem, it is a requirement in disguise. ### What is the difference between acceptance criteria and the definition of done? Acceptance criteria are per story — they describe what this particular story must do. The definition of done is one global checklist that applies to every story (tested, reviewed, documented, deployed). A story can meet its acceptance criteria and still not be done if it skips the team-wide gate. ### Who writes acceptance criteria? The product owner owns them, but they are written with the team during refinement. The product owner frames the outcome; the engineers and testers surface the edge cases. Acceptance criteria written alone, after the fact, are the ones that miss the case that breaks in production. ## 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 team-wide gate that acceptance criteria are often confused with. - [Definition of ready](/guides/agile-estimation-guide/definition-of-ready/) — the checklist that gets a story into the sprint in the first place. - [Splitting user stories](/guides/agile-estimation-guide/splitting-user-stories/) — for when the criteria list runs long. - [Backlog refinement](/guides/agile-ceremonies-guide/backlog-refinement/) — the ceremony where good criteria get written. --- # The map: agent feedback loops, tools, and approaches URL: https://www.teamretro.com/guides/ai-agent-retrospectives/agent-feedback-loops/ *TeamRetro is interested in every continuous-improvement cycle teams run; AI-assisted work is a new area we're thinking through via our retrospective lens. This page is the reference companion to this guide: the whole space laid out systematically. If you'd rather start with the story, begin at the [guide's opener](/guides/ai-agent-retrospectives/) and come back.* ## What this page is Three things, in order: the **lifecycle** a single piece of friction travels from occurring to being fixed; the **named loops** the field has built to run that lifecycle, sorted by the level each operates at; and the **classification schemes** in use for naming what went wrong. Read it top-down to locate your team: which stages your tools already cover, which loop you're already running under another name, and which vocabulary you'd label findings in. Everything here stands on its own: none of it requires adopting our practice, our labels, or our product. ## The lifecycle: seven stages from friction to fix When an agent doing real work hits friction (a missing doc, an ambiguous instruction, a flaky tool), that signal is ephemeral: the agent works around it, the session ends, and the next session hits the same wall. [Rahul Garg's friction patterns](https://martinfowler.com/articles/reduce-friction-ai/) frame the first-order cost (the Frustration Loop of generate → review → doesn't-fit → regenerate); the lifecycle below maps the second-order problem: what has to happen for friction to become a fix at the right level. The gap is measurable: ~90% of teams instrument agent traces, but only ~37–52% systematically evaluate them ([LangChain, Jun 2026](https://www.langchain.com/state-of-agent-engineering)) — most teams can watch friction; far fewer turn it into fixes. | Stage | The question it answers | Options | Practitioner term | |---|---|---|---| | **0 · Hosting** | Where does the agent run? | local CLI · web · IDE · CI/headless · scheduled | — | | **1 · Detection** | How is friction noticed? | self-notice · secondary-agent review · human correction · telemetry | *trace review*, *error analysis* | | **2 · Instrumentation** | How does the agent know to track it? | skill · hook · convention · command | — | | **3 · Recording** | How is it captured, and where? | memory · MCP store · logs/traces · tickets · tagged commits | *open coding*, *episodic memory* | | **4 · Harvesting** | How do you gather beyond one session? | trace-mining vs artifact-aggregation · sweep vs event · dedup | — | | **5 · Synthesis & targeting** | Raw records → patterns → what level of fix? | cluster + score, then route by altitude | *axial coding*, *failure taxonomy* | | **6 · Close the loop** | Did the fix reduce future friction? | measure the trend | *Feedback Flywheel*, *compounding engineering* |
One route, seven stations: a piece of friction travels from where the agent runs, through being noticed and recorded, to being harvested, routed, and (the honest last stop) checked that it actually went down.
### Stage 0: Hosting Everything downstream depends on where the agent runs. A local CLI agent leaves a transcript on disk and can write memory files; a CI or headless agent may be ephemeral, its only trace whatever it logged before the container died; a web or IDE agent keeps server-side history you can query but not grep; a scheduled agent runs with no human watching. Hosting sets the menu for every later stage: what's observable, where state can persist, and who (or what) can review it. The trade-off: richer local observability versus the reproducibility and central storage of hosted runs. ### Stage 1: Detection Four channels, rarely exclusive. **Self-notice** (the agent recognizes its own retries and backtracking) is cheapest but most biased: the agent doesn't know what it doesn't know. **Secondary-agent review**, where a fresh agent reads the transcript afterward, is more objective but costs a second pass. **Human correction** is the highest-quality signal, and still the dominant one: an eight-week production study found ~70% of silent failures were first caught by a human noticing something felt off ([arXiv 2606.14589](https://arxiv.org/abs/2606.14589)). **Telemetry** (tool-error rates, permission denials, loop counts) is automatic but shallow — it knows *that*, not *why*. The strongest setups triangulate: telemetry flags where to look, a review pass explains why. ### Stage 2: Instrumentation An agent won't record friction unless something makes it. The options, by how much they lean on the model remembering: a **skill** (an explicit, portable procedure invoked at a stopping point: clear, but must actually fire), a **hook** (fires automatically on session start or stop: reliable, but blunt), a **convention** (a context-file instruction: zero infrastructure, honors-system), or a **command** (human-triggered: deliberate, but human-gated). This is the stage most often skipped, and it's why so much friction goes unrecorded: nobody told the agent to look. ### Stage 3: Recording Two questions: what a good record contains, and where it lives. A useful record is evidence-cited (what happened, what it cost), carries one label from a fixed vocabulary so records are comparable later, and ends with a proposed next step. Where it lives, each with a real trade-off: **memory files** (durable and low-friction, but private and loosely structured), an [**MCP store**](/mcp/) (shared and queryable, but needs a server), **logs/traces** (automatic and complete, but the signal is buried in noise), **tickets** (actionable and team-visible, but heavyweight per item), or **tagged commits and PRs**, e.g. a `work-material-friction` label tying friction to the exact change, though only where work lands in version control. None of this is code-specific: a media team's account log or a support queue's annotated history are recording substrates too. One caution that applies to any substrate agents later rely on: agent-written memory is a named attack-and-drift surface ([OWASP Agentic Top 10, ASI06](https://genai.owasp.org/)), an argument for evidence-cited, reviewed writes. ### Stage 4: Harvesting One session's friction is noise; the same friction across eight sessions is a process problem. The strategic choice is **trace-mining** (re-read raw transcripts: complete, but expensive and privacy-heavy) versus **artifact-aggregation** (sweep the records deliberately written: cheap, but only as good as Stage 3's discipline); real pipelines mix both. Then cadence (a scheduled sweep versus harvest-on-session-end) and the unglamorous work of dedup: the same friction phrased five ways by five people has to collapse into one pattern with an honest count. Harvesting is where value appears, because aggregation is what reweights priorities: a five-minute annoyance nobody would fix individually is a top team cost in aggregate. ### Stage 5: Synthesis & targeting Two moves. **Cluster and score**: group findings into patterns, ranked by frequency × cost; this is what the classification schemes below exist for. **Target the altitude**: route each pattern to the right level of fix, from ephemeral to structural (memory → skill/prompt → environment & config → docs → the work material itself → process → upstream tool or vendor). Under-target (a private memory note for what's really a missing team doc) and the friction recurs for everyone else; over-target (a new skill for a one-off) and you bloat an artifact until it stops being read. The field converged on the same gradient independently: *demote ephemeral memory, promote durable learning to version control* — [Windsurf/Devin's docs](https://docs.devin.ai/desktop/cascade/memories) say to promote recurring lessons to rules or AGENTS.md (the standing instruction file agents read) rather than rely on auto-memories, [OpenAI's Codex guidance](https://learn.chatgpt.com/guides/best-practices) says the same-mistake-twice case earns an AGENTS.md update, and [Copilot memory expires in 28 days](https://github.blog/changelog/2026-03-04-copilot-memory-now-on-by-default-for-pro-and-pro-users-in-public-preview/) by design: unpromoted memory should die. One synthesis judgment is easy to miss: not all friction is waste. Some of it is the control surface, *"friction is what's necessary… to steer"* ([a recap of Ronacher's AIE Europe talk](https://tldrecap.tech/posts/2026/aie-europe/ai-agents-friction/)), so triage includes keep-or-kill, not just fix. ### Stage 6: Close the loop The honest test of the whole lifecycle: does friction of that type trend down over subsequent sessions? A fix that's filed but never lands, or lands but changes nothing, is theatre. This is Garg's [Feedback Flywheel](https://martinfowler.com/articles/reduce-friction-ai/feedback-flywheel.html) condition and the premise of *compounding engineering*: each fix makes the next unit of work easier, if the loop actually closes. ## The named loops, by operating level The field has converged on this lifecycle under at least half a dozen names. All of them are good; nothing on this page replaces any of them. The one sort this table applies is the **level each loop operates at** — and the thing to notice once it's sorted: | Loop | Runs at | Closes the loop by | |---|---|---| | [Loop Engineering](https://addyosmani.com/blog/loop-engineering/) / [Compound Engineering](https://every.to/source-code/compound-engineering-the-definitive-guide) | one practitioner | personal rules, prompts, playbooks | | [agent-retro](https://github.com/giannimassi/agent-retro) | one session | per-session skill/config edits from the transcript | | [Harness-engineering sensors](https://www.thoughtworks.com/en-us/insights/blog/generative-ai/harness-engineering-agent-feedback-exploring-ai-coding-sensors) (Thoughtworks) | one codebase's harness (the scaffolding around the model) | wiring native feedback instruments (tests, linters, CI) into the agent's loop | | Dreaming ([Anthropic](https://www.zenml.io/llmops-database/context-engineering-and-memory-management-for-production-agent-systems), [OpenAI](https://openai.com/index/chatgpt-memory-dreaming/)) | one platform's memory | idle-time mining of session history into gated memory diffs, fleet-wide | | [LangSmith Engine](https://www.langchain.com/blog/introducing-langsmith-engine) / [Braintrust Topics](https://www.braintrust.dev/articles/what-are-topics-in-braintrust-2026) | one observability stack | clustering production failures into issues, drafting PRs and evals | | [Factory Signals](https://factory.ai/news/factory-signals) | one agent platform | detecting session friction patterns and auto-filing tickets | | [gh-aw session insights](https://github.com/github/gh-aw) (GitHub) | one platform's sessions | automated session-analysis reports across agentic-workflow runs ([50-session example](https://github.com/github/gh-aw/discussions/15173)) | | [Feedback Flywheel](https://martinfowler.com/articles/reduce-friction-ai/feedback-flywheel.html) (Garg) | one team's artifacts | harvesting learnings into priming docs, commands, playbooks, guardrails | Read the middle column again: **one** practitioner, **one** session, **one** platform, **one** stack. Nearly every loop in the field runs solo or fleet-level: a person and their agent, or a vendor and its whole install base. Only Garg's flywheel reaches for the team, and his cadence list names the venue (an agenda item in the existing sprint retrospective) without operationalizing it. That's our reading of the sort, and it's the one place this guide's own angle shows: the team level is the open layer — many people, many agents, more than one tool, with the fix-owners in the same conversation. If you run any loop above, keep running it; the team layer consumes their output, it doesn't compete with them. ## The classification schemes To cluster friction you need categories, and the field's schemes classify different things; they're less rivals than instruments pointed at different questions: | Scheme | What it classifies | Shape | Reliability / origin | |---|---|---|---| | [MAST](https://arxiv.org/abs/2503.13657) | how multi-agent *systems* fail | 14 modes / 3 categories | 150 expert-examined traces, validated on 1600+; inter-annotator κ = 0.88 | | Error-analysis school ([Husain/Shankar](https://hamel.dev/blog/posts/evals-faq/)) | whatever your own traces show | open-ended; categories emerge from your data | methodology, not a fixed set; reading your traces is "the most important activity in evals" | | [Four-Layer](https://cobusgreyling.substack.com/p/the-four-layer-agent-failure-taxonomy) (Greyling) | which *layer* of the stack failed | 4 layers | synthesis of field failure reports; ~9.9% of failures attributed to model reasoning | | [TraceProbe](https://arxiv.org/abs/2607.06184) | error-handling *actions* in traces | 9 actions | automated trace analysis | | [Factory Signals](https://factory.ai/news/factory-signals) | which friction *symptom* a session shows | 7 signal types | production coding-agent sessions | | Our root-cause vocabulary | *why* the collaboration friction happened | 10 labels / 5 groups; group encodes the fix altitude | working sessions, dev and non-dev; **inter-rater reliability not yet measured**: the experiment is underway, and the vocabulary is versioned and revisable | Two reading notes. First, the axes genuinely differ: symptom schemes (Factory's signals) tell you a session went wrong; layer schemes (Four-Layer) tell you where in the stack; a cause vocabulary tells you why, which is what lets a label half-route its own fix (a `work-material-friction` finding points at the material itself — tech debt in code, or a tangled account, board, or template outside it; a briefing label points at process). Second, the universal-versus-emergent tension is real: fixed taxonomies buy comparability and measurable labeling reliability (MAST's κ = 0.88 is the bar), emergent categories fit your actual failure distribution. A workable middle keeps a small fixed vocabulary for aggregation with open-coded evidence notes beneath each label. And a caution the whole field has earned: `agent-error`-style labels should be the residual, not the default. The harness-engineering school explicitly rejects that reflex, where 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/)). The [Four-Layer analysis](https://cobusgreyling.substack.com/p/the-four-layer-agent-failure-taxonomy) attributes only ~9.9% of failures to model reasoning. ## Locate yourself A short diagnostic. Walk the stages and mark what you already have: - **You have traces or session logs** (observability tooling, JSONL on disk, server-side history) → Detection and Recording are covered. The LangChain numbers suggest this is where most teams stop. - **Something reminds the agent to log friction** (a skill, a stop-hook, a context-file convention) → Instrumentation is covered; if nothing does, that's usually the cheapest first fix. - **You update AGENTS.md / CLAUDE.md when something recurs** → you're doing Synthesis at solo level, the Codex same-mistake-twice pattern. - **Your platform curates memory for you** (Dreaming-style consolidation, Copilot memory) → fleet-level Harvesting and Synthesis, within that platform. - **Your observability stack clusters failures and drafts fixes** (Engine, Topics, Signals) → stack-level Synthesis, for the traffic that stack sees. - **Someone periodically reads across sessions, people, and tools, and the fix-owners decide together** → team-level Harvesting and Synthesis. This is the row most teams leave blank. The common gap, in our observation, is that last row: the aggregate view across tools and people, and the judgment calls it feeds: keep or kill, which altitude, whose priority. Note the review scope question that comes with it: which work belongs in one bucket for one discussion? The repo, the product, the ads account, the support inbox, the client engagement? Scope by where fixes would land, and the non-code cases route as naturally as the code ones. The rest of this guide takes the layers one at a time: the [opener](/guides/ai-agent-retrospectives/) tells the story narratively; later chapters cover [capturing friction in the moment](/guides/ai-agent-retrospectives/ai-friction-records/), harvesting across sessions, the [altitude decision](/guides/ai-agent-retrospectives/where-should-the-fix-land/), and what a [team-level venue](/guides/ai-agent-retrospectives/the-report-exists/) looks like [in practice](/guides/ai-agent-retrospectives/running-the-ai-collaboration-retro/). Start wherever your blank row is. **Next chapter:** [What a good friction record looks like](/guides/ai-agent-retrospectives/ai-friction-records/) — capture in the moment, the root-cause labels, and the never-log rules. --- # Agile ceremonies: the complete guide URL: https://www.teamretro.com/guides/agile-ceremonies-guide/ Agile ceremonies are the recurring, timeboxed meetings that give a team its rhythm: sprint planning opens the sprint, the daily scrum keeps it on track, and the sprint review and retrospective close it. This guide takes them one at a time — what each is for, who belongs in the room, and how long it should run — with the deeper how-to guides a click down from each. Run for show instead of function, the same four meetings curdle into [agile theatre](/guides/agile-theatre/) — the four ways a ceremony can look right and change nothing. Learn what each ceremony is for here; see how each one fails there. --- # Worked estimation examples URL: https://www.teamretro.com/guides/agile-estimation-examples/ Real stories run through the estimation conversation end to end — login, payments, migrations, spikes — and the questions to land before anyone votes a number. --- # Agile estimation: the complete guide URL: https://www.teamretro.com/guides/agile-estimation-guide/ Estimation goes wrong in familiar ways: numbers that mean different things to different people, sessions that overrun, forecasts nobody trusts. The fix is rarely a better formula — it's a shared understanding the whole team owns, and estimates kept as forecasts rather than commitments held against you. This guide works through the parts that hold up in practice — user stories, planning poker, story points, velocity, and the techniques that keep working when a story turns out bigger than it first looked. When you're ready to run estimation with your team, [estimate in TeamRetro](/estimations/): planning poker with private voting, reusable decks, and final story points that sync straight to your backlog. --- # Agile games for team building URL: https://www.teamretro.com/guides/scrum-masters-retrospective-guide/agile-games-facilitate-team-building/ Agile games are short, interactive activities that teach agile principles while building team cohesion, creativity, and trust. Played in quick rounds with fast feedback, they help teams learn by doing — and research links well-chosen games to measurable gains in team performance. ## What is an agile game? An agile game is a creative activity that explores an aspect of agile by having the whole team work toward a common goal. There are many different types of agile games, but they all share a few common features: - They are typically very interactive and require a high degree of collaboration between team members. - They often have a very short duration, with each game round being relatively short (no more than 10 minutes). - They typically involve some form of feedback loop so that players can learn from their mistakes and improve their performance over time. As they play, the team implements the concepts of agile software development. They change what they do in order to deliver a better outcome each time they play a round. The short, repeated nature allows the team to measure their outcomes each round and get feedback on their decisions. The team gets quick feedback on how their decisions, interactions, and behaviors impact the final outcome. This mirrors the way a high-performing DevOps team would work on a day-to-day basis. The goal of playing these agile games is that the team can better assimilate agile software practices both during, and after the game. ## Why play an agile game? Who doesn't love a good game? And if you can learn something in the meantime, it certainly beats sitting through yet another death-by-PowerPoint lecture about the theory of agile. Throw in an interactive team-based game, and it can lift the mood and start firing up a few neurons. Here are just some of the benefits of agile games: 1. They are a fun way to learn about agile. Whether it's understanding the value of kanban or seeing the importance of the iterative processes, people can experience the basics of agile principles without feeling like it's just another training session. 2. They help improve creativity and innovation. With no set "correct" answers, the agile games offer a challenge to test out those off-the-wall ideas. Exploring different perspectives and angles means that without any one known solution, the journey of creating your own as a team becomes the real win! 3. They promote team cohesion. With a common task or goal and a time limit, everyone has to learn to share ideas efficiently. As teams improve from round to round, the shared experience of achieving something together helps to build team bonds. 4. They are a safe space. The game-based environment offers a psychologically safe space for people to share as there is no one exact answer. This allows different strategies to be played out. 5. They boost team productivity. Teams become happier, more efficient and feel safer as they work; this can lead to fewer conflicts, improved work quality and overall productivity through better work practices. ## Do games really help improve performance in agile teams? There is a great deal of research that points to games improving the performance of teams. Dr. Stuart Brown, founder of the National Institute for Play and author of a book of the same name, found that games are not just for enjoyment, but that there is also a strong connection to human development and intelligence. That's why play and games are so powerful. In his book he suggests, "The opposite of play is not work… It's death." Deloitte found that 60 to 70% of all large-scale change efforts are thwarted by people who resist shifting away from what they are already doing. Their report suggests that group-based change may be more manageable and that it is "now time for a new way of thinking about how to get something accomplished" when it comes to change implementation. In the Journal of Universal Computer Science (2016), the use of games in retrospective meetings was shown to positively impact team behavior. The authors go on to say that selecting the right game — aligned with Tuckman's model of the four stages of group development — can improve the efficacy of the games and help accelerate the team depending on which stage they are in. SRI Education also states that educational games can improve team learning outcomes by up to 23%. Games can provide a gentler way of helping transition teams to agile and overcome a resistance to change. This can be a show stopper for any agile transformation. ## Which agile game should I use? Here's a list of things to consider when selecting an agile game. **The goal or wish for your team** — There might be a particular aspect of agile that is showcased. Some games will focus on kanban management or estimations. Others could cover a whole range of topics more broadly that you can then unpack later. You might want the team to hone in on a particular area of communication or ask them to set their own goals. **Logistics** — The size and location of the team will make a difference. Can you adapt a game to move away from physical resources? Can you make the game more accessible based on the number of people in the activity so that it gives everyone the chance to contribute effectively? **The stage of your team's development** — Tuckman's model suggests five stages of team development: Forming, Storming, Norming, Performing and finally Adjourning. Depending on how familiar and how comfortable your team is with each other can determine the level of complexity of your game. Starting with a few icebreaker questions can help open up the space for more intense games. **The team's familiarity with agile** — Some of the games might be more challenging when it comes to applying the principles of agile. Picking one that helps them level up from where they currently are in terms of agile maturity will help ensure that everyone can participate. Some games are designed to be played multiple times, while others are only useful the first time, or when a new person joins a team. If, for example, you had a development team that has already implemented kanbans but were struggling with moving work items between areas, then the Ball Point and Paper Airplane games are good candidates. They are both games that require ways to interact with efficiency, while trying to hit an objective of maximizing outputs using a current system. For a newer team, allow a few hours of gameplay so that the concepts can be fully discussed and then applied. ## List of the best agile games Here's a list of the agile games you can use with your team. ## Agile principles - **Ball Point Game** — Experiment and play in multiple teams while learning about continuous improvement. - **Paper Airplane Game** — A good individual and team game that explores continuous improvement. - **Chocolate Bar Game** — Become a product owner and get feedback on your ultimate chocolate bar. - **Coin Game** — Get flipping with a kanban, workflow challenge that will help teams stay active. - **Marshmallow Game** — Explore problem solving strategies and builds that require learning from failures and timeboxing. - **How long does it take to make a cup of tea** — Enhance and explore estimations and the impact on team outcomes. - **The Multitasking Name Game (Henrik Kniberg)** — Which is better, single focus or multi-tasking? Take the challenge and find out. - **LEGO Flow** — Role based workflow game that will be sure to get a few neurons firing. - **XP Game** — A powerful way to learn about Agile Software Development and the roles and responsibilities people play. - **Battleships** — A twist of the classic game which helps with practicing estimations and feedback loops. - **DevOps Dream** — An online simulation that puts your DevOps team in the role of CIO. - **Kanban Pizza** — Understanding kanbans, limiting Work In Progress (WIP) and adaptation. ## Retrospectives - **Actions for Retrospectives** — Generate actions for a specific event or goal with Nick Oostvogels' action-centered approach. - **Snakes and Ladders** — Teams explore game strategies that will help them get to the finish line. - **Draw the Last Sprint** — A prompt based game that gets people visualizing different aspects of the last sprint. - **Anti-Retrospective Bingo** — A continuous game that gets the team to be on the active lookout for antipatterns during a retro. - **Retros Against Humanity** — A spin off of the Cards Against Humanity card game. - **The Speed Boat Game** — Accelerate your team to its dream location. - **Agile Retrospective Fun Formats** — A range of fun and engaging retrospective formats that add novelty and generate new insights. ## Communication - **Emoji Communication Game** — A guessing game involving only emojis. - **Sandwich Game** — How hard can it be to make a peanut butter sandwich? - **Broken Signal** — It's time to stretch your fingers in this non-verbal communication challenge. - **Listen to a Life Lesson** — A self generating quiz game that allows a team member to share a life lesson with everyone. - **Gif Battle** — Who will be the Sommelier of Gifs? - **Zip Zap Zoom** — A speed based listening and action packed game. ## Team building - **10 Things in Common** — Find out what your team has in common. But with a twist. - **Think of a Teammate** — Can you ask the right questions to uncover the truth? Elementary, dear Watson! - **Virtual Coffee Chat** — A prompt based tête-à-tête conversation with a world café vibe. - **Write a Story** — Disney creates great stories. Turn your team into creative writers. - **Line Up** — A problem solving game that will have your team exploring creative ways to solve a simple challenge. - **The Face of the Team** — No expert drawing skills needed. This activity helps you really look at the people in your team. - **Icebreaker Questions, Warm-ups, and Check-ins** — Get people to be present, and familiar with each other, with these icebreaker games. ## A final word about agile games Agile games can be a way to hack your team's culture to try and unlock high performance. Keep in mind, they can help, but they can't create team culture. As a Scrum Master, coach, or team leader, there are still challenges to overcome. You need to get people comfortable with playing games to learn, adopting agile principles in their work, and taking what they have learned from the games into their daily work environment. There is a real danger that stress, deadlines and pressure suppress creativity and that people forget about the principles of agile. Outside the safe space of playing a game, [creating psychological safety](/guides/scrum-masters-retrospective-guide/how-to-build-a-psychologically-safe-space/) is still key. Whether it is a retrospective or a team health check, team members should still be able to share their ideas openly and freely. Agile is about people and performance. Games are also about people and performance. Playing the right agile games can revitalize and energize people, helping you create high performing, effective teams. Have fun at your next agile game! ## Frequently asked questions ### What are agile games? Agile games are short, structured activities a team plays together to build trust, sharpen collaboration, and make ceremonies like the retrospective more engaging. They range from quick icebreakers to themed retrospective formats, and they use play to lower defenses and help people contribute openly. ### Why do agile games work for team building? Play lowers social barriers and builds the connections that high-performing teams depend on. Agile games create a low-stakes space where people share more freely, learn about each other, and practice collaborating — which carries back into the team's everyday work. Research on play and psychological safety backs up why this is more than just fun. ### What agile games can you play in a retrospective? Plenty of retrospective formats are effectively games — for example the Sailboat, Hot Air Balloon, Speedboat, or themed formats like Superhero and Oscar Academy. These use a metaphor to help the team reflect on what is propelling them forward and what is holding them back, making the retrospective both productive and fun. --- # Agile Theatre glossary: four coined failure modes URL: https://www.teamretro.com/guides/agile-theatre/agile-theatre-glossary/ Four names for four ways a ceremony gets captured. We coined them because the failures were common enough to deserve nouns, and nobody had named them cleanly. Use them, cite them, and — ideally — never need them.

Estimate laundering

**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 — that 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 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 stand-up, 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 stand-up is really performed for, a velocity figure graded from above, a retrospective whose actions never survive into the next sprint — which 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://tldrecap.tech/posts/2026/aie-europe/ai-agents-friction/): "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/). *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 — 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/) — 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. - [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 stand-ups URL: https://www.teamretro.com/guides/daily-standup-guide/async-and-remote-standups/ An async stand-up 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" — and 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 stand-up 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 stand-up 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 stand-up
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 stand-up 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 stand-up 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 stand-up tool earns its place here. TeamRetro's [Slack](/integrations/slack/) and [Microsoft Teams](/integrations/microsoft-teams/) integrations prompt each person at their local time and roll the replies into a single digest — so the update lands where the team already works and nobody has to reconstruct a scattered thread. For choosing between options, see [stand-up 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 stand-up | Async stand-up | |---|---|---| | 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 "stand-up" sounds like. An [async stand-up 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 stand-up 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 stand-up](/guides/daily-standup-guide/how-to-run-a-daily-standup/); or return to [the daily stand-up guide](/guides/daily-standup-guide/) for the full set of chapters. ## Frequently asked questions ### What is an async stand-up? An async stand-up replaces the live daily meeting with short written updates each person posts by a set deadline — usually in a channel, thread, or stand-up 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 stand-up? 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 stand-up 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 stand-up. ### Do async stand-ups 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 — 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. --- # Stand-up tools and software (Slack, Teams, TeamRetro) URL: https://www.teamretro.com/guides/daily-standup-guide/best-standup-tools/ Before you evaluate a single stand-up 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 stand-up 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 stand-up 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 stand-up 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 stand-up 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 stand-up 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 stand-up 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** — 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 stand-ups. **Pro tip:** the best test of a stand-up 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. Its [Slack](/integrations/slack/) and [Microsoft Teams](/integrations/microsoft-teams/) integrations prompt each person at their local time and collect the replies into one digest, so async stand-ups land where the team already works — and if you run everything through a board, the [Jira integration](/integrations/jira/) keeps the work in sync. The reason to run stand-ups 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 [stand-ups 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 stand-up 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 the TeamRetro integrations. 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 stand-up you've already made worth attending. For the meeting itself, start with [how to run an effective stand-up](/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 stand-up guide](/guides/daily-standup-guide/). ## Frequently asked questions ### Do you need a tool for daily stand-ups? 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 stand-up that's broken for facilitation reasons. ### What is the best tool for daily stand-ups? 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 stand-up on the board; dedicated async tools suit fully distributed teams; and retro-connected platforms like TeamRetro suit teams that want the stand-up feeding the same loop as their retros and health checks. ### What should you look for in stand-up 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 stand-ups. ### Can you run stand-ups 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 stand-up bot or the TeamRetro Slack and Teams integrations add automatic prompts and roll everyone's replies into one digest so nobody has to scroll. 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](https://www.themyersbriggs.com/en-US/Connect-With-Us/Blog/2021/January/Lencioni-Blog) 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 [Common Ground](https://games.teamretro.com/games/common-ground) 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/scrum-masters-retrospective-guide/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/scrum-masters-retrospective-guide/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. ## 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. - **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 — 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 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/scrum-masters-retrospective-guide/what-is-a-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 — and turn those observations into concrete improvements for the next sprint. The chart shows the symptom; the retrospective is where the team finds the cause. ## Frequently asked questions about burndown charts ### 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" towards 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 — 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 towards zero, while a burnup chart tracks work completed, rising towards 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 towards 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 - [What are story points?](/guides/scrum-masters-retrospective-guide/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 stand-up, 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 stand-up 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 — and practitioners do this sum in person-hours, because that's the unit management feels: fifteen minutes of stand-up 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 stand-up 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 stand-up as a device for detonating the start of the day: work doesn't really begin until it's over, so the whole pre-stand-up 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 — and 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 stand-up mid-morning fragments a maker's block twice; the same stand-up 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 stand-up](/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 stand-up](/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, stand-up 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? — and 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 stand-ups](/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 — it's 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 stand-up — are they the same? URL: https://www.teamretro.com/guides/daily-standup-guide/daily-scrum-vs-daily-standup/ Daily scrum and daily stand-up 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 stand-up" is the generic name any team can use.** Every daily scrum is a stand-up. Not every stand-up is a daily scrum — because not every team runs Scrum. ## Where each name comes from "Stand-up" is the older word. It comes from [Extreme Programming](https://en.wikipedia.org/wiki/Stand-up_meeting), where the daily stand-up 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 stand-up | 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 stand-up 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 stand-up with no goal to steer toward is the one that decays into a task-list read-aloud. **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 stand-ups 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 stand-up "walks the board" against the same idea — 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, "stand-up" 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 stand-up is for](/guides/daily-standup-guide/what-is-a-standup-meeting/), or return to [the complete daily stand-up 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 stand-up? 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 stand-up" comes from Extreme Programming and is the generic name any team can use, Scrum or not. Every daily scrum is a stand-up; not every stand-up is a daily scrum. ### Is a daily stand-up the same as a daily scrum? Effectively yes. If you run Scrum, your daily stand-up is the daily scrum — 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 stand-up. 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 stand-up? No. The stand-up 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 stand-up agenda and format URL: https://www.teamretro.com/guides/daily-standup-guide/daily-standup-agenda/ A daily stand-up 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 stand-up agenda that actually holds to fifteen minutes. ## The fifteen-minute run of show **0:00 – 1:00 — Orient on the sprint goal.** 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. **1:00 – 12:00 — The main body.** 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/). **12:00 – 14:00 — Blockers and owners.** Sweep the blockers that came up. Each one gets a name attached and a "we'll sort it right after." No solving — just ownership. **14:00 – 15:00 — Parking lot.** 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 — 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 stand-up 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 stand-up 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 stand-up 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 stand-up is the clearest symptom in the [stand-up 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 stand-up 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. 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 stand-up](/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 stand-up 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 [stand-up format catalog](/guides/daily-standup-guide/standup-meeting-ideas/) has ways to vary it without losing the fifteen-minute discipline. For how the stand-up's agenda fits alongside the other sprint meetings, see the [agile ceremonies guide](/guides/agile-ceremonies-guide/); for the rest of the daily-stand-up chapters, head back to [the guide hub](/guides/daily-standup-guide/). ## Frequently asked questions ### What is the agenda for a daily stand-up? 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 stand-up? 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 stand-up? 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 stand-up 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 stand-up 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 stand-up 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 working guide to the daily standup: what it's for, the three questions and better alternatives, a fifteen-minute agenda, and the async and remote variants that keep it useful. --- # The three stand-up questions (and smarter alternatives) URL: https://www.teamretro.com/guides/daily-standup-guide/daily-standup-questions/ The three daily stand-up 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 stand-up 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. 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 stand-up needs an owner before the stand-up 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 stand-up agenda](/guides/daily-standup-guide/daily-standup-agenda/); for more ways to vary the format, see [stand-up 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 stand-up 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 stand-up guide](/guides/daily-standup-guide/). See [how to run an effective stand-up](/guides/daily-standup-guide/how-to-run-a-daily-standup/) for the moves that keep it fifteen minutes, and [copy-paste stand-up 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 stand-up 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 — because answered literally, they produce a status report rather than a coordination conversation. ### What should you say in a daily stand-up? 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 stand-up 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 stand-up templates (copy-paste, Slack and Teams) URL: https://www.teamretro.com/guides/daily-standup-guide/daily-standup-templates/ A daily stand-up 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 stand-up, a Slack or Teams channel, or an async thread. Pick one, use it unchanged for a fortnight, then adapt. 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 stand-up 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. ``` Why this beats the per-person format — and how to facilitate it — is in the [daily stand-up agenda](/guides/daily-standup-guide/daily-standup-agenda/). ## Async templates for Slack and Teams For distributed or timezone-split teams, the stand-up moves into a channel. Same brevity, one post per person, posted by a set deadline: ```text *Stand-up — [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 stand-ups](/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/) can prompt each person at a set time and collect the replies into a single digest — 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 [stand-up tools and software](/guides/daily-standup-guide/best-standup-tools/). ## 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 stand-up. ## Make it a habit, then vary it Use one template unchanged long enough for it to become automatic — a fortnight is about right. Then, if the daily rhythm starts to flatten, borrow a format from the [stand-up 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 stand-up](/guides/daily-standup-guide/how-to-run-a-daily-standup/). The [daily stand-up guide](/guides/daily-standup-guide/) hub links the rest — from the agenda to the anti-patterns. ## Frequently asked questions ### What should a daily stand-up 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 stand-up 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 or use a stand-up bot or the TeamRetro Slack integration to prompt everyone and collect the replies in one place. ### What should you say in a stand-up — 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 stand-up 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 stand-ups chapter for the tradeoffs. --- # Definition of done URL: https://www.teamretro.com/guides/agile-estimation-guide/definition-of-done/ The definition of done is one checklist for the whole team — the standard every story clears before it counts as complete. [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. ## A definition-of-done checklist (example) 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 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. ## 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 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. ### 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 — and 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. --- # 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, 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. ## 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 — an external team, 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 — reproducing on the customer's data, writing a postmortem, drafting the response, deciding whether to credit the account, communicating to other affected customers — is often most of the story. 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?" — it's "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, not 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, 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 — 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 — [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: declined card, expired card, 3DS challenge — 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 — p50, p95, 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 — 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" — and 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; 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 — and 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 compared URL: https://www.teamretro.com/guides/agile-estimation-guide/estimation-techniques/ Planning poker is one estimation technique among several, and it isn't always the right one. Every technique is a trade — speed for precision, coverage for depth, a number for a conversation. The technique you pick is really the failure mode you've decided you can live with. ## The techniques at a glance | Technique | Best for | Output | Time per item | |---|---|---|---| | Planning poker | 5–20 well-refined stories | Story points (numeric) | 2–5 min | | T-shirt sizing | Early refinement, roadmap work | XS–XL (categorical) | 30–60 sec | | Bucket system | Sizing 50+ items quickly | Story points (numeric) | 10–20 sec | | Affinity mapping | Sizing a fresh backlog from scratch | Relative groupings → points | 5–15 sec | | Magic estimation | Long, well-understood backlogs | Story points (numeric) | 10–20 sec | | Dot voting | Prioritization, not estimation | Vote counts | ~10 sec | ## Planning poker The right call when you have a focused backlog and need shared understanding, not just a number. The [private-vote-then-reveal](/guides/agile-estimation-guide/how-to-run-planning-poker/) mechanic catches the disagreement other techniques smooth over. **Fails when** the stories aren't ready. Planning poker is the slowest of the lot, and unrefined stories turn that slowness into a refinement meeting badly disguised as estimation. If the cards spread from 3 to 13, you don't have an estimation problem — you have an [unsplit story](/guides/agile-estimation-guide/splitting-user-stories/). ## T-shirt sizing XS, S, M, L, XL. Faster than planning poker because you've dropped the granularity. Common in early refinement, in product and leadership conversations, and on teams that have deliberately moved away from numeric sizing. **Fails when** someone outside the team needs a velocity number. T-shirts don't add up, and the moment you build a conversion table on the wiki to make them add up, you've reinvented [story points](/guides/agile-estimation-guide/what-are-story-points/) with extra steps. ## Bucket system The team drops items into pre-labeled buckets (1, 2, 3, 5, 8…) with a fast pass-and-discuss protocol: one person places, the next can move it, and so on. After a few minutes the buckets *are* the estimates. **Fails when** the items vary in unknowns, not just size. Buckets work because placement is almost reflexive; anything that needs a real conversation gets dropped in the wrong bucket and stays there. ## Dot voting Everyone gets a fixed number of dots and places them on the items they care about most. It isn't estimation — it's prioritization — but it gets confused with estimation often enough to be worth naming. **Fails when** anyone reads the dot count as *how big* instead of *how wanted*. The output and the question don't match, and using one as the other leaves you with a backlog full of small-but-popular items and large ones nobody owns. ## Affinity mapping The team sorts stories into piles by similarity of effort — no labels — then labels the piles (1, 2, 3, 5, 8…) by relative order once everything's grouped. Sorting first and committing to numbers last is the whole idea: by the time the numbers arrive, the relative order is already settled, so the per-story argument — is this a 3 or a 5? — never starts. It's fast, and almost as good as planning poker at avoiding anchoring.
Numbers arrive only after the sort. The sort is the conversation.
**Fails when** the team can't see each other's piles. Affinity mapping leans on a shared wall or whiteboard; run it remotely in a tool with poor spatial awareness and people anchor on whoever places first — the exact failure it was meant to avoid. ## Magic estimation Magic estimation is affinity's more decisive cousin: argue only where the team disagrees. Everyone silently places each story into a named size bucket, and the only stories that get a real discussion are the ones where the placements diverged. Stories the team agreed on in silence keep that silent consensus as their number. That bet — that agreement in silence is real agreement — is the source of both the speed and the failure mode. When it holds, it's the fastest technique that still produces real numbers: a 50-story backlog sized in half an hour. When it doesn't, the team ships a unanimous 5 on a story that was secretly a mix of 3s and 8s, and nobody finds out until the sprint runs out. **Use it** on long backlogs the team already understands, roadmap-level passes, and re-anchoring exercises. **Avoid it** on stories about to enter a sprint, or with a new team that hasn't built a shared model yet — there, the silence hides exactly the disagreement you needed to hear. **Affinity or magic?** Both flip the usual order — relative first, numbers last. Affinity sorts against a wall and labels the buckets at the end; magic sorts straight into named buckets. The choice is between arguing about the line and arguing about the bucket — pick the argument you'd rather your team have. ## #NoEstimates Some teams skip story-point estimation entirely. The bet: if every story is broken down to roughly the same size — usually "fits in a day or two" — you can forecast by counting stories per sprint. It works, but only once the refinement is genuinely that sharp. It's a graduation, not a shortcut. **Fails when** story sizes drift and nobody notices. The whole approach relies on stories being uniform; without an estimation conversation, the signal that they've stopped being uniform never surfaces. The team that "doesn't estimate" usually estimates implicitly, and badly. ## Combining techniques in practice Mature teams don't pick one forever; they switch by the moment: - T-shirts during quarterly roadmap planning. - Affinity mapping, magic estimation, or buckets during a long backlog-refinement pass. - [Planning poker](/guides/agile-estimation-guide/how-to-run-planning-poker/) at [sprint planning](/guides/sprint-planning-guide/), when the stories at the top of the backlog need real shared understanding before anyone commits. Pick the technique whose failure mode you're willing to wear this quarter — not the one that came in the agile-coach's slide deck. ## Frequently asked questions ### What are the main agile estimation techniques? The common ones are planning poker, T-shirt sizing, the bucket system, affinity mapping, magic estimation, and — for prioritization rather than sizing — dot voting. Some teams also run #NoEstimates, forecasting by counting same-sized stories instead of pointing them. ### Which agile estimation technique is best? There is no single best one; each fails differently. Planning poker is slow but builds shared understanding, T-shirts and buckets are fast but coarse, affinity and magic estimation are fast on large backlogs but hide disagreement. Pick the technique whose failure mode you can afford for the work in front of you. ### What is affinity estimation? Affinity estimation sorts stories into bigger-and-smaller piles first, with no numbers, then labels the piles at the end. Committing to numbers last is the whole point: by the time they arrive the relative order is settled, so the per-story argument never starts. It suits first-pass backlog sizing, not sprint commitment. ### What is magic estimation? In magic estimation the team silently places every story into a size bucket, and only the stories where placements diverged get a real discussion. The bet is that silent agreement is real agreement — which makes it very fast on a well-understood backlog and a poor choice for stories about to enter a sprint. ### What is the difference between planning poker and T-shirt sizing? Planning poker produces numeric story points through private voting and discussion, so it is slower but surfaces disagreement. T-shirt sizing (XS to XL) drops the granularity for speed, which suits early refinement and roadmap work — but T-shirts do not add up, so they cannot feed a velocity number. --- # 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 — 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 [Common Ground](https://games.teamretro.com/games/common-ground), 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, 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 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. | 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. [Common Ground](https://games.teamretro.com/games/common-ground), where a team hunts for things everyone shares, 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 stand-up: facilitation and rules URL: https://www.teamretro.com/guides/daily-standup-guide/how-to-run-a-daily-standup/ Running an effective daily stand-up is a facilitation problem, not a format problem. The three questions, the board, the timebox — every team knows the parts. What separates a stand-up 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 stand-up and one who merely *opens* it and hopes. Cold facilitation is how a stand-up 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 stand-up agenda](/guides/daily-standup-guide/daily-standup-agenda/) for where it sits in the run of show. ## Handling the hard cases Most stand-up 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 stand-up 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 stand-up 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 stand-up tool](/standups/) that turns each blocker into a tracked action with an owner keeps that routing from getting lost the moment the call ends. The opposite tell is a stand-up 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 [stand-up 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 stand-up 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 stand-up guide](/guides/daily-standup-guide/). ## Frequently asked questions ### Who runs the daily stand-up? 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 stand-up 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 stand-up? It's short, it leads with blockers, and it's aimed at the team rather than a manager. A good stand-up 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 stand-up? 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 stand-up to let run long. ### How do you keep a stand-up 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 stand-up 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. ## 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 — 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 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 — 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.** DORA left it out of the delivery metrics on purpose. 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 — that's 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 the four keys — comparable across teams and hard to game — and keep velocity inside the team as a planning input, never a number pushed upward.
- Velocity measures [pace, not productivity](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 four keys](https://dora.dev/guides/dora-metrics/) — deployment frequency, lead time for changes, change-failure rate, time to restore — 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. DORA's research deliberately excludes velocity from its delivery metrics for exactly this reason. ### Can you compare velocity across teams? No. Two teams sizing the same work produce different velocity numbers because they use different reference stories — that 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 four keys — deployment frequency, lead time for changes, change-failure rate and time to restore service — measure delivery in ways that do not invite gaming and are comparable across teams. Velocity stays inside the team as a planning input; the four keys 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/scrum-masters-retrospective-guide/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. --- # 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 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 stand-up 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 stand-up The daily stand-up 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 stand-up, 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 stand-up, 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. Our [stand-up anti-patterns](/guides/daily-standup-guide/standup-anti-patterns/) chapter catalogs the specific tells, and the [async and remote stand-up](/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 stand-up 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 stand-up is just a status meeting? Watch where people look. In a coordination stand-up 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 stand-up, 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. - [Stand-up anti-patterns](/guides/daily-standup-guide/standup-anti-patterns/) — the specific tells of a status-theatre stand-up. - [The daily stand-up (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 — 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 — correctly, 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 — 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 — and specifically, "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 metrics — deployment frequency, lead time, change-failure rate, and time to restore — and velocity is deliberately not among them, because 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 — the DORA research deliberately excludes it because points aren't comparable across teams. 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 stand-up? 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. ### 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/asynchronous/) 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](/team-building-activities/) 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://tldrecap.tech/posts/2026/aie-europe/ai-agents-friction/)); 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://tldrecap.tech/posts/2026/aie-europe/ai-agents-friction/)), 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 — 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: 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: 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: 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, 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 — 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 stand-up**, 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 stand-up), 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 stand-up, 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 — which 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/) — 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 stand-up (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/ Run fun, easy and effective sprint retrospectives. A complete Scrum Master's guide to the purpose, stages, templates, games and psychological safety. --- # 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 — 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/) --- # 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 — a thin slice that's actually deliverable on its own — not horizontal. "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/) — the hub for everything here. - [SPIDR story splitting](/guides/agile-estimation-guide/spidr-story-splitting/) — the five reliable cut lines, in depth. - [Horizontal vs vertical slicing](/guides/agile-estimation-guide/horizontal-vs-vertical-slicing/) — the principle underneath every good split. - [Definition of ready](/guides/agile-estimation-guide/definition-of-ready/) — the gate a split story has to clear before it re-enters the sprint. - [Backlog refinement](/guides/agile-ceremonies-guide/backlog-refinement/) — 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 stand-up](/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 — 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 — so it 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, stand-ups, 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 — 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: 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 — what to build next. The retrospective inspects the team's own process, privately — how 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 — and 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 — the team demonstrates what it built and gathers feedback from stakeholders to decide what to do next. The Sprint Retrospective inspects the process — the team reflects on how it worked and agrees on 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 [Common Ground](https://games.teamretro.com/games/common-ground) 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 stand-up is broken: the common anti-patterns URL: https://www.teamretro.com/guides/daily-standup-guide/standup-anti-patterns/ A daily stand-up 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 stand-up 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 stand-up 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 stand-up 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 stand-ups are micromanagement — and when it's run this way, they're not wrong. A stand-up 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 stand-up](/guides/daily-standup-guide/how-to-run-a-daily-standup/) has the facilitation moves. ## Anti-pattern 3: the forty-minute stand-up 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 stand-up 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 stand-up and solved outside it. Name the topic, name who's needed, move on, and hold a hard end time even mid-sentence. The [daily stand-up 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 stand-up 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 stand-up 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. 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 stand-up 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 stand-up 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 stand-up" is exactly the kind of process question the retrospective exists to fix — the two meetings are meant to improve each other. For the constructive side of all this — how to run a stand-up worth the fifteen minutes — see the rest of [the daily stand-up guide](/guides/daily-standup-guide/). ## Frequently asked questions ### Why do daily stand-ups 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 stand-up 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 stand-ups micromanagement? Not by design, but they tip into it easily. A stand-up 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 stand-up 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 stand-up 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 stand-up formats to keep it fresh URL: https://www.teamretro.com/guides/daily-standup-guide/standup-meeting-ideas/ Most stand-up "ideas" articles are a list of icebreakers. This isn't that. A stand-up goes stale because it stopped being useful, not because it lacks a fun question of the day — and 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 stand-up 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 stand-up needs.
If you take one format from this chapter, take **walk the board.** Nearly every stand-up 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 — 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 stand-up 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 — before anyone speaks. Good for flow-focused and Kanban teams that steer by the board's health. **10. Walking stand-up.** Co-located teams literally walk while they talk. The movement caps the length and loosens the room; it's the original spirit of "stand-up" taken one step further. **11. Async written.** Everyone posts a short update to a channel 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 stand-up 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 stand-up; it can't rescue a broken one. **14. No stand-up.** 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 stand-ups](/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 stand-up 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 stand-up](/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 stand-up" 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 everything else — the agenda, facilitation, the anti-patterns — see [the daily stand-up guide](/guides/daily-standup-guide/). ## Frequently asked questions ### How do you make stand-ups 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 stand-up 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 stand-up 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 stand-up from getting stale? Run one format long enough to become a habit, then change it deliberately when the energy flattens — not every day, which just creates confusion. Staleness is usually a symptom: a stand-up 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 stand-up 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 stand-up 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. --- # What are story points? Agile estimation explained URL: https://www.teamretro.com/guides/scrum-masters-retrospective-guide/story-points/ Story points are a unit of **relative estimation**: a single number that captures how big a piece of work feels, combining its **complexity**, the **amount of work**, and its **uncertainty**. Crucially, a story point is *not* a measure of time. Instead of asking "how many hours will this take?", a team asks "how does this compare to work we have already done?" — and that small shift makes estimates more honest and more useful. ## Why relative estimation, not hours People are unreliable at estimating absolute time but surprisingly good at relative judgment — we can tell that one task is roughly twice as hard as another even when we cannot say how long either will take. Story points lean on that strength. They also sidestep three problems that plague 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 — points fold that uncertainty in. ## The story point scale Most teams use a **Fibonacci-like scale** — 1, 2, 3, 5, 8, 13, 20 — rather than a linear one. The widening gaps are deliberate: the bigger an item is, the less precisely anyone can size it, so the scale stops pretending you can tell a 14 from a 15. If an item comes out larger than about 13, that is a signal to split it into smaller pieces the team can understand and deliver within a sprint. ## How teams assign points: planning poker The most common way to estimate is [planning poker](/estimations/). The Product Owner describes a backlog item, the team discusses it, and each person privately chooses a value. Everyone reveals at the same time so nobody anchors on the loudest voice. Where the highest and lowest estimates diverge, those people explain their reasoning — and that conversation, which surfaces assumptions and hidden complexity, is usually worth more than the final number. For a deeper walkthrough, see [how to use planning poker in agile estimation](/blog/how-to-use-planning-poker-in-agile-estimation/). ## From points to velocity Once a team estimates in points, it can measure **velocity**: the number of points it completes in a sprint. After a few sprints, average velocity becomes a simple, empirical forecast — if a team reliably finishes around 30 points a sprint, the Product Owner can roughly project how much of the backlog fits the next few sprints. Velocity is a *planning aid for one team*, never a target and never a cross-team comparison; the moment it becomes a goal, teams inflate their estimates and the number stops meaning anything. ## 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 this feedback loop, not by trying harder up front. ## Frequently asked questions about story points ### What are story points in agile? Story points are a unit of relative estimation that expresses how much effort a piece of work will take, combining its complexity, the amount of work, and its uncertainty into a single number. They are deliberately not a measure of time. A team compares each item against others it has already sized and assigns points on a shared scale, so estimates reflect difficulty rather than how many hours one particular person might spend. ### 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. 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. The Product Owner 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. ### 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 - [Free planning poker for agile teams](/estimations/) — estimate your backlog together in real time. - [The three Scrum artifacts](/guides/scrum-masters-retrospective-guide/scrum-artifacts/) — what the Product Backlog you are estimating actually is. - [What is a burndown chart?](/guides/scrum-masters-retrospective-guide/burndown-chart/) — how teams track the points they committed to. --- # 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 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 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 — 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. --- # 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, and how to lock in the trust, norms, 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 norms and working agreements that stick URL: https://www.teamretro.com/guides/team-dynamics/team-norms-and-working-agreements/ Team norms are the unwritten standards of behavior that form in any group. Working agreements are those norms made explicit: a short, negotiated set of rules a team writes down and agrees to follow. A team charter is the wider kickoff document that holds them, alongside your purpose, roles, and how you make decisions. 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](https://www.atlassian.com/team-playbook/plays/working-agreements). ## 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](https://www.scrum.org/resources/creating-team-working-agreement) 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 Here is a bank of concrete agreements grouped by the situation each one covers. Do not adopt all of them; that would break rule eight. Read it as a menu: take the five or ten that match your team's friction, and change the specifics to fit your context. ### 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 | ## 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/asynchronous/) 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. 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. 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. ## Frequently asked questions ### 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 a team charter and working agreements? 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 team norms stick? Co-write them with the whole team so they aren't 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. --- # The daily stand-up (daily scrum): the ceremony explained URL: https://www.teamretro.com/guides/agile-ceremonies-guide/the-daily-standup/ The daily stand-up — 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 stand-up 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 stand-ups](/guides/daily-standup-guide/). ## Daily scrum or daily stand-up? Same event, two names. "Daily scrum" is the current Scrum Guide term; "stand-up" 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 stand-up 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 stand-ups across time zones or in Slack and Teams is its own problem; [TeamRetro's stand-ups](/standups/) and the [Slack](/integrations/slack/) and [Microsoft Teams](/integrations/microsoft-teams/) integrations 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 stand-up 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 stand-up? Yes. "Daily scrum" is the term the Scrum Guide uses; "stand-up" 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 stand-up 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 — and 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 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. 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 — because 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" — and worse, "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: 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**. The second edition's 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://tldrecap.tech/posts/2026/aie-europe/ai-agents-friction/): "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 — 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 — 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 is 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. --- # Velocity: what it's for and how to calculate it URL: https://www.teamretro.com/guides/agile-estimation-guide/velocity/ 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 over the last few sprints. That's 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, 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 aren't. "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, not by doing more of it. Goodhart's law, running on a two-week cycle. ## How to calculate it Take the points completed in each of the last three to five sprints. Average them. That's your velocity. Don't adjust for "exceptional" sprints — the exceptional sprints are part of the signal you're trying to smooth out. Don't count carried-over work twice. Don't count partially-completed stories at all; they get counted in the sprint they actually finish in. 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, a major personnel change — all reasons to throw out the prior number and rebuild from scratch. The number isn't a property of the technique; it's 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.
## Calculate your velocity Run your own numbers: the points your team completed in each recent sprint, and — if you want the forecast — the points left in the backlog. 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 many story points per sprint? Searching "how many story points per sprint" is a category error. There's 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're 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.
So use velocity to do three things, and only three: project a date for a known scope (scope ÷ velocity = sprint count); decide what fits in the next sprint (pick stories until they sum to about 80–90% of the recent average, leaving room for the unplanned); and spot when something has changed (a 30% drop is signal worth a retrospective conversation). What you can't 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. ## What goes wrong 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 — that's the whole point of relative estimation. Comparing them is like comparing two thermometers with different zero points. The numbers don't 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. ## 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. ## Frequently asked questions ### How many story points per sprint is normal? There's 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, don't target it. Pick stories until they sum to roughly 80–90% 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/scrum-masters-retrospective-guide/burndown-chart/) — how teams track the points they committed to within a 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 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. ## The scale, and what points are for 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 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. ## 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. ### 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 — everything reads as tiny-or-bigger. Recalibrate against a recent reference story rather than shrinking the scale. ## 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 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. 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. 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, 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 [tips for actionable sprint retrospectives](/blog/tips-for-actionable-sprint-retrospectives/), 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 stand-up meeting? Purpose, history and the 15-minute rule URL: https://www.teamretro.com/guides/daily-standup-guide/what-is-a-standup-meeting/ A stand-up meeting is a short, daily synchronization — usually fifteen minutes, 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 stand-up. 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 stand-up 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 stand-up 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 stand-up, daily huddle — see [daily scrum vs daily stand-up](/guides/daily-standup-guide/daily-scrum-vs-daily-standup/). For this chapter, treat them as the same event. ## What a daily stand-up is for Strip it back and a stand-up 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. - **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 stand-up'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 stand-up 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 stand-up, 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 stand-up 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 — and a stand-up 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 stand-up. 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 stand-up has tipped into surveillance, that question has its own chapter: [why your stand-up is broken](/guides/daily-standup-guide/standup-anti-patterns/). ## Where the stand-up fits The daily stand-up is one of a handful of recurring agile meetings — planning at the start of the sprint, the stand-up 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 stand-up 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 stand-up? To coordinate, not to report. A daily stand-up 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 stand-up 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 stand-up? 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 stand-up? 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, 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. ## 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 — 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](https://www.mindtools.com/a6ooqev/lencionis-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 [Common Ground](https://games.teamretro.com/games/common-ground) 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 — 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. **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, not 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). 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 — fix the harness, not 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* — that's 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. 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 — 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. 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 tools, 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. ## 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/) — and 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 it is 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: by one commonly cited Scrum Alliance figure, only about a third of teams consistently complete their retro action items. The rest get written on a whiteboard and erased. The folklore does oversell the doom, though — we measured [how many retrospective action items actually get done](/guides/follow-through-index/) across hundreds of thousands of real actions, and completion is closer to three in four, with cadence and ownership deciding which side of the gap a team lands on. Two fixes, and the second is the important one. First, stop trying to fix everything. A retro that generates ten action items completes none of them. Cap it at **one** improvement the team genuinely commits to, 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 — and 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 — stop treating the *action item* as the point. 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. ## 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 — stacked on standup, planning, review, and refinement. On short cadences the maths 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 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 and 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 and health checks. These AI features streamline your experience by 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 | | Meeting summarization | AWS Bedrock | Anthropic Claude Sonnet 4.x | | Meeting suggested titles | AWS Bedrock | Anthropic Claude Haiku 4.x | | Insights topic, sentiment, keyword annotations. Theme identification. | AWS Bedrock | Anthropic Claude Sonnet 4.x
Anthropic Claude Haiku 4.x | | Automated grouping, group title suggestions | AWS Bedrock | Anthropic Claude Sonnet 4.x
Anthropic Claude Haiku 4.x | | Action suggestions | AWS Bedrock | Anthropic Claude Sonnet 4.x | | Search embeddings | AWS Bedrock | Amazon Titan Text Embeddings v2
Cohere Embed Model 3 | | AI image generation — cover and topic images | fal – Features & Labels, Inc. | Image-generation models hosted on fal.ai | *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, with appropriate consent. - 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 utilize AWS Bedrock Guardrails to actively monitor, moderate, and restrict AI use where appropriate. These include, but are not limited to: - Input prompts and user content are monitored by TeamRetro to reduce the risk of inappropriate or unsafe AI results. - Output from AI features is automatically moderated to prevent unwanted or potentially harmful responses. - AI features in TeamRetro are configured to avoid generating content related to: - - Medical information or health advice. - Self-harm or mental health diagnoses. - Sexually explicit material. - Political topics, including commentary on elections or political figures. ## 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 — a person always reviews the output and decides what to keep. 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@teamretro.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@teamretro.com](mailto:security@teamretro.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. ## 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](http://status.aws.amazon.com/) | | [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](http://status.aws.amazon.com/) | | [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.io/) | | [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.io/) | | [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](http://status.sendgrid.com/) | | [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 (Better Logs) and application uptime monitoring (Better Uptime). | Czech Republic | Germany | [Privacy](https://betterstacks.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 (Better Logs) and application uptime monitoring (Better Uptime). | United States | United States | [Privacy](https://betterstacks.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 optionally engaged when you make use of TeamRetro’s AI synthesis features such as suggested grouping, retrospective and health check meeting summaries and health check response summaries. AI Synthesis features can be globally 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 suggested grouping, retrospective and health check 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](http://status.aws.amazon.com/) | | [Amazon Web Services](https://aws.amazon.com/) 410 Terry Ave N, Seattle, Washington 98019 United States | **TeamRetro US Region** Optional suggested grouping, retrospective and health check 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](http://status.aws.amazon.com/) | ## TeamRetro AI content generation subprocessors Subprocessors in this section may be engaged when you make use of TeamRetro’s Generative AI features such as AI-generated retrospective templates, health models and icebreaker questions. No PII or commercially sensitive information shared with these subprocessors. | Entity | Task | Entity Country | Processing Country | More Info | | :-- | :-- | :-- | :-- | :-- | | [OpenAI LLC](https://openai.com/) Pioneer building 3180 18th St, San Francisco, CA 94110, USA | OpenAI generative AI is used for AI content generation (retrospective templates, health models, icebreaker questions) | 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 power TeamRetro’s AI image generation, such as cover and topic images. No PII or commercially sensitive information is shared with these subprocessors. | Entity | Task | Entity Country | Processing Country | More Info | | :-- | :-- | :-- | :-- | :-- | | [fal – Features & Labels, Inc.](http://fal.ai) 2261 Market St., Suite 10467, San Francisco, CA 94114 | 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) | ## 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 | 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/) | | [Kinsta, Inc.](https://kinsta.com/) 8605 Santa Monica Blvd #92581, West Hollywood, CA 90069, United States | Marketing website hosting (teamretro.com, groupmap.com) | United States | Not a data subprocessor — no customer data processed | [Privacy](https://kinsta.com/legal/privacy-policy/) [Security](https://trust.kinsta.com/) [Status](https://status.kinsta.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. ### 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/
UK-GDPR Certification: Art 27 representation by Prighter GDPR Certification: Art 27 representation by Prighter
## 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).
UK-GDPR Certification: Art 27 representation by Prighter GDPR Certification: Art 27 representation by Prighter
**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/un/unsc_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/). ## 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 with Health Checks URL: https://www.teamretro.com/compare/easyretro-alternative/ TeamRetro is a leading EasyRetro alternative built specifically for agile retrospectives and team health checks. Unlike EasyRetro, it adds scheduled and recurring retros, health-check models and radars, 200+ templates and SOC 2 Type 2 security on every plan. Teams usually leave EasyRetro (formerly FunRetro) when a board stops being enough. Its free tier gives you public boards only — no private team space, and one survey per board — and the paid product is still built around one-off boards rather than an ongoing practice: no scheduled or recurring retros, no health checks, and action items that don't carry forward from one session to the next. That's fine until improvement has to stick, which is the point where [teams outgrow free retro boards](/case-studies/big-give/) — Big Give moved to TeamRetro when actions kept getting lost between campaigns. Switching is light. There's nothing you have to migrate: start your next retro from one of 200+ templates, invite the team by link, and carry any open actions forward so nothing is dropped in the handover. Pricing is team-based — from $25 per team, with unlimited members — and every plan includes SOC 2 Type 2 and GDPR compliance, so bringing IT along is a short conversation. So the honest split is this. EasyRetro is a solid choice if you want a clean, fast board for the occasional retro without enterprise overhead. TeamRetro is the better fit if retrospectives are a recurring ritual you want structured, measured and actioned — with health checks, trend lines and follow-through you can see sprint after sprint. --- # Echometer Alternative — Scheduled Retros URL: https://www.teamretro.com/compare/echometer-alternative/ TeamRetro is a strong Echometer alternative that pairs health checks with a full retrospective and estimation suite. Where Echometer stops short on scheduling and planning poker, TeamRetro adds scheduled retros, 200+ templates, planning poker and SOC 2 Type 2 security. Echometer is built around psychology-backed health checks, and that's genuinely its strength — recurring pulses grounded in University of Münster research. But teams that want the retrospective itself to go further tend to hit its edges. Sessions start manually, with no scheduling or recurring cadence; the template library sits around 50; and there's no planning poker for estimation. Chat integrations are thin, too — Jira, but no Slack or MS Teams. Moving across is straightforward: there's nothing to migrate. Start your next retrospective from one of 200+ templates, invite the team by link, and carry any open actions forward so nothing slips between sessions. Pricing is a flat rate per team with unlimited members — no per-seat minimums to work around — and you're covered by SOC 2 Type 2 and GDPR, hosted in the US or EU. Echometer is the better fit if your priority is psychology-informed team development: recurring health-check pulses backed by research, with EU-only data residency. TeamRetro is the better fit if retrospectives are a recurring ritual you want structured, measured and actioned — with health checks, agile estimation and reporting in one place. --- # GoRetro Alternative — Team Health Checks URL: https://www.teamretro.com/compare/goretro-alternative/ TeamRetro is a powerful GoRetro alternative for agile teams that want more than a happiness index. It adds structured health-check models and radars, scheduled retros, AI summaries and deeper integrations — all backed by SOC 2 Type 2 security. Teams tend to move on from GoRetro when the retrospective becomes a recurring ritual rather than a sprint add-on. GoRetro runs a clean retro and tracks a happiness index, but it stops short of structured health-check models and radars, doesn't schedule recurring retros, and its integrations largely end at Jira, with Slack on paid tiers. Once your teams need repeatable health tracking and connections into tools beyond Jira, that ceiling starts to show. Switching is light. There's nothing you have to migrate to get started — you begin your next retro from one of 200+ templates, invite the team by link, and carry any open actions forward so momentum isn't lost. Pricing is team-based with unlimited members, so cost scales by team rather than per seat, and TeamRetro is SOC 2 Type 2 and GDPR compliant when IT needs to sign off. To be fair, GoRetro is a strong fit for scrum teams that live in Jira and want a polished retro bundled with planning poker, priced per team. TeamRetro suits you if retrospectives are a recurring ritual you want structured, measured and actioned over time — the shift many teams make as they outgrow lightweight or free retro tools, as the 12-person team at [Big Give](/case-studies/big-give/) found. --- # Ideaboardz Alternative with Health Checks URL: https://www.teamretro.com/compare/ideaboardz-alternative/ TeamRetro is a more powerful IdeaBoardz alternative built specifically for agile retrospectives and team health checks. Where IdeaBoardz stops at free basic boards with no integrations or security, TeamRetro adds health checks, scheduled retros, AI summaries and SOC 2 Type 2 hosting. IdeaBoardz earns its place as a free, no-signup board: spin up a shared URL, drop ideas into a few columns, vote, and export to PDF or Excel. That's plenty for a throwaway brainstorm, but teams tend to outgrow it once the retro becomes a regular habit. There's no timer or facilitation phases, no way to schedule a recurring retro, no health checks, and no Jira or Slack integrations — so the actions you raise stay stranded on a public board. It's a well-worn path: [Big Give's 12-person team moved from a free retro tool to TeamRetro](/case-studies/big-give/) to stop losing actions between campaigns. Switching is light. There's nothing you need to migrate — IdeaBoardz boards are throwaway URLs, so you simply start your next retro in TeamRetro from one of 200+ templates, invite the team by link, and carry any open actions forward instead of leaving them behind. Pricing is per team rather than per user, and everything runs on SOC 2 Type 2 and GDPR-compliant hosting in the US or EU. IdeaBoardz still suits a scrappy, one-off session where nobody wants to sign up and the board can be thrown away afterwards. TeamRetro is the better fit when retrospectives are a recurring ritual you want structured, measured and actioned — with health checks, trends over time, and actions that follow the team from one retro to the next. --- # 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** — SOC 2 and SSO start to matter the moment more than one team is on board. Each comparison above puts TeamRetro next to a specific tool on these points — with feature tables, pricing and what teams say — so you can decide with the detail in front of you rather than a marketing claim. Want a broader view first? See our roundup of [the best retrospective tools for agile teams](/blog/find-the-best-tool-for-your-teams-agile-retrospective/). --- # Kollabe Alternative with Health Checks URL: https://www.teamretro.com/compare/kollabe-alternative/ TeamRetro is a mature Kollabe alternative built for agile retrospectives and team health checks. Where Kollabe lacks health checks and independent dot voting, TeamRetro adds health-check models, private dot voting, 200+ templates and SOC 2 Type 2 security. Teams usually switch once retros become a regular habit rather than a one-off. Kollabe handles a single session well, but it can't schedule recurring retros, and each one stays fairly self-contained — there's no health-check model or cross-team view to show how a team is trending between sprints. TeamRetro is built for that cadence: recurring schedules, health checks with heat maps and trend lines, sentiment word clouds, and an action dashboard that tracks whether last retro's actions actually happened. Switching is low-effort because there's nothing to migrate first. You start your next retro from one of 200+ templates, invite the team with a link, and carry any open actions forward so nothing is dropped between tools. Pricing is per team rather than per seat, and because TeamRetro is SOC 2 Type 2 certified and GDPR compliant, the move clears a security review without slowing anyone down. To be fair to Kollabe: if you want retros, standups and planning poker bundled in one clean tool without per-seat pricing, it's a genuinely good fit for a small or mid-size team. Choose TeamRetro if retrospectives are a recurring ritual you want structured, measured and actioned — with health checks and reporting that track how a team is doing between sprints, not just within a single board. --- # Ludi Alternative — Health Checks & AI URL: https://www.teamretro.com/compare/ludi-alternative/ TeamRetro is a feature-rich Ludi alternative for agile retrospectives, estimation and team health. Unlike Ludi, it offers built-in health-check models and radars, AI grouping and summaries, and SOC 2 Type 2 certification held directly — not just SOC 2 infrastructure. --- # Metro Retro Alternative — Guided Retros URL: https://www.teamretro.com/compare/metro-retro-alternative/ TeamRetro is a focused Metro Retro alternative built specifically for agile retrospectives and team health checks. Instead of a freeform canvas, it gives you guided, time-boxed facilitation, automated grouping, action tracking and SOC 2 Type 2 security on every plan. Teams usually move off Metro Retro once retrospectives become a regular habit rather than an occasional workshop. Its playful, freeform whiteboard is built for open collaboration, but it leaves the facilitation to you: there are no guided stages, no built-in action tracking, and no health-check radars to show how the team is trending over time. When a retro needs to end in owned actions that carry into the next session, the blank canvas starts working against you. Switching is a clean start — there is nothing to export or migrate. You open your next retrospective from one of 200+ templates, invite the team with a single link, and carry any open actions forward from where the last discussion left off. Pricing is flat and team-based rather than per active user, so the cost stays predictable as the team grows, and every plan includes SOC 2 Type 2 and GDPR compliance for teams handling sensitive data. Metro Retro suits teams who want a loose, visual canvas for the occasional engagement-led session or workshop. TeamRetro is the better fit if retrospectives are a recurring ritual you want structured, measured and actioned — with guided facilitation, health checks and trend lines that show whether things are actually improving. --- # Miro Alternative for Retrospectives URL: https://www.teamretro.com/compare/miro-alternative/ TeamRetro is a purpose-built Miro alternative for agile retrospectives and team health checks. Instead of a general whiteboard, it gives you structured, guided retros with automated grouping, health-check models, scheduled retros and SOC 2 Type 2 security. Teams usually switch when the whiteboard becomes the work: every Miro retrospective starts with rebuilding a board, copying sticky notes and corralling votes — dot voting needs the Business plan, and per-member pricing grows with every participant. TeamRetro flips that. Pick one of 200+ retrospective templates and guided facilitation walks the team from private brainstorming through grouping, independent voting and agreed actions — no setup, no lasso tool. Moving is light because there is nothing to migrate. Start your next retro in TeamRetro from a template, invite the team with a link, and carry open actions forward from sprint to sprint. Team-based pricing (from $25 per team, unlimited members) replaces Miro's per-member pricing, and you keep SOC 2 Type 2 and GDPR compliance when you switch. Miro remains excellent at what it is built for: open-ended visual collaboration, design workshops and mapping. If your team mostly whiteboards and occasionally retros, it may be enough. If retrospectives are a recurring ritual you want structured, measured and actioned, a purpose-built retrospective tool earns its keep. --- # Neatro Alternative — Scheduled Retros & AI URL: https://www.teamretro.com/compare/neatro-alternative/ TeamRetro is a capable Neatro alternative for agile retrospectives and team health checks. Where Neatro has no presentation mode, AI summaries or SOC 2 certification, TeamRetro adds scheduled retros, AI grouping and summaries, presentation mode and SOC 2 Type 2 security. Teams usually start looking past Neatro when the ritual outgrows a single guided flow. Neatro runs each retro by hand and stops there — there is no AI to group similar cards or draft a summary, no way to schedule a recurring cadence so the next session sets itself up, and no native Slack or Microsoft Teams integration, so reminders and links sit outside the channels your team already works in. Its security also rests on the underlying cloud rather than an independent SOC 2 or GDPR attestation, which tends to stall things once IT or procurement gets involved. Moving across is light. There is nothing to migrate — you start your next retro in TeamRetro from one of 200+ templates, invite the team by link, and carry any open actions forward so nothing gets dropped between sessions. Pricing is a flat $25 per team with unlimited members. And where Neatro's security rests on the underlying cloud, TeamRetro carries its own independent SOC 2 Type 2 and GDPR attestation — the evidence IT and procurement ask for. Neatro is a genuinely good fit for a Scrum Master who wants a guided, safety-first facilitation flow with built-in team health tracking for a single squad. TeamRetro fits when retrospectives are a recurring ritual you want structured, measured and actioned across teams — with the scheduling, AI and reporting to keep it going. --- # NimbleRetro Alternative — 200+ Templates URL: https://www.teamretro.com/compare/nimbleretro-alternative/ TeamRetro is a complete NimbleRetro alternative for agile teams. Where NimbleRetro ships just four templates and charges per user, TeamRetro gives unlimited users 200+ templates, health checks, AI insights and SOC 2 Type 2 security. --- # Parabol Alternative — Priced Per Team URL: https://www.teamretro.com/compare/parabol-alternative/ TeamRetro is a leading Parabol alternative built for agile retrospectives, health checks and estimation. Instead of Parabol's per-user pricing and limited free tier, TeamRetro charges per team for unlimited users — with health-check models and radars, 200+ templates and SOC 2 Type 2 security. Teams usually move off Parabol for one of two reasons. The first is pricing that climbs with headcount — a Parabol retrospective is billed at $8 per active user per month, so the bill grows every time the team does, and the free tier caps you at two teams. The second is measurement: Parabol's team health is a lightweight emoji poll, with no custom health models, radars or trend lines to show whether things are actually improving from one retro to the next. Switching is low-friction. There's nothing you have to migrate — start your next retro from one of 200+ templates, invite the team by link, and carry any open actions forward so nothing gets dropped. Pricing is flat per team with unlimited members, so you stop doing per-seat math as people join. And it's ready for a security review when you need one: TeamRetro is SOC 2 Type 2 and GDPR compliant. To be fair, Parabol has a real sweet spot: distributed, backlog-heavy engineering teams that want one open-source tool for retros, poker, standups and lightweight team health, with deep write-back to Jira, GitHub and Azure DevOps. TeamRetro is the better fit if retrospectives are a recurring ritual you want structured, measured and actioned — not just another meeting. Weighing Retrium too? See the three-way comparison: [TeamRetro vs Parabol vs Retrium](/compare/teamretro-vs-parabol-vs-retrium/). --- # Reetro Alternative — Anonymity on Every Plan URL: https://www.teamretro.com/compare/reetro-alternative/ TeamRetro is a trusted Reetro alternative for agile retrospectives and team health checks. Where Reetro keeps anonymous input behind paid plans and isn't SOC 2 certified itself, TeamRetro gives anonymity on every plan, plus health checks, radars and SOC 2 Type 2 security. Most teams meet Reetro through its free plan, and for a first retrospective it does the job. The friction shows up once the habit sticks: the free tier caps you at three teams and nine members, anonymous input now sits behind a paid plan, and voting stays a simple thumbs up or down. Teams that retrospect regularly tend to outgrow those limits — much like the team at [Big Give](/case-studies/big-give/), who moved off a free retro tool once reflection became part of how they work. Moving off those limits is light. There's nothing you have to migrate — start your next retro from one of 200+ templates, invite the team by link, and carry open actions forward so nothing falls off the radar. The three-team, nine-member ceiling goes away: pricing is per team with unlimited members, and anonymous input is standard on every plan rather than a paid add-on. TeamRetro is SOC 2 Type 2 certified and GDPR compliant, so getting sign-off from IT is straightforward. Reetro is a solid pick if you want a low-cost, AI-assisted retro board for a small team and the free tier covers you. TeamRetro is the better fit if retrospectives are a recurring ritual you want structured, measured and actioned — with health checks, team radars and reporting that show whether things actually improve over a quarter. --- # Retrium Alternative with AI Grouping URL: https://www.teamretro.com/compare/retrium-alternative/ TeamRetro is a more affordable Retrium alternative for agile retrospectives and team health checks. Where Retrium has no AI and higher per-team pricing, TeamRetro adds 200+ templates, AI grouping and summaries, scheduled retros and SOC 2 Type 2 security for less. Most teams leave Retrium over cost and scope, not facilitation. Retrium is priced per team room — from $39 a month, so three teams land near $117 a month — and it stays deliberately retro-only: no planning poker, no icebreakers or check-in questions, and around ten built-in templates. It also has no AI, so grouping and summaries stay manual. Moving across is light, because there is nothing to migrate. Start your next retro from one of 200+ templates, invite the team by link, and carry any open actions forward so nothing is lost between sprints. Pricing is per team, from $25 a month with unlimited members, and TeamRetro is SOC 2 Type 2 certified and GDPR compliant, hosted in the US or the EU. > "I found TeamRetro more user friendly at the time of purchase over Retrium." > > — David W., Senior Scrum Master, via [Capterra](https://www.capterra.com/p/193264/TeamRetro/reviews/) To be fair to Retrium: if you want a focused, opinionated five-phase retro flow with a built-in Team Radar and you live in Jira Cloud, it does that job well. TeamRetro suits teams who want retrospectives, health checks, planning poker and AI assistance in one place — and want that to scale across teams without the per-room bill climbing. Weighing Parabol too? See the three-way comparison: [TeamRetro vs Parabol vs Retrium](/compare/teamretro-vs-parabol-vs-retrium/). --- # Retrospected Alternative with AI Grouping URL: https://www.teamretro.com/compare/retrospected-alternative/ TeamRetro is a more complete Retrospected alternative built specifically for agile retrospectives and team health checks. It adds 200+ templates, automated grouping, health-check models, action tracking and SOC 2 Type 2 security on every plan. Retrospected is an open-source tool for running simple retrospective boards, and for the occasional retro that can be enough. Teams tend to switch once the retro becomes a habit rather than a one-off. On a free board the amount you can capture is limited, security and compliance are left to you to manage rather than handled by the tool, and there is little to carry a discussion through to a tracked action. TeamRetro is built for that recurring practice — 200+ ready-made templates instead of a blank board, automated grouping to cut the busywork, and actions that follow the team from one retro to the next. The move is light. Start your next retro from one of 200+ templates, invite the team with a link, and carry any open actions forward as you go. Pricing is per team, from $15–$25 with volume discounts, rather than per individual license — so adding a teammate doesn't change the bill. TeamRetro is SOC 2 Type 2 certified and GDPR compliant, hosted in the US or the EU, rather than something you have to configure session by session. Which fits depends on how you work. A free, open-source board like Retrospected may be all a small team needs for the occasional retro. But if retrospectives are a recurring ritual you want structured, measured and actioned — with health checks, trends over time and follow-through you can see — TeamRetro is built for that. --- # Retros.work Alternative — SSO & Health Checks URL: https://www.teamretro.com/compare/retroswork_online_retrospective_tool_alternative/ TeamRetro is a trusted Retros.work alternative built specifically for agile retrospectives and team health checks. It brings 200+ templates, automated grouping, health checks, SSO on every plan and SOC 2 Type 2 security together in one tool for scrum masters and agile teams. --- # RetroTeam Alternative — Health Checks URL: https://www.teamretro.com/compare/retroteam-alternative/ TeamRetro is a more complete RetroTeam alternative for agile teams. Where RetroTeam offers four templates and no health checks or SOC 2 certification, TeamRetro adds 200+ templates, team health checks, AI insights and SOC 2 Type 2 security. --- # RetroTime Alternative with Health Checks URL: https://www.teamretro.com/compare/retrotime-alternative/ TeamRetro is a trusted RetroTime alternative built specifically for agile retrospectives and team health checks. It brings together 200+ templates, automated grouping, health checks, action tracking and SOC 2 Type 2 security so remote teams can improve every sprint. Teams usually move on from RetroTime when a freeform sticky-note board stops keeping up. It handles the occasional ad hoc retro, but as retrospectives become a regular habit the gaps show: no templates to structure the session, no way to group similar ideas, and non-secret voting that can quietly skew what people are willing to say. Small teams often [outgrow a free retro tool](/case-studies/big-give/) the moment they want their reflections and actions to add up over time. Switching is light, because there's nothing to migrate. Start your next retro from one of 200+ templates, invite the team with a single link, and carry any open actions forward so nothing gets dropped between sessions. Pricing is per team rather than per head, and the same enterprise-grade security applies at every plan — TeamRetro is SOC 2 Type 2 certified and GDPR compliant, hosted in the US or EU. If you only need the occasional lightweight brainstorm, a simple board like RetroTime does the job. But if retrospectives are a recurring ritual you want structured, measured and actioned — with health checks, sentiment trends and follow-through you can see sprint after sprint — TeamRetro is built for that. --- # RetroTool Alternative — Jira, Slack & Teams URL: https://www.teamretro.com/compare/retrotool-alternative/ TeamRetro is a more connected RetroTool alternative for agile retrospectives and team health checks. Where RetroTool has no integrations, health checks or SOC 2, TeamRetro adds Jira, Slack and Teams integrations, health-check models, AI grouping and SOC 2 Type 2 security. Teams usually start with RetroTool because it's a free, no-login board — quick to spin up for a one-off session. The friction shows up later, when a retro tool has to do more than host a single meeting. RetroTool has no recurring or scheduled retros, no health checks, and no presentation mode, so as retrospectives become a regular habit the manual work piles up. A free, no-login board hides its real cost: when a retro is a throwaway URL, the actions from it are too — orphaned the moment the board is closed, with no continuity from one sprint to the next. Moving to TeamRetro trades that hidden cost for a place where retros and their actions persist. There's nothing to migrate — you start your next retro from one of 200+ templates, invite the team with a link, and carry open actions forward so nothing falls off the radar. Pricing is per team, from $25 with unlimited members and no per-seat fees, with SOC 2 Type 2 and GDPR compliance on every plan. RetroTool suits a small or ad-hoc team that wants a free retro tool for the occasional session with no setup. TeamRetro is the better fit if retrospectives are a recurring ritual you want structured, measured and actioned — across sprints, and across teams. --- # Reviews & Ratings from Agile Teams URL: https://www.teamretro.com/compare/reviews/ [![Capterra logo representing trusted software review feedback](../../assets/comparisons/reviews/capterra-logo-review-276x300.webp)](https://reviews.capterra.com/products/new/35062843-3dc8-4bef-a877-2c34e0b8c9ff/) [Capterra](https://reviews.capterra.com/products/new/35062843-3dc8-4bef-a877-2c34e0b8c9ff/) [![Crozdesk logo representing trusted software review feedback](../../assets/comparisons/reviews/crozdesk-logo-review.webp)](https://crozdesk.com/software/teamretro/reviews/new) [Crozdesk](https://crozdesk.com/software/teamretro/reviews/new) [![G2 logo representing trusted software review feedback](../../assets/comparisons/reviews/g2-logo-review-300x300.webp)](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) [![Google logo representing trusted customer review feedback](../../assets/comparisons/reviews/google-logo-review-294x300.webp)](https://g.page/r/Cf7vvNYpylIBEAI/review) [Google](https://g.page/r/Cf7vvNYpylIBEAI/review) [![Slashdot logo representing trusted software review feedback](../../assets/comparisons/reviews/slashdot-logo-review-300x300.webp)](https://slashdot.org/software/p/TeamRetro/reviews/new) [Slashdot](https://slashdot.org/software/p/TeamRetro/reviews/new) [![SourceForge logo representing trusted software review feedback](../../assets/comparisons/reviews/sourceforge-logo-review-300x300.webp)](https://sourceforge.net/software/product/TeamRetro/reviews/new) [SourceForge](https://sourceforge.net/software/product/TeamRetro/reviews/new) [![Trustpilot logo with green stars highlighting customer reviews](../../assets/comparisons/reviews/trustpilot-logo-review-300x300.webp)](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/ TeamRetro is a strong ScatterSpoke alternative for agile retrospectives and team health. Where ScatterSpoke has no team health checks or radars, TeamRetro adds health-check models, radars, 200+ templates, AI grouping and SOC 2 Type 2 security on every plan. Teams usually move on from ScatterSpoke when retrospectives need to become a longer-term practice, not just a feed of AI summaries. ScatterSpoke concentrates on theme extraction and sentiment for engineering orgs already in Jira and Slack, but it has no health checks, team radars or mood tracking — so there's no way to see how a team is trending between retros. Its integrations stop at Jira, Slack and Teams, and proper SAML/OIDC SSO and SCIM only arrive on the Enterprise tier. The move across is light. There's nothing to migrate: you start your next retro from one of 200+ templates, invite the team by link, and carry any open actions forward so nothing gets dropped. Pricing is per team ($15–25), not a base fee plus per-seat charges, so the cost stays predictable as you add people. TeamRetro is SOC 2 Type 2 certified and GDPR compliant, with hosting in either the US or the EU. ScatterSpoke suits engineering orgs that already live in Jira and Slack and want AI to synthesize themes across many retros. TeamRetro is the better fit if retrospectives are a recurring ritual you want structured, measured and actioned — with health checks and radars showing how teams trend over time, not just what surfaced in the last session. It's a natural next step for growing teams that have [outgrown a free retro tool](/case-studies/big-give/) and want their reflections to build on each other. --- # Scru.ms Alternative with Health Checks URL: https://www.teamretro.com/compare/scrums-alternative/ TeamRetro is a trusted Scru.ms alternative built specifically for agile retrospectives and team health checks. It brings 200+ templates, automated grouping, action tracking, insights and SOC 2 Type 2 secure hosting together in one tool for scrum masters and agile teams. --- # Sprintlio Alternative — Health Checks URL: https://www.teamretro.com/compare/sprintlio/ TeamRetro is a modern Sprintlio alternative built specifically for agile retrospectives and team health checks. Where Sprintlio has no health-check models, scheduling or free plan, TeamRetro adds health checks and radars, scheduled retros, 200+ templates, AI grouping and SOC 2 Type 2 security. Most teams start looking for a Sprintlio alternative for one of two reasons. The first is signs of life: Sprintlio's homepage still carries a 2023 copyright, its last public product launch was back in 2019, and it no longer publishes a pricing page or changelog — so it's worth confirming the product is still actively maintained before you commit. The second is scope. Sprintlio is built around pushing action items into Jira and Slack, which it does well, but there's no free plan, no structured health-check models, no scheduling and little AI — a narrow toolkit by today's standards. Switching is light because there is nothing to migrate. You start your next retrospective from one of 200+ templates, invite your team by link, and carry any open actions forward so nothing gets dropped between sprints. Pricing is per team with unlimited members rather than per seat, so cost stays predictable as the team grows, and TeamRetro is SOC 2 Type 2 certified and GDPR compliant with US or EU hosting. Sprintlio still suits a small team that lives in Slack and Jira and wants lightweight retros where actions land back in the daily workflow — but given the quiet development signals, weigh continuity and support before you rely on it long term. TeamRetro is the better fit if retrospectives are a recurring ritual you want structured, measured and actioned over time. --- # 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: An Honest Comparison URL: https://www.teamretro.com/compare/teamretro-vs-parabol-vs-retrium/ **The short answer:** all three run a solid online retrospective. Pick **Parabol** if you want a genuine free tier or open-source self-hosting. Pick **Retrium** if you want a guided, retro-only tool with per-room pricing. Pick **TeamRetro** if health checks, action follow-through and enterprise security matter — SOC 2 Type 2 and SAML SSO on every plan, 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 July 2026. Where Parabol or Retrium is genuinely stronger, we say so. ## The three tools at a glance Facts as of July 2026, from each vendor's public pricing and feature pages. Pricing examples assume three teams of about eight people. | | 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, unlimited members — 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 bundle) | ~$192/month | ~$117/month | | **Retro templates** | 200+ | 40+ | 10+ (plus custom) | | **Health checks** | First-class: custom models, radars, trends, cross-team reporting | Emoji-style poll on paid plans | Team Radar with custom spokes | | **AI features** | Grouping, summaries, suggested actions, sentiment | Grouping, summaries, discussion prompts, insights | None | | **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 | ## Where each tool genuinely wins ### Parabol The only one of the three with an ongoing free tier, and the only one you can self-host — it's open source under AGPL-3.0. Backlog write-back to Jira, GitHub, GitLab, Azure DevOps and Linear is best-in-class, and its AI summaries and groupings are genuinely useful. Sprint Poker and async standups round out the ceremony stack. The trade-offs: team health is a single emoji-style poll — no radars or trend dashboards. SAML SSO and SCIM sit on the Enterprise tier only, and per-user pricing grows with every person you add. ### Retrium A battle-tested library of retro techniques with an opinionated five-phase flow that keeps discussions on track — a facilitator's tool first. Team Radar is a credible 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. The trade-offs: no free tier, no AI features at all, and integrations stop at Jira Cloud plus a beta Slack app. It's retro-only — no planning poker or estimation — and its public product updates last show new features in 2024. ### TeamRetro Health checks are a first-class module — custom models, radar charts, trend lines and cross-team reporting — not a poll bolted onto retros. 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. 200+ templates, AI grouping and summaries, and planning poker included. The trade-offs: no free tier — a 30-day trial, then a paid plan. No self-hosted option, and SCIM plus the full account-level API are Enterprise-only. ## Which should your team pick? **Choose Parabol if** you want a free or self-hostable tool. An engineering team living in GitHub, GitLab or Jira that runs light retros and doesn't need SSO below the Enterprise tier will get real value from the free tier alone. See the deeper two-way look at [TeamRetro vs Parabol](/compare/parabol-alternative/). **Choose Retrium if** you want a focused, retro-only tool with strong facilitation guardrails. If your facilitator values the five-phase structure, you live in Jira Cloud, and you don't need AI, estimation or a Microsoft-stack footprint, Retrium's per-room pricing is straightforward. 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 unlimited members. [Plans start at $25/month per team](/plans/), with a 30-day trial and no credit card required. --- # TeleRetro Alternative — Health-Check Radars URL: https://www.teamretro.com/compare/teleretro-alternative/ TeamRetro is a robust TeleRetro alternative for agile retrospectives and team health checks. Where TeleRetro offers pulse surveys but no team radars or SOC 2, TeamRetro adds health-check models and radars, AI grouping, 200+ 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. ### 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. 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 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. 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. ### 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. --- # 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. --- # 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, or estimation 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. Import the Jira issues you’re planning into a TeamRetro [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! --- # 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. --- # 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/ ### 1. Link your TeamRetro team with your Slack channel Find **Slack** under *Team* > *Settings* > *Integrations*. ### 2. Invite your team to join retrospectives or health checks Click “Post to #channel” in the invitation dialog. ### 3. 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. ### 4. 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. - Give everyone a chance to contribute in real time or asynchronously. - Ideas can be added to your retrospective at any time. - Run team health checks to get more insight and help the team work better together. - Get a high-level summary of participation, ideas, priorities, and actions that can be shared on Slack. - Enable Single Sign-On and SAML so people don’t have to remember yet another login. **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. --- # 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 — and still getting better — in a few years. 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, and agile estimation — 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. ### 26,000+ 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.9% 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. */} --- # 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 and estimation metadata, plus health models, to feed your reporting. ### Report exports Download CSV exports — 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 — summarize, chase actions, park topics — in natural language. 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 — every resource, filter and field — is at [developer.teamretro.com/docs](https://developer.teamretro.com/docs). ## Questions, answered --- # 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 — 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 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. --- # 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 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. --- # 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 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 — for example, "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. --- # 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 320 #### 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, and agile estimation, 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 ### 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 — Card's own surface would render dark-on-dark and be unreadable. */} ## Predictable pricing that scales with you From 5 to 5,000+ teams, our pricing adapts to your growth. Let us tailor a plan that fits your needs. Request a quote See 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 No, or limited AI capability
Team health checks Ready to go survey templates with trend history and radars Basic polling
## What teams are saying Trusted by enterprise teams to turn retrospectives into meaningful insights and actions at scale. Client Stories How 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 Stories How 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 Stories Helping 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 demo Talk 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, 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 estimates to Jira, Linear, GitHub, and your project tools, 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, and our roundup of the [best planning poker tools](/blog/best-planning-poker-tools-for-agile-teams/) compares the options — or [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. ### 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, 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. 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.

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 — no account, 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, Linear, and GitHub — 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. New to the practice? Our [team health check guide](/guides/team-health-check/) covers questions, cadence, and what to do with the scores. ### 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. {/* Live links to the dedicated feature page /health-checks/agile-maturity-assessment/. That page (hero + 13 templates + social proof) isn't migrated yet, so this points at the on-topic blog post as a stand-in. When the feature page is migrated, repoint this CTA there and add a redirect for /health-checks/agile-maturity-assessment/. */} 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 Browse health check templates ## You're in good company
--- # 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 templates Learn 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 ### 40+ 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. ### Run an icebreaker Create engagement from the very beginning. ### Check-in questions Focus the team before starting a survey. ### 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. ## Unlock team potential with data-driven insights 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. --- # 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. ## 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. Park an idea for the next retro the moment it comes up. ### 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. ### Park it before it's lost Captures the topic as a parked item the moment it comes up in conversation. ## 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. The endpoint is the same everywhere: ```text https://mcp.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 - Create and update actions, and park topics - 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. Requires a plan with API & MCP access. ## Questions, answered --- # 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 ## Questions, answered --- # 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 ## Questions, answered --- # 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 ## Questions, answered --- # 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 — 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 ## Questions, answered --- # 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 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. --- # Plans and pricing URL: https://www.teamretro.com/plans/ ## Our plans and features ## 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? Our [Scrum Master's retrospective guide](/guides/scrum-masters-retrospective-guide/) walks through 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 or 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. ## 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 a retrospective board in action Start from a ready-made template like the classic retrospective, then make it your own. See all retrospective features Explore retro templates See how TeamRetro compares ## 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 ### 200+ 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 a quick icebreaker or check-in question to set the mood, then keep everyone involved with roles, private voting and visual collaboration. ### Music ### Mentions ### Live reactions ### Quick poll ### Meeting feedback ### Quick and easy icebreakers Choose, create or get an AI suggestion… then spin to start! ### 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. ### 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, sentiment trends, team health and action tracking, all in one place. ### Meeting cadence Track meeting frequency and activity over time. ### Meeting sentiment Explore team and meeting sentiment based on topics. ### 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. --- # 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. {/* Featured product-board screenshot (matches the live hero media + caption). */} ## Drive continuous improvement with your team --- # 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 is SOC 2 Type 2 accredited for security, availability, confidentiality, and privacy. An independent auditor has evaluated our policies, product, platform, and infrastructure in accordance with the Standard on Assurance Engagements (ASAE 3150) and verified that TeamRetro complies with their stringent requirements.

## 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 data-centers and subprocessors located exclusively in EU member-state countries, with our primary services hosted in Frankfurt, Germany. #### 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 Our platform is PCI DSS compliant, ensuring secure handling of payment data with industry-leading protection and compliance measures. 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). 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 are frequently reviewed by our security team to identify anomalies. - 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. - 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 response 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 you have any questions or suspect an incident may have occurred, please contact [security@teamretro.com](mailto:security@teamretro.com). #### Downtime reporting Enterprise customers can elect to be notified of any problems via email. Our hosting platform usually obviates the need for downtime when we make changes to our services. However, we will notify customers by email at least 24 hours in advance of any planned downtime. #### 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. [![STAR-Level-1-badge-image](../../assets/security/index/STAR-Level-1-badge-1-1-150x150.png)](https://cloudsecurityalliance.org/star/registry/groupmap-technology/services/teamretro/) ## 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 state-of-the-art bcrypt 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 - We review our code for security vulnerabilities - 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. We are also warned when application components with known vulnerabilities are used in production (dependencies). #### Vulnerability scanning TeamRetro is scanned on a monthly basis, and after significant releases, by [intruder.io](http://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 logs are frequently reviewed by our security team to identify attempted unauthorized access. #### Our team’s access - Our strict internal procedure prevents any employee or administrator from gaining access to user data. We 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 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. Rewards are done at our discretion depending on the criticality of the vulnerability reported. 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@teamretro.com](mailto:security@teamretro.com). --- # Run daily stand-ups your team doesn't dread URL: https://www.teamretro.com/standups/ ### Keep the fifteen minutes Timeboxed by design, so the daily sync stays a sync — not a status meeting that swallows the morning. ### Stay in sync across time zones Post async in Slack, Teams or the browser, on your own schedule — no one waits on a meeting that doesn't fit their day. ### Surface blockers early Flag what's in your way the moment it appears, and track it to done instead of losing it in a thread. ## Most teams run a stand-up. Far fewer run one worth the fifteen minutes. The daily stand-up is meant to be a short sync — where the team lines up on the day and clears what's in the way. Too often it drifts into status theatre: a lap of the table, everyone reciting yesterday to the manager, no one really listening. [The difference is facilitation, not format](/guides/daily-standup-guide/). TeamRetro is a daily stand-up tool that gives the meeting a shape. Everyone answers the same prompts, the timebox holds, and a blocker becomes a tracked action with an owner — not a comment that scrolls away. Live or async, in the browser or in your chat tool, the meeting stays short and the follow-through outlasts it. ## Async stand-ups for teams that don't share a morning When your team spans time zones, a live stand-up just taxes whoever's awake at the wrong hour. Run it async instead — everyone answers the same prompts on their own schedule, and the summary is waiting when the next person logs on. You still get the sync, without the calendar collision. [See when async wins, and how to run one](/guides/daily-standup-guide/async-and-remote-standups/). ## Stand-ups where your team already works Bring the stand-up into [Slack](/integrations/slack/) or [Microsoft Teams](/integrations/microsoft-teams/). TeamRetro reminds the team to post, collects the responses against the same prompts, and drops a tidy digest back into the channel — so the update lives next to the work, not in another tab someone forgets to open. ## Timeboxed, so it stays a sync The fastest way to lose a stand-up is to start solving problems in it. TeamRetro keeps the meeting moving — one prompt at a time, a visible timebox, and a parking lot for the conversations that only need two people. Fifteen minutes in, everyone's aligned and back to work. [The facilitation moves that keep it tight](/guides/daily-standup-guide/how-to-run-a-daily-standup/). ## Blockers you can actually follow up A blocker mentioned out loud is a blocker forgotten by lunch. In TeamRetro, flagging one creates an action with an owner and a due date, carried across days until it's cleared — and pushed straight to [Jira](/integrations/jira/) if that's where your team works. Nothing falls through the gap between two stand-ups. ## Know who's waiting on whom Status is the least useful thing a stand-up produces. The gold is the handoffs — the API's ready but nothing ships until someone deploys it; design is stuck on a call only the PM can make. TeamRetro turns each "I need X from Y" into a dependency with both names on it, carried from one day to the next until it clears. So the person who's blocked and the person who can unblock them leave the *same* stand-up knowing it — instead of finding out on Thursday they'd each been waiting on the other since Monday. [Make dependencies part of the daily sync](/guides/daily-standup-guide/). ## You're in good company Thousands of teams — from Fortune 500s and banks to fast-moving startups — already run their retrospectives and health checks in TeamRetro. Stand-ups are the newest thing to bring into the same place. --- # 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. ### 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. ![](../../assets/blog/3-nifty-ways-to-keep-your-retros-fun-and-exciting/image1-1024x683.png)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) ![](../../assets/blog/3-nifty-ways-to-keep-your-retros-fun-and-exciting/image5-1-1024x768.png)![](../../assets/blog/3-nifty-ways-to-keep-your-retros-fun-and-exciting/image8-1-223x300.png) 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, or 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 set 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?” — it wouldn’t be an easy answer. 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. ## 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 — 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, not 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 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 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 often find this model maps directly to where the friction actually lives. ## 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 — 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. ## 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 — all in one place, with zero setup required. [Start your free assessment today](https://secure.teamretro.com/login/new) — 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 — and 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 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 — prompt templates, shared standards, 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 — prompt templates, 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 is [SOC 2 Type 2 accredited](/security/) and 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-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**: 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)** 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. - Use exercises like creating Team Agreements to establish norms for respectful and open communication. - Consider leveraging online retrospective tools 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. - 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. Our own team at TeamRetro is fully distributed, and 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. **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. 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. - **200+ 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 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. ## 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 — 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, 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 — confirm the current price on their site. ### 3. 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). ### 4. 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. ### 5. 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. ### 6. 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). ### 7. 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. ### 8. 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. ### 9. 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. ### 10. 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 | | **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, 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. ### 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 — 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, and Estimioo 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, no limits — or [see how estimation works in TeamRetro](/estimations/). --- # 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 — delivery, psychological safety, workload, and so on — 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 genuinely good at, and gives a clear best-for pick. We build one of these tools, so treat us as a party with a view — but the comparison below is written to be useful even if you pick someone else. Every competitor fact here was checked against the vendor's own live pages in July 2026; 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 health check platform built around exactly the loop above: anonymous rating, dimension-by-dimension discussion, trends across quarters, and actions tracked through to done. It ships 40+ 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 organisations running many teams, cross-team reporting rolls the picture up 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 — worth reading as marketing, not independent evidence.) ### Parabol — best open-source and check-in-style option Parabol is primarily an agile meeting tool — retrospectives, sprint poker estimation, standups, and check-ins. Its team health check runs as an anonymous check-in round, usually inside a retro, where people register mood and engagement, and it can track that mood over time. It is lighter than a dedicated multi-dimension health model, but it has one thing none of the others do: 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 want health as a light check-in inside their retros, or that need a self-hosted, open-source option. ### 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 framework — Spotify squad health check 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 to eleven 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, not instead of, a team health check. ## Comparison table | Tool | Type | Anonymous rating | Dimensions + trends | Action tracking | Pricing (as of July 2026) | Best for | | --- | --- | --- | --- | --- | --- | --- | | **TeamRetro** | Dedicated tool | Yes | 40+ models, team radar, trends | Owners + due dates, carried over | Free trial; paid plans per active user | 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 | Retro tool + check-in | Yes | Mood check-in, tracked over time | Via retro actions | Free up to 2 teams; Team $8/user/mo | Open-source / self-hosted, light check-ins | | 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) | ~11 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 want health as a light round inside retros, or need open source / self-hosting:** Parabol. 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 — as a complement to, not a replacement for, a team health check. ## 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, not HR. **What are the best team health check tools in 2026?** TeamRetro and Echometer for a dedicated agile tool; Parabol and Neatro for health inside retros (Parabol is the best open-source pick); 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.

--- # 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. ## 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 — 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. ## 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. 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) --- # 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) --- # 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 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! --- # The best retrospective tools for agile teams (2026) URL: https://www.teamretro.com/blog/find-the-best-tool-for-your-teams-agile-retrospective/ If you're choosing an online [retrospective tool](/retrospectives/), 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 **July 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** — SOC 2 and SSO start to matter the moment more than one team is involved. ### Retrospective tools at a glance | Tool | Best for | Pricing model | Free plan | Health checks | | --- | --- | --- | --- | --- | | **TeamRetro** | Retros, 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 | | **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 July 2026; plans change, so always check the vendor for current details. Here's each tool in more depth. ### 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 **The best all-rounder** — teams that want retros, health checks and estimation together in one secure tool, and expect to add more teams over time. 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 (200+) and a genuinely 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 - 200+ 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 Teams that want a simple, low-cost board with a big template library and a free tier to start. [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 Facilitators and coaches running structured, technique-led distributed retros where unlimited seats per team matter. [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. It integrates with Jira, GitHub, Azure DevOps, Slack, Microsoft Teams and Google Calendar. ### Top three features - Open-source, fully auditable codebase. - Retros, sprint poker and standups 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 Engineering teams that want open-source, self-hostable retros and estimation, billed only for active users. [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 Teams that want one flexible whiteboard for many activities, with retros as just one of them — not a dedicated retro workflow. [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 Small-to-mid teams that want a polished, facilitation-first retro at a low flat per-team price. [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 Scrum teams that want retros tied directly to sprint metrics. [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 Teams — especially in the EU — that pair retros with recurring team-health measurement and want German data residency. [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 Engineering leaders who want AI-synthesized insight across feedback, not just a retro board. [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 A small team or one-off retro on a tight budget — though note it doesn't appear to be actively developed. [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 A single team that wants a polished, engaging facilitated retro with health checks. [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 Teams that want AI features and Jira/Azure action tracking with a generous free tier. [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 A free, no-login throwaway brainstorm or retro board when guarantees don't matter. [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 Teams that want a visual, whiteboard-style retro canvas — though the repeated rebrands are worth weighing as a stability consideration. [Compare Metro Retro with TeamRetro](/compare/metro-retro-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 — check the vendor before you commit. ### What customers say No reviews available at the time of writing. ### Great for A lightweight, real-time retro for small teams. [Compare RetroTime with TeamRetro](/compare/retrotime-alternative/) in our side-by-side breakdown. ## Retrospected ### Overview Retrospected is open-source software (MIT-licensed) 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 Privacy-conscious or budget teams that want open-source, self-hostable control. [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. All pricing and features were verified against each vendor's site in July 2026. Details change over time — check the vendor for the latest. --- # 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, stand-ups, 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 and easy retrospective ideas for 2026 URL: https://www.teamretro.com/blog/fun-and-easy-retrospective-ideas/ A retrospective is the meeting where your team looks back at the last sprint — what went well, what didn’t — and agrees what to change next. Run well, retrospectives are the engine of a team’s improvement; run on autopilot, they become the meeting everyone quietly dreads. (New to running them? Start with our [Scrum Master’s guide to retrospectives](/guides/scrum-masters-retrospective-guide/).) Here we share simple and effective ways to keep your retrospectives fun and easy. From choosing the right [retro 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. 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) 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. The missing README it wished existed, the environment variable that wasn't documented, the brief that could have been read three ways — none of it carries to the next session unless something writes it down. 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 — 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 — this is the rule that makes it useful — **ends with a ticket-sized "→ Fix:"**. 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 — right beside your people, where a participant's feedback belongs. 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 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. ## 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) (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 stand ups 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=) 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://www.itproportal.com/features/life-in-lockdown-how-to-run-a-remote-retro/) from [Kelly Cook](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 tools 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=). --- # 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. ## 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. ### 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 tools 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 [t](/retrospectives/)[est drive a range of retrospectives](/retrospectives/) or sign up for a [free trial](https://secure.teamretro.com/login/new) (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 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 of which are 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—all 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 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—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) 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. > **⚡ 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. 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. ### 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. 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 — 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 — about the work, the team, or yourself — this sprint? 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 onboarding session. 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](/team-building-activities/) 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 is SOC 2 Type 2 accredited for Security, Confidentiality, Availability and Privacy. An independent auditor has evaluated our policies, product, platform, and infrastructure in accordance with the Standard on Assurance Engagements (ASAE 3150) and verified that TeamRetro complies with their stringent requirements. 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. --- # 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. ## 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-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 100+ 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! ### 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, use a classic such [https://giphy.com/](https://giphy.com/). Each person picks a gif and then shares their screens to explain why they picked that gif.