#### 7.2.2.3 Iteration Plan In its minimal form, the Iteration Plan is the set of Work Items - a subset of the Work Items List (WIL) - which are planned for the upcoming iteration. It includes the Iteration start and end dates, the Iteration Goal, defined by the Product Owner (PrOw) and committed to by the Agile Project Core Team (A-PCT) and the list of all the work items that must be delivered to achieve the Iteration Goal. Additionally, the Iteration Plan may need to capture synchronisation points with other teams, especially if they are in different projects. This artefact is also used to refer to issues, risks, etc, that need to be solved during the iteration. The Iteration Plan helps the Agile Project Core Team (A-PCT) monitoring the progress of the iteration (using an Iteration Kanban board and burndown charts, for example), and keeps the results of the iteration for assessment that may be useful for future improvement, based on the outputs of the Iteration Review. The main purpose of the Iteration Plan is to provide the Agile Project Core Team (A-PCT) with the following: - One central source for information regarding the iteration goal. - A visualisation of the scope of an iteration. - Evaluation results. - An indicator of the current team's progress and a forecast for the iteration work completion. Work items assigned to an iteration do not necessarily have the same priority. Once Work Items have been assigned to the iteration, the team ensures that they can complete all work, regardless of original work item priorities (except for items that represent blocking dependencies with items from other teams). Deciding what to develop first in an iteration will vary across projects and iterations. Work Items can be part of a feature (functional unit) that should represent a recognisable and valuable part of the solution. The Work items are then decomposed in the corresponding tasks required to complete them. | Key Participants | Description | |:------------------------- |:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [[Project Manager (PM)]] | Accountable for ensuring the Iteration Plan goal is aligned with the Release Plan strategy and the Project Charter. | | Team Coordinator (TeCo) | Responsible for the development of the Iteration plan, assisted by the Product Owner (PrOw), providing the Iteration goal and the <br> remaining Agile Team Members (ATeM), providing information on what items will be implemented and how. | | Agile Team Member (ATeM) | Supports the Team Coordinator (TeCo) by providing inputs related to the feasibility of the plan, including which items can be implemented during the iteration. | | Architecture Owner (ArOw) | Supports the Team Coordinator (TeCo) by providing relevant information regarding potential architecture risks/issues that may impact the iteration plan. | | Product Owner (PrOw) | Consulted by the Team Coordinator (TeCo) to provide the iteration goal and a prioritised Work Items List (WIL) - the main input for the iteration plan. | | Business Manager (BM) | Business Manager (BM) Informed by the Product Owner (PrOw) and Project Manager (PM) on the iteration goals and what can be expected <br> by the end of the Iteration. | **Guidelines** - **One Iteration, one (Iteration) Plan** – Every Iteration starts with the Iteration Planning ceremony, where a strategy to reach an iteration goal is defined, and ends with the Iteration Review ceremony, where the delivered work’s result is evaluated towards the defined iteration goal. This information is captured in the corresponding and unique Iteration Plan. - **Start with the Iteration Planning ceremony** – The strategy defined by Agile Project Core Team (A- PCT) during the Iteration Planning ceremony provides critical information to the Iteration Plan, such as the iteration period, the iteration goal, the work items to implement, dependencies, associated risks, etc. The initial version of the Iteration burndown chart18 is also generated based on the inputs coming from this critical ceremony. - **It’s a living artefact** – The Iteration Plan is not a static artefact since some of its elements will be frequently updated. For example, the burndown chart must constantly reflect the iteration’s situation based on the planned and achieved work. The iteration’s scope is another example of an element that may be subject to revision, generating several changes in the Iteration Plan. - **Close with the Iteration Review** – The Iteration Review ceremony presents final conclusions about the work done by the Agile Project Core Team (A-PCT) during the iteration. Was the Iteration Goal achieved? Were there any work items not delivered successfully? If so, what was the reason? Collected during this ceremony, this invaluable information is recorded as part of the Iteration Plan for present and future reference. - **Use of software tools to create and maintain an Iteration Plan** – Before compiling the different types of information described in the previous points to a standard, manually generated document, one should investigate alternative software tools that may save a significant amount of time. ![[7.2.2.3 Iteration Plan — Inputs and main roles.png]]