Highly-effective agile teams deliver user-valuable software incrementally and iteratively. What’s the difference?
An increment is “something added as part of a series of regular additions.” Scrum relies on incremental by employing the user story (originally promoted by Extreme Programming and written about extensively by agile champion Mike Cohn). The user story is the fundamental building block of how sprint commitments in Scrum are managed. Incremental delivery relies on intra-sprint-based “vertical slice” delivery, in which new features are divided up like sashimi – as thin as the skill of the chef can accomplish. Effective vertical slicing is a best practice in Scrum and XP because incremental delivery minimizes uncertainty in any given sprint and release, throughout the development of a complex product. Vertical slices follow the INVEST rules for user stories:
- Independent, end-to-end, “shippable” increments of the emergent whole. The slice could be delivered fully tested without any other product increment and create value for the user or owner.
- Negotiable, in planning and expectations with users and stakeholders, allowing delayed incorporation of enhancements or, if a major pivot becomes necessary, easily removed from the product roadmap (without previous over-engineering, over-planning, or over-documentation).
- Valuable to the user or owner, likely in a way that is sufficiently noticeable that it is monetizeable.
- Estimable by the delivery team because the User Story does not generalize or hide uncertainty. An inestimable story is often an Epic. It is either complex enough to warrant a technical spike or compounds enough feature work that it should be broken into independent, smaller, user stories.
- Small enough to be estimated by a team, with certainty, and deliverable fully-tested within a single sprint.
- Testable by virtually any team member because the expected outcome is qualitatively or quantitatively noticeable (as part of its being value) to the target user.
The INVEST method for user stories ensures that planning and development occur just-in-time so that the emergent product can regularly evolve in response to changing stakeholder demands. More importantly, in the fast-paced markets in which agile/scrum/lean/xp programs compete today, incremental delivery maximizes the freedom to release the Minimum Viable Product and pivot in a new direction based on real-time feedback from users.
An iteration is “a repetition of successive approximations in which progressive versions evolve to a desired level of accuracy.” Iterative delivery relies on an openness to prioritizing value that is good-enough rather than perfect. The perfection of a single feature or a single screen, as defined by one Stakeholder, Architect, UI Designer, or Engineer and taken out of the context of the overall emergent product leads to unnecessary delays, lack of decisiveness, and delayed time-to-market and ROI. The Scrum team avoids working in a silo through collaboration, entrusting the Scrum Product Owner with accountability for decisions. In contradistinction, over-analysis and churn prior to meaningful user feedback is utterly inefficient and ineffective. Thus, while Just-in-Time vertical slices maximize the freedom to bring Lean MVP’s to market and pivot as appropriate, iterative and “just-enough” Lean delivery is equally critical to ensure that increments can evolve based on user feedback instead of non-plans made due to (unnecessary) fear of scrutiny.
Connect With Me:
2 thoughts on “Incremental AND Iterative Product Delivery”