1a. Make (but don't immediately communicate) a best guess based on initially determinable requirements (functional and non-functional), which includes a large a

1a. Make (but don't immediately communicate) a best guess based on initially determinable requirements (functional and non-functional), which includes a large amount of contingency. [It is ideal to understand the problem with "use cases" and "stories" is that they are a poor building block for estimation and development because they inevitably require further and further decomposition.] 1b. Formally (in writing) present the estimate, together with the known requirements upon which it is based. 1c. Include in writing that changes in requirements (and undiscovered requirements) w ill affect the estimate. 1d. Document and immediately communicate in writing all new and changed requirements. When your boss's boss (inevitably) asks him what the problem is with this project taking so long, and he responds to him that you the developer (or team) "keeps finding problems and more work to do", you can at least rely on a written record of the project's changing scope.