Prioritization is only one piece of the scope puzzle. After all, if we could do all the work, the prioritization would be unnecessary. If we can't do all the work, we still haven't figured out how much we can do, and therefore, we do not yet know where to draw the baseline for the project.
Table 18-1. Prioritized Features List
The next step is to establish the rough level of effort implied by each feature of the proposed baseline. Doing so is tricky since little useful information is available yet on which to estimate the work; we have no detailed requirements or design output on which to base an estimate. The best we can do is to determine a "rough order of magnitude" of the level of effort for each feature.
Estimating effort at this early time is a learned team skill. The engineering team will be naturally reluctant to provide estimates before feasibility and requirements are fully understood , and yet the first cut at scope management must happen before this next level of detail is known.
Let's assume that the product or project manager is the champion for our project and has the following dialogue with the developers for the project. 
Why can we not allow for a process that creates detailed requirements and design information for each feature so that we can create more meaningful estimates? Isn't that the professional way to approach the problem? If the schedule provides time for more detailed estimating at this time, by all means do it!
However, we believe that it is crucial to be able to make some quick decisions about the scope of the activity without a more detailed estimate. Why? Because to do otherwise invests resources in what will later be determined to be " wasted inventory," including requirements specifications for features that will not be implemented, design information for those features, test scripts for requirements that will be scope-managed out of the project later, a false determination of the critical path for the project, and so on. We cannot afford to invest any resources in these scrap-producing activities, or we will fail to optimize the resources invested. In other words, scope management will reduce the number of features that will be developed in the initial release, and since resources are extraordinarily scarce , we cannot afford any additional investment in features that are not going to be implemented in the current baseline. Table 18-2 illustrates the addition of effort information to our feature list.