Scope creep doesn't exist

The title is controversial, but if you think about it is true. Using a common refrain I have observed that a segment of software is experiencing scope creep, as in this is taking longer because what it means is not comprehensive or complete with respect to the end goal.

Baseline Situation

I am saying is that this will never happen if you are adhering to a customer centric or agile approach. A code feature is either done or not done. Arguing over is this in the specification or not is unproductive and not relevant to satisfying the requirements. Trying to discern the complete specification at the beginning is impossible, why are you performing contractual legal wrangling over is this particular situation spelled out and handled?

Consider

If you go back you will realize that at the beginning you had the least amount of knowledge on the impact and changes needed and as you build and work towards your goal understanding and specifications grow i.e. (scope creep occurs). This is natural and expected, there is no need to call this out or to make claims for redo of rules. It doesn't matter you need to complete the task to what the end goal is and that goal is always going to be a series of steps to a customer as no software is ever done.

The grading of completeness must have multiple stages as in this is done for now it does 50% of what we needed at the start, but only 10% of what is needed in actuality now so continue to work on it and expect and relish that there are changes. In that case the process is working and should be praised that new requirements are coming in to better complete the task at hand.

Further Notes

I will say that the default situation of the majority of programmers is not of direct awareness of the customer. Their goals are to complete a set of points or internal key performance indicators and in that way they build out a skewed worldview that rewards blocking changes to improve the decisions made on their performance as they are told they are going to be judged by those factors by management.

This is symptomatic of say any organization in my experience that has more than 5 programmers. After this a tipping point happens that the programmers are insulated and separated from seeing direct impact of their labors and lose contact with what is directly important to the business:

Customers and delivering working software to customers.

To be clear let me state that customers care about tests, code quality, security as secondary and baseline expectations, but those are all extras to them. They care for completeness, capabilities, and cost foremost.

You could have no tests, atrocious code quality, zero security and if your software is cheap, complete and capable they will use it and love it.

Case in point credit card software that just works, no one is asking those deep questions unless there is a security hack.