### 5.4.2 Structure of an Iteration Review Following the agile principle “Working software is the primary measure of progress”, the core part of this ceremony is a demo conducted by the Agile Team Members (ATeM) where they expose the iteration’s achievements to the business stakeholders. However, to ensure a successful ceremony, preparation needs to be done, conclusions need to be taken and a set of actions to be planned as the outcome of the Iteration Review. To ensure an effective meeting, the Iteration Review has three different moments that must be carefully prepared: - **Align/Review Expectations** - A brief ten to fifteen minute presentation to align the expectations on the contents of the Demo. Should include a comparison between what was promised versus what was delivered. - **Demo** - Following a specific set of guidelines, either the Product Owner (PrOw) or another Agile Team Member (ATeM) team member, demonstrates the progress achieved during the iteration. - **Wrap-up + Work items List (WIL) Review** - After the demo, conclusions should be reached, followed by a discussion on impacts to the Work items list (WIL). ![[5.4 The structure of an Iteration Review.png]] These moments are further explained in the following sections. #### 5.4.2.1 Align Expectations The Agile Project Core Team (A-PCT) seeks to avoid misaligned expectations with the business stakeholders, especially during an Iteration Review. Misalignment leads to frustration leading to a lack of objectivity, which may affect the meeting’s outcome. Therefore, PM2-Agile recommends introducing one of the Agile Team Members (ATeM) to tackle the key points that will drive the demo. This is a 10 -15 minutes presentation that must address the following items: - **Scope** - Describe the Iteration goal and the corresponding Work Items that the Agile Project Core Team (ATeM) committed at the iteration’s start. - **Achieved** - The work items the Agile Project Core Team (A-PCT) believes it has completed and will demonstrate. - **Not Achieved** - The work items the Agile Project Core Team (A-PCT) could not deliver. This can be discussed unless related to risks and issues that are discussed after. - **New/Dropped Items** - It’s imperative to communicate this information to the business stakeholders, especially if new items were added to the work items list (WIL). - **Difficulties/Impediments/Risks** - Quickly identify these items and describe how they affected the team and impacted Work Items. With this quick introduction (which will likely trigger some questions), the Agile Project Core Team (A-PCT) ensures that everyone is now on the "the same page" on the Iteration Review’s ceremony. This activity ensures everyone is ready for the demo. #### 5.4.2.2 Demo the Solution The demo is, on its own merit, the most critical moment of this ceremony. This is when the Agile Project Core Team (A-PCT) exposes the business stakeholders and the Product Owner (PrOw) to the iteration’s outcome. In order to properly facilitate and conduct a demo, some decisions need to be taken and agreed in advance. - **Single point demo or hands-on demo** - A single point demo means that the Product Owner (PrOw) or another Agile Team Member (ATeM) will conduct the demo, while a hands-on session will allow the business stakeholders to “feel” and use the solution being demonstrated. PM2-Agile does not suggest a specific option, since it will depend on the stakeholders’ will and commitment. Having the stakeholders using and trying is optimal for demo delivery. However, a hands-on approach requires more effort to facilitate and conduct the demo, as everyone must be focused on what is necessary to validate during the entire session. - **Who will be conducting the Demo** – The Product Owner is a good candidate to conduct the demo. She is empowered and closely involved with the business stakeholders, who may feel more comfortable if she is conducting the demo. However, it is also a good approach if an Agile Team Member (ATeM) conducts the Demo, as the Product Owner (PrOw) becomes available to assist the stakeholders during the session. - **Decide which test scenarios to use** –The test cases created by the Agile Team Members (ATeM) during development should be used to evaluate the demo. However, the business stakeholders may want to create and user their own scenarios. If that’s the case, the Agile Project Core Team (A- PCT) has to guarantee that those tests are aligned with the acceptance criteria of the stories, since that’s what will guide the demo. Nevertheless and whatever the scenario is, this must be previously agreed so that the meeting facilitator can prepare the meeting properly. With these elements properly defined and agreed, it should be clear for the Agile Project Core Team (A-PCT) who and how the demo will be facilitated. Even with a well-defined facilitation plan, it’s also very important to have a proper structure for the demo. Since several items are presented, each with its own acceptance criteria, its own test cases and with several different questions that may pop-up, the Agile Project Core Team (A-PCT) needs to guarantee that all these items are properly demonstrated, and the feedback is captured. To help achieving this, PM2-Agile foresees the following sequence of steps for each demonstrated item. - **Identify and describe the item** – The person conducting the demo starts by introducing the item that will be demonstrated. This includes the description of the work item and the corresponding acceptance criteria. She can conclude with the indication of the several test cases that will be executed. - **Demo the Item** – While demoing the item, each test scenario should be properly identified, including the acceptance criteria (very important) that the scenario is targeted to validate. This helps the stakeholders to clearly see the usefulness of the tests being made and will give them more confidence when they need to accept the item. - **Ask for confirmation of the item** – If all the acceptance criteria are met, the Agile Team Members (ATeM) should ask for the confirmation that the item does exactly what was agreed to. In other words, to mark that item as DONE. If, on the other hand, some acceptance criteria are not met or there are new things to be made, they should be noted and discussed in the wrap-up step. As mentioned before, these steps must be repeated for each item that needs to be demonstrated. As soon as all the items are done, the ceremony can proceed to the next step: Wrap-up and Work items List (WIL) Review. #### 5.4.2.3 Wrap up and Work Items List (WIL) review During the solution demo, a lot of information is exchanged. As such, it’s very important to leave enough time for consolidation, since these conclusions are used to keep a refined and prioritised Work Items List (WIL) and to prepare for the next Iteration Planning meeting. After the demo is finished, an Agile Team Member (ATeM) or even the Team Coordinator (TeCo) must go through each demonstrated item and check the following: - Was the Item Accepted or not? If not, it should be clear what was the reason (acceptance criteria not verified, bug was found, etc). - Is it a new Item? Is it an Item that will be dropped from the Work Items List (WIL)? - For the new items, clarification must be requested to the Product Owner (PrOw) and stakeholders. This will allow the Agile Team Members (ATeM) to provide high level estimates during the Work Items List (WIL) review that comes immediately after. Once the Agile Project Core Team (A-PCT) consolidates all the items, they can proceed to the Work Items List (WIL) refinement, based on the knowledge gained from the meeting so far. This activity is quite relevant because it will provide a Work Items List (WIL) that is ready to use in the Iteration Planning meeting. This means going over the following: - Work Items that did not meet the acceptance criteria – Should they return to the top of the Work Items List (WIL), ready to be included and corrected in the next iteration or shall they be postponed for a future iteration? - New Items in the Work Items List (WIL) – With the information provided by the Product Owner (PrOw) and the business stakeholders, the Agile Team Members (ATeM) shall agree (whenever possible) on relative estimates for each new added item. This will help the Product Owner (PrOw) to prioritise them in the Work Items List (WIL). Depending on the number of new stories and the feedback received, the Agile Team Members (ATeM) may not be able to finish their analysis during this meeting. When they believe this will be the case, they should definitely focus on the items that, in theory, will be tackled in the next Iteration. All the rest can be handled after the Iteration Review, as part of the Release Planning exercise of the next iteration. When the Iteration Review is finished (or a couple of hours after, if the Agile Team Members (ATeM) need to perform some estimates after the meeting), the Agile Project Core Team (A-PCT) must have a properly refined and prioritised Work Items List (WIL) which they feel comfortable to use as the basis for the planning exercise of the next iteration. The success of an Iteration Review is not solely linked to the number of Work Items approved. In fact, ensuring that the team collected solid and relevant feedback that will guide them towards the needs of the business stakeholders is, without any doubt, the best indicator of success.