Estimates for Emerging Devs

estimation

/ˌɛstɪˈmeɪʃn/

noun

1. a rough calculation of the value, number, quantity, or extent of something.

Source: Unsplash

Estimation is the act of predicting how much time, effort, and resources will be required to progress a videogame's development from one milestone to another. That could be from ideation through to release, from one sprint to another, or any milestone length in between.

Estimation is more than assigning numbers to tasks. It is a communication tool: a way of setting expectations, identifying risks, and aligning everyone involved in the project. Roadmaps, backlogs, and timelines are often essential for communicating with external stakeholders. Publishers, funding bodies, and—if you’re a student—teachers will often explicitly request these documents. They show that you have thought through the work ahead and can communicate a plan with confidence.

Even if you’re working independently or with a small team, estimation still adds value. It helps you:

• Understand the true scope of your project

• Identify potential bottlenecks early

• Plan realistic milestones that keep momentum without burning out

• Reflect on how your team works and improve over time

• Ensure you don’t work on a passion project forever

Treat estimation not just as something you do for others, but as a tool for your own decision-making and risk management.

Start with the “Why”

Source: Unsplash

Before you decide how to approach estimation for your project and start the estimating process, it’s important to define your goals and intended outcomes. The reason behind your estimates shapes how detailed they should be, how they are communicated, and what format they take.

For Your Team

Internal estimates help align everyone’s understanding of the work ahead. They help the team plan sprints, share workload, and anticipate where bottlenecks might appear. These estimates can be lightweight and focus more on relative effort than exact numbers. Documenting dependencies and risks provides a clear, shared view of the work, allowing discussions to remain objective. This transparency helps reduce miscommunication and prevents conflict from escalating.

For Your Coursework

When developing games as part of your coursework, the goal is practice and reflection rather than precision. The production process helps you notice what you tend to underestimate or overestimate, so you can improve over time. Choose appropriate methods for documenting your estimates and consider the scope of your project carefully to make sure it aligns with the expectations of your course. Check your assessment criteria, assignment requirements, and key milestones, and then prioritise work that helps you meet those outcomes. A smaller project that is functional, well-considered, and polished will be more successful than a large, ambitious, but incomplete game. Think about what you can realistically deliver within the time available and focus on finishing it to a high standard. You can—and should—use estimation to determine that.

For External Stakeholders

Estimates for external stakeholders like publishers and funding bodies are about demonstrating that a project is feasible and that you have considered the potential risks to its completion, as well as mitigation strategies and contingencies. These estimates and documents need to be more formal and detailed, to communicate credibility to a stakeholder.

Act as a Translator

Once you know why you are estimating, the next step is to consider how to both gather and communicate that information effectively. A producer’s role is to facilitate effective estimation processes within their team and then translate that information into a format that stakeholders can understand and act on.

Being a translator means:

• Interpreting your team’s internal conversations and converting these discussions into clear, structured estimates that stakeholders can understand and plan around.

• Communicating estimates honestly without overpromising, to build trust between your team and stakeholders.

• Learning the uncertainties and unknowns from your team, and communicating those risks to stakeholders in a way they will understand.

• Sharing enough information to build trust without overwhelming non-technical audiences with unnecessary information and detail.

• Ensuring both the team and stakeholders have a shared understanding of what is being delivered, when, and at what quality level.

Translation also happens within the team. Developers will approach their work differently based on discipline, seniority, or preferred work style. For example:

• Discipline: Designers might estimate by feature, engineers might prefer to ‘timebox’ (ie. limit how long they can work on a task to a specific period of time) rather than estimate how long a task will take, and artists might work to asset lists.

• Seniority: Senior staff may be confident giving ballpark numbers, while juniors may be more granular or may underestimate to avoid disappointing others.

• Work style: Some team members prefer detailed task breakdowns, while others think in broader strokes.

A good producer respects the team’s preferred ways of working and asks only for the information needed to translate their estimates into a shared, standardised format. Every request for information should have a clear purpose: producers should be able to explain why they are asking for it and how it will be used. This transparency builds trust and helps the team stay engaged in the process.

If your team doesn’t have a dedicated producer, someone still needs to take on this coordination role. Without it, estimates can become fragmented and the team may be misaligned, leading to unnecessary challenges. Good translation ensures that everyone feels heard; the team should see that their input is respected and accurately represented, while stakeholders gain confidence that the project is on track.

Estimate Effectively

Source: Unsplash

The goal of estimation is to produce a realistic picture of the work that needs to be done and that reflects the team’s expertise and constraints. This process needs to respect the varied commitments and experience of the team, and ensure nobody feels pressured into giving optimistic numbers or agreeing to timelines they know they will be unable to adhere to.

Define requirements

Start by making sure everyone agrees on what needs to be created. Your team might agree that they are aiming to complete a ‘minimum viable product’ or a ‘vertical slice’, but make sure you work together to explicitly define what that means. Those terms can refer to a slightly different product for each developer, and it’s important to make sure you know you are all working towards the same goal.

You should also take this opportunity to create a shared definition of done. Task estimates will be different depending on what the team considers is a completed task. For example:

• Is a feature complete when it’s been designed, implemented, or fully tested?

• What level of polish is expected from assets at this stage of production?

Creating shared definitions and documenting them early will help prevent misunderstandings later in production. Estimates are only meaningful if everyone agrees on the goal you are aiming for and on what counts as a completed task towards that goal.

Establish psychological safety

Accurate estimates rely on team members feeling safe to speak honestly about how long tasks will take. Psychological safety is the shared belief that it is acceptable to share concerns, admit uncertainty, and give realistic numbers without fear of judgement or punishment.

When psychological safety is missing, team members may:

• Give overly optimistic estimates to avoid disappointing others

• Stay quiet about risks or blockers

• Agree to deadlines they know are unrealistic, leading to stress and crunch later

Producers—or whoever is facilitating estimation—can build psychological safety by:

• Framing estimates as a planning tool, not a promise

• Normalising revisions when new information changes the scope or complexity

• Thanking team members for raising risks or giving longer-than-expected estimates

• Creating a collaborative environment where every voice is heard, regardless of seniority

Establishing psychological safety can be difficult, but it means that when disagreements or delays arise, they can be discussed openly and constructively. Teams that feel safe are more likely to give accurate estimates and maintain sustainable production practices.

Choose estimation techniques

There is no ‘correct’ way to estimate. Different situations, team sizes, and project stages call for different techniques. Teams should choose (or combine) the approach that best suit the context. Some key techniques include:

• Expert judgement

• Historical data

• Collaborative estimation

Expert judgement

Sometimes the fastest way to get an estimate is simply to ask somebody who is experienced with the task. This may be someone on your team or, if you are still an emerging developer, it could be a teacher or mentor.

Expert judgement works best when:

• The work is familiar and well-understood.

• The person has done similar tasks before.

• The estimate is needed quickly.

Be aware that expert judgement can carry bias and inaccuracy. For example, asking a more senior team member how long a task will take but then giving that task to a junior will inevitably result in an estimate that is too optimistic and unlikely to reflect the actual time required. Pair estimates based on expert judgement with a quick discussion or comparison to past work, if possible.

Historical data

It is valuable to not only estimate tasks but also record actuals (the real time and effort it took to complete the task). Comparing estimates with actuals helps you see where your team tends to over- or underestimate, and allows you to understand the velocity of your team. Over time, this builds a library of historical data that can inform future estimates with much greater accuracy. The more consistently you track this information, the more reliable your forecasting becomes, allowing you to spot patterns, plan with confidence, and improve as a team.

Keep in mind that estimates are least accurate early in a project, when many details are still unknown. This is called the cone of uncertainty: estimates start broad and become more precise as the project moves forward and more information is available. Share this with your team and stakeholders so they understand why early numbers may change over time.

Historical data from one team should not be used to judge estimates from another team. It can give a general benchmark, but should not be an expectation or assumption. Every team is different and should be considered as such.

Collaborative estimation

Involving multiple team members in the estimation process can not only result in more accurate numbers but also lead to discussions that highlight misalignment, uncover hidden assumptions, and reveal potential risks that might not have surfaced otherwise. There are many estimation techniques that involve a group of developers. Some examples include:

• Planning Poker: Everyone privately selects an estimate, then reveals at the same time. Discuss any significant differences.

• T-Shirt Sizing: Use relative sizes (XS, S, M, L, XL) rather than exact numbers. Work with your team to create a shared understanding of what each of these sizes means (effort, complexity, time, or a combination of all three) and have some examples of what tasks fit into each category. T-shirt sizing can help teams quickly assess their capacity across many tasks.

• Three-Point Estimation: Ask for three numbers: the optimistic case, the pessimistic case, and the most likely outcome. Use this to calculate an average and make uncertainty visible.

Some teams prefer relative estimation, like using t-shirt sizing or story points. For example, instead of assigning a number of days to a task, the team might instead say, “Task A is twice as hard as Task B.” This can reduce conflict when time tracking feels stressful. The important thing is that these relative ‘points’ are assigned consistently so that, later, they can be converted into timeframes using real velocity data to allow for more accurate future planning and communication with stakeholders.

Subdivide tasks

Large features or tasks are difficult to estimate because they contain too many unknowns. Split these into smaller, more granular tasks until each one feels manageable. Set an upper-limit for how high an estimate can be (e.g. 5 days) and if a task has an estimate higher than that, break it into smaller pieces. Smaller tasks result in more accurate estimates and make it easier to track progress.

Consider Dependencies, Risks, and Buffers

Source: Unsplash

To make realistic estimates, you must account for the unknown, consider risks, add buffers, and map out dependencies that can affect delivery.

Map dependencies

Some tasks cannot start until others are complete. Mapping these dependency chains ensures you know the order of work and where bottlenecks could form. When considering dependency chains, think about whether tasks can be parallelised (completed simultaneously) or must be serialised (completed one after another).

This distinction affects both individual task estimates and the overall project timeline. A project with many tasks that can run in parallel will finish sooner than the sum of all individual task durations, while a project with highly serialised work will take closer to the full total of every task added together. Remember that ‘10 days of work’ on one task might take much longer if those days can’t be done in parallel with other tasks and are waiting for other tasks upstream in the dependency chain.

Parallelisation also affects resource planning. If multiple tasks can run at the same time, you need to ensure you have enough people available to work on them. If work is highly sequential, plan so that team members are not left waiting for someone else to finish before they can start. This might mean reordering tasks, reassigning responsibilities, or identifying small, independent tasks that can be slotted in to keep everyone productive and avoid wasted time.

It is tempting to add more people to speed up development, but this approach can backfire. As Fred Brooks famously stated, “Adding manpower to a late software project makes it later.” Brooks’ Law highlights that adding more people to a project can increase delivery time due to:

• Ramp-up costs: New team members need time to learn tools, pipelines, and project context before they are productive

• Increased communication overhead: More people means more meetings, check-ins, and hand-offs to coordinate.

• Task division limitations: Some work cannot be split into smaller pieces and must be done sequentially, no matter how many people you have.

• Disruption: Core team members lose time onboarding newcomers, further slowing progress.

Estimating early and considering dependencies, parallisation, and team resourcing during this process allows scoping and resourcing decisions to be made proactively.

Identify risks

As you estimate, discuss what might go wrong and document it. A key part of the production process is identifying risks, as well as planning mitigations that will reduce the likelihood of them occurring or their severity if they do eventuate. It’s also important to put contingencies in place, so if the risk does occur, there’s a planned set of next steps that can be enacted.

Predictable events that will definitely happen—such as platform certification processes, public holidays, or exam periods—are called known constraints, not risks. These should be scheduled for directly rather than treated as uncertainties.

Learn more about Risk, Mitigation, and Contigency →

Add buffers

Adding buffers to your estimates is one consistent way of mitigating risk. A buffer gives you breathing room when something unexpected happens.

Buffers don’t need to be consistent across teams or tasks. Low-risk, well-understood work might receive a 5-10% buffer while high-risk or unfamiliar work has a 10-20% buffer instead. Producers might choose to add a larger buffer to teams who are often too optimistic, who are less experienced, or who have less historical data that can be used to validate estimates.

When creating buffers, make them visible and intentional. Communicate them clearly to your team and stakeholders so they understand they are part of good planning, and not something that can be reduced or removed to fit in more work. Ensuring the team sees these buffers being added to estimates as part of the production process will also encourage the team to provide more realistic estimates, rather than adding their own buffers to their original numbers.

Expect change

Estimates will evolve as the project progresses and more information becomes available. Early-stage estimates are inherently broader and less precise. Revisit and revise estimates regularly to keep them accurate and meaningful, and to reassure your team that you don’t need them to provide perfect estimates on their first try.

Present Your Estimates

Once you have gathered realistic estimates from your team, the next step is to communicate them in a way that is clear, useful, and actionable.

Consider your audience

Different audiences need different levels of detail:

• Internal Team: For day-to-day work, use lightweight tools like task boards, shared spreadsheets, or simple documents. Work with your team to determine what information is genuinely useful to them, and create dashboards or trackers that reflect those needs rather than defaulting to a standardised template. If your team is overwhelmed by production tools or doesn’t find them useful, they won’t open them.

• External Stakeholders: Publishers, funding bodies, and teachers may require more formal documentation, such as roadmaps, milestone charts, or Gantt charts. These documents should clearly outline deliverables, dates, and risk management strategies to build confidence in your plan. Communicate early with stakeholders to confirm what they expect, and tailor your documentation to those expectations.

Remember that producers may care about values that both the internal team and external stakeholders would be overwhelmed by. It’s important to present data in multiple ways depending on the audience, as part of the work of translation.

Remember that producers may need access to a deeper level of data than either the team or the stakeholders would find helpful. Presenting information in multiple formats—for the team, for stakeholders, and for their own production tracking—is part of the producer’s role as a translator. The goal is to provide the right level of detail to the right audience, so everyone stays aligned without being overloaded.

Conclusion

On the surface, estimating tasks may sound simple, but it’s actually a complicated and vitally important exercise. Time spent outside the engine can sometimes feel like wasted time, but dedicating effort to estimating throughout your project can help you communicate with stakeholders, mitigate risks, and ensure your team is aligned. Good estimates come from a shared understanding about what the team is doing and why—which can ultimately save time by reducing miscommunication and rework.

When estimating:

• Start by creating definitions together

• Adapt estimation techniques for different teams and avoid being prescriptive

• Iterate on estimates over time and remember that estimates aren’t guarantees

• Identify and expose risks

• Make buffers and contigency plans transparent

• Foster a psychologically safe team environment

With every task, milestone, and project, you will get better at creating estimates and will learn why they are so useful. Treat estimation as a technical skill, like other aspects of your gamemaking craft.

Sources

Bethesda Game Studios. (2012). The Elder Scrolls V: Skyrim Postmortem. GDC Vault

Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.

Cohn, M. (2005). Agile Estimating and Planning. Upper Saddle River, NJ: Prentice Hall.

McConnell, S. (2006). Software Estimation: Demystifying the Black Art. Redmond, WA: Microsoft Press.

Pressman, R. S. Software engineering: A practitioner’s approach (7th ed.). McGraw-Hill.

Schreier, J. (2018). The Horrible Crunch Time Experience That Nearly Killed The Team Behind This Indie Game. Game Developer. https://www.gamedeveloper.com/business/the-horrible-crunch-time-experience-that-nearly-killed-the-team-behind-this-indie-game