DEV Community: Matt Lewandowski

I Built a Microservice Name Generator Because Naming Things Is Hard 🤖🌱

Matt Lewandowski — Wed, 25 Feb 2026 18:52:14 +0000

There are two hard problems in computer science: cache invalidation, naming things, and off-by-one errors.

I've made peace with cache invalidation. Off-by-one errors? I'll get to those eventually. But naming microservices? That one haunts me.

You know the feeling. It's 10 AM. You've got a fresh service to build. The architecture is clear, the tickets are groomed, you're ready to go. Then someone asks: "What are we calling it?"

And suddenly it's 11:30 and your team is in a heated Slack thread debating whether email-sender is too generic and outbound-notification-delivery-service is too long.

I got tired of this, so I built a thing.

The tool

Microservice Name Generator. You describe what your service does, pick a naming style, and it gives you 5 names with README descriptions ready to copy-paste.

That's it. That's the tool.

But the fun part is how the names get generated.

Two modes for two moods

I built two naming styles because sometimes you're feeling creative and sometimes your architect is watching.

Fun & creative

This is the one I actually use. You type "a service that sends emails" and instead of getting email-service like some kind of animal, you get names like:

Hermes, the Greek messenger god. Obviously.
Pidgeot, the carrier pigeon Pokemon. Tell me that's not perfect for a delivery service.
Paul Revere, the original "one if by land, two if by sea" notification system.

The prompt behind this mode pulls from mythology, pop culture, video games, history, all of it. I told the AI to think laterally. Don't just describe what the service does, find a clever reference that connects to it.

Each name comes with a README description that sounds like it was written by a developer who is way too enthusiastic about their service name:

> The swift messenger of your application stack.

**Hermes** handles all outbound email delivery with the grace
and speed of the Greek messenger god himself. Whether it's
transactional notifications or bulk campaigns, Hermes ensures
your messages reach their destination without getting lost
in the underworld.

I'm not going to pretend that's not delightful.

Professional & enterprise

For when you need to keep it boring. Sorry, "enterprise-grade."

This mode generates names like srv-outbound-emails and api-user-auth. Kebab-case, prefixed, scannable in a service registry. Your platform team will love it. The README descriptions read like internal documentation because, well, they are.

I included this mode because I know not everyone gets to name their service "Cerberus" at work. But they should.

Copy-paste ready

One thing I was adamant about: the output has to be immediately usable. Every name comes with a copy button that grabs the markdown README description. There's also a "Copy All" button if you want to dump all five into a doc and let your team vote.

No reformatting. Generate, copy, paste into your repo, done.

Go name your services

The tool is free: kollabe.com/tools/microservice-name-generator

Go generate some names. Send the weird ones to your team's Slack. Name your next service after a Greek god. Life's too short for svc-data-processor-v3.

What's the best (or worst) microservice name you've ever seen at work? Drop it in the comments. I collect these like Pokemon cards.

Your Team's Icebreakers Shouldn't Make People Cringe 😬

Matt Lewandowski — Wed, 18 Feb 2026 20:17:21 +0000

You know the moment. Someone shares their screen, pulls up a list of icebreaker questions, and reads: "If you were a kitchen appliance, what would you be and why?"

Half the team goes on mute. One person nervously laughs. Someone types "toaster" in the chat and hopes that counts as participation.

I've sat through so many bad icebreakers that I almost gave up on them entirely. But then I started running retros regularly and noticed something I didn't expect -- the meetings where we skipped the icebreaker were consistently worse. Not because the question itself mattered, but because nobody had spoken yet. And when people don't talk in the first five minutes, they tend to stay quiet the whole time.

So the issue isn't icebreakers. It's that most of them are terrible.

Why most of them miss

They're either too weird, too generic, or wrong for the room.

"What's your spirit animal?" might be fine with close friends. In a Monday morning standup with people you've known for two weeks, it just creates silence. "How was your weekend?" isn't really an icebreaker at all -- it's small talk everyone already had in Slack. And a goofy question before a serious retro about a failed sprint? Tone-deaf.

I think the mistake people make is treating icebreakers like a box to check instead of thinking about what the meeting actually needs. A retro needs people in a reflective headspace. A casual sync just needs people awake and willing to talk. Those are different questions.

What I've seen work

I run retrospectives and team meetings through Kollabe, so I've watched a lot of teams try different approaches over the past year. Some patterns keep showing up.

Keep it to five minutes. Go around, everyone answers in a sentence or two, done. The icebreaker is the on-ramp, not the meeting.

Let people pass. This sounds minor but it changes everything. The moment someone feels forced to answer, the whole exercise backfires. Say "feel free to skip" and, ironically, almost nobody does.

Rotate who picks the question. When the same scrum master picks the icebreaker every single week, it starts feeling like their thing rather than a team thing. Some of the best icebreakers I've seen came from the quietest person on the team, given the chance.

And match the energy. Light questions for regular syncs. Reflective ones for retros. Professional but warm for cross-team meetings where half the people don't know each other. This is the part most people skip, and it's the part that matters most.

The real reason they work

I keep coming back to this: icebreakers aren't about fun. They're about getting voices in the room early.

There's actual research behind this. When someone speaks in the first few minutes of a meeting, they're more likely to contribute for the rest of it. Remote teams feel this the hardest. In an office, you had the hallway chat, the coffee run, the "hey did you see that PR?" as you sat down. Remote meetings just... start. You go from solo deep work to a group video call with zero transition.

An icebreaker is that transition. It doesn't have to be clever. "What's the last thing you watched that you'd recommend?" does the job.

Coming up with them every week gets old

I'll be honest -- this is the annoying part. You want to do an icebreaker, but it's Tuesday night and you're trying to think of one that isn't too cheesy, isn't too personal, and isn't the same one you used three weeks ago. It takes longer than it should for something that lasts two minutes.

I built an Icebreaker Generator because I got tired of this exact loop. Pick the meeting type, pick the tone -- fun, thoughtful, professional -- and it spits out questions that actually fit. You can add a theme too if your team has a thing. It's free and takes about ten seconds.

Whether you use it or not, the point stands: spend thirty seconds picking a question that matches your meeting, and you'll get better participation out of the other fifty-nine minutes.

(If you're also in goal-setting mode because review season never really ends, I wrote about making SMART goals less painful too.)

Some that actually land

I've tested a lot of these. A few that consistently get good responses:

For regular team meetings: "What's something small that made your week better?" Low stakes, easy to answer, and you actually learn something about people.

For retros: "One word to describe this sprint." Sets the reflective tone without being heavy.

For meetings with new faces: "What's your role in one sentence, and one thing about your work people might not know?" Gives context and a conversation starter.

For Fridays: "What are you looking forward to this weekend?" Simple. Gets people mentally out of work mode before the meeting even ends.

None of this is complicated

That's sort of the whole point. Icebreakers don't need to be creative or clever or carefully workshopped. They need to get people talking before the real agenda starts. Two minutes, one question, everyone speaks. The meetings where that happens go better than the ones where it doesn't.

Pick something that fits the room, keep it short, and let people opt out. That's the whole strategy.

Best Free Retrospective Tools for 2026 🏆

Matt Lewandowski — Thu, 12 Feb 2026 19:53:40 +0000

Most retro tools have a free tier. Very few of them are actually usable past your second sprint.

I've been running retros for six years across teams of 4 and teams of 40. The pattern is always the same: you sign up, run a solid first retro, and then hit the wall. Board limits. History caps. Features locked behind a paywall that somehow only unlocks at the "Business" tier. The free plan was never a product — it was a demo with extra steps.

So I went through the retro-specific tools that exist right now (not whiteboards like Miro or MURAL that happen to have retro templates) and evaluated their free plans based on what actually matters: can you run a recurring retro with your team without constantly bumping into limits?

Here's where things stand in 2026.

1. Kollabe

The all-in-one that doesn't charge per seat.

Kollabe bundles retros, planning poker, and async standups into a single platform. The retro side is where it shines — AI grouping that actually understands context (it'll cluster "our deploys take forever" with "CI pipeline needs work" without you touching anything), 1,000+ templates, and a drawing tool for the inevitable person who communicates exclusively through diagrams.

Key features:

AI grouping with semantic similarity — not just keyword matching
AI-generated summaries with customizable instructions
Anonymous mode with mixed anonymous + attributed cards
Inline polls on retro items (added February 2026)
1,000+ templates plus an AI template generator
Action items with Jira, GitHub, Linear, and Azure DevOps export
Themed retros with 30+ backgrounds
PDF, Markdown, CSV, JSON, and Confluence export
Guided facilitation with customizable phases

What's in the free plan:

Included	Limit
Participants per room	Up to 10
Retro history	7 days
Templates	All 1,000+
AI grouping	Yes
AI summaries	Yes
Anonymous mode	Yes
Voting	Yes
Planning poker issues	10 per session
Data export	No
Permission management	No

The 10-participant cap is fine for most scrum teams. The 7-day history is the real friction point. If your team doesn't discuss action items within a week, they're gone. No Slack or Teams integration on any plan either, which is a real gap if your team lives in Slack.

Best for: Small teams who want retros, poker, and standups in one place without paying per head.

2. Parabol

Open source and used by teams at Netflix and GitHub.

Parabol's the only tool on this list where you can read every line of the source code on GitHub. It's AGPL-licensed with 2,000+ stars and 85 contributors. That matters if your org has opinions about vendor lock-in or data ownership.

The retro flow is well-designed. Four guided phases (Reflect, Group, Vote, Discuss) with each step timeboxed. AI auto-names grouped topics and generates meeting summaries, though those are limited on the free plan: 3 AI summaries total, and no AI grouping.

Key features:

Step-by-step guided facilitation (Reflect > Group > Vote > Discuss)
40+ built-in retro templates with custom template builder
AI meeting summaries posted to Slack automatically
Sprint poker with Jira/GitHub/GitLab ticket import
Async standups with customizable questions
Team health checks (paid plans only)
Action items carry over between meetings automatically
Integrations: Jira, GitHub, GitLab, Slack, Teams, Linear, Azure DevOps

What's in the free plan:

Included	Limit
Users	Unlimited
Teams	Up to 2
Meetings per month	10
Meeting history	30 days
Custom templates	2
AI summaries	3 total
AI grouping	No
Health checks	No
SSO/SAML	No

Unlimited users is a big deal. Most free tiers cap you at 5-10 participants. But 10 meetings per month will bite you fast if you're running retros, poker, and standups across two teams. That's maybe 4-5 meetings per team per month, tight for a biweekly sprint cadence. The 30-day history is more forgiving than Kollabe's 7 days.

Best for: Engineering teams that value open source and want guided facilitation out of the box.

3. EasyRetro

The one that's been around since 2015 and does exactly one thing.

EasyRetro (originally FunRetro) doesn't do poker. Doesn't do standups. Doesn't do health checks. It makes retro boards, and it's been quietly doing that for over a decade while other tools pivot and rebrand every eighteen months.

200+ templates, real anonymity (participants don't need accounts), and the Jira export is mature enough that it handles bulk card export as of late 2024. They added AI board summaries in early 2024. No AI grouping though, so you're still dragging cards into clusters manually.

Key features:

200+ retro templates with custom board builder
True anonymous participation — no signup required for board members
AI-generated board summaries
Card drawing, GIFs, and emoji reactions
Dot voting with per-column or per-board limits
Presentation mode for revealing columns one at a time
Export to PDF, CSV, PNG, Excel, Confluence
Jira and Trello action item export
Password-protected boards
8 languages supported

What's in the free plan:

Included	Limit
Boards on dashboard	1 at a time
Boards per month	1
Participants per board	Unlimited
Templates	All 200+
Surveys	1 per month
Teams	None
Exports	No
Integrations	No
Analytics	No

Here's where EasyRetro's free plan gets honest. One board. Not one board per sprint. One board total on your dashboard. You have to delete it before creating another. No exports, no integrations. For a one-off retro with a new team or a workshop, it works. As a recurring tool, you'll hit the wall fast.

Best for: Teams that want a simple retro board and nothing else, or occasional facilitation where one board at a time isn't a problem.

4. GoRetro

Sprint management that's wider than just retros.

GoRetro goes wider than just retro boards. There's a sprint capacity calculator, Jira-based sprint monitoring, and a "Joker Cards" feature that auto-generates discussion prompts from your sprint data. The happiness index tracks team mood over time, which is basic but useful if you're an SM who reports up to leadership.

The retro board itself is solid. 34 templates, anonymous mode, configurable voting. No AI grouping. GoRetro's marketing mentions a "meeting recap" feature but competitor comparison pages call it out as not being a true AI summary. I couldn't verify it either way. Take the claim with some salt.

Key features:

34 retro templates plus custom board builder
Happiness index tracking across sprints
Joker Cards — auto-generated discussion prompts from sprint data
Planning poker with Jira backlog import (paid plan only)
Sprint capacity calculator (paid plan only)
Facilitated icebreakers with random question generation
Action items with owner assignment, due dates, and email notifications
Jira integration (import and export)
Slack integration for action item sharing (paid plan only)

What's in the free plan:

Included	Limit
Teams	1
Public boards	5
Users	Unlimited
Templates	All 34
Anonymous mode	Yes
Voting	Yes
Action items	Basic
Exports	No
Planning poker	No
Slack integration	No

Five public boards and unlimited users is reasonable for a small team on biweekly sprints. You'll burn through those five boards in ten weeks though, and there's no clear info on whether old boards count against the limit after archiving. No exports on free, so your retro data lives in GoRetro or nowhere.

One flag: GoRetro's public changelog hasn't been updated since May 2023. The product is still active and selling, but the pace of visible development has slowed.

Best for: Scrum masters who want sprint-level analytics and mood tracking alongside their retros.

5. Neatro

Guided retros with built-in health checks and ROTI.

Neatro is a small Canadian team (three people, bootstrapped) that built a retro tool around structured facilitation. Every retro follows four steps: Collect, Group, Vote, Action Plan. There's no freeform canvas. No infinite whiteboard. Just a guided workflow that keeps your retro on track.

The things that set Neatro apart are features other tools charge for or don't have at all. Team Radars (health checks) are a standalone feature, not just a retro template you repurpose. ROTI surveys run at the end of every retro automatically. And the action plan auto-surfaces incomplete items from previous retros, which kills the "did we actually do that?" conversation at the start of every session.

Key features:

4-step guided workflow (Collect > Group > Vote > Action Plan)
Team Radars — standalone health check surveys
ROTI (Return on Time Invested) survey after each retro
30+ built-in templates plus Neatroverse community gallery
Icebreaker Question Game with 200+ questions
Async retros — collect feedback throughout the sprint
Auto-surfacing of incomplete action items from past retros
Action item export to Jira, GitHub, Azure DevOps, Asana, Monday.com
Long-term analytics with recurring theme identification
PDF and CSV reports

What's in the free plan:

Included	Limit
Teams	1
Members per team	Up to 10
Retros	Unlimited
Team Radars	Unlimited
Templates	All (built-in + custom)
Retro history	30 days
Integrations	No
Exports	No
ROTI	Yes
Icebreakers	Yes

Honestly a solid free plan. Unlimited retros and health checks with a team of 10. No board caps, no meeting limits. The 30-day history and no-export restrictions are the usual tradeoffs, and the 10-member cap means larger teams are out. No AI features at all. Whether that matters depends on how many cards your team generates per retro. Under 30? Manual grouping is fine. Over 50? You'll want AI.

Best for: Facilitators who want structured retros with health tracking and don't need AI.

Quick Comparison

Tool	Free Plan Limit	AI Features	Guided Flow	Extra Ceremonies	Integrations (Free)
Kollabe	10 users, 7-day history	Grouping + Summaries	Yes	Poker, Standups	None
Parabol	10 meetings/mo, 30-day history	3 summaries only	Yes	Poker, Standups	Jira, GitHub, Slack
EasyRetro	1 board at a time	Summaries only	Partial	None	None
GoRetro	5 boards, 1 team	None confirmed	Partial	None on free	None
Neatro	10 members, 30-day history	None	Yes	Health Checks	None

Which One Should You Actually Use?

There's no best free retro tool. There's the one that annoys you least within its constraints.

Kollabe gives you the most raw functionality on free: AI grouping, poker, standups, the works. The 7-day history means you need to act on things fast, but for a team under 10 it's hard to beat.

Parabol is the pick when open source matters or you need Slack and Jira integration without paying. Watch that 10-meeting monthly cap though. It sneaks up on you.

EasyRetro is the path of least resistance for one-off retros. No signup for participants. But one board at a time makes recurring use painful.

GoRetro works well for scrum masters who want sprint analytics and mood tracking alongside their retros. Five boards gets you ten weeks. After that, you're paying.

Neatro is quietly the most generous for pure retro usage. Unlimited retros, unlimited health checks, a real guided workflow. No AI, but not every team needs it.

All five of these tools are banking on you outgrowing the free plan. That's fine. It's a business model, not a conspiracy. Just know what the upgrade costs before you get your team hooked.

Your User Stories Are Too Big 🎯🤯

Matt Lewandowski — Wed, 04 Feb 2026 18:43:51 +0000

It's sprint planning day. Someone pulls up a ticket called "Implement user authentication" and the room goes quiet.

The story has been sitting in the backlog for three sprints. Nobody wants to estimate it because everyone knows it's going to blow up. The last time you tried to tackle something this size, it turned into a two-week death march that ended with the story getting split mid-sprint anyway.

Large user stories are planning poison. They hide complexity, resist estimation, and turn your sprint board into a graveyard of half-finished work.

The problem with big stories

When a story is too large, a few predictable things happen:

Planning poker turns into guessing. You throw out an 8, someone else says 13, a third person suggests breaking it down. Twenty minutes later, you've compromised on "we'll figure it out" and moved on.

Work bleeds across sprints. The story gets started but not finished. It carries over. Then carries over again. Your velocity charts start looking like modern art.

Hidden complexity surfaces at the worst time. Day three of the sprint, someone discovers an edge case that doubles the scope. Now you're cutting corners or cutting scope, neither of which feels good.

What good splitting looks like

A well-split story should pass a simple test: can a user actually do something with it?

"Create database schema for users" is not a good split. It's a technical task disguised as a story.

"User can register with email" is better. Someone can use it. You can demo it. It delivers actual value.

The trick is finding the right seam to cut along. Sometimes that's workflow steps. Sometimes it's data types. Sometimes it's complexity levels (basic case first, edge cases later).

Splitting strategies that actually work

By workflow: If your story involves multiple steps, each step might be its own story. "User can upload a profile photo" and "User can crop their profile photo" are both independently useful.

By data variation: If your story handles different types of input, split by type. "User can import from CSV" and "User can import from Excel" can ship separately.

By complexity: Start with the happy path. "User can reset password via email" ships first. "User can reset password via SMS" comes later.

By user type: "Admin can view reports" and "Team lead can view reports" might have different requirements worth separating.

The tool I built for this

I got tired of staring at massive stories trying to figure out where to cut them. So I built a Story Splitter that does the thinking for you.

Paste in your oversized story, add some context about your project if you want, and it generates sub-stories with acceptance criteria. Takes about 30 seconds.

It's free. No signup required.

When not to split

Not every story needs splitting. A story that fits comfortably in a sprint with clear acceptance criteria should stay whole. Over-splitting creates its own overhead: more tickets to track, more PRs to review, more standups where someone says "still working on that tiny thing."

The goal is stories your team can estimate with confidence, build within a sprint, and demo to stakeholders. If you're already there, leave it alone.

Smaller stories, better sprints

Better story sizing fixes problems upstream. Estimates get more accurate. Work actually finishes. The board moves in a way that feels real instead of theatrical.

Next time you're staring at a monster ticket nobody wants to touch, try breaking it down first. Your sprint planning sessions will thank you.

SMART Goals Don't Have to Be a Chore 🎯

Matt Lewandowski — Tue, 03 Feb 2026 00:00:55 +0000

It's review season again. Your manager sends the dreaded message: "Please submit your goals for next quarter by Friday."

You open a blank doc. You stare at it. You write "get better at system design" and immediately delete it because you know that's going to get sent back with "can you make this more specific?"

We've all been there.

The problem with most developer goals

Most engineers I've worked with fall into one of two camps.

The first group writes goals that are too vague. "Improve my technical skills." "Be a better communicator." "Learn more about the codebase." These sound reasonable until you try to figure out if you've actually done them.

The second group goes too ambitious. "Become an expert in Kubernetes, GraphQL, and machine learning while also mentoring three juniors and leading the platform migration." By March, you've quietly abandoned all of it.

Vague goals are impossible to track. Impossible goals just make you feel bad. Neither helps.

SMART goals, minus the corporate nonsense

You've probably heard of SMART goals. The framework has been around since the 80s and gets trotted out in every management training ever. Most explanations make it sound more complicated than it is.

Here's what actually matters:

Specific means spelling out what you're going to do. "Learn TypeScript" becomes "Convert the authentication module from JavaScript to TypeScript."

Measurable means knowing when you're done. "The auth module passes all existing tests with strict TypeScript config enabled."

Achievable means being honest about your workload. If you're heads-down on a major feature, maybe converting one module is more realistic than rewriting the entire service.

Relevant means the goal actually helps your team or your career. Converting that auth module might not matter if your team is pivoting to a different language anyway.

Time-bound means setting a deadline. "By end of Q2" is better than "eventually."

What this looks like in practice

Here's a real goal I set for myself last year:

Complete the AWS Solutions Architect certification by March 31st by studying 5 hours per week and passing at least 3 practice exams with scores above 80%.

Compare that to what I might have written before:

Learn more about AWS.

The first version told me exactly what I needed to do each week. The second version would have let me watch one YouTube video and technically claim progress.

Making this less painful

The actual writing is the annoying part. You know what you want to achieve, but translating that into corporate-acceptable goal format takes longer than it should.

I built a SMART Goal Generator for exactly this reason. You describe what you want to accomplish, and it structures it properly with all the SMART criteria plus action steps. It's free and takes maybe 30 seconds.

But whether you use a tool or write them yourself, the important thing is having goals you can actually track. Review season is a lot less stressful when you can point to concrete accomplishments instead of hand-waving about how you "definitely grew as an engineer."

A few tips from trial and error

Break annual goals into quarters. A 12-month goal is hard to track. "Get promoted" is a year-long ambition, but "complete the tech lead shadow program by Q1" is something you can actually work toward.

Update goals when reality changes. If your project pivots or you realize a goal was unrealistic, change it. A modified goal beats an abandoned one.

Pick fewer goals than you think you need. Three focused goals beat eight scattered ones. You'll actually finish them, which matters more than having an impressive-looking list.

Connect them to something you care about. "Learn GraphQL because my manager said so" has a much lower completion rate than "Learn GraphQL because I want to build a side project that uses it."

The actual point

Goals aren't about impressing anyone during your performance review. They're about making sure you're working on things that matter to you and can articulate what you've accomplished when the time comes.

The SMART framework isn't magic. It's just a checklist that keeps you honest. The important thing is that when next review season rolls around, you have something concrete to show for your time.

Friday = Retro Day 🍻📈

Matt Lewandowski — Thu, 29 Jan 2026 22:28:05 +0000

Every week we see the same thing. Friday afternoon hits and retro activity spikes across Kollabe.

Makes sense when you think about it.

The sprint's still fresh. You actually remember why that one ticket took three days instead of one. And there's something about Friday energy that makes people more willing to be honest before they clock out.

I think there's also something satisfying about heading into the weekend knowing your team actually talked about what worked and what didn't. Loose ends tied up. Slate cleaned.

If you're lucky, you can crack open a drink while you do it. Retros don't have to feel like a performance review. Some of the best ones happen when people are relaxed and just... talking.

For teams running one today

Keep it tight. 30-45 mins max.
Walk away with one or two things you'll actually do, not a list of 15.
Talk about the wins too, not just the fires.

What day does your team usually run retros? Curious if Friday is as common as our data suggests or if we're just seeing a certain type of team.

Happy Friday 🍻

It's 2026. Why Are Teams Still Playing Planning Poker? ♣️

Matt Lewandowski — Wed, 28 Jan 2026 19:26:46 +0000

I run Kollabe, a free planning poker tool. We've got around 70,000 users using it every month. And I keep getting the same question from people outside the agile world: why are developers still doing this?

It's a fair question. We have AI that can estimate tickets now. We have historical data. We have tools that can look at a codebase and make educated guesses about complexity. So why are smart people still sitting in a virtual room holding up cards with numbers on them?

I've talked to a lot our users users about this. The answer aligned pretty well with my own experiences.

The number isn't the point

Here's what most people get wrong: nobody actually cares if a ticket is a 3 or a 5. The velocity math works out either way over time.

What matters is what happens when someone votes 3 and someone else votes 8.

That gap is where the value lives. Because now you have a conversation. "Wait, you think this is an 8? What am I missing?" And then someone mentions the legacy payment system this ticket touches. Or the API that's being deprecated next month. Or the fact that QA is going to need three days with this one because of some edge cases the ticket doesn't mention.

That information was locked in someone's head. The vote forced it out.

AI can't fix this

I get pitched constantly on AI estimation features. "Let us analyze your tickets and predict story points." And look, we've built some AI stuff into Kollabe. It's useful for certain things.

But AI can't tell you that your tech lead gets twitchy every time someone mentions the auth module. It doesn't know that the DevOps guy is on vacation next week and he's the only one who understands the deployment pipeline for that service. It hasn't been in the meeting where someone said "we'll clean that up later" two years ago and never did.

Your team has context. They have history. They have opinions about what's actually going to happen when this code hits production. Planning poker is just a structured way to get that stuff out of their heads.

What actually surfaces in these conversations

I've asked a lot of teams what they learn during estimation that they didn't know going in. Same themes keep coming up:

Dependencies nobody wrote down. "Oh, that needs the inventory team's API? They're doing a migration right now."

Scope that seemed obvious but wasn't. "Does user authentication include the SSO flow, or just email and password?"

Landmines in the codebase. Someone who's been around a while will just know that a particular file is fragile, or that a certain pattern has caused problems before.

Experience gaps. Sometimes a junior dev will vote low because they found a simpler approach. Sometimes they'll vote low because they don't know what they don't know. Either way, you want to find out before day three of the sprint.

The ritual matters too

There's something else going on here. Planning poker is a ritual, and rituals have value.

It's dedicated time where everyone focuses on the same thing. It creates a weird kind of psychological safety because you're not arguing with your lead directly - you're just revealing a card. You can disagree without it feeling like a confrontation.

For remote teams especially, these synchronous moments matter. It's easy to lose shared understanding when everyone's async all the time.

So yeah, it's 2026

Teams are still playing planning poker. They'll probably still be playing it in 2030.

Not because the story points are magic. Not because we haven't invented something better. But because the conversation that happens when two people disagree about a number is genuinely useful, and we haven't found a way to automate that.

The point was never to get the estimate right. The point was to have the conversation that helps you avoid getting it catastrophically wrong.

The Art of Better One-on-Ones

Matt Lewandowski — Sun, 25 Jan 2026 19:53:46 +0000

Most one-on-ones start the same way: "So... how's everything going?"

And most responses are equally predictable: "Fine. Busy, but fine."

Then you both sit there, trying to fill the next 25 minutes.

Why One-on-Ones Matter

One-on-ones should be the most valuable meeting on your calendar. They're where trust gets built, where problems surface before they explode, and where people actually feel heard.

But without intention, they become status updates that could've been a Slack message. Or worse, they get cancelled because "nothing urgent came up."

The difference between a great one-on-one and a forgettable one usually comes down to one thing: the questions you ask.

What Makes a Good Question

Good one-on-one questions share a few traits:

They're open-ended. "Are you doing okay?" gets a yes or no. "What's been on your mind lately?" opens a door.

They're specific enough to be useful. "How's the project?" is vague. "What's the biggest risk you see with the timeline?" gives someone something concrete to respond to.

They signal that you care. Questions like "What's something you're proud of that I might not know about?" show you're interested in more than just deliverables.

They create space for honesty. "Is there anything I could be doing differently to support you?" invites feedback that people might not volunteer otherwise.

Questions Worth Asking

For building trust:

What's something on your mind that we haven't talked about?
Is there anything you've been hesitant to bring up?
How are you feeling about work lately, really?

For career growth:

What skills do you want to develop this quarter?
Where do you see yourself in a year? Does your current work align with that?
What's a project or responsibility you'd love to take on?

For removing blockers:

What's slowing you down right now?
Is there a decision you're waiting on that I could help with?
What's one thing that would make your day-to-day easier?

For feedback (both directions):

What's one thing I could do differently as a manager?
Is there feedback you've been wanting to share but haven't found the right moment?
How do you prefer to receive feedback?

Context Changes Everything

The questions you ask depend heavily on who you're meeting with. A skip-level conversation is different from a direct report check-in. Meeting with your own manager requires a different approach than meeting with a peer.

A new team member needs questions focused on onboarding and clarity. A senior engineer might benefit more from questions about autonomy and long-term growth.

A Tool That Can Help

If you're ever stuck on what to ask, there's a free one-on-one question generator that can help. It works for engineering managers, product managers, or really any manager running 1:1s.

You select the context (direct report, your manager, skip-level, peer), choose a focus area, and it generates tailored questions using AI. You can even add additional context about your specific situation to get more focused suggestions.

Use it before your meeting to prep, or pull it up during the conversation when you want to go deeper. No signup required.

Making It a Habit

The best one-on-ones aren't about having perfect questions every time. They're about showing up consistently, being genuinely curious, and creating a space where real conversation can happen.

A few principles that help:

Protect the time. Cancelling signals that it's not a priority.
Let them drive. The best 1:1s are owned by the other person, not you.
Skip the status updates. You have other channels for that.
Follow up. If someone shares something important, remember it next time.

The Real Goal

At the end of the day, one-on-ones are about connection. They're a chance to understand what someone is dealing with, what they care about, and how you can help.

The questions are just a tool to get there.

What questions have worked well in your one-on-ones? Always looking for new ones to try – share yours in the comments.

Planning Poker Integration for Linear 🃏

Matt Lewandowski — Thu, 22 Jan 2026 03:45:41 +0000

Planning poker sessions just got a major upgrade for Linear users! If you're tired of manually copying story points from your planning sessions back to Linear, or struggling to keep your team's estimates in sync with your actual issues, I've got some exciting news for you.

The Problem Every Agile Team Faces

We've all been there: you run a fantastic planning poker session, get great estimates from the team, and then... someone has to manually update every single issue in Linear. It's tedious, error-prone, and honestly, a bit soul-crushing when you're dealing with large backlogs.

What if I told you there's a way to make this entire process seamless, automated, and actually enjoyable?

Meet the Integration

Kollabe's Planning Poker integration with Linear has completely transformed how teams handle sprint planning. This isn't just another basic integration – it's a full-featured solution that bridges the gap between collaborative estimation and issue management.

What Makes This Integration Special?

🔍 Smart Search & Filtering

Gone are the days of manually creating cards for every issue. You can:

Search your Linear issues directly within the planning session
Filter by project, cycle, status, labels, or assignee
Import exactly the issues you need with a few clicks
Pull in your current or upcoming sprint in seconds

🎯 Automatic Estimate Syncing

This is where things get really exciting. The integration uses your team's configured estimation scale in Linear:

Estimates sync back using the exact scale your team already uses
No manual mapping or configuration required
Support for whatever estimation approach your team prefers

⚡ Real-Time Automatic Syncing

Here's the magic moment: when your team reaches consensus and reveals the votes, the winning estimate automatically syncs back to Linear. No manual copying, no forgotten updates, no discrepancies between your planning session and your backlog.

You'll even see a visual indicator confirming the sync was successful – it's those little touches that make the experience feel polished and reliable.

🔄 Full Workflow Integration

But wait, there's more. The Linear integration extends to retrospectives too:

Export action items from retros directly to Linear with one click
Those exported issues can then be imported into your next planning poker session
Your agile ceremonies actually feed into each other now

The Developer Experience You've Been Waiting For

Setting up this integration takes minutes, not hours. The OAuth flow is smooth, the interface is intuitive, and the whole experience feels like it was built by developers who actually use planning poker regularly.

Linear is built for modern software teams who value speed and simplicity. This integration matches that philosophy perfectly.

Real Impact on Team Productivity

Since implementing this integration, teams report:

50% reduction in time spent on administrative tasks after planning sessions
Zero estimation discrepancies between planning sessions and Linear
Higher team engagement during planning (no one's worried about the manual cleanup afterward)
Better sprint tracking with estimates that actually reflect team consensus

Getting Started

The setup process is refreshingly straightforward:

Connect your Linear account through secure OAuth
Select your team to configure the estimation scale
Search and import issues using the built-in filters
Start planning – estimates sync automatically!

Why This Matters for Modern Development Teams

In an era where developer experience and team efficiency are paramount, tools like this represent the evolution of agile practices. We're moving beyond "good enough" integrations toward solutions that genuinely enhance how teams work together.

This integration doesn't just solve a technical problem – it removes friction from one of the most important collaborative activities in software development.

Try It Yourself

Ready to experience planning poker the way it should be? Check out the detailed setup guide and see how this integration can transform your team's sprint planning process.

Your future self (and your team) will thank you for making the switch to automated, seamless planning poker sessions.

Have you tried this integration? What's been your experience with planning poker tools? Drop a comment below – I'd love to hear how different teams are approaching sprint planning in 2026!

5 Tools That Make Daily Standups Actually Async

Matt Lewandowski — Sat, 10 Jan 2026 23:14:36 +0000

Daily standups sound great in theory. In practice? They turn into calendar clutter. Half the team is still waking up, someone's in a different timezone, and by the time you're done, 15 minutes have vanished and nobody remembers what was said.

Async standups fix this. Instead of synchronizing schedules, team members drop their updates whenever it works for them. No more "sorry I'm late" or awkward silences while someone unmutes.

Here are the best tools for making the switch.

Why Async Standups Work Better

Quick context before the list:

Timezone-friendly: Distributed teams don't need to find that impossible overlapping hour
Respects deep work: No interrupting flow states for a meeting
Written record: Everything's documented automatically
Thoughtful updates: People can actually think before they type

The trade-off is you lose some spontaneous conversation. But let's be honest—most standup chatter is just "still working on the thing I mentioned yesterday."

1. Kollabe

Kollabe stands out for its AI-powered approach to async standups. Instead of manually reading through every team member's update, managers get an auto-generated summary highlighting key wins, blockers, and focus areas.

Key features:

AI summaries generated daily, weekly, or fortnightly
Per-group summaries for larger orgs (engineering gets engineering context, design gets design context)
Persistent daily rooms—no meeting creation required, just show up and post
Rich media support with image and video uploads
Customizable questions with color coding and emoji prefixes
Comments and reactions on updates
Bulk export to CSV, JSON, or PDF

Free plan:

Included	Limit
Team size	15 users
AI summaries	Full access
Media uploads	Images + video
History	7 days

Best for: Teams who want intelligent insights without manual effort. The AI summaries are genuinely useful for managers juggling multiple projects.

Try the demo

2. Geekbot

Geekbot lives entirely inside Slack and Microsoft Teams. It DMs team members at scheduled times, collects responses, and posts them to a channel. Zero context switching if your team already lives in chat.

Key features:

Native Slack and Teams integration
Conversational AI queries ("what did Sarah work on last week?")
Timezone-aware scheduling
Pre-built templates
Anonymous reporting option
Participation analytics

Free plan:

Included	Limit
Team size	10 users
Features	Everything
Platforms	Slack + Teams

Best for: Teams deeply embedded in Slack or Teams who don't want another tool in the stack.

3. Standuply

Standuply's differentiator is video and voice standups. Instead of typing, team members record short clips—up to 5 minutes. Adds a human element that text-only tools miss.

Key features:

Video and voice standup submissions
Text standups also supported
Deep integrations with Jira, Trello, GitHub
Built-in retrospective tools
Agile workflow templates
Acts as a virtual scrum master

Free plan:

Included	Limit
Team size	3 users
Features	Basic only
Trial	30 days full access

Best for: Teams who want face-to-face energy in async format, or need tight PM tool integration. Note the free tier is very limited—it's essentially a trial.

4. DailyBot

DailyBot goes beyond standups into full team engagement—kudos, mood tracking, icebreakers, wellness checks. Standups are one piece of a larger platform.

Key features:

Async check-ins and standups
Peer recognition (kudos)
Team mood tracking over time
Icebreakers and watercooler prompts
Works on Slack, Teams, Discord, and Google Chat
SOC2 Type II compliant

Free plan:

Included	Limit
Features	Basic check-ins + kudos
Platforms	All supported

Paid: $1.60/user/month (very affordable)

Best for: Teams who want culture-building features bundled with standups. Can feel like overkill if you just want simple status updates.

5. Range

Range positions itself as a complete team sync platform. Check-ins sit alongside meeting management, goal tracking, and team directories.

Key features:

Async check-ins with mood sharing
Daily icebreaker prompts
Meeting agendas and notes
Goal and OKR tracking
Team directory
Integrations with Asana, GitHub, Jira

Free plan:

Included	Limit
Users	12
Teams	2
Trial	14 days Pro

Best for: Teams wanting standups plus goals plus meetings in one place. Private check-ins (manager-only visibility) require paid plan.

Quick Comparison

Tool	Best For	Free Users	Standout Feature
Kollabe	AI-powered insights	15	Auto-generated summaries
Geekbot	Slack/Teams natives	10	Conversational queries
Standuply	Video/voice updates	3	Recorded standups
DailyBot	Team engagement	Limited	Kudos + mood tracking
Range	Full team sync	12	Goals + meetings

How to Choose

Feature lists aside, here's what actually matters:

Where does your team already work? If everyone's in Slack, a Slack-native bot reduces friction. If people use multiple tools, a standalone web app might be cleaner.

How big is your team? Free tiers vary wildly. Check the limits before you commit.

Do you need insights or just collection? Some tools just gather updates. Others surface patterns and blockers automatically. Managers with multiple teams benefit most from AI summaries.

What's your async maturity? Teams new to async might want simpler tools. Veteran remote teams can handle more sophisticated features.

Bottom Line

Async standups aren't about abandoning team connection—they're about respecting that connection doesn't require everyone being online simultaneously.

Any of these tools beats the calendar invite that half the team skips anyway.

Optimizing JSON for LLMs

Matt Lewandowski — Thu, 08 Jan 2026 00:39:18 +0000

If you're building AI-powered features, you're probably sending a lot of JSON to language models. And if you're sending a lot of JSON, you're probably burning through tokens faster than you'd like.

At Kollabe, we use AI to generate summaries, action items, and suggestions for retrospectives and standups. When you have dozens of team members submitting updates daily, the JSON payloads get large quickly. We needed ways to shrink our data without losing information.

There are newer formal solutions out there like TOON (Token-Oriented Object Notation) that can compress JSON for LLMs by up to 40%. It's a proper spec with benchmarks and SDKs. Worth checking out if you want a standardized approach.

But sometimes you want to stay in control. You don't want another dependency. You want to understand exactly what's being sent to the model and tweak it for your specific use case. These are the simple tricks we use to cut down token usage without adding complexity.

1. Replace Long IDs with Short Ones

UUIDs are everywhere. They're great for databases, but terrible for token efficiency.

// This UUID is 4-5 tokens
"550e8400-e29b-41d4-a716-446655440000"

// This is 1 token
"u-1"

When you're referencing the same user across hundreds of standup entries, those extra tokens add up fast.

The solution: build a simple mapping as you process your data. First user you encounter becomes u-1, second becomes u-2, and so on. If you see the same UUID again, reuse the short ID you already assigned.

// Before: UUIDs everywhere
{
  odUserId: "550e8400-e29b-41d4-a716-446655440000",
  odQuestionId: "7c9e6679-7425-40de-944b-e07fc1f90ae7",
  odAnswerId: "f47ac10b-58cc-4372-a567-0e02b2c3d479"
}

// After: short, prefixed IDs
{
  uid: "u-1",
  qid: "q-1", 
  aid: "a-1"
}

The key insight is that the same UUID always maps to the same short ID. So when the LLM sees u-1 multiple times across different answers, it understands those entries belong to the same person. Use different prefixes for different entity types so the model can distinguish between a user ID and a question ID.

2. Drop the Formatting

JSON.stringify has a second and third parameter that most people forget about. The third one adds indentation:

// Pretty printed (wasteful)
JSON.stringify(data, null, 2);

// Minified (efficient)
JSON.stringify(data);

The difference looks like this:

// Pretty: ~80 characters
{
  "name": "Alice",
  "role": "Engineer",
  "team": "Platform"
}

// Minified: ~45 characters
{"name":"Alice","role":"Engineer","team":"Platform"}

For small objects, whatever. For thousands of standup entries? That whitespace adds up. LLMs don't care about formatting anyway.

3. Use Shorter Key Names

This one feels obvious once you think about it. Compare:

// Verbose
type StandupEntry = {
  odUserId: string;
  userName: string;
  yesterdayUpdate: string;
  todayPlan: string;
  blockerDescription: string;
};

// Concise
type StandupEntry = {
  odUid: string;
  name: string;
  yesterday: string;
  today: string;
  blocker: string;
};

When you have hundreds of entries, shorter keys save real tokens. Just keep them readable enough that the LLM can understand the context.

A few rules we follow:

Drop redundant words: userId becomes id if it's clearly a user object
Use common abbreviations: desc instead of description
Keep it unambiguous: y for yesterday is too cryptic, but yest works fine

4. Remove Null and Empty Values

Don't send data that doesn't exist:

function removeEmpty<T extends object>(obj: T): Partial<T> {
  return Object.fromEntries(
    Object.entries(obj).filter(([_, v]) => {
      if (v === null || v === undefined) return false;
      if (v === "") return false;
      if (Array.isArray(v) && v.length === 0) return false;
      return true;
    })
  ) as Partial<T>;
}

// Before
{
  "name": "Alice",
  "blocker": null,
  "tags": [],
  "notes": ""
}

// After
{
  "name": "Alice"
}

If someone didn't report a blocker, why tell the LLM about it?

5. Flatten Nested Structures When Possible

Sometimes nesting is just organizational overhead:

// Before
{
  "user": {
    "profile": {
      "name": "Alice",
      "team": "Platform"
    }
  },
  "update": "Finished feature"
}

// After
{
  "name": "Alice",
  "team": "Platform",
  "update": "Finished feature"
}

The second version conveys the same information with fewer structural tokens. Obviously don't flatten things if the hierarchy carries meaning, but often it doesn't.

6. Use Arrays Instead of Repeated Objects

If you have a list of similar items, consider whether you need the full object structure for each:

// Before: 3 objects with repeated keys
{
  "entries": [
    { "name": "Alice", "status": "done" },
    { "name": "Bob", "status": "blocked" },
    { "name": "Carol", "status": "done" }
  ]
}

// After: header row + data rows
{
  "cols": ["name", "status"],
  "rows": [
    ["Alice", "done"],
    ["Bob", "blocked"],
    ["Carol", "done"]
  ]
}

This trades some readability for efficiency. For large datasets, it's worth it.

7. Strip Unnecessary Metadata

Timestamps, audit fields, and internal IDs often aren't needed for AI processing:

// Before: full database record
{
  odAnswerId: "f47ac10b-58cc-4372-a567-0e02b2c3d479",
  odUserId: "550e8400-e29b-41d4-a716-446655440000",
  text: "Great sprint!",
  createdAt: "2024-01-15T10:30:00.000Z",
  updatedAt: "2024-01-15T10:30:00.000Z",
  isDeleted: false,
  version: 1
}

// After: just what the LLM needs
{
  uid: "u-1",
  text: "Great sprint!"
}

Ask yourself: does the model actually need this field to generate a useful response? If not, drop it.

8. Represent Booleans Efficiently

For boolean flags, consider whether you even need the field when it's false:

// Before
{ "name": "Alice", "isAdmin": false, "isActive": true, "isVerified": false }

// After: only include truthy flags
{ "name": "Alice", "active": true }

// Or use a flags array for multiple true values
{ "name": "Alice", "flags": ["active", "verified"] }

If most users aren't admins, don't include isAdmin: false on every record.

Putting It All Together

Here's a before and after from a real retrospective summary we generate at Kollabe:

Before optimization:

{
  "retrospectiveData": {
    "questions": [
      {
        "odQuestionId": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
        "questionText": "What went well this sprint?",
        "questionType": "positive"
      },
      {
        "odQuestionId": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
        "questionText": "What could be improved?",
        "questionType": "negative"
      }
    ],
    "answers": [
      {
        "odAnswerId": "1b9d6bcd-bbfd-4b2d-9b5d-ab8dfbbd4bed",
        "odQuestionId": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
        "odUserId": "550e8400-e29b-41d4-a716-446655440000",
        "userName": "Alice Chen",
        "answerText": "Team collaboration was excellent during the release",
        "createdAt": "2024-01-15T10:30:00.000Z",
        "voteCount": 3
      },
      {
        "odAnswerId": "6ec0bd7f-11c0-43da-975e-2a8ad9ebae0b",
        "odQuestionId": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
        "odUserId": "6ba7b810-9dad-11d1-80b4-00c04fd430c8",
        "userName": "Bob Smith",
        "answerText": "CI/CD pipeline improvements saved us hours",
        "createdAt": "2024-01-15T10:32:00.000Z",
        "voteCount": 5
      },
      {
        "odAnswerId": "3f333df6-90a4-4fda-8dd3-9485d27cee36",
        "odQuestionId": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
        "odUserId": "550e8400-e29b-41d4-a716-446655440000",
        "userName": "Alice Chen",
        "answerText": "Documentation was often outdated",
        "createdAt": "2024-01-15T10:35:00.000Z",
        "voteCount": null
      }
    ]
  }
}

After optimization:

{"qs":[{"id":"q-1","text":"What went well this sprint?","type":"positive"},{"id":"q-2","text":"What could be improved?","type":"negative"}],"ans":[{"id":"a-1","qid":"q-1","uid":"u-1","name":"Alice Chen","text":"Team collaboration was excellent during the release","votes":3},{"id":"a-2","qid":"q-1","uid":"u-2","name":"Bob Smith","text":"CI/CD pipeline improvements saved us hours","votes":5},{"id":"a-3","qid":"q-2","uid":"u-1","name":"Alice Chen","text":"Documentation was often outdated"}]}

What changed:

UUIDs replaced with short IDs (q-1, a-1, u-1)
Long key names shortened (odQuestionId to qid, answerText to text)
Removed wrapper object (retrospectiveData)
Dropped null values (no voteCount: null)
Removed timestamps (not needed for summary generation)
No whitespace formatting

The optimized version is roughly 50% smaller. When you're processing retrospectives for a 50-person team with hundreds of answers, that's a meaningful reduction in token costs and faster inference times.

When to Optimize

Not every JSON payload needs this treatment. If you're sending a small config object or a single user query, the overhead of optimization isn't worth it.

But when you're building features that process large amounts of structured data, like we do with retrospective and standup summaries at Kollabe, these tricks make a real difference. They're simple to implement, don't require external dependencies, and give you immediate wins.

There's also something to be said for staying in control of your data pipeline. When you write your own optimization layer, you understand exactly what's happening. You can tweak the short ID prefixes, decide which fields to drop, and adjust the strategy as your data evolves. No black boxes.

The best part? LLMs handle optimized JSON just fine. They don't need pretty formatting or verbose key names to understand your data. They just need the information.

Oh and one last shameless plug: if you work on an agile dev team, check out my free planning poker and retrospective tool called Kollabe. We use all these tricks to power our AI summaries.

A Halloween Retrospective 🎃

Matt Lewandowski — Thu, 30 Oct 2025 10:14:13 +0000

Let's be honest. Running the same "What went well? What didn't?" retrospective format sprint after sprint gets stale. Your team shows up, adds a few cards, and you move on. No energy. No engagement. Just another meeting.

But what if your next retro could actually be... fun?

Kollabe's Halloween Retrospective template

Why Themed Retros Work

Here's the thing about retrospectives: they're only as good as the participation you get. When people are engaged, they share more honest feedback. When they're bored, you get surface level responses that don't move the needle.

Themed retros break the monotony. They give people permission to be creative, have fun, and think differently about the same problems. And right now? Halloween season is the perfect excuse to try something new.

The Halloween Retrospective Format

Instead of your standard columns, try this spooky twist:

🕸️🎃 Spooky Successes
What treats and triumphs haunted your sprint? This is your "what went well" but with way more personality.

👻🕷️ Ghoulish Glitches

What scares and missteps gave you chills? Your "what went wrong" column, but it sounds way less harsh.

🧙♀️🪄 Witchy Wishes
What spells can you cast to improve the next sprint? Your action items, but now you're conjuring solutions instead of just "noting concerns."

How to Run It

Start with a Halloween icebreaker. Ask everyone to share their favorite spooky movie or their worst Halloween costume. Gets people loosened up and talking.
Set the mood. Use Halloween emojis, GIFs, whatever. Make it visually fun. The more playful the board looks, the more people engage.
Fill out the columns. Give everyone 5 minutes to add their cards. Encourage emoji use. Make it weird.
Group and vote. Cluster similar items together, then vote on the top priorities. Democracy, but spooky.
Turn wishes into action. Take your top voted items and create actual action items with owners and deadlines. This is where the magic happens.

The whole thing takes 45 to 60 minutes, works great for teams of 5 to 12 people, and honestly? It's just more fun than your standard retro.

Try It Yourself

If you want to run a Halloween retrospective (or any themed retro) without building it from scratch, check out Kollabe's Halloween Retrospective template. It's got the board already set up, includes ice breakers, and has AI features to help group similar items and summarize discussions.

No signup required to start. Just create a room, share the link, and you're ready to go.

Final Thoughts

Retrospectives should drive continuous improvement. But if your team dreads them, they won't. Themed retros are a simple way to inject energy back into a ceremony that often becomes stale.

Try a Halloween retro this month. See what happens when you make reflection fun instead of formulaic.

What's the most creative retrospective format you've tried? Drop it in the comments. Always looking for new ideas.