[dcastonguay]

This isn't my understand of what the parent commenter is trying to communicate. I think the point that they're trying to make is this:

A chef could originally decide that a dish is only complete if it is garnished with a terribly rare ingredient that costs an enormous amount of money; this would be analogous to a dev team lead deciding that a new feature will only be considered complete if it covers non-primary use cases or specific pieces of functionality that will add a substantial amount of time to the overall development estimate.

The parent comment is saying that defining that 100% is part of what will impact your possibility/rate of success or failure; the 100% is not predefined or intrinsic, it's a place in time / level of progress that you need to carefully define. If rarity and cost keep you from obtaining the "finishing" ingredient 80% of the time that you make the dish then you're setting yourself up for failure. If you define the feature as only being finished when it covers nearly every sub-feature you can think of then you're setting yourself up for failure.

There also seem to be analogies between quantity and quality. You can get 80% of the way through a feature and decide it's "good enough". The leftover 20% could either be bugs that needed to be fixed or additional features. I don't think leaving out some additional features would be considered skipping the "finishing" phase, but leaving serious unresolved bugs almost definitely would be. An undercooked dish is nearly useless, but one missing a garnish is not.