How to Estimate Task Time in Game Development (and Stop Being Wrong)

Most developers underestimate how long tasks take, often by a wide margin. Psychologists call it the planning fallacy: we imagine the smooth version of the work, not the real one. Bent Flyvbjerg’s research on large projects at Oxford shows the same optimism bias at a much bigger scale, and game development, where so much is discovered during the work, is especially exposed to it. Senior engineers with a decade of experience quote “two days” on tasks that eat two weeks. The cure is not willpower; it is tracking estimates against actuals.

The problem isn’t that developers are bad at their jobs. The problem is that most estimation advice is built for software development in enterprise environments, not for a medium where “make the combat feel good” is a legitimate task on the board.

Why Game Dev Estimation Breaks Down Differently

Enterprise software has well-defined acceptance criteria. A login form either works or it doesn’t. Game development has subjective outputs. “The jump feels right” is an acceptance criterion. That subjectivity means scope is genuinely unknowable at the start, which makes estimation harder in ways that standard project management literature doesn’t account for.

Crunch and poor upfront scheduling go together. Bad estimates create schedule compression, and schedule compression creates crunch.

There’s also a motivation problem. Developers who give conservative estimates sometimes get pushback from producers or directors who want shorter timelines. So estimates drift optimistic to avoid conflict. Producers apply that pressure all the time, and it backfires. The fix isn’t just better estimation technique, it’s creating a culture where an honest estimate isn’t punished.

The Three-Point Method (And Why You Should Use It Every Time)

Single-point estimates are fiction. You ask someone “how long will this take” and they give you their most likely number, which is usually optimistic because they’re imagining the task going smoothly. Three-point estimation forces people to think about the range.

The structure is simple: Best Case (B), Most Likely (M), Worst Case (W). The weighted formula is:

Expected Time = (B + 4M + W) / 6

This comes from PERT (Program Evaluation and Review Technique), which NASA used in the 1950s for good reason. It weights the most likely case heavily but doesn’t ignore the tails.

Here’s what this looks like in practice:

A character animator is estimating a walk cycle for an NPC.

• Best Case: 1 day (reference is clean, notes are fast)
• Most Likely: 2.5 days (one round of feedback, minor revision)
• Worst Case: 5 days (reference changes, needs to support cloth simulation that wasn’t originally scoped)

Expected Time = (1 + 4(2.5) + 5) / 6 = (1 + 10 + 5) / 6 = 2.67 days

That 0.17 days over the intuitive “two and a half” estimate sounds trivial on one task. Across forty tasks in a milestone, it’s not trivial.

The other thing three-point estimation does is surface the worst case explicitly, which makes it harder to ignore. When someone says “this could take five days if X happens,” that’s a flag to figure out whether X is likely before the sprint starts.

Breaking Down Tasks: The 3-Day Rule

Related video

Codecks -- Game Development Project Management Tool · Gamefromscratch on YouTube

If a task estimate is longer than three days, break it down. This isn’t a style preference, it’s a structural reliability issue. Tasks over three days have a statistically higher miss rate because longer tasks hide complexity. You think you understand what “implement inventory system” means until day four when you realize persistence, UI, controller input, and save state are all separate problems.

The research backing this comes from Steve McConnell’s “Software Estimation: Demystifying the Black Art” (Microsoft Press, 2006), which remains the best quantitative treatment of estimation I’ve read despite being 20 years old. Among its most practical lessons: break large tasks into smaller ones, because big estimates hide the most error.

In my experience: the pushback from developers when you ask them to break down tasks is real. “I don’t know how to break it down yet, that’s why I need to investigate.” Fine. Create an investigation task, cap it at two days, and re-estimate after. This is called a spike in Scrum, and it’s one of the few Scrum conventions that actually translates well to game dev.

Velocity-Based Estimation: The Most Underused Tool

Here’s something I wish someone had told me earlier in my career: your team’s past velocity is the most accurate predictor of future throughput you have access to, and most small teams don’t track it.

Velocity is simple. Count how many story points (or hours, or tasks, whatever unit you use) your team actually completes in a sprint. Do this for three or more sprints. Average it. That’s your velocity. When planning the next sprint, don’t load in more work than your velocity predicts you can complete.

The catch is that three sprints is the minimum sample size to get a meaningful signal. One sprint’s velocity could be a fluke (team was fully staffed, no bugs escalated, no external meetings). Three sprints starts to show the real pattern.

[Scenario: Small indie team, 3-person dev team, tracking task hours for the first time] → Sprint 1: committed 120 hours of tasks, completed 74 hours worth → Sprint 2: committed 90 hours, completed 81 hours → Sprint 3: committed 85 hours, completed 83 hours → Velocity stabilized around 79 hours/sprint. They were previously committing to 120-hour sprints and burning out trying to hit them. Adjusting to 80-hour commitments dropped their unplanned weekend work from ~6 days/month to under 1.

The point of the scenario: a team convinced it has a motivation problem often has a math problem.

The Hidden Tasks That Eat Your Schedule

The single most common estimation failure I see isn’t underestimating known tasks. It’s forgetting entire categories of work.

These categories need to be explicit line items in your schedule, not absorbed into feature estimates. “Polish” is real work. Certification for console submission takes time you can’t always predict (Sony’s cert process currently runs 2-4 weeks depending on submission queue and issue severity, as of mid-2026). Bug fixing late in development is a known unknown: you don’t know which bugs, but you know they’ll exist.

A rough heuristic I use: for every 8 weeks of active feature development, budget 2-3 weeks explicitly for bug fixing and polish, and 1-2 weeks for submission/review overhead if you’re shipping to a platform. These aren’t conservative numbers; they’re what studios who ship on time actually set aside.

Estimation by Task Type

Not all game development tasks have the same estimation difficulty. Here is a rule-of-thumb breakdown of common task types by estimation reliability, with suggested buffers to start from and then replace with your own data:

AI and new gameplay mechanics are where schedules go to die. Both have a genuine R&D component that makes estimation inherently speculative. The right answer isn’t a more confident estimate; it’s a time-boxed prototype with a defined decision point.

Tooling That Actually Helps

A few tools worth knowing if you’re building or improving your estimation process:

Jira (free for small teams, then paid per user) has story point tracking and velocity charts built in. It’s over-engineered for a 4-person indie team, but if you’re 10+ people, the reporting alone is worth it. The velocity chart is genuinely useful once you have 4+ sprints of data.

HacknPlan was built specifically for game development and handles the IGDA-style task categories better than generic PM tools. It suits early-stage teams who find Jira overwhelming, and it has a free tier with paid plans per user.

Notion plus a manual velocity spreadsheet works fine for teams under 6 people. Overhead stays low. You lose some automation but gain flexibility.

For reading: McConnell’s “Software Estimation” is the canonical text on the math. For something more game-specific, “The Game Production Handbook” by Heather Maxwell Chandler is solid on production workflow and milestone structure. Jason Schreier’s “Blood, Sweat, and Pixels” isn’t a production manual, but every game producer should read it to understand what bad estimation and bad production culture actually does to a team.

For learning the discipline more formally, Michigan State University’s Game Design and Development specialization on Coursera touches on production fundamentals, and the IGDA’s own professional development resources are underused by most indie devs who would benefit from them.

Sources

• Flyvbjerg, B., et al., Oxford Saïd Business School: Research on planning fallacy and optimism bias in project estimation across industries.
• McConnell, S., “Software Estimation: Demystifying the Black Art” (Microsoft Press, 2006): Quantitative analysis of estimation accuracy by task size and type.
• Chandler, H.M., “The Game Production Handbook” (Jones & Bartlett Learning, 3rd ed.): Industry-standard reference on game production workflow and milestone planning.
• NASA/DoD PERT Documentation: Original Program Evaluation and Review Technique methodology and weighted estimation formulas.

Photo: Jakub Zerdzicki via Pexels