In agile product development, an Increment (often “Product Increment”) is the working output of an iteration that builds upon all previous work. Each Increment is the sum of all “done” Product Backlog items completed so far. For example, the Scrum Guide defines an Increment as “the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints” – and requires that each new Increment be “Done” (meeting the team’s Definition of Done) and be in usable condition . Similarly, Scrum Alliance notes that a product increment is “whatever you previously built, plus anything new you just finished in the latest Sprint, all integrated, tested, and ready to be delivered or deployed” . In practice the Increment must be potentially releasable: it meets all quality criteria so it couldbe shipped, even if the Product Owner decides not to release it immediately.
In all mature agile frameworks (Scrum, LeSS, Nexus, etc.), increments are cumulative: each one builds on the prior Increments, with no gaps or rework left behind. For example, LeSS insists that teams produce a Potentially Shippable Product Increment each Sprint, integrating all teams’ work so that “no surprises” (no undone work) remain . Nexus (Scaled Scrum) likewise mandates an Integrated Increment each Sprint – “the current sum of all integrated work” by all teams toward the Product Goal – which must meet the shared Definition of Done . In short, an Increment is a finished slice of product (often vertical feature slice) that adds to the existing product and is thoroughly tested, integrated, and of high quality .
Context (Agile Frameworks & Cadence
Across agile models the Increment is the primary artifact for each iteration. In Scrum, each Sprint produces a single Increment, and the Sprint Review inspects that Increment and adapts future plans as needed . In LeSS, multiple teams deliver one Potentially Shippable Product Increment per Sprint, keeping a “whole product” focus by integrating all work before sprint end . In Nexus (Scrum@Scale), a small group of Scrum Teams works from one backlog to deliver one integrated Increment each sprint – again, combined work of all teams that meets the Nexus Definition of Done .
Definition of Done: In all cases, “Done” means each increment adheres to a strict Definition of Done – ensuring it is truly complete. As the Nexus Guide emphasizes, the Increment is only “done when [it is] integrated, valuable, and usable” and must meet the agreed DoD for the product . This shared DoD assures quality and potentially releasable state.
Cumulative & Releasable: By definition each Increment is additive to prior work. It contains the latest working product plus all previous increments (nothing is thrown away without notice), so the “sum of all increments forms the product” . Because each increment is releasable, teams can get real user feedback and pivot quickly. Incremental delivery enables faster feedback and adaptation: “incremental releases allow for fast feedback, quicker innovation, continuous improvement, [and] rapid adaptation to change” . Conversely, failing to produce a usable increment each cycle delays value and learning.
SAFe (ARTs and PIs): In the Scaled Agile Framework, the same Increment concept applies at multiple levels. Each Agile team still produces a “team increment” every sprint (iteration) that meets DoD. These team increments feed into the Agile Release Train (ART), which integrates the teams’ work. SAFe organizes work into Program Increments (PIs) – fixed timeboxes (often 8–12 weeks) during which an entire ART delivers incremental value. A Program Increment is essentially to the ART what a Sprint is to a Scrum team: it is “a timebox in which an ART delivers incremental value in the form of working software or systems” . Over the course of the PI (composed of several sprints), teams plan and execute features aligned to PI objectives. At the end of the PI an Integrated System Demo (or “Inspect & Adapt”) shows the combined increment of all teams. In SAFe, cadence-based events (Sprint Planning/Review and PI Planning) ensure that team increments regularly sync up. SAFe literature notes that during a PI, teams engage in Inspect & Adapt exercises and hold an “Integrate & Demo” at the PI boundary . This cadence ensures that increments remain coordinated: by each iteration’s end the ART has an integrated working system (the system increment) that supports adjustment of priorities.
CALADE Perspective (Transformation Increments
In a similar spirit, CALADE applies the Increment concept to organizational change itself. CALADE divides a transformation project into Transformation Increments (TIs) – fixed-period timeboxes (often one quarter, ~3 months) during which specific change initiatives are delivered. At the start of each TI (“Transformation Increment Planning”), leadership prioritizes a set of top transformation themes or epics for that quarter . These epics are broken down into actionable transformation features for teams to execute. By the TI’s end, the organization expects concrete results (new processes, pilot projects, training outcomes, etc.) and collects relevant metrics. This deliverable-increment approach makes progress visible and measurable. Each Transformation Increment yields feedback – what worked, what resistance was encountered, what metrics moved – and this learning feeds directly into the next TI’s plan .
This “agile transformation” cadence combats change fatigue and enables adaptive steering. Because changes are introduced incrementally, stakeholders see regular improvements (quick wins) rather than one overwhelming upheaval. The ability to measure outcomes every TI also means the transformation roadmap can be constantly refined: objectives and backlog are adjusted based on real evidence . As one transformation case study notes, this process is iterative: the “learning and feedback of each increment informs the next increment of changes” . By using TIs, CALADE ensures collective steering toward goals and keeps transformation efforts focused and purposeful . In short, the Increment model in transformation work creates cadence, visibility, and continuous learning just as it does in product development.
Expert Takeaways
- Empirical foundation: Treat each Increment as an experiment and transparency point. The working Increment is the primary measure of progress every cycle; inspect its results (through demos/reviews) and adapt the backlog or strategy accordingly .
- Quality enabler: By insisting each Increment meets the Definition of Done, teams build quality in (not bolt it on). This prevents technical debt: if an Increment isn’t truly shippable, the team stops and refines until it is.
- Systems thinking: Delivering increments means building end-to-end slices. Teams must integrate architectures, dependencies and cross-cutting concerns each sprint. This “whole product” focus (as emphasized in LeSS and Nexus) forces teams out of silos and toward overall system quality .
- Fast learning cycles: Frequent increments accelerate learning. Each Increment is an opportunity to validate assumptions with real users or stakeholders. Rapid feedback loops shorten the learning cycle, enabling faster innovation and continuous improvement .
- Cadence aligns teams: The rhythm of iterations or PIs synchronizes people. In SAFe, consistent sprint/PI cadences coordinate teams on an ART. In transformations, regular TIs align leadership on progress reviews. This regular cadence (and the cadence of reviews/demos) enhances predictability and integration.
- Manage risk and fatigue: Small, releasable increments reduce risk. By delivering in increments, large uncertainties are broken into smaller bets. In change initiatives, shorter TIs prevent overload – stakeholders absorb change gradually and see tangible results each cycle.
← zurück zur Übersicht