Every game developer knows the pain: you look at a task and think, “This will take a few hours.” Days later, you’re still in the weeds.
The truth is simple: humans are terrible at estimating time. And in game development, where bugs, scope creep, and constant discoveries derail even the best-laid plans, hour-based estimates are more fantasy than forecast.
Worse yet, not all hours are equal. A senior programmer might squash a bug in two hours that would take a junior three days. Leads often spend half their time in meetings or context-switching across multiple systems. Estimating in hours assumes everyone works with the same speed, focus, and availability, and that’s just not reality.
The good news? There’s a better way. Instead of obsessing over hours, you can use points, group estimation, and backlog refinement to predict progress realistically. This guide shows you how to estimate smarter, avoid crunch, and keep milestones on track.
Why Time Estimation in Hours Fails
At first glance, estimating in hours feels natural: “two hours for this bug,” “one week for this feature.” But in game development, it rarely works. Here’s why:
-
Optimism bias: We assume the smooth path and ignore blockers.
-
Variability across roles: What takes a senior dev a couple of hours might take a junior days. Leads have meetings and context-switching that eat into their “dev hours.”
-
Hidden disruptions: Bugs, tool issues, design changes, or asset delays can turn a simple task into a marathon.
-
Compounding errors: Small misses on individual tasks stack up, creating a project-wide death spiral.
Hour-based estimates assume perfect conditions and equal productivity across the team. Games are anything but.
The Switch: From Hours to Points
Instead of saying, “This will take 12 hours,” you assign a relative effort score.
Common scale (Fibonacci-style):
-
1 = Small (~half a day)
-
2 = Medium (~a day)
-
3 = Large (2–3 days)
-
5 = Extra Large(4–5 days)
-
8 = Extra Extra Large (1+ week)
Points focus on effort instead of clock time. They absorb variability, give room for surprises, and shift the discussion from “when will it be done?” to “how much effort will this take compared to other work?”
Secret from AAA/indie trenches: you don’t need precision, you need comparability.
Planning Poker: How Teams Estimate Together
If one person sizes work alone, bias creeps in. A junior might under-estimate to impress, a lead might over-inflate to protect time.
That’s why we use Planning Poker:
-
Review: Make sure everyone understands the task and its definition of done.
-
Discuss: Share dependencies, risks, and blockers.
-
Blind vote: Each teammate picks a point value in secret.
-
Reveal & align: Compare estimates. Outliers explain their reasoning. Adjust and re-vote if needed.
-
Agree: Land on a shared size.
Pro tips (the secrets):
-
If estimates differ, choose the higher one. Better to be conservative.
-
Any item ≥8 points? Split it. Big stories hide risks and uncertainty.
-
Each item must have its own estimate, don’t lump features together.
The Product Owner doesn’t run this session, their job is to set priorities, not to size work. Planning Poker belongs to the team, guided by the Scrum Master. The result? More accurate estimates, less bias, and stronger collective ownership.
Tired of wild guesses?
If you’ve ever looked at a feature and thought, “Two days tops!” only to be drowning in it a week later—you know the pain of bad estimates.
That’s why I built the Time Estimation Tool: a lightweight worksheet that helps your team size tasks realistically, spot hidden risks, and align on effort before committing.
It’s quick to set up, simple to use, and designed specifically for game dev teams. Use it in your next refinement session and see how much clarity it brings.
What About Kanban Teams?
Not every team runs on Scrum. Many studios rely on Kanban, where tasks are pulled from highest priority to lowest priority and delivered continuously.
This makes Kanban a natural fit for stabilization phases, performance work, or bug triage, the kind of tasks that must be handled immediately but don’t expand the game’s scope. The goal isn’t adding new features, it’s making sure the game works as intended.
That’s also why time estimation isn’t as critical in Kanban. Most tasks are relatively small (fixes, optimizations, cleanup), so breaking them into points doesn’t add value. Instead, teams focus on:
-
Flow efficiency → keeping work moving without bottlenecks.
-
Cycle time → how long it takes for a task to go from “To Do” to “Done.”
-
WIP limits → preventing overload by capping how much is in progress.
Producers or project managers may still size big features for stakeholder planning, but at the day-to-day level, Kanban thrives on speed and clarity—not estimates.
Refinement, Not Fortune-Telling
A common mistake is trying to size the entire game upfront. That’s not just overwhelming—it’s misleading.
Instead, treat backlog refinement as a small, recurring investment:
-
Keep it light → 1 hour per week (or every other week) is plenty.
-
Top priorities first → Focus only on what’s most important right now. Priorities shift sprint to sprint, so don’t waste effort on distant items.
-
Estimate the immediate → Size only the tasks coming soon, not everything at once.
-
Cut off naturally → End the session when time’s up or when the team needs a break. The goal is steady progress, not exhaustive sizing.
Why this works:
-
Stay ahead of the game → Refinement keeps you working comfortably ahead, never scrambling at the margins.
-
Revisit regularly → Tasks evolve. What felt like a “3-point” story last week may feel like a “5” once you’ve uncovered new challenges. Or the opposite: sometimes another team (or even an external contributor) builds a tool, pipeline, or feature that removes friction. Suddenly, that “5” drops to a “3” or even a “2.” Regular refinement keeps estimates grounded in the current reality, not outdated assumptions.
-
Build adaptability → Even after a milestone, there’s always another on the horizon. Whether it’s updates, expansions, or live services, refinement ensures the team is ready.
-
Leverage team speed → Velocity improves as the team works together. Refinement lets you keep estimates aligned with reality.
-
Anchor in story mapping → Refinement works best when it follows Story Mapping. Mapping gives you the backbone of the player’s journey; refinement translates those stories into estimable tasks. Without that foundation, you’re just sizing in the dark.
-
Production guardrails → In practice, refinement is guided by Producers or Project Managers. They keep sessions focused, prevent scope creep, and ensure estimation becomes actionable forecasting, not just guesswork.
This isn’t about predicting the whole project, it’s about creating just enough clarity to move forward confidently.
Tracking Velocity: Your Scoreboard
Once you size in points, you can measure velocity: how many points your team finishes each sprint.
-
If a 4-person team averages 25 points per sprint, you can predict how much work they’ll complete in the next milestone.
-
Velocity improves over time as teams align and pipelines stabilize.
-
Use velocity shifts to justify new tools or pipelines (e.g., “After switching to a new animation pipeline, output jumped by 20%”).
Points turn production into data you can trust, without the stress of hour-based guesses.
Release Planning: Turning Velocity Into Real Roadmaps
Velocity by itself is just a number. The real power comes when you use it to plan releases. This is what’s often called release management, and it’s where many studios stumble.
Here’s why it matters:
-
From velocity to forecast → Once you know how many points your team completes per sprint, you can project forward. Instead of vague promises, you have data-driven forecasts for when features or milestones will be done.
-
Burn charts → A burn-up or burn-down chart visualizes remaining work against completed velocity. This gives everyone, from devs to execs—a clear picture of progress and scope.
-
Informed trade-offs → Release planning gives producers and Product Owners the tools to decide: Do we cut features, extend the schedule, or increase capacity? Without it, decisions are just guesses.
-
Clarity for stakeholders → When marketing, biz dev, or community teams ask, “When can we announce this?” you’ll have a realistic answer based on data, not gut feel.
Release planning doesn’t mean predicting the entire game’s development, that’s impossible. Instead, it’s about anchoring each milestone to reality and making sure the team’s effort translates into concrete outcomes.
Done well, it transforms estimation from “numbers on a spreadsheet” into actionable roadmaps that align design, production, and business.
Closing: Estimation as Production’s Secret Weapon
Time estimation will never be perfect, but it doesn’t need to be. With points, Planning Poker, and backlog refinement, you shift from fantasy deadlines to realistic forecasts.
This is where Technical Production shines: guiding teams to deliver milestones predictably, while protecting them from chaos.
Want to see how healthy your production really is? Take the Game Production Health Quiz and find out where your processes keep you strong, and where hidden risks might be slowing you down.
FAQ: Time Estimation in Game Development
1. Why doesn’t estimating in hours work for game dev?
Because hours assume a perfect world, and games are anything but. What takes a junior dev 2–3 days might take a senior just a few hours. Leads lose hours each week to meetings and context-switching. Add bugs, scope creep, and surprise discoveries, and “5 hours” quickly becomes 3… or 10. Estimating in points avoids this trap by abstracting effort, not clock time.
2. What are story points, really?
Story points represent effort, complexity, and uncertainty. They’re not tied to hours. Instead, they help teams compare tasks, “this feels twice as big as that.” Over time, velocity (points completed per sprint) becomes your forecast tool.
3. What’s backlog refinement, and why is it so important?
Refinement is a lightweight investment, about an hour per sprint (or every week). The team reviews the top-priority items, clarifies them, and sizes them in points. The session ends when clarity fades or someone calls a break, because chasing precision is wasted effort. The goal isn’t to size everything, just enough to stay ahead of the next milestone.
4. How often should you refine estimates?
Regularly. Tasks evolve as you learn more. A “3-point” story may turn into a “5” when new dependencies surface, or shrink to a “2” if another team delivers a new tool that removes friction. That’s why refinement is ongoing: it keeps estimates grounded in the current reality, not outdated guesses.
5. Can time estimation predict the full game timeline?
Not exactly. Full-game forecasts are unreliable because scope tends to expand endlessly. What estimation does enable is release management: once stories are mapped, prioritized, and sized, you can chart progress with a burn chart. This gives Product Owners a clear view of milestone delivery and helps them make informed scope and scheduling decisions.
6. How does this reduce crunch and rework?
By working in points, refining regularly, and focusing only on near-term priorities, teams avoid the death spiral of missed hour-based deadlines. Everyone has shared clarity on what “done” means, scope creep is easier to spot, and milestones are planned on evidence not optimism. That’s how you keep schedules realistic and teams healthy.
