We’ve all been there—looking at a task, thinking, “Oh, this will take a few hours,” only to realize, hours later, that we’ve under- (or over-) estimated the time by a factor of 10.
But here’s the truth: we’re terrible at estimating time, and that’s okay.
You’re not alone. Seriously.
No matter if it’s the adrenaline rush of a looming deadline, the excitement of starting a new feature, or just sheer optimism, we all fall into the same trap: “It’ll be done soon,” or “I’ll knock this out in no time.”
Spoiler alert: it doesn’t ever work that way.
So what can we do about it? Change how we estimate.
Instead of trying to predict the exact number of hours (which, let’s be honest, feels like guesswork), we can use a more flexible system. The result? Less stress, fewer panicked sprints, and, yes, more accurate predictions on how much work will actually get done.
And who doesn’t want that?
In this guide, we’re going to walk through a method that’ll make time estimation a whole lot easier—and dare I say—fun! You’ll learn how to ditch the hour-by-hour guesswork and adopt a system that gives you a clearer picture of the work ahead.
Another spoiler: It doesn’t involve magic, but it does involve points—and no, not the kind you get for finishing a game, but the kind that’ll help your team finish the project.
Ready to get started? We definitely are!
Why Time Estimation is So Hard in Game Dev
We’re wired to think we’re great at predicting how long something will take, but the reality? Not so much. Seriously—human brains just aren’t built for it. When we estimate time in hours, we’re trying to get really precise—like, to the minute.
But let’s be honest: time estimates (in hours) are rarely that precise.
They’re more like a rough guess, a “gut feeling,” or just the result of a desperate attempt to avoid feeling like we’re totally off track. It’s more like guestimation than estimation.
Here’s where it gets tricky.
When we try to estimate in hours, we make an unspoken assumption: we think we can work like machines—in a perfect world where nothing goes wrong.
But, in game development, everything goes wrong. Bugs appear out of nowhere, tasks take longer than expected, new ideas keep popping up (resulting scope creep), and, let’s not forget, a whole lot of unexpected discoveries throw off the entire project timeline.
Hours don’t account for any of this chaos. They assume you’re working in a perfect, smooth world where you can perfectly plan every minute.
And that’s never the case.
So, what happens when something goes wrong? Let’s talk about it
How Time Estimates Get Messed Up
Time estimates? Ah, the joy and frustration of trying to predict the unpredictable.
The longer the project goes on, the worse it gets, and here’s why: the more we try to estimate in hours, the more we’re setting ourselves up for a rollercoaster ride. But don’t worry, we’re about to smooth out that ride with a little help from points.
Let’s start with something that seems optimistic at first glance—“optimistic” estimates. And no, not the kind you’re thinking about.
You know the one: “This’ll be done in no time,” or “It’ll only take a couple of hours!” Classic. It’s wishful thinking at its finest. We’ve all been there, right? You glance at a task and think, “This is a breeze. I’ll totally have it done before lunch.”
Cut to 3 hours later, and you’re staring at your screen like it’s a portal to a parallel universe where time doesn’t exist.
Here’s the thing: when we say something will be quick, it’s usually because we seriously underestimate how much effort it’ll take. You think you’re dealing with a tiny task, but then—plot twist—your browser has 15 tabs open, there are 3 bugs to squash, and you’ve got 2 meetings coming up (it is sometimes just easier to have these meetings as emails). Suddenly, that “quick task” feels like it needs a personal assistant.
It happens to the best of us. And let’s face it: it’s hard not to fall into the “It’ll be done soon” trap. But spoiler alert: this mindset tends to lead to disappointment when things run longer than we hoped. And who enjoys being behind production schedule? Ugh, who enjoys that, right? (Well, maybe the person who always says, ‘It’ll be done soon’ while secretly knowing they’re way off. But hey, those folks are true thrill-seekers.)
If you’re tired of chaotic dev cycles and missing deadlines, we’ve got something to help you out. Check out our free guide! In it, you’ll learn:
- The 5 key elements of an effective production schedule
- How to estimate task durations without going overboard
- Tips for staying flexible while hitting your big milestones
PLUS, you’ll also get a customizable Game Production Schedule Template to kickstart your workflow. Say goodbye to confusion and hello to smooth sailing!
But, let’s move back to the track.
Now here’s where we get real: when you estimate time in hours, you’re basically making your best guess. And sometimes that guess is wildly off. We’re all human (in case you forgot), and there are too many variables in game development to predict with laser precision.
Maybe a task takes longer because of bugs, distractions, or—oh no—the coffee machine breaks down for the third time this week. Or maybe, if everything goes smoothly (rare, but possible), it’ll take less time. But here’s the catch: there’s always variability.
Estimating time is like predicting the weather in a place you’ve never been. “Today’s forecast: 50% chance of being right.”
Sometimes, you get lucky and nail it. But most of the time, you’re somewhere in the ballpark, but not exactly where you thought you’d be. For example, a 5-hour estimate could end up taking anywhere from 3 to 7 hours. That’s a pretty wide swing—and guess what? You still need to finish your work, even with that uncertainty hanging around.
And… drumroll… those inaccuracies? They multiply (do you know about the death spiral?).
Let’s say you’ve got several tasks on your plate, and each one takes a little longer than expected. No big deal, right? But when you add up all those small delays, suddenly you’re in a snowball effect. The whole project starts running behind schedule, like a stack of dominoes toppling one after another.
This gets even trickier when you’re predicting outcomes over the long term. Let’s break it down with a real example. Imagine you estimate 150 hours of work for the next 3 months. But here’s the thing – 150 hours would be about 5 weeks of work for 1 person.
So, for 3 months, you’re looking at more like 390 hours of work for just 1 person. Now, if you’ve got a 2-person team, that’s closer to 780 hours. And because things rarely go perfectly, those hours can easily shift – it could end up anywhere from 140 hours (if you’re super lucky) to 230 hours (if you’re running into a few hiccups).
And that’s just the beginning!
Now, predicting how much work will be completed in 3 months? It’s basically like trying to forecast a tornado during a hurricane. Not only is it impossible to get it right, but it’ll probably stress you out, too.
So, what’s the takeaway here? Time estimates in hours are full of variability, and the longer you try to predict, the more things can spiral out of control. That’s where points come in. They take a lot of that unpredictability and toss it out the window, helping you build more accurate forecasts without the rollercoaster ride.
But we have a solution here. Keep reading—spoilter alert—it’s all about points.
Switching to Points: A Better Way to Estimate
Alright, let’s get into the magic sauce that is points. And let’s make long story short: Instead of saying something will take exactly 5 hours, you could just say, “This is 3 points” or “This is a Medium task.”
That’s it! Now you know. But why?
This simple shift makes a world of difference. Why? Because it allows you to stop obsessing over the exact number of hours and instead, focus on a flexible and abstract representation of effort.
Why it’s working? Because when you try to estimate in hours, you’re often setting yourself up for disappointment when things take longer (or shorter) than expected.
But points?
They’re like that comfy pair of jeans that stretch when you need them to—they’ve got room for error. Points don’t lock you into that specific, anxiety-inducing “X hours” frame. They let you be a little more flexible. Because, spoiler alert: things will never go as planned, and that’s okay.
So, instead of looking at every task like it’s a ticking clock, you start seeing it as “How much effort will this take on a scale?” And trust me, that’s a much healthier way to approach the unpredictable chaos that is game development.
Let’s break down how this actually works. Here’s the handy-dandy point scale guide to get you started (don’t worry, no math degrees required here):
- 1 = XS (Extra Small): Half a day (~3 hours)
- 2 = S (Small): A day (~6 hours)
- 3 = M (Medium): 2-3 days (~12-18 hours)
- 5 = L (Large): 4 days to a week (~24-36 hours)
- 8 = XL (Extra Large): More than a week (>36 hours)
You get the picture, right?
Smaller tasks = smaller points, bigger tasks = bigger points.
No need to break out the stopwatch for every little thing. It’s all about getting a rough idea of how much effort is involved. Plus, it gives you room for those inevitable things (like surprise bugs, your coffee machine deciding to take a break, or getting distracted by a really cool game mechanic you’re working on).
And here’s why points are the secret sauce to better time estimates: They offer a range, not a single fixed number. Instead of trying to figure out exactly how long something will take to the minute (which, let’s be honest, is almost impossible), points just give you a rough sense of how much effort is involved.
It’s abstract, which is a fancy way of saying: “It’s going to take more than a couple of hours, but not a whole week. Let’s call it 3 points, and be done with it.”
By using points, you can easily account for human variability (because we all know something will go wrong eventually). You’re not worried about being 5 minutes off; you’re just focused on the bigger picture: How much work is actually getting done, and how much effort is involved in each task.
This makes your time estimation much more accurate and flexible than rigid hour-based predictions. At this point, you might have a question: ‘So, I just need to place some points, and my colleague does it as well, right?‘ Short answer is “No!”, but you’re not completely wrong.
Let us answer your question with another question: ‘Do you play poker?‘ It’s where the fun begins: group estimation!
Planning Poker: The Power of Group Estimation
Instead of relying on one person’s guess (and let’s face it, we’ve all been that person who underestimates a task), we’re going to use planning poker.
What’s that, you ask?
It’s a simple yet powerful tool to help your team decide how much effort a task will take—together. By bringing everyone into the estimation process, you avoid bias, get a better idea of the task’s complexity, and ultimately end up with a much more accurate estimate.
Think of it like playing a game (who doesn’t love games, right?). But instead of trying to guess how much time something will take on your own, you get to collaborate and share the load with your team.
This way, everyone’s input counts, and no one feels like they’re alone in the “guessing game.”
The magic behind planning poker is simple: independent estimates followed by a group discussion. Everyone estimates how much effort a task will take based on their own understanding and experience. This process helps you avoid biases like groupthink (where everyone just agrees with the first estimate because it’s easier).
When everyone has their own say and their own vote, you get a clearer sense of the task’s complexity. Plus, since everyone does it simultaneously, you also sidestep the risk of senior or manager bias – no one’s opinion carries more weight than anyone else’s.
And here’s the bonus: it helps normalize the amount of effort. We’re not expecting an entry-level developer to do as much as a senior-level developer. By doing it this way, you’re not just relying on one person’s opinion—you’re tapping into the collective knowledge and experience of the whole team. That means better decisions and less guesswork.
And who doesn’t want that?
Alright, now let’s break down how this works in practice. It’s actually really simple and kind of fun (trust me, it’s like a mini team-building exercise). Here’s the step-by-step process:
- Review the item: First, make sure everyone on the team understands the task and what it means to be ‘done.’ You don’t want anyone estimating based on vague knowledge. If something’s not clear, that means more context is needed. If the producer (ScrumMaster) doesn’t have the clarity, it should be sent back to the person who added the item—whether that’s the Product Owner, Director, lead, or someone else who might not be in the room at the moment. The key is making sure everyone is on the same page before diving into estimates!
- Quick discussion: Share any relevant details about the task—dependencies, work that’s already been done, possible roadblocks, or anything that could impact how long it takes. The goal here is to make sure everyone has all the information they need to make a solid estimate.
- Blind vote: Now comes the fun part. Everyone votes in silence—no peeking at each other’s answers. You can use planning poker cards (which have numbers on them, like 1, 2, 3, 5, 8, etc.) or any other voting system that works for your team. The key is, you don’t know what anyone else voted until the cards are revealed.
- Agree on points: Once everyone reveals their vote, the team discusses the differences (if there are any). If there’s a big difference in estimates, the person who chose the highest estimate explains why they think it’ll take that long. The team talks it out and agrees on how many points the task should take. If necessary, vote again after the discussion to see if opinions change.
- Update: Once you’ve reached a consensus, you record the points on the task. And that’s it! You now have a solid estimate based on the collective knowledge of the team. No one person is stuck with all the guesswork, and everyone is involved in the decision-making process.
Alright, now that you’ve got the hang of how planning poker works, let’s make sure your sessions don’t turn into a chaotic mess of cards and confusion.
Suggested Rules for Voting in Planning Poker
Let us help you even more, here’s our first pro tip: when in doubt, go conservative.
If you’re ever in a situation where there’s a bit of a disagreement in your planning poker votes, the most conservative (read: highest) estimate wins.
Yep, you heard that right.
If one person thinks a task will take 3 points, and another thinks it’ll take 5 points, then the team should go with the higher estimate. Why? Because it’s better to overestimate than underestimate.
This is like being prepared for a rainstorm, but hoping for sunshine. If you plan for the worst, you won’t be scrambling when things go south. So, if you’re unsure whether the task will take 3 points or 5, go for 5. You can always be pleasantly surprised if it takes less time!
But if you lowball it and things run longer, well… that’s when the stress and panic set in.
Now, let’s say there’s a wild outlier in the group. One person votes, like, way off from the rest of the team—maybe they said 8 points when everyone else said 3.
What do you do? Well, don’t just ignore them and move on. Instead, ask them to explain.
Ask: “Hey, what’s up with the 8 points?”
Maybe they’re seeing something others missed— an unexpected challenge they’re worried about. If their concern is valid, then you and your project manager have to adjust the estimate accordingly.
Just remember: Each item should stand on its own. Any dependencies it has should be listed right alongside it, but each item should have its own estimate. That way, you’re not lumping things together and risk missing key details!
Now, if an item scores an 8 or higher, it’s time to break it down into smaller components. For example, if you have a scope item (or story) that the team agrees is an 8, it could take, for example, 2-4 weeks to complete.
The bigger the item, the harder it is to predict and estimate accurately. That’s why we need to split it into 2, maybe 3 or 4 smaller stories to keep things manageable!
But if they’re being overly cautious (or maybe a bit too ambitious, depending on their mood that day), here’s what you do: If there’s no way to bring that estimate down, then stick with the conservative estimate. But if there is room to adjust, go with the number they feel most comfortable with. It’s all about finding that sweet spot where everyone feels good about the estimate!
The goal here is alignment—not everyone agreeing for the sake of agreeing, but understanding why someone thinks a task is more complicated. And if you do have an outlier—like if everyone votes a 5, but one person votes a 3 or 2—take a step back. It could be that they’re noticing something the rest of the group missed, so it’s worth digging into.
But in the end, going with the higher number usually saves you from any unpleasant surprises!
Here’s the final rule: speed over perfection. The goal isn’t to get a perfectly accurate estimate down to the minute. Nope, you’re not trying to nail down the exact number of hours it’ll take to finish this task.
The goal is to get a “good enough” estimate that gives the team a solid sense of the work involved.
Think of it like a rough map—you don’t need every street name to navigate, you just need to know where you’re going. The sooner you can agree on a good estimate, the faster you can move forward with the work.
And let’s face it, in game development, you don’t have time to waste on overthinking. Get the estimate, get the task done, and then move on to the next one.
We’re going to share some more insights about practical aspects of time estimation—tracking progress with points. Keep reading!
The Role of Time Estimates in Team Improvement
Once you start using points to estimate tasks, you can start tracking how many points your team is completing during each sprint.
Think of it like a scoreboard for your team’s productivity. And who doesn’t like a good scoreboard?
Over time, you’ll notice something magical: improvement. As your team gets more comfortable with the workflow, gains more experience, and maybe even discovers some new tricks, you’ll see an increase in the number of points completed per sprint.
This is a sign that your team is becoming more efficient. Yay for progress!
This approach is especially helpful when you’re working with a team over time. Instead of worrying about whether you hit your exact time estimates (which, let’s be real, never happens), you can look at how many points were accomplished.
The more points, the better—just like leveling up in a game. And who doesn’t love a good level-up moment?
For example, let’s talk about measuring the impact of new tools. This is where things get really interesting. Let’s say your team starts using a shiny new tool or process that’s supposed to improve productivity—maybe it’s a new animation pipeline or a faster coding framework.
With hours, it’s really hard to see the impact of that new tool. After all, time doesn’t always capture the real benefits of a process improvement.
But with points? Oh yeah, you’ll see it.
If the team starts completing more points in the same amount of time, then boom—you know that tool is working. It’s like getting a power-up in a video game. You might not know exactly how much faster or more productive everyone is, but you can measure the results by the number of points getting finished. It’s a much clearer, more satisfying way to see how your tools and processes are actually making a difference.
So, if you’re ever looking to justify a new tool purchase, just look at those point totals.
And here’s the big win when you focus on points: you get better insights into team dynamics, efficiency, and overall project health. The problem with focusing on hours is that it tells you nothing about the actual productivity or teamwork happening behind the scenes. A task that takes 6 hours might feel like a breeze for one person but could be a marathon for another.
But with points, you’re measuring the effort involved—not just the clock.
Tracking points means you’re not caught up in the hours game, where everyone’s constantly trying to hit that “perfect” estimate. Instead, you’re looking at trends over time, and those trends are a much more accurate reflection of how well the team is working together and improving.
Plus, it makes everyone feel a little less stressed because, hey, we’re not racing against the clock—we’re just trying to rack up those points!
Time to Stop Guessing
Alright, you’ve made it to the end of the guide—now it’s time to put this all into action. By now, you’re probably thinking, “Okay, I’m ready to ditch the endless hours of time estimation and start using points like a pro.”
And guess what? You totally can. It’s really that simple.
Remember: the goal here is to take the guesswork out of game development and make time estimation work for you, not against you. No more guessing how long a task will take, no more panicking when things take longer than expected, and no more stressed-out scrambles to hit unrealistic deadlines.
By using planning poker, group estimation, and points instead of hours, you’ll have a more flexible, accurate system in place that reflects the reality of game dev. And here’s the best part—it’s way less stressful.
So here’s your action plan:
- Ditch the hours—seriously, stop trying to estimate to the minute. Switch to points for better flexibility and room for error.
- Get the team involved—planning poker isn’t just a tool; it’s a team-building exercise that helps everyone align and share their insights.
- Track progress—Keep an eye on how many points your team completes each sprint. You’ll see improvements, and those small wins will keep the motivation high.
- Embrace the flexibility—If a task takes a little longer or a little less time than expected, no worries. Points let you handle that without freaking out.
At the end of the day, time estimation doesn’t need to be a nightmare. You don’t have to be a mind reader to predict how long something will take—just use points and start thinking in terms of effort rather than hours.
It’s that easy.
So go ahead, give it a try, and watch as your team gets better at estimating, collaborating, and, most importantly, getting things done. Oh, and remember: if someone says, “It’ll be done soon,” just smile, nod, and think, “Yeah, sure, 3 points sounds about right.”
And hey, if you find yourself stuck, stressed, or just want a little extra help with your game production, Toño Game Consultants has your back. We specialize in smoothing out the bumps in your production process—so you can focus on building a great game while we handle the rest.
Reach out to us today and let’s make your project the smoothest rollercoaster ride yet!