for lower frequency tasks performed by lower priority users with strong computer or domain skills. Simply put, a feature can be a little rough around the edges if it's used infrequently by a smart user who isn't one of the user types we really cater to. A feature like this may be a candidate for a "knot on the end of a rope," as opposed to the "two-roped seated swing" we initially put into scope and estimated.
Yes, I know it's usually not that cut and dry. But, knowing users, tasks, the frequency of each task, and its importance sure helps find opportunities to scale. To act on scaling opportunities, you'll need to be good at proposing alternative and cheaper solutions that help those users accomplish their tasks and meet their goals.
While this helps to cut scope as a release draws near, these are important details to consider when initially scoping the project. For each proposed feature of the product, consider the user and task supported. Consider the possible range of design solutions for that user. Is the solution chosen in line with the user and task supported? Are we spending more time building better solutions for our most important users engaged in their most frequent and critical tasks? Consider deferring detail designs until closer to implementation time.
Trap user tasks as requirements. To estimate, discuss the range of possible solutions, then give a rough estimate on the most likely solution. Plan your project around those estimates, and consider keeping notes regarding the range of solutions with your estimates as a reference. Resolve detail design when development time draws near--by then you should have good information about other features, time constraints, and development capacity.
Leave room to rescale. Although being alert to appropriate scale is important, slicing feature scale too thin and too early leaves little room for rescaling in the future. If you postpone choosing detail design solutions for user tasks until later, keep your initial estimates on the high side of moderate. This will allow you flexibility to raise and lower scale as time allows, based on user and task priority.
The next time you feel cornered and compelled to drop a feature from scope in order to reach a delivery, go back to the users, goals, and problems that motivated the particular solution in scope. Look at other alternatives that might allow you to still solve the problems at a lower cost. Rescale the feature, don't de-scope it.