Story Points vs Days: The Epic Battle of Estimation!

The Great Estimation Debate

Picture this: It's another sunny morning in the development office (unless you're in Scotland, of course!). The coffee is brewing, keyboards are clacking, and somewhere in a meeting room, a developer and a product manager are engaged in what can only be described as the software industry's equivalent of asking for directions - one person wants precise distances in kilometers, while the other prefers "turn left at the big oak tree". Inevitably, things will start to get heated.

Story Points: The Abstract Art of Estimation

Story points were introduced as part of the Agile methodology, promising to free us from the chains of time-based estimates. The idea was simple: instead of saying how long something would take, we'd rate its complexity on a Fibonacci-like scale. Because apparently, regular numbers weren't confusing enough.

If this all sounds suspiciously like the 1980s Management Consultants who turned 'firing people' into 'right-sizing human capital optimization initiatives', you're not far off. Today's Agile Evangelists seem to have borrowed from the same playbook: taking perfectly sensible concepts like 'how long will this take?' and wrapping them in enough jargon to justify a three-day certification course. At least the Management Consultants had better suits.

Here's the first contradiction: Sprints themselves are time-boxed (usually two weeks in most places I've worked), so we're already working within a time-based framework. It's rather peculiar that we'd use abstract points to measure work that fits into concrete time boxes. It's like measuring your kitchen in 'cooking complexity units' when you know dinner needs to be ready by 6 PM.

Notice something? The official Scrum Guide itself defines Sprints explicitly in terms of time - not story points, not complexity units, but actual, measurable time. When the very framework you're using is fundamentally time-based, doesn't it seem a bit contradictory to then measure the work within it using abstract points?

The argument for story points goes something like this:

• They account for complexity and uncertainty
• They're relative measures (like comparing the size of different pizzas)
• They help avoid the dreaded "but you said it would take 3 days!" conversation
• They sound more "Agile-y" in status meetings

Day Estimates: The "Let's Be Real" Approach

On the other side of the fence, we have good old-fashioned day estimates. You know, those things that actually tell you when something might be done. Novel concept, right?

The case for day estimates is compelling:

• Everyone understands what a day is (even management!)
• They translate directly to project timelines
• They make resource planning actually possible
• They don't require a decoder ring to understand

The Burndown Chart Conundrum

Let's talk about everyone's favorite wall decoration: the burndown chart. With traditional story points, you get these beautiful, theoretical planning lines that suggest everything will go according to plan - a neat diagonal line from start to finish that bears little resemblance to reality. Meanwhile, in our day-estimated version, you can actually see what's REALLY happening day to day.

At Insights, instead of relying on that mythical straight burndown line, we create a real, planned burndown based on actual scheduling. During Sprint Planning, we use JIRA's "Start Date" field to indicate when each story or task is planned to begin. Combined with our story point values (remember: 1 point = 1 day), this automatically calculates the planned completion date for each item. When a ticket moves to "In Progress", we record the actual start date, and "Done" gives us the actual completion date.

The result? Our burndown chart shows a planned line based on real task scheduling, not just a theoretical diagonal. This means we can spot problems much earlier - if a task that was supposed to take two days is still in progress on day three, we know immediately that we need to reassess. No more waiting until sprint end to discover we were wildly optimistic! It's amazing how much clearer your planning becomes when you're working with actual dates instead of abstract points.

What Research Says

Recent studies have shown interesting findings in this debate. A 2022 study by the University of Somewhere Jolly Important (UoSJI) found that teams using day estimates were 42% more likely to accurately predict project completion dates. However, they were also 137% more likely to need stress relief therapy. (They also noted in a post-script that 96.45% of all statistics are made up on the spot)

The Practical Solution

Here at Insights, we've found that day estimates (or half-day estimates) provide the most practical approach for our teams. Why? Because when someone asks "When will it be done?" we can actually answer without first consulting the Fibonacci sequence and three sprints' worth of historical velocity data.

Speaking of historical velocity, here's another inconvenient truth that story point evangelists tend to gloss over: Teams change. People move on to new projects, new hires join the team - it's the natural cycle of software development. Each of these changes immediately invalidates all that precious historical velocity data you've been collecting. Then you're stuck waiting several sprints with your new "stable" team just to calculate a new average velocity. Meanwhile, in the real world, stakeholders are still asking when features will be delivered.

However, we still use the "Story Points" field in our JIRA tickets - but with a twist that keeps everyone happy: we've simply defined one story point to equal one day, with a minimum unit of 0.5 story points (half a day). This way, we maintain compatibility with tools and reports built around story points while keeping our estimates grounded in actual, understandable time units. You might call it having our cake and eating it too, but sometimes the simplest solution is the best one.

Our approach:

• Have proper Sprint Planning sessions where we assign planned start dates for each task
• Use half-day and full-day estimates for tasks (using the Jira "Story Points" field)
• Include buffer time for unknowns (because something always goes wrong)
• Keep it simple and transparent
• Update estimates as we learn more (yes, it's allowed!)

The Bottom Line

Whether you're Team Story Points or Team Day Estimates, the key is finding what works for your team and stakeholders. Just remember: at the end of the day (or story point), we're all trying to build great software and keep our product managers from having nervous breakdowns.

And if anyone asks you to estimate in story points AND days... well, that's what sick days are for.

---

P.S. I am fully aware that this is a contentious topic and that many Agile Fundamentalists will be foaming at the mouth, tearing their hair out and waving their copy of the Agile Manifesto in the air as they scream for the head of this out-and-out apostate. "He's missed the whole point!", they cry angrily. Well - I may have "missed the whole point", but I haven't missed my deadline! 😀