DEV Community: Matt

5 million planning poker votes later: the most common card is 3 🃏

Matt — Fri, 22 May 2026 22:25:15 +0000

You know the moment. Everyone's picked a card, the host hits reveal, and you find out whether your team is roughly aligned or about to spend ten minutes arguing about whether a ticket is a 3 or a 5.

I run Kollabe, so I had a lot of those reveals to look at: 5,055,407 votes across 165,510 planning poker sessions. Anonymised, counted, no story-point opinions of my own attached.

The headline finding is almost boring, and that's what makes it interesting. The cards barely matter.

The most common estimate on the planet is 3. It shows up in about a quarter of all votes. Add 1, 2, 5 and 8 and you've covered roughly four out of five estimates. The giant Fibonacci cards, 34, 55, 89, almost never get touched. Teams think small.

Everyone defaults to Fibonacci. A third quietly rebuild it. Fibonacci is the deck you get when you open a room, so its 60% share is partly just inertia. The real tell is the runner-up: about 31% of sessions run a fully custom deck, more than pick any other preset. And the single most popular custom deck? 1, 2, 3, 5, 8, 13. Fibonacci with the zero and the big numbers chopped off. It's the most engineer thing imaginable. Keep the scale, delete the cards you never use.

The coffee card gets played more than 13. The little "I need a break" cup shows up in 4.3% of all votes, ahead of 13 and every t-shirt size. Someone plays it in roughly one round in eight, and 3,634 rounds officially ended on it. I have cast that card mid-session more than once, so no judgement here.

Teams agree on the first vote about 1 in 6 times. Only 16.6% of rounds come up unanimous on the reveal. The average round has more than two different numbers on the table. That gap isn't a failure of the process. It is the process.

The rest of the breakdown, with charts for decks, days of the week, integrations and consensus, is here: Planning Poker Statistics 2026.

A rule of thumb I've started repeating: if your reveals are always unanimous, you're not estimating, you're rubber-stamping. The disagreement is where the useful conversation lives. If it never happens, the cards are theatre.

Fair caveat: this is data from teams who chose Kollabe, so it leans toward people who like running quick, low-ceremony poker. But five million votes is enough that the shape holds. Small numbers dominate, and almost nobody wants a 55-point card.

If you want to run a round this week, Kollabe poker is free and needs no signup. Or open whatever you already use and check: how often does anyone actually pick a number above 13?

I gave Claude six months of our retros. It found three things I'd missed.

Matt — Mon, 18 May 2026 05:45:10 +0000

There's a thing PMs do that nobody puts on a job description. Every couple of weeks, after a retro, you flag three or four items in your head as things to watch. Then a sprint goes by. Then another. Three months later you're in a leadership review, somebody asks "is X getting better or worse?", and you answer from gut feeling because there's no time to read 12 retros before the meeting.

The retros are sitting there. The data is fine. The labour of reading them isn't.

I work on Kollabe, so take this with the appropriate grain of salt. The patterns generalise; if your retro tool exposes an API or an MCP server, the workflow below works against whatever you've got. I'll keep the prompts vendor-shaped so they're easy to swap.

What I changed

For the last two months I've been driving most of my retro-adjacent work through Claude with three MCP servers connected: Kollabe (for the retro and action-item surface), Atlassian (for Jira), and GitHub. The Kollabe MCP exposes about 50 tools that map 1:1 to the public REST API, so anything I can do in the UI, Claude can do as me. That includes reading every retro and action item in the spaces I have access to.

The Monday-morning workflow is one prompt. It does four things in order, then stops and waits for me.

Reads the last 26 weeks of retros across the spaces I own.
Pulls every open action item, including ones quietly older than the people who created them.
Reads the last sprint's standups for additional signal.
Writes a structured brief: what's getting better, what's getting worse, what action items are stale, and a one-line "here's what I'd ask the team about this week."

Then it shuts up and lets me think.

The action item half: the part that quietly fails

Here's the embarrassing thing nobody says out loud about retros: most action items don't close because they fall out of working memory. The retro happens, somebody writes "investigate flaky CI", it gets assigned, two sprints pass, the person who owned it changed teams, and the item is technically open in the tool forever. Read a clean dashboard of "open action items" on most teams and you'll find the median age is something like 47 days.

The fix isn't a better tracker. The fix is somebody reading every open action item once a week and asking three questions: is it still relevant, did it actually get done quietly, who really owns it now.

I have Claude do that. The prompt is short:

For each space I own, use `action_item_list` (status = PENDING).
For every item older than 21 days:
1. Use `search` (Kollabe MCP) to look for activity on the item's keywords across
   retros, standups, and Jira via the Atlassian MCP — last 30 days.
2. If the item appears resolved or superseded, propose marking it COMPLETED with
   a one-line note explaining what closed it.
3. If the assignee changed spaces or hasn't been active in standups for >14 days,
   flag it for reassignment.
4. Otherwise, propose a one-sentence nudge comment from me, via
   `action_item_create_comment`.
Show me a table. Wait for me to approve each row before any writes.

It produces a table. Most weeks, I approve about 80% of it and reject the rest. The rejected ones are the most interesting. They're items the AI thought were resolved but I know aren't, which usually means we have an undocumented decision that should become a docced one.

Two months in, the median action-item age in our spaces is 14 days, not 47. Nobody had to nag anyone. Nobody had to build a dashboard.

The six-month delta: the part that's new

This is the bit I underestimated when I wired it up. The Kollabe MCP has a search tool that runs semantic search across every retro, standup, action item, and round in your spaces, backed by pgvector embeddings. Faster-than-scrolling isn't really the point. The point is the questions you'd never have asked because the labour wasn't worth it.

What I ask, every Monday, in the same prompt:

Using the Kollabe MCP `search` and `retro_list` + `retro_get`, scan the last
26 weeks of retros in my spaces. Produce:

1. The five themes that appeared in the first 3 months but have NOT appeared
   in the last 6 weeks. (Things that quietly got fixed.)
2. The five themes that have appeared in 3+ retros over the last 6 weeks
   and weren't a problem 6 months ago. (Things that quietly got worse.)
3. Any theme that appeared, was resolved, and has come back.
4. Two questions worth asking the team this week given (1) - (3).

The first time I ran it, the AI surfaced three things that genuinely surprised me. One was a fix I'd forgotten the team had quietly made. The deploy flow had been a chronic complaint for the first quarter and had simply stopped being a complaint, which meant somebody's January work had paid off and I hadn't thanked them for it. One was a slow drift in code review wait times, too quiet to feel like a problem in any single retro, obviously a problem when you saw three retros in a row mention it without escalation. The third was a recurring frustration about meeting overload that had been resolved once and was creeping back.

It was uncomfortable. It was also the most useful single data point I'd gotten about my team in a year. I sent the dev who fixed deploys a public kudos that afternoon.

Why MCP and not "I'll just build a script"

I work on this stuff for a living and I have, in fact, built the script version. It works. It is also rigid: every time I want to ask a slightly different question, I edit code. The MCP version lets me write the question in English on Monday morning and have it run against the same API surface my Python script would have used.

The thing that makes this real, not a parlour trick, is that the public API and the MCP server are the same surface. Every MCP tool is registered against a /api/v1/* handler, with the same Zod schemas and the same access checks. So when I prototype something in chat that turns out to be useful weekly, I can lift the same calls into a scheduled Worker, run it Friday at 4pm, and email myself the brief. The prompt and the script share an interface.

That matters for technical PMs specifically. You're going to want to graduate the things that worked into something that runs without you. With an MCP that mirrors a real REST API, you can — without translating between two surfaces or waiting for a vendor to ship Zapier support.

The honest caveats

A few:

It works to the depth of your retro content. If your team writes "deploy bad" as a retro item, the search and summary surfaces are not going to mine wisdom out of that. The first thing it convinced me of was that we needed better retro write-ups. We added a templated "what happened, who was affected, what changed" body to two columns. The signal jumped a month later.
Semantic clusters are smart, not psychic. The AI will sometimes group two superficially-similar items that are actually about different things. A CI complaint and a release-process complaint, say. I read the cluster headers, not just the takeaway.
The action-item triage prompt makes writes. Always. I've never let it write without a per-row approval step. The day I trust it to update without me is the day it'll mark an unresolved compliance item as fixed because somebody mentioned the word "fixed" in a tangent. The prompt stays in the "propose then wait" shape.

A rule of thumb you can steal

If you're a PM who feels like the data exists but the labour doesn't, here's the question to ask before you build anything:

What's the question I'd ask my team if I'd just spent two hours reading the last six months of retros?

Write that question down. That's your weekly prompt. If your retro tool has an MCP server or a public API with semantic search, you can have an AI do the reading and bring you back the question's answer with citations. If it doesn't, that's a procurement question. The next generation of agile tooling is going to assume an AI is reading the history, not just a human.

I run my version on Monday at 9am. Whatever your version is, time saved isn't really the win. The win is questions asked that weren't being asked.

If you want to try this against Kollabe's MCP, the connection takes about a minute and is included on Premium plus all trials. The MCP page has the OAuth flow and a one-click setup. If you want the script version, every tool I mentioned is also a documented REST endpoint, same auth, same shape.

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

Matt — 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 — 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 — 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 — 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 — 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 — 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 — 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 — 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 — 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 — 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.