Why I prefer bigger story points in Scrum

When I first got into Scrum, story points seemed a bit mysterious. Why Fibonacci numbers? Why not just stick with hours or days? And if Fibonacci, why are we constantly hovering around the smaller numbers like 2, 3, or 5? After spending some serious time with Scrum, I’ve found myself leaning toward something a bit counterintuitive: bigger numbers are better. Yeah, I’m talking 8s and 13s, maybe even the occasional 21.

Now before you roll your eyes or think I’ve lost my mind, let me explain why I genuinely prefer working with larger story points and how it actually helps my teams.

Bigger numbers, bigger questions!

When you see a 13 on the board, it immediately triggers the alarm bells in your mind. “Whoa, why is this so big?” And that reaction is exactly the point. Bigger numbers demand clarity. They force the team to pause and start asking questions. Is the story really this big or are we missing something? Is it truly a single story, or can it be broken down?

Contrast this with smaller numbers like 2 or 3. We often end up just shrugging and saying, “Well, I thought it was a 2, but sure, let’s make it a 3.” That’s easy, comfortable, and unfortunately, doesn’t always help the team gain clarity or sharpen their understanding.

The difference in complexity between 8 and 13 is much clearer than the difference between 3 and 5. Use that!

Clearer lines, better conversations

Here’s the truth: clarity is king. Bigger numbers provide clear lines in the sand. When a team member picks 13, it’s not just a number, it’s a statement. It signals potential risk, uncertainty, or complexity. It sparks important discussions that smaller numbers often don’t.

I’ve noticed that smaller numbers blend together too easily. It’s tempting to treat 2s and 3s as interchangeable. But that interchangeability can mean skipping over subtle but crucial differences. When you’re dealing with bigger numbers, you can’t just ignore the details. You have to get specific. That specificity often leads to smarter decisions and, ultimately, better products.

Encouraging better breakdown

Another huge advantage of bigger points is that they naturally encourage breaking stories down into manageable chunks. Think about it: faced with a 13, the immediate instinct of most teams should be to see if we can split it into smaller, clearer pieces.

By starting larger, we end up with well-defined, truly manageable tasks. These smaller pieces aren’t just random splits; they’re genuine subdivisions of the original story, each with its own clear value and deliverable outcome. This prevents scenarios where we break down tasks just for the sake of smaller numbers, without genuinely understanding or adding clarity to the work.

But you still need to remember an important point here: broken tasks still need to be valuable and usable. If you break the UI part of a task that is just a component with a button that does nothing, you are not delivering anything and you should notice that in the details of the story itself.

The feature can be insignificant, but not useless.

Avoiding the false comfort of small numbers

There’s a psychological comfort in smaller numbers. They feel safe, manageable. But that sense of comfort can sometimes be deceptive. Small numbers give us the illusion of precision. We feel confident, even when there might still be unanswered questions hiding beneath that 3.

Big numbers don’t let us hide. They force conversations about risks and unknowns. They prevent us from falsely assuming everything’s fine and instead make sure we face reality head-on.

Practical advice for teams

If you’re going to try this approach, here’s how I suggest you start:

• Be intentional about choosing bigger story points initially. It might feel odd at first, but it’ll get better.

• Whenever you encounter an 8 or a 13, stop and discuss. Ask the hard questions: why is this big? What don’t we know? Can we split this? Should we split it? Maybe 13 is a good number for it anyway.

• Encourage everyone to speak up. Make these discussions about clarity and understanding rather than rushing to consensus.

I’ve found that over time, this practice genuinely makes our estimations more accurate, our stories clearer, and our sprints smoother. And hey, isn’t that exactly what we’re aiming for in Scrum?

---

So, next sprint planning, give it a shot. Go bigger, and watch how quickly your team starts producing clearer, better-defined work. Trust me, you’ll wonder why you ever spent so much time sweating over whether something was a 2 or a 3.