Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Waterfall Game Development Done Right
View All     RSS
October 25, 2020
arrowPress Releases
October 25, 2020
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Waterfall Game Development Done Right

November 21, 2012 Article Start Previous Page 2 of 3 Next

Build a Rough Order Magnitude Estimate (ROM)

If we feel comfortable moving forward under a fixed priced contract, it's time to do the second analysis of how, and how much. We will also do the first analysis of when. We use Excel.

First take a look at your set of features and implementations. It's time to define some milestones. Milestones are waypoints towards your end goal of delivering the product. A good milestone is measurable and defined by the outcome of your work. Write these down as eloquently as possible. Hopefully, you can describe 90 percent of the milestone in one sentence. A detailed description of the milestone is best described as a test plan written by QA. If a developer can test their work before it gets into the hands of QA, the less time you will need to iterate.

Milestone Definition: The first play experience of Level 1.

At each milestone, think about the steps you will need to take to reach that outcome. Look at your implementations and segment them in a way that puts risker items earlier in the development process. Why? Because if an implementation goes awry, you can tell your customers as soon as possible so that you can work together to resolve it. A lack of time is your biggest enemy when things go wrong.

Many project managers forget the following tasks. Set aside time for the following:

  • Shims (scaffolding code required to stand-up an implementation or increase testability and efficiency)
  • Refactoring before milestones build on new code foundations
  • QA
  • Reactions to QA (why find a bug if you aren't going to fix it)
  • Usability
  • Customer Feedback and correction time

Now that you have your milestones, write them down. Add in the implementation tasks. Use a hierarchy to help you organize work and decompose as necessary. A simplified snipped of a ROM might look like the following:





Milestone 2 -- User Kills a Simple Enemy


Art & Design


Build Level



Build Initial Player Character



Build Initial Weapon





Implement Player Damage



Implement Basic Enemy AI



Implement Enemy Damage



Implement Enemy Death



A snippet from a ROM. We prefer to use estimates in hours, but sometimes days makes more sense.

For each line, develop an estimate. But before you start, we need to think more carefully about what an estimate really is. At GarageGames, we believe an estimate is a time and risk estimate. Let's take a second to really understand how GarageGames determines risk adjusted estimates, it's critically important.

Note: When estimating, we always use work effort which is the total work required to complete the job. Duration measures how much calendar time it will take from start to finish. For example a 16 work effort hours can have a duration of 8 hours if two people are working on the task.

Risk Adjusted Estimates

Let examine two estimates: Task A is a non-risky job you've done before. Task B is a risky job you've done before. Assume for a second that I've asked the engineer to give me an estimate for each and in both cases, they say two weeks.

Beware: In this case, two weeks does not equal two weeks.

More often than not, undiscovered work will cause job B to take longer than expected. It's likely that two weeks REALLY means: "two weeks if everything goes the way I hope it will." It's probably more accurate to assume that the job will take two to four weeks. Since we don't really understand all ramifications of a risky task until we do it, we really can't be very accurate. Some people pad the estimate; we prefer something a bit more pragmatic, descriptive, and standardized.

With every estimate, GarageGames uses confidence to determine a risk adjusted estimate. So if we include confidence numbers, the two estimates might look more like this:

Task A: 2 Weeks, Confidence: 9

Task B: 2 Weeks, Confidence: 4

To calculate the risk adjusted estimate, GarageGames uses the following function:

Risk Adjusted Estimate = Estimate + (Estimate*(10-Confidence)/9)

Task A: Risk Adjusted Estimate: 2.2 Weeks

Task B: Risk Adjusted Estimate: 3.3 Weeks

Having the confidence value represented is useful for more than just determining risk adjusted estimates. As stated earlier, finding ways to reduce cost for a project is something that we openly embrace. Low confidence numbers are expensive and clients are motivated to help you increase confidence numbers to reduce cost. Before writing a single line of code, you can reduce risk the following ways:

Cutting a Feature -- "We didn't need it anyway... It's not that important."

Constraining a Feature -- "What if it did half of what we were hoping for."

Defining a Feature Better -- "Oh, I didn't understand what that meant... That's not so risky now."

Rapid Prototyping - Allowing time for rapid prototyping early in the project (and then updating the estimate ex post facto) --"Eureka!"

This is a great time for leads to share estimates with those who need to actually implement the task. It's hard to have developers who are vested in delivering a project if you didn't consult them initially. They are usually quite motivated to help. It's during this phase that implementers will ask you, "What does this task actually mean?" You will need to work with them and the customer to define what the implementation will or won't do. Save this definition, it will be important later.

Now that you have all the estimates, confidence numbers, and risk adjusted estimates, you should be able to provide your first estimate of when the project will be complete. Add up the risk adjusted estimates and divide it by full-time employee team size (two half-time employees equal one).

This isn't a very accurate estimate because it assumes a perfect world where everyone can do every job perfectly parallel -- hardly the case. But at least you will have some data to help you understand the very best case very high-level ball park figures. If someone wants a task done in 6 months and your estimate says you'll be done in seven months, you'll know early that something needs to change.

Same goes for the risk level. Average the confidence numbers. If the confidence numbers are too low (below, say, a 6), then maybe it's time to suggest either 1) moving to a time and material contract or 2) doing a small fixed bid contract up front to rapid prototype in an effort to bring up confidence numbers.

Keep in mind that while you are working on estimates, you will be defining the project or asking questions that will lead to the definition of the product. Write them down in small one or two page descriptions and save them. You will use them to develop the Statement of Work.

The final step is to share it with your customer. Show them where the risk is high and tell them why. Discuss opportunities to save money by reducing risk.

Article Start Previous Page 2 of 3 Next

Related Jobs

Strange Loop Games
Strange Loop Games — Remote, Remote, Remote

Programmer on PC game 'Eco'
Insomniac Games
Insomniac Games — Burbank, California, United States

Character TD
Camouflaj — Bellevue, Washington, United States

Senior Graphics Engineer
Camouflaj — Bellevue, Washington, United States

Animation Engineer

Loading Comments

loader image