The aim of a single Iteration in an IterativeDevelopment process is to deliver something of concrete measurable value by the end, something that the business will recognize as a concrete increase in the value that the software delivers.
The detailed structure of an iteration varies from project to project, depending lots of different variables including team-size, the nature of the relationship to the users, the complexity of the problem domain and so on.
All AgileDevelopment projects share in common that during a single iteration the development team is focussed on the delivery of a concrete set of requirements, from analysis through to completion to the point where, from the team's perspective, the code is ready to deploy into production.
In [:LargeProjectIterationStructureExample: larger projects] the structure of an Iteration may be fairly formal, in smaller projects less so, but most will follow the following sequence in some form:
At the end of the previous Iteration...
- Behaviour implemented in previous iteration is reviewed by the users.
- The performance of the team in the previous iteration is reviewed, to see if they can identify any ways to improve their productivity.
- All of the [:Story: stories] that have yet to be developed are reviewed and prioritized by the business, including any new [:Story: stories] that seem good candidates "Note: This could include re-work from the previous iteration if the users have changed their minds or don't like what has been developed"
- The rate at which behaviour was delivered in the previous iteration defines how many [:Story: stories] can be planned for in the next iteration.
In most projects, all of the [:Story: stories] to the end of the project will be re-assigned, if necessary, based on the new priorities, and based on the productivity of the team a CostToComplete is extrapolated.
At the start of each Iteration...
- The team get together and review the [:Story: stories] that are to be developed in this iteration.
- Developers and analysts sign-up for the [:Story: stories] that they will work on.
There is often a NarrativeReview of some kind.
Developers do EnoughDesignUpFront to build on their shared mental model of the system.
During each Iteration...
[:Analyst: Analysts] will collaborate with [:Tester: Testers] to define AcceptanceCriteria for stories in-play.
Developers will work with [:Tester: Testers] to develop an ExecutableSpecification that will prove that the AcceptanceCriteria are met
- Developers will work with [:Analyst: Analysts] to explore the requirements in enough detail to build the system.
Developers will do EnoughDesignUpFront to maintain the coherence of the code base.
Developers will develop code to implement the behaviour defined by the ExecutableSpecification