Why schedules slip
Almost every game project takes longer than its first plan says. This is not mainly a matter of laziness or poor discipline. It comes from the nature of the work, and understanding the causes is the first step to estimating better.
Games are discovery work. Until something is playable, nobody knows whether it is fun. Designers change their minds after seeing a prototype, and each change ripples into art, code and audio. A schedule built before that discovery treats uncertain work as if it were routine.
Estimates favor the smooth path. When people imagine a task, they picture it going well. They rarely include the bug that takes two days to find, the illness, the late asset, or the meeting that moves everything. Individual tasks rarely finish much faster than planned, but they can easily finish much slower, so errors lean in one direction.
Scope grows quietly. Small additions seem free when proposed. Ten “quick” features add up to weeks. Controlling project scope is as much a scheduling tool as a design one.
The last stretch is slow. Polish, bug fixing and platform requirements consume time that early plans usually underestimate, which is why quality assurance deserves its own line in any schedule.
Milestones: checkpoints, not promises
Many teams divide a project into milestones, each with a clear definition of what exists and what it can do. The names vary between studios, and the common build milestones such as alpha, beta and gold are covered elsewhere, but the principle is the same: a milestone should describe something observable.
“Combat is 80 percent done” is vague. “A player can finish the first encounter using all three attacks, with temporary art” is something anyone can check. Good milestones let you ask a simple, honest question at each point: is the work behind us the size we expected?
If a milestone is missed, the useful response is to find out why and update the plan, not to compress the remaining schedule and hope.
Tracking velocity
Teams that work in short cycles, often called sprints, can measure how much they actually finish per cycle. One common approach assigns each task a relative size in points and counts only tasks that are fully complete. The points finished in a sprint are the team’s velocity.
Points are not hours, and a point value means nothing outside the team that set it. Their value is that, over several sprints, they reveal a pattern you can use for forecasting.
A hypothetical sprint example
Suppose a team has a backlog of 120 points of remaining work and uses two-week sprints. Over the last five sprints, it completed 18, 22, 15, 20 and 25 points.
- Total completed: 18 + 22 + 15 + 20 + 25 = 100 points
- Average velocity: 100 divided by 5 = 20 points per sprint
- Slowest sprint: 15 points. Fastest sprint: 25 points
Now forecast the remaining 120 points three ways:
| Case | Velocity | Sprints needed | Time |
|---|---|---|---|
| Optimistic | 25 | 120 / 25 = 4.8, so 5 sprints | about 10 weeks |
| Average | 20 | 120 / 20 = 6 sprints | 12 weeks |
| Cautious | 15 | 120 / 15 = 8 sprints | 16 weeks |
The honest answer is therefore “between 10 and 16 weeks, with 12 the middle estimate”, not “12 weeks”.
Now add scope growth. If the team keeps discovering new work and the backlog gains 5 points each sprint, the net progress at average velocity is 20 minus 5, or 15 points per sprint. The remaining 120 points then take 8 sprints, which is 16 weeks. A modest, steady addition of work moved the middle estimate from 12 weeks to 16 weeks. This is how projects drift without anyone making a single dramatic mistake.
Five sprints is a small sample, and velocity numbers are noisy. Treat them as a rough guide and never as a precise measurement.
Why estimates should be ranges
A single date suggests certainty that does not exist. A range communicates it honestly and lets others plan around it. A few habits help:
- Give a low, likely and high estimate for each large piece of work.
- Widen the range for work the team has never done before, and narrow it for work it has repeated.
- State what the estimate assumes, such as team size and fixed scope, so a change to those assumptions visibly changes the answer.
- Re-estimate regularly. A forecast made at the start of a project is the least informed one you will ever have.
Ranges also connect schedule to money. Because labor usually dominates the development budget, a four-week slip on a team of several people carries a real cost, so the high end of the time range should feed directly into the high end of the cost range.
Using evidence from the team’s own history
The most reliable source for a forecast is the team’s own past results, not an industry average. A project postmortem is a good place to record what was planned against what happened, so the next estimate starts from data. Even a short list of “we guessed three weeks, it took six” gives a useful correction factor for a particular team and type of work.
Smaller exercises help calibrate too. A weekend event such as game jams forces a team to plan a whole project in a few days, and the gap between ambition and what was finished is often instructive.
Practical takeaways
Keep tasks small, count only finished work, track scope changes openly, and present every forecast as a range with its assumptions beside it. None of this prevents delay, but it makes delay visible early, when there is still time to cut scope or move a date calmly.