Ryan Cole
Most developers underestimate task time by 40% on average. Not 10%, not 15%. Forty percent. That figure comes from research by Bent Flyvbjerg and colleagues at Oxford’s Saïd Business School, who studied large-scale project planning bias across industries, and game development consistently lands at the bad end of that distribution. I’ve watched senior engineers with a decade of experience quote “two days” on tasks that eat two weeks. I’ve done it myself. The first time I tried tracking my estimates against actuals on a Unity prototype back when I was still at the studio, the gap was embarrassing enough that I stopped showing people the spreadsheet.
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.
- Developers underestimate task time by ~40% on average, per Oxford research on planning bias.
- Three-point estimation (best/likely/worst case) produces tighter ranges than single-point guessing.
- Tracking velocity over 3+ sprints is more predictive than any upfront estimation technique alone.
- Buffer for unknowns explicitly: "polish," "bug fixing," and "platform submission" each deserve their own line items.
- Tasks taking longer than 3 days should be broken down further, every time, no exceptions.
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.
The International Game Developers Association’s developer satisfaction surveys have consistently shown that crunch correlates strongly with poor upfront scheduling. This year’s data is consistent with prior waves: studios that don’t track estimate accuracy have significantly higher rates of unplanned overtime. That’s not a coincidence. 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. I’ve been the producer applying that pressure, and I’ve seen it backfire spectacularly on at least three projects. 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
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. His data shows that tasks estimated at over 40 hours have roughly twice the error rate of tasks estimated at 8-16 hours.
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.
That’s not a made-up scenario. That’s approximately what happened on a project I consulted on in late 2024. The team was convinced they had a motivation problem. They had 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’s a breakdown of how I’d categorize common task types by estimation reliability, based on my experience and general industry patterns:
| Task Type | Typical Estimate Accuracy | Main Cause of Overrun | Recommended Buffer |
|---|---|---|---|
| UI implementation (static) | High | Dependency on design handoff | 15% |
| Gameplay mechanics (new) | Low | Iteration and feel tuning | 50-75% |
| Audio integration | Medium-High | Asset delivery timing | 20% |
| AI behaviors | Very Low | Emergent edge cases | 75-100% |
| Level design (blockout) | Medium | Scope creep from design reviews | 30% |
| Bug fixing (known bugs) | Medium | Root cause more complex than apparent | 40% |
| Platform-specific features | Low | Certification, SDK quirks | 50% |
| Art assets (asset-matched) | High | When reference is locked | 10% |
| Shader/rendering work | Low | R&D component, unknowns | 60-80% |
| Localization | High | With strings finalized | 10% |
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 (currently around $8.15/user/month at the standard tier, as of July 2026) 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. I’ve recommended it to early-stage indie teams who find Jira overwhelming, and the feedback has been consistently positive. Pricing is around $6/user/month at mid-tier.
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, the Coursera Game Design specialization from Michigan State 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.
- IGDA Developer Satisfaction Survey (2025): Annual survey of game developer working conditions, crunch, and production practices.
- 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
