But here's what happened when they spoke to another development shop the week before: "Well, we estimate this at about 400 story points, and our velocity is typically 25 points per sprint..."

The client interrupted. "But when will it be done?"

"Well, that depends on our velocity and whether the team maintains consistent story point completion rates..."

You can probably guess how that conversation ended.

Don't get me wrong—I respect the traditional Scrum approach. Story points, Fibonacci sequences, relative estimation—these tools emerged from smart people solving real problems. The idea of comparing user stories against each other, sizing them relatively rather than absolutely, makes perfect sense when you're dealing with the inherent uncertainty of software development.

But somewhere along the way, we started treating these tools as ends rather than means. We got so focused on perfecting our point systems that we forgot why we were estimating in the first place: to answer that fundamental question of "when will it be done?"

The truth is, when a client has 90 days to launch their application—maybe it's tied to a marketing campaign, or a trade show, or a regulatory deadline—telling them "it's 400 story points" provides exactly zero practical value. What does that number mean to someone trying to run a business?

At Full Stack, we've taken a different path. We estimate in hours, not points.

I know what you're thinking—hours are harder to estimate, more prone to error, more likely to create false precision. You're not wrong. But here's what I've learned after years of this approach: the discomfort of hour-based estimation is actually a feature, not a bug.

When a developer has to say "this will take 8 hours," they're forced to think concretely about the work. They can't hide behind the abstraction of a story point. They have to consider not just the complexity, but the actual steps, the potential obstacles, the integration points.

More importantly, it creates a shared language between our team and our clients. When we say a project will take 600 hours, and we're putting two developers on it working 35 productive hours per week, everyone in the room can do the math. That's roughly 8.5 weeks. Add some buffer for unknowns, and you're looking at a 10-12 week timeline.

Suddenly, we're having a real conversation about real dates.

Here's how it actually works day-to-day:

Once we've broken down a project into user stories—and yes, we still write proper user stories, we're not barbarians—our developers provide initial hour estimates for the entire scope. This isn't done in isolation. We review these estimates together, challenge assumptions, and make sure everyone understands what we're committing to build.

The beauty of this approach becomes clear during sprint planning. Instead of abstract velocity discussions, we're planning 30-40 hours of work per developer per week. It's concrete. It's measurable. And most importantly, it's trackable in real-time.

Our daily standups revolve around a simple burndown chart: hours planned versus hours completed. The line should trend downward steadily. When it doesn't, we know immediately—not at the end of the sprint, not when we're calculating velocity retrospectively, but right now—that we need to address something.

Of course, estimates are still estimates, regardless of the unit you use. Software development remains wonderfully unpredictable. The difference is what happens when reality diverges from the plan.

With story points, that conversation often goes like this: "Well, our velocity was lower this sprint because the stories turned out to be more complex..." It's technically accurate, but it doesn't help anyone make decisions.

With hours, the conversation is different: "We planned 80 hours of work this sprint, but we've only completed 60 hours worth. Looking at our burndown, if this trend continues, we'll miss our milestone by a week. Here are the three factors causing the delay, and here are our options for addressing them."

It's the difference between explaining why you're late and actually managing the problem.

This approach serves our core principle: transparency. Our clients aren't software developers—they shouldn't need to become experts in agile methodologies to understand their project's status. But everyone understands time.

When a client asks where we stand, we can show them exactly how many hours of planned work remain, how many hours per week we're completing, and when we expect to finish. If scope changes, we can immediately discuss the hour impact and timeline implications. If we discover something more complex than anticipated, the conversation is about concrete time, not abstract points.

It's not perfect—no estimation approach is. But it's honest, it's practical, and most importantly, it keeps everyone focused on what really matters: delivering valuable software when our clients need it.

At the end of the day, successful software projects aren't measured in story points or velocity metrics. They're measured in whether we delivered what we promised, when we promised it, at the quality level we promised.

Our hour-based approach isn't just about estimation—it's about accountability. To our clients, to our deadlines, and to the real-world constraints that drive business decisions.

Because when someone asks "when will it be done?" they deserve a real answer, not a lesson in agile methodology.