Development Process – How to Infer Assumptions for Time Estimates

From The Pragmatic Programmer: From Journeyman to Master:

What to Say When Asked for an Estimate

You say "I'll get back to you."

You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.

In the section, the authors recommend the following process:

• Determine the accuracy that you need. Based on the duration, you can quote the estimate in different precision. Saying "5 to 6 months" is different than saying "150 days". If you slip a little into the 7th month, you're still pretty accurate. But if you slip into the 180th or 210th day, not so much.
• Make sure you understand what is being asked. Determine the scope of the problem.
• Model the system. A model might be a mental model, diagrams, or existing data records. Decompose this model and build estimates from the components. Assign values and error ranges (+/-) to each value.
• Calculate the estimate based on your model.
• Track your estimates. Record information about the problem you are estimating, your estimate, and the actual values.
• Other things to include in your estimate are developing and documenting requirements or changes to requirements specifications, creating or updating design documents and specifications, testing (unit, integration, and acceptance), creating or updating user's manuals or READMEs with the changes. If 2 or more people working together, there's overhead of communication (phone calls, emails, meetings) and merging source code. If it's a long task, account for things like other work, time off (holidays, vacation, sick time), meetings, and other overhead tasks when picking a delivery date.

what common assumptions do you include with your estimates

Every single "fact" provided by the customer is listed as an assumption.

Those are the common assumptions.

Everything else is just fluff. You can write down lots of fluffy things like you assume that plague doesn't break out, and zombies don't arise and eat our brains, but none of that makes any sense to a customer.

Taking their "facts" about the development effort, and relabeling each "fact" as an assumption makes it clear that everything is fanciful.

Then.

Study up on Agile methods and be sure to identify that -- really -- it's a matter of priorities and budget. You'll build things from most important to least important and they can stop you at any time.

There are several -- irreconcilably different -- "intents" for an estimate.

1. It could be a firm, fixed price that will establish an upper limit on the budget and a lower limit on delivered functionality.

2. It could be a ballpark price used to reverse engineer an hourly rate used to qualify you as a resource.

3. It could be a cost number that goes into a cost/benefit decision.

Until you know what the "intent" is, the nature of the assumptions will vary. There's no single right answer until you actually define the customer's intent.