Most software projects have a schedule that's shorter than the engineers and project mangers would like, and also excruciatingly long in the opinion of marketing and customers. In the negotiations that take place to bridge this gap, the typical outcome is to prune the requirements specification until it is, allegedly, the minimum that customers will accept.
This is wrong! Managing a software project this way is a bit like going fishing with a shopping list that says "1 halibut, 3 mackerel, etc." - unrealistic. You won't be able to catch exactly what you set out for, although if you know what you're doing you should be able to catch enough fish. You have only a little bit more control over your software deliverables.
Now, you're a good project manager, so you know to estimate all the items and get the mean estimate right: you'll overestimate some and underestimate others, so your project is supposed to balance on average. But unfortunately it won't. You'll get the geometric mean right in your estimates, so out of your myriad 10-day tasks some will take 5 days and others will take 20, and your project will be something like 25% late as the times add up. The wider the deviation, the bigger the slip.
If your project is so tightly constrained that you have to implement all the items, you're left with the thankless task of predicting the chance of completion at various dates, or trying to estimate in minute detail to get more confidence. For most projects involving real customers, there is a better way.
You have to specify more items than you hope to deliver, so that you can choose those that turn out to be easier as you progress. For example, say your customers expect 100 features of equal value. 50 of those you absolutely have to do, and you encounter some technical problems so you use up 75% of your time. If you had 100 items in your spec to begin with, chances are the other 50 would take the other 75% of the time.
But if you had 200 items in your initial spec, you can probably find, out of the 150 that remain, some 50 or so that you can implement within the remaining 25% time. You couldn't have chosen those at the outset, and certainly your marketing team couldn't have chosen them for you. The choice depends on how technical factors turn out during the project.
So, what you need to do is agree with your product management an expansive set of desirable features, and a way to consult or empower you so you can choose which ones to implement along the way. You also need a way to convince your boss that you're in control of something that does not look at all like a waterfall. That is left as an exercise for the reader.