short link: http://goo.gl/kn8Mll
Also Known As:
Motivation: There is a risk that when a system is delivered it will not prove fit for purpose, or that certain features will be delivered too late for a maximum return on investment. This risk can be managed by the regular and timely delivery of system features that have been usefully grouped, and which are potentially releasable in themselves.
Structure: A development team plans a Sprint Backlog with a Product Owner. The Sprint Backlog chosen will be drawn from the Product Backlog, and in line with an agreed Sprint Goal. It will represent those items which the Product Owner considers most appropriate and timely for a return on investment on the project. The team must also be satisfied that they can in fact deliver an increment of corresponding value by the end of the Sprint (iteration) to the Product Owner. Once the Product Owner is in receipt of the increment, he or she may then choose to release it. The value delivered will be reviewed, and the process followed can be retrospectively inspected and adapted to improve value further.
Applicability: Incremental release is appropriate for project work where scope risk and delivery risk are high, and that work can be batched in terms of meaningful intermediate goals. It is less appropriate for Business As Usual work consisting of discrete and isolated changes.
Consequences: Incremental release implies that work will be batched, and that each constituent item may not be delivered prior to that release. Items that could have been delivered earlier than the end of the Sprint will therefore have their return on investment delayed.
Implementation: Incremental release is a core feature of Scrum, XP, and DSDM. It is less commonly found in Lean Kanban and DevOps approaches, where continuous integration and deployment techniques are rather more likely to be in use.