Game Development Task Estimation Without Fake Precision

A small game team should estimate work from the evidence it has, not from how badly it wants the milestone date to be true. Use past similar work for repeatable tasks, ranges for partly familiar work, and short investigation tasks for genuine unknowns. Then forecast the milestone from team capacity and visible uncertainty. The goal is not a perfect number; it is a plan that tells you what you know, what you do not know, and when to re-estimate.

Estimate by evidence class

Before assigning hours, days or points, classify the work.

Use three evidence classes:

• Repeated: the team has completed closely comparable work before.
• Adjacent: parts are familiar, but the task includes a new constraint, tool, platform or integration.
• Unknown: the team cannot yet explain the implementation path well enough to estimate delivery responsibly.

This prevents a common failure: giving the same level of confidence to “make another enemy using the existing pipeline” and “replace the save format without breaking existing data.”

Atlassian’s guidance on agile estimation recommends using complexity, effort, risk and unknowns when sizing work, then reviewing previous estimates to improve future ones. That makes historical work useful as evidence, not as a promise that every similar task will take exactly the same time.

For unknown work, do not hide uncertainty inside a large estimate. Create a short investigation with a concrete output: a prototype, benchmark, technical decision or list of implementation steps. Then estimate the delivery work after the uncertainty has been reduced.

This fits naturally beside a game development risk register: a risk records what may disrupt the plan; the estimate records what the current evidence supports.

Break work until the estimate has a clear boundary

“Implement inventory,” “polish combat” and “finish controller support” are poor estimate units because their boundaries are unclear.

Split work around observable outputs. For controller support, that might mean:

• detect the supported controller;
• map gameplay actions;
• make menus fully navigable without a mouse;
• handle disconnect and reconnect;
• run the agreed controller test route in a packaged build.

Atlassian recommends splitting oversized work because larger items are harder to estimate with confidence. Joel Spolsky’s Evidence-Based Scheduling makes the same point from a scheduling perspective: smaller tasks are easier to compare with work a developer has done before.

Do not split merely to create more cards. Stop when each item has a clear result, owner and acceptance condition. If a task still depends on an unresolved handoff, surface that separately using a dependency map rather than burying waiting time inside the estimate.

Forecast the milestone, not just the tasks

A list of estimates is not yet a milestone forecast.

Microsoft’s Azure Boards forecasting guidance recommends using historical team velocity to forecast future capacity and explicitly notes that forecasts weaken when estimates vary, team composition changes or dependencies are not accounted for. For teams with history, recent completed work is a better capacity anchor than an idealized number of available hours.

The other missing piece is work that has not been discovered yet. Mike Cohn’s guidance on estimating unknown work argues for keeping known work and expected unknown work separate instead of quietly padding every item.

For a small game team, use this milestone estimate template:

• Playable outcome: what the build must prove.
• Known work: the tasks currently understood.
• Evidence class: repeated, adjacent or unknown.
• Estimate: one value or a range appropriate to the evidence.
• Unknown allowance: work expected to emerge but not yet describable.
• Capacity basis: recent completed work, not theoretical availability.
• Critical dependency or risk: anything that can invalidate the estimate.
• Re-estimate point: the build, spike or review that will produce better evidence.

If the unknown allowance is large enough to decide whether the milestone fits, the next milestone should probably be learning, not delivery.

Example: estimate a combat milestone without pretending

Consider a hypothetical three-person action-game team planning its next playable milestone.

The milestone needs one new enemy, controller remapping and a save-data migration.

The team has built three enemies with the same pipeline. The new enemy is repeated work, so they estimate it from those actuals.

Controller remapping uses an existing input system but adds menu navigation and reconnect behavior. It is adjacent work, so the team uses a range and names the extra test path.

The save migration touches a format nobody on the team has upgraded before. It is unknown work. Instead of calling it “five days,” they schedule a one-day investigation whose output is a migration prototype, failure cases and a delivery estimate.

After that investigation, they rebuild the milestone forecast. If migration is larger than expected, they can cut scope, move the date or remove the migration from this milestone before the team is already late.

Three mistakes would make this forecast worse: padding every task “just in case,” treating team velocity as a productivity target, or leaving estimates unchanged after the design or acceptance criteria change.

Re-estimate when the evidence changes

An estimate should expire when its assumptions do. Re-estimate after a spike resolves a major unknown, a dependency changes, a playtest forces redesign, or the team’s available capacity shifts.

Use the next playable milestone review to compare estimate versus actual, record what changed, and calibrate the next forecast. If your team already uses PlayablePlan, bring this estimation pass into that review so the plan reflects current evidence rather than the number someone guessed weeks ago.