What 1,000 Trello Teams Taught Me About Estimation

1,000 boards in

EstiMate quietly crossed 1,000 active Trello boards last week. I wasn't planning to write about it, partly because milestone posts always feel a bit self-congratulatory, and partly because the number itself doesn't actually mean that much. What I think is more interesting is what those teams have taught me along the way.

A bit of context first. "Active" here means a board that someone actually opened in the last month - not just installed once and forgotten. The teams using it are spread across more than 60 countries, which I genuinely did not expect. The top 5 in order: USA, Brazil, France, Germany, UK. Brazil being second still throws me off a little.

Beyond the counts, I'm not going to walk you through behavioural analytics. I want to share what I've learned from emails, support threads, and watching how the conversations around estimation actually play out. Four things keep coming up.

1. Most teams aren't doing pure scrum

If you read the agile literature, you'd think every team is running two-week sprints with a Scrum Master, a Product Owner, daily standups, and a sprint review followed by a retrospective. Almost nobody I've talked to actually does all of that.

Trello users in particular tend to land somewhere between scrum and kanban. They borrow the parts they like - sprints, story points, maybe a burndown chart - and quietly skip the parts that feel like overhead for their team size. A lot of them don't even call what they do "scrum."

For a long time I thought this was a problem to solve. People not following the framework correctly. Now I think it's just how good teams work. The frameworks were built for a specific kind of organisation, and not every team needs all the ceremony. If you're four people building a product, you probably don't need a Scrum Master. You need a way to agree on what to build next and how big it is. That's mostly what estimation gives you.

2. There's no "right" estimation scale

The single most common question I get is some version of: "should we use Fibonacci, T-shirt sizes, hours, or something else?"

My honest answer, after a lot of these conversations, is that the scale matters far less than people think. What matters is that everyone on your team uses the same one and means roughly the same thing by it. A team that consistently uses 1, 2, 3, 5, 8 will get better at estimating over a few sprints. So will a team that uses XS through XL. So will a team that just uses days.

The teams that struggle aren't the ones who picked the "wrong" scale. They're the ones who keep changing it, or where two devs interpret a "5" completely differently. Pick something. Calibrate it together with a few reference cards. Stick with it for a quarter before you decide to change anything.

If you want a deeper dive on this, I have a guide on story point estimation that walks through how to calibrate.

3. The social value beats the numerical one

This one took me a while to see clearly. Most product copy around estimation tools (mine included, in earlier versions) talks about velocity, forecasting, capacity, and other numerical outputs. The chart you can show your boss.

But when I read what teams actually write to me about, the value is somewhere else. It's in the conversation that happens during estimation. Two devs disagree about whether a card is a 3 or an 8, and that disagreement surfaces something nobody had thought about - a hidden dependency, an assumption about scope, a part of the codebase one of them knows is fragile. The estimate isn't really the point. The discussion is.

This is also why planning poker is so popular even though, on paper, it's a slower way to assign numbers to cards. The slowness is the feature. Independent voting forces everyone to commit before being influenced, and the disagreements that follow are where the actual learning happens.

4. Teams that start small are the ones that stick around

The pattern I've seen most consistently in successful adoption: people start with one board and a handful of cards. They estimate a single sprint, see whether it lines up with reality, then keep going.

The teams that try to roll out estimation across every board, configure every setting, and get everyone trained on Fibonacci before sprint one, often quietly drop it after a few weeks. Too much process, too early. The teams that stick around are the ones that let the practice grow with them.

Which is also a useful product reminder for me. The instinct is always to add features and surface them upfront. The reality is that most users want a small number of features that work well, with the rest available when they're ready.

What's next

1,000 active boards is a nice number, but it's also a starting point more than a finish line. The Power-Up is about to be featured in the Trello marketplace soon, which will probably bring a wave of new teams who have never used a dedicated estimation tool before. I'm spending most of my time right now making sure the first-run experience is good for them.

If you're one of the people whose feedback or questions ended up shaping this list, thank you. Most of what I've built was someone's email first.