I define an increment as an addition to a system under development that extends, enhances, or refactors the existing parts. First, it changes the product in a way that stakeholders can see. For example, a new feature, an improved workflow, or a refactored module can all form a deliverable. In agile development, each iteration normally produces one increment. Therefore, these additions drive visible progress.
I use increments to deliver business value early. In practice, the first increment often aims at a minimum viable product (MVP) or a minimum marketable product (MMP). Next, I add further increments that increase value. In addition, I prioritize increments by business value and risk reduction. Thus, I maximize the product value with every release.
I also treat this as part of versioning. Version numbers usually have two parts: the version and the increment. In principle, I start the version at zero while I develop the work product. Then, I assign version one when I formally approve or release the product. Meanwhile, I start it at one. I increase it every time I make an externally visible change. Moreover, I may use a sub-increment for typo corrections only. Sometimes teams use increment nine to mark a final draft before approval or release.
I recommend managing versioning at the work product level. In that case, all requirements in the work product inherit the work product version and change history. Otherwise, version numbers for many small requirements soon become confusing. Also, I keep an archiving and cleanup policy. For example, I restore older versions only when needed. Because storage is rarely unlimited, I archive or delete work products that no longer serve the project.
I use increments for product validation. Each time I release a new increment, product owners and stakeholders validate the product. For example, I schedule a sprint review or product demonstration. In that meeting, I show the integrated product increment. Thus, stakeholders can assess end-to-end features. In large-scale development, I integrate all team deliverables into a single increment worth validating. Then, teams coordinate via a delivery roadmap to sync release milestones.
I emphasize clear rules for when to assign a new version or increment. I assign a new version number for each formal change. However, I normally do not change the version for a life cycle state change alone. Instead, I change the increment when content or text changes in a visible way. This approach keeps the history meaningful. Finally, I keep requirements at the right level of detail. I refine only those requirements that will be implemented soon. In this way, I maintain focus. Moreover, I enable fast feedback and continuous improvement with every increment.