A real example: My boss asked me how long it would take me to deploy the software on a new piece of hardware and run through the manual acceptance test procedure. I'd done the test procedure on other systems before, so I knew the whole thing took about 2 hours. I also know that deployment, installation, and configuration takes about 30 minutes. There are other factors, but let's just take these. I could very well say that it will take me 3 hours to do everything that was asked...assuming that the system was on the network. My assumption was that IT had done their configuration of the machine to put it on the network, and I could just log on and deploy the software. If they hadn't, my estimate would be blown already, since I couldn't do anything until that happened.
Assumptions aren't "evil things that like to stay hidden". They are things that you are counting on to have happened that are out of your control. You can present your estimate with these assumptions that these other things have happened, and outline what exactly you assumed would happen.
By enumerating and making your assumptions known, you didn't make an ass out of yourself. In fact, everyone's now on the same page. If you get into the situation and something didn't happen, you can point to the assumptions that you based your estimate on and then reestimate based on your newly found knowledge that the original assumptions were wrong.
You won't be able to account for everything. Some things will be overlooked. The only thing that you can do is keep track, learn from your mistakes, and get better next time. That's why you (especially at a project level) reestimate frequently - NASA's Software Engineering Laboratory estimates once at the start of the project...and then again 5 times throughout the project, revising based on clarifications, information learned, risk analysis, and assumptions made.
It might be a simple approach, but why don't you calculate your velocity as completed story points * capacity or completed story points / capacity, depending on how measure capacity. If you measure capacity in man-hours, use the second. If you measure capacity as a percentage of a 40-hour week, use the first. When you go to pull off story points, you should have a good idea about your capacity for a given sprint, and use your project's historical data to determine the story points completed for a given load.
However, this makes some potentially dangerous assumptions, such as treating all employees as equal - if your most junior developer takes a week off or the developer with the most experience in the domain and/or technologies takes a week off, your capacity will be the same numeric value, but the impact on velocity would probably be different.
Ultimately, use professional judgement based on historical data when planning a sprint. In this case, use previous velocity as an input into some other estimation scheme, involving the team. I would also err on the side of caution - it's easier to pull more work into a sprint than it is to remove a commitment to do a task.
Best Answer
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.
It could be a firm, fixed price that will establish an upper limit on the budget and a lower limit on delivered functionality.
It could be a ballpark price used to reverse engineer an hourly rate used to qualify you as a resource.
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.