Once we have our captured our requirements. We identify the substance of the content for the iterations from the development.  In fact, recall from the requirements prioritization blog post. That work has given us some insight into how the iterative packages could be developed and what content or capabilities are to be delivered.  In the end we will essentially have a road map of the functions with defined revision level of the products (hardware and software), associated feature content along with a schedule. We provide a brief example below:

• Package A content
  • X features
• Package B content
  • Y features
  • Corrections due to Package A
• Package C content
  • Z features
  • Corrections due to Package B
• Package D content
  • Corrections due to Package C

Each subsequent package will add some portion of the remaining requirements as well as corrections from previous package. This is the incremental, iterative development of the product or service.  If we are developing a system, we will manage the packages for all of the system interactions required to produce some defined level of system functionality for each package delivered.  Consider an automotive subsystem for example, that contains instrument cluster aspects as well as supporting elements from another controller on the network such as the brakes.  To produce a functioning set of features we will synchronize the delivery of these two components so we are able to work with the feature and learn and assess the product. We will discuss the assessment at greater length in subsequent blogs.

With each package we will steadily grow the product or service capability until we either:

•  Meet the total list of product capabilities and the project objective,
• Realize that we cannot meet the final intention we had desired and terminate the project.
• Run out of money to develop the product or service
• Run out of customer mandate for the product or service

Ultimately we learn from each of the iterations, addressing problems found and unexpected or unanticipated circumstances that always attend project work.  We reduce the risk in this iterative incremental approach rather than one release and a test at the end when there is no time to adjust and everybody is shouting to deliver something!