Will Scrum Projects Ever Be Complete?
The purpose of each sprint is to deliver increments of the product that are complete in themselves even if the product is not complete as a whole. In the example of home building, an increment of a sprint could be to finish the foundation, standup the framing, or build a retaining wall. Each increment can be complete in itself without the house being finished. As in the example of the house, every increment is accretive to all prior Increments and thoroughly inspected, so that all increments work together.
To ensure transparency, everyone on the scrum team must have a common definition of what it means to complete an increment of the product. In some cases, such as the case of writing these blog posts, building a house, or pursuing a negotiation, the definition is straightforward. In others, and particularly in the case of developing software, the definition is more ambiguous. When the software is done, does that mean that the software is in production, or ready for testing, or executable, or compliable? It is more important to have a shared definition of what exactly complete means to the team, than it is to have a standard definition.
Since software algorithms fall into a class of mathematical problems that resist proofs and can only be proven to be correct by trying every possible combination and permutation there will always be bugs and defects. Quality is perhaps the most elusive aspect of software and, I suspect, always will be.
The definition of complete guides the development team when considering how many product backlog items it can realistically select during a sprint planning. It helps them deliver an Increment of product functionality with every sprint. If the increment is useable, the product owner may choose to immediately release it. But work on an increment can be done without being finished. Some organizations have conventions, standards and guidelines for development that all scrum teams must acknowledge in their planning.
If there are no conventions, the development team must define what makes an increment complete for itself. If there are multiple scrum teams working on a bigger system or a product release, the development teams of all scrums must mutually agree to the definition.
As scrum teams progress, it is typical for their definitions of complete to mature. New definitions of complete may expand the work by demanding previous increments be reworked to fit the new standard. This is usually a good thing and results in the end in a better product.
An important part of every sprint planning meeting must be to review, define or redefine what complete will mean at the end of the sprint. Only in this respect can scrum projects be said to be complete.